Each section can be expanded, and has links to the respective section on the WC3 website for more information.
Content such as images need to have a text alternative so the information can be accessible to all. For example, a person who cannot see a picture can have the text alternative read aloud using synthesized speech. A person who cannot hear an audio file can have the text alternative displayed so they can read it.
For CAPTCHAs as they tend to push the edge of human abilitiies in order to defeat automated processes, having a few CAPTCHA alternatives, providing access to a human customer service rep who can bypass the CAPTCHA for the user, or not requiring CAPTCHAs for authorized users are a few ways to get around this.
The same idea as above with images, by providing a text alternative to video-only and audio-only content, you give all users the ability to consume the content in a way that matches their needs.
You can do this easily by linking to video transcripts and writing a brief summary of what the video or audio content is about.
Along with transcripts for video-only and audio-only content, providing captions inside the content itself so a user can read the captions while watching the video.
This benefits those who are deaf or have hearing loss, as well as users in public spaces who can't use their audio.
Whereas the above points relate to creating an additional way to consume what's being said in video-only or audio-only content, this is specifically around providing audio or text prompts to help people who have difficulty watching video or other synchronized media content, including people who have difficulty perceiving or understanding moving images.
An example could be describing a scene change in a video, introducing new characters, and describing what is happening during pauses in dialogue.
Sighted users can perceive structure and relationships of information through various visual cues - links being blue and underscored, errors or discounts being highlighted in red, headings being larger, bold font in paragraphs, bullet points, etc.
Screen readers often can pull a lot of this information if it's clearly labeled in the code.
Sometimes technologies do not provide a means to programmatically deteremine and share these cues to all users, and in those cases, we can provide additional prompts to ensure the information comes across correctly.
One example is adding an asterisk (*) on form fields that are required.
Another example is if form contains both required and optional fields. Instructions at the top of the form explain that required fields are labeled with red text and also with an icon whose text alternative says, "Required." Both the red text and the icon are programmatically associated with the appropriate form fields so that assistive technology users can determine the required fields.
Content on websites often have a clear sequence in which you should consume the content. A sequence is meaningful if the order cannot be changed without affecting its meaning.
For example if there are two independent articles on a page, and one articles gives context to the other, there is a meaningful sequence.
This is often defined through HTML in the form of tables and ordered lists having meaningful sequence, and unordered lists not.
The goal of this is to have the content presented in the same order written as it is in spoken form.
The goal of this Success Criterion is to ensure that every user can access intructions for using the content, even when they cannot percieve the shape or size or use information about spaciatl location or orientation.
Although these cues are very effective, including those with cognitive limitations, and should continue to be used, this is about ensuring users who are blind or have low vision to also access the same level of depth.
Some users using assistive technology won't be able to perceive shape or position.
For example on an online survey or onboarding sequence might have an arrow on the right hand of the screen point right suggesting 'next' and an arrow on the left hand side point left suggesting 'back'. Which this is a handy cue, this information won't be able to be understood by some assistive technology, so adding a clear "Next" label on the arrow and instructions which state "to move to the next section, select the green arrow labelled 'next' in the lower right hand corner below the last survey question."
Colour is a very important part of ensuring web content is accessible, aesthetically pleasing, and usable. However, some users have difficulty perceiving colour.
Sometimes colour is used to indicate action, such as a link being blue. Other times it can be used to prompt a response, such as highlighting on form fields to indicate a required form field has been left blank.
However there are plenty of users who often experience limited colour vision, such as older users, users with colour blindness, people using text-only displayed, and more.
By adding clear tags you can enhance the experience to those who can't perceive colour. For example in the New Zealand road code which often uses cars of two colours to describe situations can mention the position and colour of each car in the image.
Another example could be on forms, adding icons whose alternative text says 'required' on the required field .
Individuals using screen reading software can find it hard to hear the speech output if there is other audio playing at the same time.
This is made even worse as the audio for most screen reading software is controlled the same way as the sound playing from the video so it's crucial to be able to turn off the sound coming from web content quickly and easily.
To solve this, you can display audio controls on the video, or add the ability to easily silence any audio from the page.
In most cases, audio that automatically plays can be annoying for any user so it's usually best to avoid this.
Users that are blind (who cannot use devices such as a mouse which requires hand-eye coordination), have low vision (who may have trouble finding or tracking a pointer indicator on the screen), or have hand tremors who find using a mouse more difficult need to be able to navigate a website through keyboard alone.
One example of making your content accessible for a program that allows drag drop functionality, is to also allow users to "cut" and "paste" with a keyboard.
Another example is by making sure drop downs like menus are able to be targeted through tabbing and opened.
Plug-ins on websites or embedded applications such as calendar software can sometimes trap users inside the embedded application and not let users exit the through the keyboard alone.
Ensure every plug-in or embedded application allows users to leave.
Examples of this could be calendar software, booking software for car hire companies, embedded checkout software for eCommerce, or embedded maps on contact pages.
Another example is pop-up software that makes the 'x' to close the pop-up impossible to select with a keyboard.
Shortcuts often help users save time when using web applications such as our email, or our calendar.
While these single character shortcuts can be valuable for keyboard users, they can become inappropriate and frustrating for speech input users, and even for keyboard users who are prone to accidentally hit keys.
To ensure this isn't an issue, you need to allow users to either turn off or reconfigure shortcuts that are made up of only character keys.
For example, a speech-input user named Kim has her cursor focus in the main window of a web mail application that uses common keyboard shortcuts to navigate ("k"), archive ("y") and mute messages ("m"). A coworker named Mike enters her office and says "Hey Kim" and her microphone picks that up. The Y of "hey" archives the current message. K in "Kim" moves down one conversation and M mutes a message or thread. And, if Kim looks up and says "Hey Mike" without remembering to turn off the microphone, the same three things happen in a different sequence.
The goal of this Success Criterion is to ensure that users with disabilities have the adequate time to interact with content whenever possible.
Users with disabilities such as low-vision, blindness, cognitive limitations, or dexterity impairments may take longer to interact with content such as filling out forms. And if there's a time limit, it makes the process more difficult and in some cases impossible for these users.
There are a range of exceptions here such as if the time limit is due to a real-life event.
To resolve this, simply giving users the ability to turn off the time limit before encountering it, allowing users to adjust the time limit, allowing users to extend the limit at least 20-seconds before the time expires, and more.
The goal of this Success Criterion is to ensure that users can avoid distraction during their interaction with a website.
"Moving, blinking and scrolling" refers to visible content that conveys a sense of motion.
This is any information that (1) starts automatically, (2) lasts for more than five seconds, and (3) is present in parallel with other content.
If those three criteria are met, there needs to be a way for a user to pause, stop, or hide it.
The same goes for auto-updating information such as weather updates, stock-tickers, or games.
The goal of this Success Criterion is to allow users full access to the content of a site without inducing seizures due to photosensitivity.
This could include video content, or GIFs that contain scenes involving very bright lightning flashes.
Solutions are either editing the content so the content only flashes three times in any one second period or less, or removing the content altogether.
The goal of this Success Criterion is to allow people who use assistive technology to skip repeated sections of websites.
Most websites contain content that's repeated consistently, such as navbars, blocks for advertising, search icons, and more. If your website or app contains a lot of these blocks, giving users a link to skip to the main content is recommended.
While sighted users can quickly navigate to the main section of content, users who use assistive technology might have to tab 40+ times on each new page to actually get to the main content.
Example solutions from W3:
The goal of this Success Criterion is to allow users to quickly find content and understand where they are on a website or app through a clear page and section title.
You can see the title of a page by looking at the tab on your browser.
On top of helping a range of users such as people with cognitive disabilities like short-term memory or reading disabilities, clear titles help all users quickly and easily identify whether the information contained on a page is useful and relevant to their needs.
If a meta title isn't pre-defined, your page title will also be shown on search engines like Google and a clear title can help improve the number of users who find you through search.
The goal of this success criterion is to allow users to quickly navigate content in a logical way.
This can help users with mobility impairments who rely on keyboard access, those with disabilities who can become disorientated if the focus moves somewhere unexpected, or users using a screen magnifier who can only see a small portion of the page.
An example of a clear focus order is on YouTube where you tab through the controls down the bottom of a video, and each time if focuses on a new control each time going left to right.
An example of a unclear focus order would be on a web form, where the focus jumps from the first question, to the last question, then back up to the second question, and so on.
Assistive technology often has the ability for the user to see a list of all the links a web page contains so the user can quickly move towards the information they're looking to find.
However, if the link isn't descriptive, then the user will have a much harder time navigating the website.
An example of bad link text is 'learn more' or 'click here' as by itself the text of these links describe nothing about what the user is learning more about.
On the other hand, take a look at Wikipedia for inspiration on descriptive links.
All functionality that uses multi-point or path-based gestures for operation can use for operation can also be operated with a single pointer without path-based gesture, unless it is essential.
For example, a map widget on a website that allows a pinch to zoom (multi-point gesture) also has a plus and minus arrow to allow users to zoom in and out with a single pointer.
Another example is a kanban widget like Trello which allows users to drag and drop (path-based gesture) to also allow users to move an element between columns by selecting the element with a single tap or click, and then activating an arrow button to move the selected element.
People with various disabilities can inadvertently initiate touch or mouse events with unwanted results.
The goal of this is to allow users to easily cancel pointer operations, and to allow users to quickly recover from hitting the wrong target.
One example is a drag and drop app, where when you click down and hold, you select an element, and when you release the click, it drops the element. To help users recover quickly, if the user drops the element outside the target area, the program could move the element back to its original position.
Most controls are accompanied by a visible text label.
Those same controls have a programmatic name, also known as the Accessible Name.
Users typically have a much better experience if the words and characters in the visible label of a control match or are contained within the accessible name.
In the example image below, "B", "I", and "ABC" appear on icons in a text editor, where they are meant to symbolize the functions for Bold, Italics, and Spelling, respectively. In such a case, the accessible name should be the function the button serves, e.g., "Spell check" or "Check spelling".
The intent of this success criterion is to ensure that functions triggered by moving a device (for example, shaking or tilting) or by gesturing towards the device, can also be operated by more conventional user interface components.
On top of this, some users may accidentally activate these commands due to tremors or other motor impairments so the user must also have the ability to turn these motion features off.
One example is on some phones which have the functionality to shake the phone to undo the last action you did. You can make this more accessible by adding in a button to be able to undo, and giving the user the ability to turn this feature off.
Content developers who are creating content on web pages must declare the correct language to make it easier for people who use assistive technology to quickly understand the language of a page.
For example, if you have a page that's predominantly in German with some English, you can declare the language by setting the lang attribute on the html element to German (de).
Below you can see a screenshot of the backend of our website built on Webflow where we have set the language of this website to English (en), since most of our content is currently in English.
This is also best practice to help your content rank higher on Google.
The goal of this is to simply ensure that functionality is predictable as a user goes through your website or app.
Focus is usually controlled via the keyboard (e.g. tabbing to control), the mouse (e.g. clicking on a text field).
We want to make sure that an element doesn't change context when it receives focus.
For example, you don't want links opening automatically, pop-ups appearing, or forms submitting when you initially focus on the element.
Examples from W3:
Similar to the above, the goal here is to ensure that each input has a predictable outcome.
This could be as simple as ensuring that when a user selects 'agree to terms and conditions' that this stays selected when the user tabs onto the next field.
Examples from W3:
The goal here is to give users a very clear indication if an error has occurred, and help them easily determine what's wrong.
It's not enough for a form to display 'oops something went wrong' or highlight the form in red for example. Instead the form needs to clearly articulate which field needs the users attention.
Errors must at a minimum be identified with text as screen readers can often not pick up highlight-only errors and the user will have no idea that there any errors occurred.
This helps users with colour-blindness or low vision understand errors since the website isn't only relying on colour prompts. On top of this, you'll be making your website more accessible to users with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.
Examples by W3:
The goal of this success criterion is to help users understand what information a form requires. Especially if the form is requesting the information in a specific way (such as abbreviations, dates that require a specific format, or NZ bank-account information that requires 2, 4, 7, 3 number format).
Examples by W3:
The goal of this is to ensure that user agents, including assistive technologies, can accurately interpret or parse content.
In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.
The intent of this is to ensure that Assistive Technologies (AT) can gather information about, activate (or set) and keep up to date on the status of user interface controls in the content.
When standard controls from accessible technologies are used, this process is straightforward. If the user interface elements are used according to specification the conditions of this provision will be met.
If custom controls are created, however, or interface elements are programmed (in code or script) to have a different role and/or function than usual, then additional measures need to be taken to ensure that the controls provide important information to assistive technologies and allow themselves to be controlled by assistive technologies.
A particularly important state of a user interface control is whether or not it has focus.
The focus state of a control can be programmatically determined, and notifications about change of focus are sent to user agents and assistive technology. Other examples of user interface control state are whether or not a checkbox or radio button has been selected, or whether or not a collapsible tree or list node is expanded or collapsed.