The 70-point ADA Plan of Work
In my last post I commented that far too many internet articles pretending to tell American businesses how to make their websites ADA compliant are misleading. Most of them pull maybe four or five rabbits out of the WCAG hat and claim that's all companies need to do in the matter.
Anyone reading those articles and applying their advice will be no more ADA-proof than they were before.
So this is my list of nearly 70 separate matters you must look at. It simply lists the Level AA requirements of the WCAG 2.0, but:
- paraphrased a for little my readers in more intelligible language than the W3C tends to use
- and also reworded specifically with websites in mind
- where a criterion includes several separate items, I show them in subsidiary lists so they are included in the total count of things to do.
It is not intended as a definitive list of what to do. For that you still need expert guidance from accessibility professionals to ensure you are doing everything correctly. It just gives a true understanding of how much you need to do, as an antidote to all those articles that over simplify it. (If your developers follow it, you will be nearly there before calling in the experts just to check and audit your work.)
And I have called it a plan, not a checklist, because it shows remedial work you will actually need to be planning - it is not just something to check and forget!
Identifying the WCAG's requirements
The WCAG has 38 criteria at Level AA, but when you take into account those that include several matters, you realise the total is actually considerably larger than that. Here they are:
- All non-text content must have a text alternative that conveys the same information, including:
- images must have an alt text that describes the image or its purpose
- complex images that cannot easily be described using a simple alt text must have a full description available for all users via a button or link adjacent to the image
- but images that are purely decorative must have an empty alt text
- every input field and control must have a <label> that describes its purpose
- any video or other multi-media component must have a label that, at minimum, says what it does
- if the non-text content is a test of knowledge or ability that cannot be explained in text without invalidating the test, then alternative text at least explains the purpose of the test
- content that is a sensory experience that cannot be conveyed in text, then alternative text identifies or descrbes the content
- CAPTCHAs or other content designed to distinguish a human user from a robot must a) have alternative text that tells users about the CAPTCHA and b) alternative CAPTCHAs are provided for people with sight, hearing and other disabilities.
- For recordings that are either audio-only or video-only but do not contain both:
- An audio recording must have an alternative text version (such as a transcript) that conveys the same information.
- A video recording must have either an audio recording, or a text alternative, that conveys the same information.
- Videos and other multimedia presentations must have captions that present the same information as the audio track.
- Videos and other multimedia presentations must have either an alternative text version (such as a screen play or transcript) that conveys the same information, or an alternative audio track that contains added narrative descriptions of actions, events and other visual content that are not understood from the original audio track.
- Provide captions for all live audio content in multimedia presentations.
- Provide an alternative soundtrack with narration added to describe important visual details that cannot be understood from the original soundtrack for all prerecorded video content in multimedia presentations.
- Information, structure, and relationships that can be be seen visually on-screen, or by other presentation methods, are either
passed to assitive technology using standard markup that such tecnology can understand, or are available to all users in text form.
This includes, but is not limited to:
- Use the correct HTML element for all items on the web page, and use them correctly according to the HTML specification.
- In headings use the <h1> to <h6> HTML heading elements, and in the correct hierarchical structure.
- Mark up lists using the correct ul, ol, dl and li HTML elements.
- Mark up data tables using the correct table, tr, th and td elements. (But do mot use these elements for layout purposes only.)
- Mark up row and column headings in data tables using the th header cell element.
- Use button and link elements for their correct purpose, and give link elements a valid href attribute.
- When the sequence in which content is presented affects its meaning, ensure the correct reading sequence is passed to assistive technology using correct standard markup.
- Ensure instructions provided to users on a web page:
- do not rely on visual appearence, or on terms or expressions to do with such characteristics such as shape, size, location or orientation that cannot not be understood by blind people
- and do not rely on sounds that cannot be heard by deaf people.
- Do not use color as as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual item.
- Do not play audio sounds automatically for more than 3 seconds without providing users with a mechanism to pause or stop it.
- Make sure all text, including text in images, has a contrast ratio of at least 4.5 to 1 against its background (or, if large text of 19px font size or greater, at least 3 to 1). (There are some exceptions including text in logos and purely decorative text.) There are color contrast tools for meauring contrast.
- Ensure all text can be resized (e.g. using your browser's text size settings) up to 200% without losing content or operability e.g. due to text being overwritten, cropped, or disappearing. Exception: text in images (but see a separate criterion about them), and captions.
- Do not include text in images, use actual text instead. Exceptions: logos, and cases where including the text in the image is essential (for instance displaying a photo of a historical docment).
- Ensure all user interactivity can be done from the keyboard using standard keys.
- Ensure keyboard focus does not become trapped on any interactive component. The user must always be able to move on to the next and previous interactive component.
- Wherever a time limit exists in the content, users can either turn it off before beforehand, or extend it, or the user is warned before it expires and given at least 20 seconds to extend the time limit with a simple action (for example, "press the space bar"), and the user is allowed to extend the time limit at least ten times. Exceptions: where the time limit is an essential part of a real time event (such as an auction), or of an activity that would be invalid without the time limit.
- For any moving, blinking or scrolling information that starts automatically and lasts more than five seconds, give the user a mechanism to pause, stop, or hide it.
- Do not have any content that flashes more than three times in any one second period.
- Provide a link to bypass blocks of content (containing links or other interactive components) that are repeated on multiple web pages (e.g. page headers or menus in a sidebar).
- Ensure that each page's <title> element (in the <head> section) describes that page's topic or purpose.
- Ensure that when a user navigates your web page using the keyboard, focusable components receive focus in an order that preserves meaning and operability.
- The purpose of each link can be determined either from the link text alone, or from the link text plus other text in the same paragraph, list item or table cell that contains the link.
- More than one way is available to locate a web page within a set of pages. Exception: where the web page is the result of, or a step in, a sequential process.
- Ensure headings and labels describe topic or purpose.
- Make sure the keyboard focus indicator is always visible when the user is navigating from the keyboard.
- Correctly specify the human language of each web page in the "lang" attribute of its <html> element.
- Correctly specify the human language of each foreign language passage or phrase in the content by giving it a "lang" attribute. Exceptions: proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the language used in the immediately surrounding text.
- Ensure that no user interface component receiving keyboard focus automatically initiates a change of context. ("Change of context" includes a change of user agent, viewport, focus, or a change in meaning of the page, or change to a new page.
- Ensure that changing the setting of any user interface component does not automatically cause a change of context (see item above) unless the user has been warned of the behavior beforehand.
- Navigational mechanisms that are repeated on multiple pages within a set of web pages occur in the same relative order each time they are repeated. Exception: where a change has been initiated by the user.
- If an input error is detected by the system, the input field or control that is in error is identified and the error is described to the user in text.
- Labels or instructions are provided when content requires user input.
- If an input error is detected by the system and suggestions for correction are known, then the suggestions are provided to the user. Exception: where it would jeopardize the security or purpose of the content.
- For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: Submissions are reversible, or data entered by the user is checked for input errors and the user is provided an opportunity to correct them, or a mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
- All HTML elements in the markup:
- have complete and correct start and end tags, are nested according to their specifications, and do not contain duplicate attributes
- and any IDs are unique.
- For all user interface components (including but not limited to: form elements, links and components generated by scripts):
- the name and role can be programmatically determined and passed to assistive technology, particularly including but not limited to the items listed below
- states, properties, and values that can be set by the user can be programmatically set
- notification of changes to these items must be available to user agents, including assistive technologies
- if an interactive component does not have an associated <label> element, give it an aria-label or aria-labelledby attribute
- if a component displays and hides content, give it the aria-expanded attribute
- if a component opens a pop up display content, give it the aria-haspopup attribute
- if an HTML element is used for a purpose different from specification give it the ARIA role attribute specifying its new role
- if an interactive component has additional description that is evident visually but not associated programatically, use the aria-describedby attribute
- required input components should have either the HTML required attribute or aria-required
- content that is hidden visually must be hidden from all users using means such as display:none or visibility:hidden
- ensure content that appears or changes after the page is loaded are announced by AT using means such as the aria-live attribute
- give the selected item in a set the aria-selected attribute
- pop-up dialogs need extra ARIA and markup
- give input components that auto-complete the aria-autocomplete attribute
- "breadcrumb" lists of page location data need extra ARIA
- lists of page numbers of additional pages in search results need extra ARIA
- Finally, any less common components not mentioned above (e.g. slider controls as just one example) are likely to require additional ARIA attributes and/or markup.
(End of planning list)
- That last item in the list is mainly for components custom-built by the user, since standard HTML controls used according to spec already meet it.
- The above list covers the most common things required on the average website, but is not exhaustive.
- The paraphrasing may lead to a slight loss of accuracy, but it still serves to show what is needed in most sites.
Well that was a long list! Add up all the numbered sub-criteria gives us 38 plus 30 items, 68 in all. Following one of those articles that list only 5 or 6 things to do for the ADA will leave you just as open to a lawsuit as before your work started.
Each of the 38 WCAG criteria has a whole article about it in the WCAG named "Understanding Success Criterion [and the reference number]". That means 38 articles to read as a starter to the work if you choose to do it all yourself, and if your website contains content that is affected by them all. It may not; for instance if your site does not contain any videos that will eliminate the Criteria applying to them.
How easy is it?
Please do not misunderstand me, I do not want to frighten you off or make the task seem too difficult - it isn't. WCAG, and therefore ADA, compliance is not difficult technically. There is just rather a lot of it, and likely every page of your website will require several corrections. However the changes required to achieve compliance are quite small in themselves, generally needing little more than adding an extra attribute or two to elements. Just ensuring your HTML follows the HTML specification will correct some ADA issues!
Only two things are likely to cause real difficulty: videos (if they need improved captions or sound tracks), and complex custom-built components. The latter can sometimes be solved by replacing them with more standard HTML/CSS structures. For example a component that far too many web designers decide to recustomise, for no very obvious reason since they usually replace them by something that looks and behaves just the same way, is the simple drop down list selector (the HTML <select> element). As to the videos, unfortunately, one university that was taking a hammering from the Justice department decided the only solution was to withdraw all its existing videos from public access as the job of remaking many hundreds of them was just too great.
Once your developers have done the work, you do need to have the site tested by an expert accessibility tester or auditor (such as myself - I am plugging my own services now, but the same applies whether you use me or some other accessibility consultancy that you may already know!). However, as you can probably judge from the above list of requirements, even testing multiple pages will take a few days. The remedial work, to fix an already existing website, will take quite a lot longer.
Beware the people who claim "I can test your website for ADA compliance" for just a few dollars. All they will do is run one of the several automated test tools that can be found. Those tools are useful in finding some issues, but they can only catch around one quarter of the possible issues, and even then they cannot tell you what to do to correct the issue, or even if there actually is an issue!
There are no short cuts to this work.