The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA
What are the Web Content Accessibility Guidelines (WCAG)?
- The Web Content Accessibility Guidelines (WCAG) Version 2.1, Level AA is the technical standard for state and local governments’ web content and mobile apps.
- ADA Title II’s digital compliance update sets WCAG 2.1 level AA specific technical standard that state and local governments must follow to meet their existing obligations under Title II of the ADA for web and mobile app accessibility.
- WCAG, the Web Content Accessibility Guidelines, is a set of guidelines that say what is needed for web accessibility, such as requirements for captions for videos. WCAG is developed by the World Wide Web Consortium (W3C).
- A technical standard says specifically what is needed for something to be accessible. For example, the existing ADA Standards for Accessible Design are technical standards that say what is needed for a building to be physically accessible under the ADA, such as how wide a door must be or how steep a ramp can be.
Update to ADA Title II - Nondiscrimination On The Basis Of Disability; Accessibility Of Web Information And Services Of State And Local Government Entities
- Title II of the Americans with Disabilities Act (“ADA”) was updated in April 2024, requiring all web and mobile apps offered by state and government entities to be accessible to people with disabilities. This rule covers all web and mobile apps UNF provides directly or through contractual, licensing, or other arrangements with 3rd Parties.
- The update establishes WCAG 2.1 levels A & AA as Title II’s technical compliance standard.
WCAG Success Criteria are organized by Principles and their Guidelines; each guideline includes testable success criteria.
WCAG’s four guiding principles are POUR:
- Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
- Operable: User interface components and navigation must be operable.
- Understandable: Information and the operation of the user interface must be understandable.
- Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.
Within WCAG’s four principles are 13 guidelines
-
Perceivable Guidelines
- 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
- 1.2 Time-based Media: Provide alternatives for time-based media.
- 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
- 1.4 Distinguishable: Make it easier for users to see and hear content including separating foreground from background.
-
Operable Guidelines
- 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
- 2.2 Enough Time: Provide users enough time to read and use content.
- 2.3 Seizures and Physical Reactions: Do not design content in a way that is known to cause seizures or physical reactions.
- 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.
- 2.5 Input Modalities: Make it easier for users to operate functionality through various inputs beyond keyboard.
-
Understandable Guidelines
- 3.1 Readable: Make text content readable and understandable.
- 3.2 Predictable: Make Web pages appear and operate in predictable ways.
- 3.3 Input Assistance: Help users avoid and correct mistakes.
-
Robust Guidelines
- 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
WCAG Success Criteria
Under the WCAG Guidelines there are 30 level A and 20 level AA success criteria
Each success criterion is meant to address a situation where a user with a disability (or a user of assistive technology) could encounter an accessibility barrier. Some success criteria are testable through an automated process, but many success criteria require a manual review process conducted with assistive technology to determine compliance
- Automated testing alone will catch 25 to 30% of accessibility errors; manual testing is required to catch the remaining 75 to 70% of issues.
- WCAG compliance testing is incomplete without manual testing.
WCAG 2.1 Success Criterion
| Success Criterion | Level | Summary |
|---|---|---|
| A | Provide alt text for all non-text content. | |
| A |
Provide an alternative to video-only and audio-only content. This criterion requires providing an alternative to video-only content (i.e., the video is purely visual and has no audio track) and audio-only (i.e., the audio is solely auditory and there are no accompanying visuals). This is a separate criterion from captions, because audio-only and video-only usually cannot be captioned. For example, an alternative for an audio file of two people having a conversation would be a text transcript of the conversation. Another example, an alternative to a soundless video of traffic filmed from the sky over the course of a day, would be a text description of the purpose of the video and traffic information, such as how many cars passed by, stopped at a light, or how many pedestrians crossed the street. |
|
| A |
Provide captions for videos with audio. This WCAG criterion requires including captions for pre-recorded videos; criterion 1.2.4 requires captions for live videos. A pre-recorded video is content that is filmed and edited before being shared with an audience, unlike live video, which is broadcast in real-time. |
|
|
1.2.3 - Audio Description or Media Alternative (Pre-recorded) |
A |
The intent of this criteria is to provide people who are blind or visually impaired access to visual information in video or audio presentations; this criterion describes two options to achieve this end, one is to provide all the video/audio information in text forms, such as a transcript with scene descriptions which should read like a screen play or book, and the second is to provide audio description of what's going on in video content. There is a separate level AA criterion (1.2.5) that requires audio descriptions in video content; meeting 1.2.5 will also mean you have met 1.2.3. |
| AA |
Live videos have captions provided. Live video is a method of broadcasting video content in real-time, allowing viewers to witness events as they happen without any editing or delays; this criterion requires live captioning, which is where spoken words are presented as text and displayed on a screen as the video is being played or broadcast. |
|
| AA |
Users have access to audio description for video content. This criterion requires that audio descriptions be provided for pre-recorded videos. Audio descriptions are an additional audio portion of the video with added information about what's visible on screen. During existing pauses in dialogue, audio description provides information about actions, characters, scene changes, and on-screen text that are important and are not described or spoken in the main soundtrack. Captions will cover dialogue, but visual information that's important to understand the video may not be explained through dialogue alone. For example, a screening of the Wizard of Oz with audio description will include audio describing the film changing from black and white to technicolor when Dorothy opens the door to discover Oz. |
|
| A | Information, structure, and relationships conveyed on the page can be programmatically determined or are available in text. | |
| A | If the sequence information is presented, it is essential to understand the meaning of the content; then the sequence is programmatically set on the page for assistive technology to understand the correct reading sequence. Tables and ordered lists are always meaningful sequences because if the information in a table or list is presented out of order or outside of the intended format, then information is lost. For example, when a numbered list is present, it is programmatically set into the web page so assistive technology will go through the information in the correct reading sequence it is intended to be read in. | |
| A |
Instructions for operating or understanding content do not rely on only sensory characteristics such as shape, size, visual location, or sound. Some users with disabilities are not able to perceive shape or position due to the nature of the assistive technology they use. For example, without labels, assistive technology will not recognize what button instructions are referring to if it describes a "round button" or a "button to the right." Adding a label to a round button that mentions that it is round will provide a label alternative for persons who can't visually detect the shape of the button. Assistive technology navigates pages using a linear reading order that can move forward or backward, so instructions should avoid descriptions of content being to the left or right, because those orientations are not clear to assistive technology. It is commonly understood that "above" refers to the content previous to that point in the content and "below" refers to the content after that point, so if the content being referenced is in the appropriate place in the reading order and the references are unambiguous, statements such as "choose one of the links below" or "all of the above" would conform to this Success Criterion. |
|
| AA |
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape. This criterion is specific to content accessed through a phone or tablet. An example of non-compliance would be an app that doesn't work if the phone is held in portrait mode and requires the user to hold it horizontally. Some wheelchair users have a tablet or phone affixed to a stand in a set position, making it difficult to change the position of the device. |
|
| AA | The purpose of each input field collecting information about the user can be programmatically determined when the input field serves a purpose identified in the input purposes for user interface components identified by the W3C, and the content is implemented using technologies with support for identifying the expected meaning for form input data. | |
| A |
Don't use presentations that rely solely on color. Information conveyed through or with color needs an alternative method for people who can't see or perceive color. For example, if you inform users which events are canceled by changing the event name to red, add a symbol as well, such as an asterix *, so users can tell an event is canceled by both the color and the symbol. A common error is removing underlines from links; if the only method to tell a link from body text is the color of the link, then the link is a use of color error; links need a visual indication other than color alone, such as an underline, that informs users that the text is a link. |
|
| A |
Don't play audio automatically. If a web page has any audio that plays automatically for more than three seconds, either provide a method to pause or stop the audio, or provide a method to control the audio volume separate from the computer's overall system volume level. |
|
| AA | The contrast ratio between text and background is at least 4.5:1. | |
| AA | Text can be resized to 200% without loss of content or function. | |
| AA |
Don't use images of text instead of text. Avoid using images in text. "Live" text on a page will resize and reformat itself if the page is made larger or smaller. Images of text, however, may not resize clearly, leading to fuzzy, difficult-to-read text for people who use screen magnifiers. |
|
| AA | Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for 320 CSS pixels for vertical scrolling and 256 CSS pixels for horizontal scrolling. | |
| AA |
Essential visual information for user interface components is used to indicate that content meets color contrast requirements. Non-text contrast color contrast was added in WCAG 2.1 to cover color contrast for icons and other similar items. For example, if the search feature is shown as a magnifying glass icon on a webpage, that icon needs to meet color contrast requirements. The color contrast minimum of non-text content is the same requirement as the large text color contrast minimum. |
|
| AA | Content and functionality are not lost for people with disabilities who override text spacing to read text. | |
| AA | When additional content becomes visible or hidden upon point hover or keyboard focus, the following is true: content is dismissible, hoverable, and persistent on Focus. | |
| A | All content is operable through a keyboard interface. | |
| A | Do not trap keyboard users so that they cannot navigate. | |
| A | If keyboard shortcuts are in place using only one letter, punctuation, number, or symbol character, at least one of the following is true: the shortcut can be turned off, remapped, or is only active during the Focus of an interface component. | |
| A | Provide user controls, such as a pause button, for any time limits. | |
| A | Provide user controls for moving content. | |
| A | Ensure no content flashes more than three times per second. | |
| A | Provide a 'Skip to Content' link on the page. | |
| A | Use clear, informative, and precise page titles. | |
| A | Ensure the page's content order is logical. | |
| A | Ensure every link's purpose is clear from its text context. | |
| AA |
Offer several ways to find pages within a website. For example, two ways to find a web page include providing links between pages and a search mechanism. Users can choose to use the search engine to find a page or click on the page's menu link. |
|
| AA | Use headings and labels that describe the topic or purpose. | |
| AA | Ensure keyboard focus is visible and clear with indicators. | |
| A | All functionality that uses multipoint or path-based gestures (such as requiring two fingers to move to access content) can be operated with a single pointer without path-based gestures unless essential. | |
| A |
For all functionality that can be operated using a single pointer (such as a single click or tap), the function can be canceled unless essential. This WCAG criterion is mobile-specific and related to touch screens. Someone with a disability may accidentally tap on a button without intending to. An example of this criterion is that if a close button activates with one tap, then the action can be undone. |
|
| A |
User interface components (such as link buttons) with labels that have text or images of text have labels that match the same text presented visually. For example, if the site has a button that has the word "account" visible, the button's label needs to match the word "account." The label can't be something different than what is visually on screen. If a button's label doesn't match, assistive technology that runs on voice commands may not be able to complete a task. For example, if a button says "close" visually, but its label is "exit," a voice command may tell the technology to "close" the window, but it won't be able to find and activate "close" because the label is "exit." |
|
| A |
This criterion is primarily for mobile. It relates to movement requirements and alternatives. For example, if an app allows users to shake their device to open a window, then there must be an option to turn off the shake option, and there is an alternative method to open the window without requiring a specific movement. Functionality that can be operated by device motion or user input can also be operated by an alternative method and disabled to prevent accidental actuation. |
|
| A |
The default human language of the page is programmatically determined. The official W3C recommendation is to declare the primary language for each Web page with a <…lang => attribute in the <html> Declaring an English Page <html lang="en"> ... </html> |
|
| AA |
Inform users when the human language on a page changes. For example, if a portion of the webpage switches from English to Spanish, then the Spanish portion of the webpage needs to be coded to identify the language change. View the Code <p> This sentence is in English. </p> <p lang="es"> Esta frase es en espanol </p> Guide: https://accessibility.psu.edu/foreignlanguages/langtaghtml/ |
|
| A | When a page component receives Focus, it does not initiate a change of context for the user. | |
| A | Setting changes do not change automatically without informing users that a change will occur once prompted. | |
| AA |
Use menu navigation and format consistently throughout the website. For example, if your home page button is in the top left corner of every webpage, don't suddenly move it to the right corner for one page on your site. It's essential that navigation and formatting be reliable and consistent. |
|
| AA |
Use and identify icons and buttons consistently. A strategy that people who use screen readers use when operating a website is to rely heavily on their familiarity with functions that may appear on different Web pages. If identical functions have different labels on different Web pages, the site will be considerably more difficult to use. It may also be confusing and increase the cognitive load for people with cognitive limitations. Therefore, consistent labeling will help. For example, the same common "save" icon is used throughout the site, where the option to save a page is available across various web pages. |
|
| A |
When an input error is automatically detected, that error is identified and described to the user in text. The intent of this Success Criterion is to ensure that users are aware that an error has occurred and can determine what is wrong. The error message should be as specific as possible. For example, if the user fails to enter the proper abbreviation for a state or region in a form, the user is made aware of the abbreviation error. |
|
| A | Labels or instructions are provided when content requires user input. | |
| AA |
Provide suggested fixes when users make input errors. 3.3.3 Error Suggestion expands on the requirements of 3.3.1 Error Identification; error identification requires errors to be pointed out, which error suggestion requires that suggestions for repair be provided to users when errors are identified. |
|
| AA |
Reduce the risk of input errors for sensitive data. The intent of this Success Criterion is to help users with disabilities avoid serious consequences as a result of a mistake when performing an action that cannot be reversed. For example, purchasing non-refundable airline tickets or submitting an order to purchase stock in a brokerage account are financial transactions with serious consequences |
|
| A | Ensure there are no major code errors. | |
| A | Build all page elements for accessibility. | |
| AA | Messages about status changes (such as adding an item to a cart) can be presented to the user without receiving Focus. |