This document outlines Suitable's accessibility conformance information, following the structure of the Voluntary Product Accessibility Template (VPAT). It is intended to support administrators and decision-makers in assessing alignment with Section 508 of the Rehabilitation Act and WCAG 2.1 Level A/AA standards.
Table of Contents
Accessibility Statement
At Suitable, we are devoted to building a new kind of higher education. One that is more personalized, outcome-focused, and accessible for all students. Suitable is committed to ensuring its platform is inclusive and accessible for the diverse needs of our users.
Suitable is steadfast in our commitment to meeting WCAG 2.1 Level A/AA and the standards laid out in Section 508 of the Rehabilitation Act. Through regular internal audits and accessibility testing of our mobile and web applications, we continually refine and enhance accessibility features. Additionally, we welcome feedback on the accessibility of our platform. Please email us at support@suitable.co with any questions or concerns.
Suitable Accessibility Conformance Report - WCAG Edition
(Based on VPAT Version 2.4)
Name of Product/Version: Suitable Web Application v2.125.0
Report Date: March 2025
Contact Information: support@suitable.co
Evaluation Methods Used: This conformance report is the result of using automated, manual, and functional accessibility test methods on the web desktop platform. As noted below, testing was performed to the Web Content Accessibility Guidelines (WVAG) 2.1 Level AA standard. The following tools were used as a part of the test methods:
- Desktop Browsers: Chrome and Safari
- Assistive Technologies for Manual Testing: NVDA and VoiceOver
- Automated Testing Tools: Axe Accessibility Testing Tool
- Contrast Checker: WebAIM Contract Checker
Applicable Standards/Guidelines
This report covers the degree of conformance for the following accessibility standard/guidelines:
- Web Content Accessibility Guidelines 2.0 (Level A/AA)
- Web Content Accessibility Guidelines 2.1 (Level A/AA)
Terms
The terms used in the Conformance Level information are defined as follows:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of the product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
WCAG 2.1 Report
Note: When reporting on conformance with the WCAG 2.1 Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.1 Conformance Requirements.
Table 1: Success Criteria, Level A
Criteria | Conformance Level | Remarks & Explanations |
1.1.1 Non-text Content (Level A) | Supports | Images either have descriptive alt text or empty alt text if the image is considered to be decorative. |
1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
1.2.2 Captions (Prerecorded) (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
1.3.1 Info and Relationships (Level A) | Supports |
The site has been developed/tested to be programmatically determinable by assistive technologies, i.e. screen-readers. |
1.3.2 Meaningful Sequence (Level A) | Supports | Our pages adhere to expected semantic structuring when using header tags and other related HTML elements. |
1.3.3 Sensory Characteristics (Level A) | Supports | Our graphical symbols contain alt text as needed. |
1.4.1 Use of Color (Level A) | Supports | Color is not the sole means of conveying information, it is merely supplementary. For example, required form elements have text cues to denote their priority. |
1.4.2 Audio Control (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
2.1.1 Keyboard (Level A) | Supports | Manual testing has been done by team members and customers to confirm that the site is navigable via keyboard. |
2.1.2 No Keyboard Trap (Level A) | Supports | Manual testing has been done by team members and customers to confirm that all modals trap focus within a dialog box. |
2.1.4 Character Key Shortcuts (Level A 2.1 only) | Supports | There are no special character key shortcuts currently in the application, therefore the success criterion is satisfied. |
2.2.1 Timing Adjustable (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
2.2.2 Pause, Stop, Hide (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
2.3.1 Three Flashes or Below Threshold (Level A) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
2.4.1 Bypass Blocks (Level A) | Supports | A bypass button exists as the first tabbable element on the page that when pressed focuses the main content of the page, thus bypassing the navigation menu. |
2.4.2 Page Titled (Level A) | Supports | Page titles are dynamic and contextual to the content of the page. |
2.4.3 Focus Order (Level A) | Supports | Manual testing has been performed to ensure that elements receive focus in an order that preserves meaning and operability where applicable. |
2.4.4 Link Purpose (In Context) (Level A) | Supports | Manual testing has been performed to ensure that link purposes are explicit and have clear meaning within the given context. |
2.5.1 Pointer Gestures (Level A 2.1 only) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
2.5.2 Pointer Cancellation (Level A 2.1 only) | Supports | The down-event of the pointer is not used to execute any part of the function. Buttons and clickable element actions are executed upon the up-event of the pointer. |
2.5.3 Label in Name (Level A 2.1 only) | Supports | Control inputs and buttons that have label texts have matching accessible programmatic names. “aria-label” and “aria-labelled-by” attributes are used for some cases, as well as combining the usage of “id” and “for” attributes for matching the visual text label with the control’s programmatic name. |
2.5.4 Motion Actuation (Level A 2.1 only) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
3.1.1 Language of Page (Level A) | Supports | The default human language of each web page can be programmatically determined. |
3.2.1 On Focus (Level A) | Supports | There are no known elements of the site that change context upon focus. |
3.2.2 On Input (Level A) | Supports | There are no known elements of the site that suddenly change context upon input without user confirmation. All form elements have confirm/submit buttons that must be pressed before the app changes context in any way. |
3.3.1 Error Identification (Level A) | Supports |
Form elements that do not meet their respective validation requirements (i.e. a required field is blank, a text input is too long/short, etc.) have error text that is displayed in line with the element. Other expected errors display text in an error dialog modal or an error “banner”. The banner is a <div> element that is appropriately labelled with ARIA to be an alert element containing error text. |
3.3.2 Labels or Instructions (Level A) | Supports |
User inputs contain clear and descriptive label texts with associated ARIA attributes such as “aria-labelled-by”, “aria-described-by”, and other various ARIA attributes. |
4.1.1 Parsing (Level A) | Supports | Site contains complete start and end tags and are nested according to specification. Manual testing has been performed with various screen-readers to ensure that these assistive technologies can parse the html appropriately. |
4.1.2 Name, Role, Value (Level A) | Supports |
User-interface components properly express focus/selection. The site utilizes the JavaScript frameworks “Angular” and “React”, which has a lot of these compliances built in that the site takes advantage of. We also have an internal convention for inputs that require special care when expressing selection/state such as dropdowns, pop out buttons, tab views, etc. |
Table 2: Success Criteria, Level AA
Criteria | Conformance Level | Remarks & Explanations |
1.2.4 Captions (Live) (Level AA) | Supports |
There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
1.2.5 Audio Description (Prerecorded) (Level AA) | Supports |
There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
1.3.4 Orientation (Level AA 2.1 only) | Supports |
There are no restrictions on content orientation within the application.
|
1.3.5 Identify Input Purpose (Level AA 2.1 only) | Supports | There are not many form inputs that are related to user information outside of the account settings where users can update their contact email, name, and password. All of these inputs do support autocomplete with compatible browsers as well as explicit text labels. |
1.4.3 Contrast (Minimum) (Level AA) | Supports | We worked with a 3rd party auditor to resolve all previously existing contrast issues and regularly use our contrast checker tool during design and development when implementing new features. |
1.4.4 Resize text (Level AA) |
Supports | Text can be resized using various common browsers. The site is designed to be responsive, meaning that surrounding elements will conform to the size of the screen and still be displayed in a user friendly fashion. This responsive design also applies to when the text is resized. |
1.4.5 Images of Text (Level AA) | Supports |
There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
1.4.10 Reflow (Level AA 2.1 only) | Supports | The application is designed to be fully responsive based upon viewport and therefore supports reflow. The application leverages CSS media queries, max-width, flexbox, as well as Bootstrap grid styling to achieve responsive styling. |
1.4.11 Non-text Contrast (Level AA 2.1 only) | Supports | We worked with a 3rd party auditor to resolve all previously existing contrast issues and regularly use our contrast checker tool during design and development when implementing new features. |
1.4.12 Text Spacing (Level AA 2.1 only) | Supports | Verified our web application views meet the spec via a text spacing bookmarklet tool. We occasionally use this tool to audit the site to ensure any new additions pass the criteria. If any deficiencies are noted we itemize them and place them on our accessibility roadmap. |
1.4.13 Content on Hover or Focus (Level AA 2.1 only) | Supports | Tooltips and pop out menus are designed to be dismissable, hoverable, and persistent according to the spec. |
2.4.5 Multiple Ways (Level AA) | Supports |
The site contains a navigation bar that provides links to all of the various pages that the site has to offer. In the “Activities” page, there is a text input search bar as well as multiple tabs to help with filtering and finding activities. There are various back buttons that are utilized throughout the site when inspecting certain detailed pages, as well as a “Dashboard” button in all of the page headers that can bring the user back home at all times. |
2.4.6 Headings and Labels (Level AA) | Supports | |
2.4.7 Focus Visible (Level AA) | Supports |
A visual border is displayed around focused elements. This is implemented via the AngularJS framework and the related ARIA tools that come with it. |
3.1.2 Language of Parts (Level AA) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
3.2.3 Consistent Navigation (Level AA) | Supports |
The main navigation bar is present on all views of the site and the ordering of the options do not change. |
3.2.4 Consistent Identification (Level AA) | Supports | All user-interface components that share functionality will also share the same (or similar) identification. Examples of these being various form inputs, buttons, icons, and error messages. Additional context is applied to the aria labels as needed. |
3.3.3 Error Suggestion (Level AA) | Supports |
Error messages for form inputs that fail validation and have a suggestion for correction will be displayed in-line with the error message and form input. Examples of this being entering a valid email address, adding a valid date/time string, and meeting minimum/maximum requirements for text inputs and selections. |
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Supports | There is no content to which a success criterion applies, therefore the success criterion is satisfied. |
4.1.3 Status Messages (Level AA 2.1 only) | Supports | Important status messages that are not given focus have proper ARIA roles and will be read aloud by a screen-reader when applicable. Examples: a banner message being displayed indicating an action took place, number of search results is announced when searching a list of elements. |
Comments
0 comments
Please sign in to leave a comment.