Organization of WCAG 2.1
An accessibility standard recognized in many countries is the WCAG (Web Content Accessibilty Guidelines) version 2. These guidelines are one of the many web technology guidelines sponsored by the W3C (World Wide Web Consortium). They cover the needs for users with a variety of disabilities and include guidelines for
- Contrast between text/graphics and the background
- Use of semantic headings and clear link text
- Video captions and audio description
- Image ALT text and correct form labeling
- Alternate access in tools via keyboard and simplified gesture
- Usable text in different viewports
- Accessible table structure
- And other guidelines
Priority Levels A, AA, AAA
Each specific guideline is tagged with a priority level A (highest priority), AA and AAA. Penn State, most U.S. universities, the U.S. federal government and other U.S. and international organizations mandate adherence to levels A and AA only.
POUR Model for Guidelines
Below is a list of principles summarizing WCAG 2.1 principles and guidelines with simple implementation guidelines and links on where to find more details. These guidelines are not a list of HTML "dos and don’ts", but rather a list of guidelines that must be followed in order to optimize access for users with different disabilities.
The How to Implement links provides some recommendations from the W3C on how the guidelines may be implemented in HTML and other technology. Note that not every technology may be covered in these guidelines.
The main guidelines are organized into four groups 1-4 organized by needs for
- Perception (Guidelines 1.1 to 1.4)
- Operation (Guidelines 2.1 to 2.5)
- Understanding (Guidelines 3.1 to 1.3)
- Robustness (Guidelines 4.1)
The the first letters form the acronym POUR.
Relation of WCAG 2.1 to WCAG 2.0
WCAG 2.1 is a 2018 upgrade to the WCAG 2.0 guidelines originally published in 1998. Version 2.1 includes additions and amendments to WCAG 2.0 meaning that all guidelines from WCAG 2.0 are still in effect.
Principle 1: Perceivable
Examples of Principle 1:
- Visually impaired users must be able to receive information via sound or touch
- Hearing impaired users must be able to receive information via sight
- Low vision users must be able to receive information with alternative formatting or zoomed to larger sizes
- Color deficient users must be able to receive information without use of color
Guideline 1.1: Text Equivalent
such as large print, braille, speech, symbols or simpler language.
How to Implement 1.1
- Use ALT tags for images and text descriptions for animations, 3D models and other media. Also see the Charts and Math pages.
- Use CAPTCHA alternatives.
Guideline 1.2: Time Based Media (Audio/Video)
How to Implement 1.2
- Provide captions for video.
- Provide audio transcriptions for audio.
- Ensure that videos have sufficient audio description for those unable to see the video.
Guideline 1.3: Adaptable
How to Implement 1.3
- Use appropriate semantic markup whenever possible for HTML documents, including semantic headings and styles.
- Use appropriate markup for table headers.
- Use appropriate markup, including form LABELS and other techniques, to identify form and application controls.
- Preserve the visual sequence of content even with disabled styles.
- Content is usable on mobile devices when the screen is oriented vertically or horizontally.
- If content is magnified, it can be viewed without horizontal scrolling.
- All content is read aloud in an appropriate reading order by screen readers.
Guideline 1.4: Distinguishable
How to Implement 1.4
- Ensure appropriate contrast between the background and the text, graphics, charts or interface elements.
- Ensure that content is distinguishable independent of color.
- Avoid automatically-playing audio, slideshows and animation. Provide play buttons instead.
- Use CSS formatting instead of graphics to format text whenever possible
- Use responsive/fluid design techniques to ensure that text can be read without horizontal scrolling in multiple display sizes.
- Ensure that content opened with a hover effect does not interfere with other content and can easily be opened or closed by all users regardless of manual dexterity or visual acuity.
Principle 2: Operable
Examples of Principle 2:
- Functions triggered via mouse gesture are also available via a keyboard
- Functions triggered by a complex gesture on a touch device are also available by an alternate method such as a button or simplified gesture.
- All users are given sufficient time to read and use content.
- Content does not induce seizures.
- Users are given mechanisms to skip repetitive content.
- Landmarks are provided to assist in screenreader navigation (e.g. meaningful page title, semantic headings, ARIA landmarks) meaningful headers and meaningful and unique link text.
Guideline 2.1: Keyboard Accessible
How to Implement 2.1
- All form and application controls can be operated from a keyboard. For example:
- Arrows keys can control sliders, or numbers can be entered to set parameters.
- Tab keys can be used to be navigate between form fields and buttons.
- The ESC key can be used to close a window, menu or pop-up box.
- Keyboard commands can be used to activate and operate video players.
- Keyboard commands can be used to close and control windows.
- Keyboard shortcuts should include a non-printable character (e.g. arrow keys, CONTROL/ALT/OPTION+char, or ENTER/TAB/ESC).
Guideline 2.2: Enough Time
How to Implement 2.2
- When appropriate:
- A user can pause
- content in a rotating carousel or other similar technology
- video or animated content (when it’s longer than 5 seconds)
- scrolling text (when it’s longer than 5 seconds)
- The user is warned of time limit expiration and permitted to extend time.
- Users have the option to block an automatic update of content.
- A user can pause
Note: Exceptions are allowed when changes in timing would interfere with an essential function.
Guideline 2.3: Seizures
How to Implement 2.3
- Flashing objects should be avoided or limited to 3 flashes per second.
- Exceptions are allowed for flashes below the general or red flash threshold.
Guideline 2.4: Navigable
How to Implement 2.4
- Navigation cues are provided to assist in screen reader navigation such as
- Users are given mechanisms to skip repetitive content.
- Keyboard users are able to see a cursor or other indicator of position on the screen (i.e. which item has keyboard focus.
- Multiple paths are provided to navigate through Web site content.
Guideline 2.5: Input Modalities
How to Implement 2.5
Provide alternatives such as buttons or simplified gestures for
- Device gestures with complex paths
- Actions triggered by shaking or moving a device
Principle 3: Understandable
Examples of Principle 3:
- Navigation labels and placement are consistent across a document or web site.
- Status messages and other alerts:
- are detectable to all users including those on a screen reader
- can be closed with a keyboard as needed
- remain open until closed by the users
- do not block
- Form labels are announced with the same text as would be seen by other users.
- Mechanisms are available to detect form submission errors and provide clear instructions to users on fixing errors.
- Separate Submit or Go buttons/links are provided to initiate page changes (versus autosubmit upon selection).
- Language of text is identified as well as changes in page language.
Guideline 3.1: Readable
How to Implement 3.1
- Identify language of text or subsection of text with a language code.
- Identify and define unusual words or jargon.
Guideline 3.2: Predictable
How to Implement 3.2
- Avoid unannounced pop up windows.
- Avoid disabling the browser’s Back button.
- Provide a separate Submit or Go button/link to initiate page changes (versus autosubmit upon selection).
- Allow automatic slideshows, videos and scrolling/blinking text to be paused.
- Give users the option to block automatic updates of content.
Guideline 3.3: Input Assistance
How to Implement 3.3
- Provide appropriate form field validation.
- Provide clear labels for form and application controls.
- Provide usable instructions for entering information into forms and applications (preferably before the form field).
- Provide clear and usable error messages identifying the location of error and information for correcting it.
Principle 4: Robust
Guideline 4.1: Compatible
How to Implement 4.1
- Use validated markup
- Label the name and role of all user interface components.
- Identify the value for all data fields, including parameters for interface controls.
- Ensure that alerts and notifications are detectable on a screen reader and other devices.