Accessibility Principles
Web accessibility standards
Web accessibility relies on several components that work together. Some of these include:
- Web content - refers to any part of a website, including text, images, forms, and multimedia, as well as any markup code, scripts, applications, and such.
- User agents - software that people use to access web content, including desktop graphical browsers, voice browsers, mobile phone browsers, multimedia players, plug-ins, and some assistive technologies.
- Authoring tools - software or services that people use to produce web content, including code editors, document conversion tools, content management systems, blogs, database scripts, and other tools.
More about web accessibility standards
These components inter-relate and support each other. For instance, web content needs to include text alternatives for images. This information needs to be processed by web browsers and then conveyed to assistive technologies, such as screen readers. To create such text alternatives, authors need authoring tools that support them to do so. More background is provided in Essential Components of Web Accessibility.
Standards play a vital role in defining accessibility requirements for each of these components. Some accessibility requirements are easy to meet, yet understanding the basics of how people with disabilities use the Web helps implement them more effectively and efficiently. Some aspects of accessibility require more technical skills or advanced knowledge of how people use the Web. In all cases, involving users early and throughout your web projects will make your work better and easier.
The W3C Web Accessibility Initiative (WAI) provides a set of guidelines that are internationally recognized as the standard for web accessibility. These include:
- Web Content Accessibility Guidelines (WCAG)
- User Agent Accessibility Guidelines (UAAG)
- Authoring Tool Accessibility Guidelines (ATAG)
There is also a WAI specification for Accessible Rich Internet Applications (WAI-ARIA), which include dynamic content and advanced user interface controls developed with Ajax, JavaScript, and related web technologies.
Perceivable information and user interface
Text alternatives for non-text content
Text alternatives are equivalents for non-text content. Examples include:
- Short equivalents for images, including icons, buttons, and graphics
- Description of data represented on charts, diagrams, and illustrations
- Brief descriptions of non-text content such as audio and video files
- Labels for form controls, input, and other user interface components
Text alternatives convey the purpose of an image or function to provide an equivalent user experience. For instance, an appropriate text alternative for a search button would be “search” rather than “magnifying lens”.
Text alternatives can be presented in a variety of ways. For instance, they can be read aloud for people who cannot see the screen and for people with reading difficulties, enlarged to custom text sizes, or displayed on braille devices. Text alternatives serve as labels for controls and functionality to aid keyboard navigation and navigation by voice recognition (speech input). They also act as labels to identify audio, video, and files in other formats, as well as applications that are embedded as part of a website.
Accessibility requirements related to text alternatives (links to technical specification)
WCAG
UAAG
ATAG
- Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
- Guideline A.2.1: (For the authoring tool user interface) Make alternative content available to authors
- Guideline A.2.2: (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined
- Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents
- Part B. Support the production of accessible content
Stories related to text alternatives
- Alex, reporter with repetitive stress injury
- Martine, online student who is hard of hearing
- Ilya, senior staff member who is blind
- Preety, middle school student with Attention Deficit Hyperactivity Disorder and Dyslexia
- Yun, retiree with low vision, hand tremor, and mild short-term memory loss
- Kaseem, teenager who is deaf and blind
Captions and other alternatives for multimedia
People who cannot hear audio or see video need alternatives. Examples include:
- Text transcripts and captions for audio content, such as recordings of a radio interview
- Audio descriptions, which are narrations to describe important visual details in a video
- Sign language interpretation of audio content, including relevant auditory experiences
Well-written text transcripts containing the correct sequence of any auditory or visual information provide a basic level of accessibility and facilitate the production of captions and audio descriptions.
Accessibility requirements related to multimedia (links to technical specification)
WCAG
UAAG
ATAG
- Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
- Guideline A.2.1: (For the authoring tool user interface) Make alternative content available to authors
- Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents
- Part B. Support the production of accessible content
Stories related to multimedia
Content can be presented in different ways
For users to be able to change the presentation of content, it is necessary that:
- Headings, lists, tables, input fields, and content structures are marked-up properly
- Sequences of information or instructions are independent of any presentation
- Browsers and assistive technologies provide settings to customize the presentation
Meeting this requirement allows content to be correctly read aloud, enlarged, or adapted to meet the needs and preferences of different people. For instance, it can be presented using custom color combinations, text size, or other styling to facilitate reading. This requirement also facilitates other forms of adaptation, including automatic generation of page outlines and summaries to help people get an overview and to focus on particular parts more easily.
Accessibility requirements related to adaptability (links to technical specification)
WCAG
UAAG
- Guideline 1.4 - Text configuration
- Guideline 1.5 - Volume configuration
- Guideline 1.6 - Synthesized speech configuration
- Guideline 1.7 - User style sheet configuration
- Guideline 1.9 - Alternative views
- Guideline 1.10 - Element information
ATAG
- Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
- Guideline A.2.2: (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined
- Guideline A.3.7: (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents
- Part B. Support the production of accessible content
Stories related to adaptability
- Lee, online shopper with color blindness
- Alex, reporter with repetitive stress injury
- Ilya, senior staff member who is blind
- Preety, middle school student with Attention Deficit Hyperactivity Disorder and Dyslexia
- Yun, retiree with low vision, hand tremor, and mild short-term memory loss
- Luis, supermarket assistant with Down syndrome
- Kaseem, teenager who is deaf and blind
Content is easier to see and hear
Distinguishable content is easier to see and hear. Such content includes:
- Color is not used as the only way of conveying information or identifying content
- Default foreground and background color combinations provide sufficient contrast
- When users resize text up to 400% or change text spacing, no information is lost
- Text reflows in small windows (“viewports”) and when users make the text larger
- Images of text are resizable, replaced with actual text, or avoided where possible
- Users can pause, stop, or adjust the volume of audio that is played on a website
- Background audio is low or can be turned off, to avoid interference or distraction
Meeting this requirement helps separate foreground from background, to make important information more distinguishable. This includes considerations for people who do not use assistive technologies and for people using assistive technologies who may observe interference from prominent audio or visual content in the background. For instance, many people with color blindness do not use any particular tools and rely on a proper design that provides sufficient color contrast between text and its surrounding background. For others, audio that is automatically played could interfere with text-to-speech or with assistive listening devices (ALDs).
Accessibility requirements related to distinguishability (links to technical specification)
WCAG
UAAG
- Guideline 1.3 - Highlighting
- Guideline 1.4 - Text configuration
- Guideline 1.5 - Volume configuration
- Guideline 1.6 - Synthesized speech configuration
- Guideline 1.7 - User style sheet configuration
- Guideline 1.8 - Orientation in viewports
- Guideline 1.9 - Alternative views
- Guideline 1.10 - Element information
ATAG
Stories related to distinguishability
Operable user interface and navigation
Functionality is available from a keyboard
Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including form controls, input, and other user interface components.
Keyboard accessibility includes:
- All functionality that is available by mouse is also available by keyboard
- Keyboard focus does not get trapped in any part of the content
- Web browsers, authoring tools, and other tools provide keyboard support
Meeting this requirement helps keyboard users, including people using alternative keyboards such as keyboards with ergonomic layouts, on-screen keyboards, or switch devices. It also helps people using voice recognition (speech input) to operate websites and to dictate text through the keyboard interface.
Accessibility requirements related to keyboard accessibility (links to technical specification)
Stories related to keyboard accessibility
Users have enough time to read and use the content
Some people need more time than others to read and use the content. For instance, some people require more time to type text, understand instructions, operate controls, or to otherwise complete tasks on a website.
Examples of providing enough time include providing mechanisms to:
- Stop, extend, or adjust time limits, except where necessary
- Pause, stop, or hide moving, blinking, or scrolling content
- Postpone or suppress interruptions, except where necessary
- Re-authenticate when a session expires without losing data
Accessibility requirements related to sufficient time (links to technical specification)
WCAG
UAAG
ATAG
Stories related to sufficient time
Content does not cause seizures and physical reactions
Content that flashes at certain rates or patterns can cause photosensitive reactions, including seizures. Flashing content is ideally avoided entirely or only used in a way that does not cause known risks. Also animations and moving content can cause discomfort and physical reactions.
Examples of avoiding causing seizures and physical reactions:
- Do not include content that flashes at particular rates and patterns
- Warn users before flashing content is presented, and provide alternatives
- Provide mechanisms to switch off animations, unless they are essential
Accessibility requirements related to seizures (links to technical specification)
WCAG
UAAG
ATAG
Users can easily navigate, find content, and determine where they are
Well organized content helps users to orient themselves and to navigate effectively. Such content includes:
- Pages have clear titles and are organized using descriptive section headings
- There is more than one way to find relevant pages within a set of web pages
- Users are informed about their current location within a set of related pages
- There are ways to bypass blocks of content that are repeated on multiple pages
- The keyboard focus is visible, and the focus order follows a meaningful sequence
- The purpose of a link is evident, ideally even when the link is viewed on its own
Meeting this requirement helps people to navigate through web pages in different ways, depending on their particular needs and preferences. For instance, while some people rely on hierarchical navigation structures such as menu bars to find specific web pages, others rely on search functions on websites instead. Some people may be seeing the content while others may be hearing it or seeing and hearing it at the same time. Some people may be using the content with only a mouse or a keyboard, while others may be using both.
Accessibility requirements related to navigation (links to technical specification)
WCAG
UAAG
- Guideline 2.2 - Sequential navigation
- Guideline 2.3 - Direct navigation and activation
- Guideline 2.4 - Text search
- Guideline 2.5 - Structural navigation
- Guideline 2.7 - Graphical controls
ATAG
- Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
- Guideline A.2.2: (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined
- Guideline A.3.4: (For the authoring tool user interface) Enhance navigation and editing via content structure
- Guideline A.3.5: (For the authoring tool user interface) Provide text search of the content
- Part B. Support the production of accessible content
Stories related to navigation
- Alex, reporter with repetitive stress injury
- Ilya, senior staff member who is blind
- Preety, middle school student with Attention Deficit Hyperactivity Disorder and Dyslexia
- Yun, retiree with low vision, hand tremor, and mild short-term memory loss
- Luis, supermarket assistant with Down syndrome
- Kaseem, teenager who is deaf and blind
Users can use different input modalities beyond keyboard
Input modalities beyond keyboard, such as touch activation, voice recognition (speech input), and gestures make content easier to use for many people. Yet not everyone can use each of these input modalities, and to the same degree. Particular design considerations maximize the benefit of these input modalities. This includes:
- Gestures that require dexterity or fine movement have alternatives that do not require high dexterity
- Components are designed to avoid accidental activation, for example by providing undo functionality
- Labels presented to users match corresponding object names in the code, to support activation by voice
- Functionality that is activated by movement can also be activated through user interface components
- Buttons, links, and other active components are large enough to make them easier to activate by touch
Meeting this requirement makes the content easier to use for many people with a wide range of abilities using a wide range of devices. This includes content used on mobile phones, tablet computers, and self-service terminals such as ticketing machines.
Accessibility requirements related to input modalities (links to technical specification)
Stories related to input modalities
Understandable information and user interface
Text is readable and understandable
Content authors need to ensure that text content is readable and understandable to the broadest audience possible, including when it is read aloud by text-to-speech. Such content includes:
- Identifying the primary language of a web page, such as Arabic, Dutch, or Korean
- Identifying the language of text passages, phrases, or other parts of a web page
- Providing definitions for any unusual words, phrases, idioms, and abbreviations
- Using the clearest and simplest language possible, or providing simplified versions
Meeting this requirement helps software, including assistive technology, to process text content correctly. For instance, this requirement helps software to read the content aloud, to generate page summaries, and to provide definitions for unusual words such as technical jargon. It also helps people who have difficulty understanding more complex sentences, phrases, and vocabulary. In particular, it helps people with different types of cognitive disabilities.
Accessibility requirements related to readability (links to technical specification)
Stories related to readability
Content appears and operates in predictable ways
Many people rely on predictable user interfaces and are disoriented or distracted by inconsistent appearance or behavior. Examples of making content more predictable include:
- Navigation mechanisms that are repeated on multiple pages appear in the same place each time
- User interface components that are repeated on web pages have the same labels each time
- Significant changes on a web page do not happen without the consent of the user
Meeting this requirement helps people to quickly learn the functionality and navigation mechanisms provided on a website, and to operate them according to their specific needs and preferences. For instance, some people assign personalized shortcut keys to functions they frequently use to enhance keyboard navigation. Others memorize the steps to reach certain pages or to complete processes on a website. Both rely on predictable and consistent functionality.
Accessibility requirements related to predictability (links to technical specification)
WCAG
UAAG
ATAG
- Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
- Guideline A.2.2: (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined
- Guideline A.4.2: (For the authoring tool user interface) Document the user interface, including all accessibility features
- Part B. Support the production of accessible content
Stories related to predictability
- Alex, reporter with repetitive stress injury
- Ilya, senior staff member who is blind
- Preety, middle school student with Attention Deficit Hyperactivity Disorder and Dyslexia
- Yun, retiree with low vision, hand tremor, and mild short-term memory loss
- Luis, supermarket assistant with Down syndrome
- Kaseem, teenager who is deaf and blind
Users are helped to avoid and correct mistakes
Forms and other interaction can be confusing or difficult to use for many people, and, as a result, they may be more likely to make mistakes. Examples of helping users to avoid and correct mistakes include:
- 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
Meeting this requirement helps people who do not see or hear the content, and may not recognize implicit relationships, sequences, and other cues. It also helps people who do not understand the functionality, are disoriented or confused, forget, or make mistakes using forms and interaction for any other reason.
Accessibility requirements related to input assistance (links to technical specification)
WCAG
UAAG
ATAG
- Principle A.1: Authoring tool user interfaces follow applicable accessibility guidelines
- Guideline A.2.2: (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined
- Guideline A.4.1: (For the authoring tool user interface) Help authors avoid and correct mistakes
- Part B. Support the production of accessible content
Stories related to input assistance
Robust content and reliable interpretation
Content is compatible with current and future user tools
Robust content is compatible with different browsers, assistive technologies, and other user agents. Examples of how this can be achieved include:
- 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
Meeting this requirement helps maximize compatibility with current and future user agents, including assistive technologies. In particular, it enables assistive technologies to process the content reliably, and to present or to operate it in different ways. This includes non-standard (scripted) buttons, input fields, and other controls.