Another day, another question from Rubicon Labs client:
Quick Checkers/Reporting Tools
*Recommended for professional developers only!
WAVE Accessibility Evaluation Tool is a highly regarded checker that will alert you of the most common accessibility errors such as missing image alt tags, non-matching or missing form labels, empty elements, etc..
HTML_CodeSniffer goes a few steps further, checking the color contrast and the semantic structure of the document, but beware that it is often over-sensitive and produces many false positives. You must understand WCAG guidelines and semantic HTML in order to take full advantage of this tool.
Color Contrast Check
The color checks should be completed at the design stage to ensure compliance with the contrast guidelines:
- Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
- Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
- Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
Multimedia Components (Audio and Video)
You should provide accessible alternatives for the information contained in the audio and video recordings posted on your website per WCAG guidelines below:
- If you use audio files on your Web page, a text transcript or other text-based material should be provided. WCAG 2.0 Guideline 1.2.1—”An alternative for time-based media is provided that presents equivalent information for prerecorded audio-only content.”
- If video files are used, captions or a synchronized text transcript should be provided.
NOTE: Captions also benefit non-native speakers, users with audio disabled or viewers watching a video with poor quality audio. WCAG 2.0 Guideline 1.2.2—”Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.”
- Video files should be embedded or displayed in a player that can be accessed by a screen reader via keyboard commands. Accessible players include QuickTime, RealPlayer, iTunes, YouTube and properly configured JW Player. WCAG 2.0 Guideline 2.1—”Make all functionality available from a keyboard.”
- Videos that include visual information critical to comprehension should include a description of events or images for visually impaired audiences. For example, a screencast of a software product should name the buttons and commands being used, not just say “click here”. WCAG 2.0 Guideline 1.2.3—An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.
- A lengthy piece of audio or video should not be played by default when entering a page. Instead, the user should be able to click the play button to start the file. This provision prevents audio from interfering with screen reader audio.
NOTE: Transcripts are also beneficial to users who may not be able to access audio on their computers. This is a very frequent situation.
It is important to understand what the errors mean and how the browsers handle them. For example, deprecated tags are treated as generic <div>’s, non-standard attributes and non-standard/deprecated CSS rules are ignored. Generally, these types of errors will have very little impact on the site’s accessibility compliance.
At the time of this writing, the Google search page contains 17 HTML validation errors and the Twitter homepage has 10x of that. Both are accessible and deliver consistent user experience in all major browsers and screen readers.
Disabled Stylesheet Testing
One way to check the proper semantic structure of the document is to view it without any styling, in its raw HTML form. The page should be fully readable and accessible, with headings, lists, paragraphs and other elements appearing in logical order. Realize that the visually impaired users won’t see any of your clever styling or effects. Google search crawler won’t care for the looks either. Semantic HTML = better SEO!
Cross Browser and Device Testing
Remember, the website does not have to look exactly the same in every browser, but the core user experience should not differ widely between various devices and platforms. At the very least, test your site in all major browsers (Internet Explorer, Firefox, Chrome, Safari, Opera) on PC and Mac platforms as well as on the iOS and Android tablets and smartphones. Ideally, you want to have access to all devices and test natively, but virtualization tools such as Browserstack can be helpful for quick assessments.
If you are building a responsive or adaptive site layout, Responsive Design Checker is another useful tool that let’s you quickly test your site at most common screen widths.
Keyboard Navigation and Screen Readers
Test your website using keyboard only and in at least one of the popular screen readers. There is no reason whatsoever why every single function should not be available to the users of assistive technology. Even complex behaviors such as drag-and-drop can be coded to support screen readers and keyboard-only navigation.
- Writing Hyperlinks: Salient, Descriptive, Start with Keyword
- Guidelines for Visualizing Links
- Avoid Within-Page Links
One thing that is often missed by the automated tools is link text accessibility. How many times have you seen linked text that says nothing more than click here?
A screen reader user will often use a speed scroll functionality to go through a list of links present on an HTML page and it is extremely important to have link text that makes sense out of context. “Click here” is useless out of context. Besides, given the ever-increasing mobile Web traffic, many users won’t be clicking. The guidelines above go into further detail on how to make your links usable and accessible.