When I speak to business owners about website compliance it is typically the first time they have heard about it. They are often surprised that this is an area of their business that requires their attention. The guidelines to follow for website compliance are published by the World Wide Web Consortium (www.w3c.org) and are known as WCAG 2.1 (Web Content Accessibility Guidelines). The guidelines can be overwhelming and often difficult to understand, so in this post we attempt to simplify the basics.
The good news is that most modern websites are close to being compliant, and if they are not, the steps required to meet the standards should not cost a lot.
The overall goal is to make sure your website is accessible to everyone that visits. To determine if your website is compliant answer these 10 questions. If you answer no to any of these questions, you know where to start to make your website accessible.
- Does the top of each page with navigation links have a “skip navigation” link?
This feature directs screen readers to bypass the row of navigation links and start at the webpage content, thus enabling people who use screen readers to avoid having to listen to all the links each time they move to a new page. The basis for this feature is the main website content is not usually the first thing on a web page. Keyboard and screen reader users must navigate a long list of navigation links, sub-lists of links, corporate icons, site searches, and other elements before ever arriving at the main content. This is particularly difficult for users with some forms of motor disabilities.
- Do all links have a text description that can be read by a screen reader (not just a graphic or “click here”)?
Linked text should describe the function of what will happen if the user visits it. For example, you might have a list of upcoming events on your site with a link that takes you to the complete list of events. Instead of making the link say “View All”, it should say “View All Events”.
- Do all the photographs, maps, graphics and other images on the website currently have HTML tags, such as an “alt” tag?
Alternative text serves several functions: It is read by screen readers in place of images allowing the content and function of the image to be accessible to those with visual or certain cognitive disabilities. It is displayed in place of the image in browsers if the image file is not loaded or when the user has chosen not to view images. It also provides a semantic meaning and description to images which can be read by search engines or be used to later determine the content of the image from page context alone. The key principle is that computers and screen readers cannot analyze an image and determine what the image presents. As developers and site owners, text must be provided to the user which presents the CONTENT and FUNCTION of the images within your web content.
- Do all the photographs, maps, graphics and other images on the website contain aria labels?
For sighted users, the context and visual appearance of an element (Ex. an image or icon) can provide enough cues to determine the purpose. For visually impaired users, it can be impossible to determine what the element is describing without audible direction and/or explanation. In some situations, elements can be given the attribute “aria-label” to provide an accessible name for situations when there is no visible label due to a chosen design approach or layout, but the context and visual appearance of the control make its purpose clear. This implementation becomes interpretive to the developer and would require developer discretion for proper application. The presence of Aria Labels does not make or break ADA compliance.
- Are all the documents posted on your website available in HTML or another text-based format (for example, rich text format (RTF) or word processing format), even if you are also providing them in another format, such as Portable Document Format (PDF)?
PDF’s, by default, are not ADA compliant. That’s because PDF documents, or those in other image-based formats, are often not accessible to users who use screen readers and people with low vision who use text enlargement programs or different color and font settings to read computer displays. To remedy this, new technology is becoming available to make them readable in their current format (PDF). Until then, the most effective way to make PDF’s accessible is to provide documents in an alternative text-based format, such as HTML or RTF (Rich Text Format), in addition to the PDF.
Text-based formats are the most compatible with assistive technologies. A general example of an RTF format for a PDF is to add an icon beside the PDF which can be read by the screen reader and inform them of the alternative “readable” format. This would satisfy ADA compliance for PDF’s on the website.
- If your website has online forms, do HTML tags describe all the controls (including all text fields, check boxes, drop-down lists, and buttons) that people can use to complete and submit the forms?
If a form control does not have a properly associated text label, the function or purpose of that form control may not be presented to screen reader users. Form labels also provide visible descriptions and larger clickable targets for form controls.
If a text label for a form control is visible, use the element to associate it with its respective form control. If there is no visible label, either provide an associated label, add a descriptive title attribute to the form control, or reference the label(s) using aria-labelledby. Labels are not required for image, submit, reset, button, or hidden form controls.
- If your website has online forms, does the default setting in drop-down lists describe the information being requested instead of displaying a response option (e.g., “your age” instead of “18 – 21”)?
Any form that has a dropdown should state, within the dropdown what you want the reader to select.
- Do all video files on your website have written captions of spoken communication synchronized with the action to provide access to people who are deaf or hard of hearing?
Closed captions and an accompanying transcript are required to make a video accessible. When a deaf user watches a video, subtitles alone can communicate spoken information, but miss out on non-verbal audio cues. Closed captions can describe sounds such as cars honking or music playing which would help give the viewer better context for on-screen actions.
- Do all audio files on your website have written captions of spoken communication?
A transcript of the audio file will quickly solve the issue and allow a deaf visitor access to the content.
- Have all webpages been designed so they can be viewed using visitors’ web browser and operating system settings for color and font?
As much as you might love your website’s design, it may not be completely accessible to all users due to contrast and readability issues. A compliant website should not force CSS styling to override browser and operating system settings for color and font. Browsers like Firefox allow users to set what fonts and colors appear on websites they visit. A simple way to make sure this is accommodated is to not use the CSS !important keyword on any font or color rules.
This check list is a starting point and does not cover all that is required but it should give you a good idea of where you stand.