Web accessibility is vital for people with disabilities and benefits many others. The W3C Web Accessibility Initiative (WAI) provides guidelines, notably the Web Content Accessibility Guidelines (WCAG). WCAG is based on four POUR principles: Perceivable, Operable, Understandable, and Robust, ensuring content is accessible, usable, and compatible across technologies.
“Accessibility is a necessity for people with disabilities, and is helpful and often necessary for many others.”
The W3C Web Accessibility Initiative (WAI) guidelines for digital accessibility, include:
- Web Content Accessibility Guidelines (WCAG)
- Authoring Tool Accessibility Guidelines (ATAG)
- User Agent Accessibility Guidelines (UAAG)
POUR Principles
- Perceivable – Information can be presented in different ways.
- Provide text alternatives for non-text content.
- Provide captions and other alternatives for multimedia.
- Create content that can be presented in different ways, including by assistive technologies, without losing meaning.
- Make it easier for users to see and hear content.
- Operable – Functionality can be used in different modalities.
- Make all functionality available from a keyboard.
- Give users enough time to read and use content.
- Do not use content that causes seizures or physical reactions.
- Help users navigate and find content.
- Make it easier to use inputs other than keyboard.
- Understandable – Information and functionality is understandable.
- Make text readable and understandable.
- Make content appear and operate in predictable ways.
- Help users avoid and correct mistakes.
- Robust – Content can be interpreted reliably by a wide variety of browsers, media players, and assistive technologies.
WCAG
- It is a normative W3C web standard called W3C Recommendation.
- It is designed to be technology-agnostic so that it applies to different technologies (it doesn’t specify how to code a heading, list, or table. Instead, it requires that such structures are present).
- How to Meet WCAG (Quick Reference)
- Tips for Getting Started
Stable versions of WCAG supported by W3C:
- WCAG 2.1 (2018)
- It is fully backward compatible with WCAG 2.0, so that if your content conforms to WCAG 2.1 it also conforms to WCAG 2.0.
- WCAG 2.1 defines 13 Guidelines and 78 Success Criteria.
- WCAG 2.0 (2008)
- It defines 12 Guidelines under the four POUR principles.
- Conformance Levels: A, AA, and AAA.
- WCAG 2.0 defines 61 Success Criteria.
- WCAG 2 Overview
- WCAG 3.0
- It is in an exploratory phase as draft, so it is not considered as a stable version.
Perceivable
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.
This can include many types of images, such as:
- Pictures of people, and places
- Charts, diagrams, and other infographics
- Buttons and other actionable objects
- Decoration and illustrative images
Time-based media
Provide alternatives for time-based media.
There are four primary methods for providing alternatives for time-based media:
- captions: can be thought of as a transcription of dialogue for people who are Deaf and hard-of-hearing, while subtitles are essentially helper text for people who can hear the audio but may not understand what was said.
- transcripts
- audio descriptions
- sign language
Adaptable content
Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
Distinguishable content
Make it easier for users to see and hear content including separating foreground from background.
Operable
Keyboard accessible
Make all functionality available from a keyboard.
Enough time
Provide users enough time to read and use content.
Avoid seizures and physical reactions
Do not design content in a way that is known to cause seizures or physical reactions.
- Animated media must not auto-play for more than five seconds.
- Content should not flash or blink more than three times in one second, cover a large area and is very bright.
- If you plan to have animations go on longer than five seconds or play on an infinite loop, provide a way for users to pause the animation.
Navigable content
Provide ways to help users navigate, find content, and determine where they are.
- Use succinct and specific page titles.
- Separate large blocks of content, such as long text passages, into smaller ones and adding headings to each.
- Divide long forms into a series of smaller ones.
Input modalities
Make it easier for users to operate functionality through various inputs beyond keyboard.
- Design functionality in such a way, so that it accepts input from a variety of different input modalities.
- Components are designed to avoid accidental activation, for example by providing undo functionality.
- Buttons, links, and other active components are large enough to make them easier to activate by touch.
Readable content:
Make text content readable and understandable.
- Identifying the primary language of pages and of page parts.
- Explaining abbreviations, unusual words, and phrases.
- Using simple language or providing simplified alternatives.
Predictable content
Make Web pages appear and operate in predictable ways.
- Keep the navigation consistent across your website.
- Name buttons and controls consistently too.
- Avoid changing the page simply when actionable elements receive focus or input.
- Predictable and consistent functionality.
Input assistance
Help users avoid and correct mistakes.
- Descriptive instructions, error messages, and suggestions for correction.
- Context-sensitive help for more complex functionality and interaction.
- Opportunity to review, correct, or reverse submissions if necessary.
Robust
Compatible content
Maximize compatibility with current and future user agents, including assistive technologies.
- Ensuring markup can be reliably interpreted, for instance by ensuring it is valid.
- Providing a name, role, and value for non-standard user interface components.
WAI-ARIA provides Web authors with the following:
- Roles to describe the type of widget presented, such as “menu”, “treeitem”, “slider”, and “progressbar”
- Roles to describe the structure of the Web page, such as headings, and regions
- Properties to describe the state widgets are in, such as “checked” for a check box, or “readonly” for most form controls
- Properties to define live regions of a page that are likely to get updates (such as stock quotes)
- A way to provide keyboard navigation for the Web objects and events, such as those mentioned above
- WAI-ARIA Overview
Accessibility Statement
- Accessibility statements are primarily for users of your content. Usually, they will refer to accessibility statements when they encounter problems.
- Technical or legal language will likely lead to confusion and increase frustration rather than help your users.
- It is important to write in simple language rather than use the language of developers and lawyers. Make sure that the information is useful and relevant to your users.
- Accessibility Statement Generator Tool
Tools and Helpful Links
Web Accessibility Laws & Policies
The Business Case for Digital Accessibility
Web Accessibility Evaluation Tools
Contrast Checker
Before and After Demos
Photosensitive Epilepsy Analysis Tool
Dave Coding 