Chapter 17: Accessibility

Building an accessible site is a lot easier when you know the qualities of an accessible site and how these qualities help different kinds of site visitors. Sometimes it’s hard to “see” where the problems are if you don’t have problems seeing. To make it easier to evaluate your site without having to be an expert in accessibility, there are a number of automated testing tools you can use on your site. Some things, such as the clarity of the language on your site, will still need to be checked “by hand.”

There are two main sets of Web accessibility guidelines: Web Accessibility Initiative (WAI) guidelines and, in the United States, Section 508 of the Rehabilitation Act. Although these two sets of guidelines are not mutually exclusive, building a site that complies with the highest level of accessibility using the WAI guidelines will often create a Section 508–compliant site.

The Web Content Accessibility Guidelines in the WCAG address the four principles of accessibility.

• Can the information be easily perceived (or “seen”)?

• Can the software (Web site) be easily operated (or “navigated”)?

• Is it easy to understand the content?

• Is the content robust enough to be interpreted by a wide range of browsers and assistive technologies?

Appendix F includes the points for each of the accessibility guidelines.

Once you’ve built your site (ideally while you’re building your site), you will need to check to see whether you have met all the guidelines required to declare your site “accessible.” You can check every point by hand using the checklists for each set of guidelines, but there are also a number of automated tests that will make testing a lot easier and a lot more accurate. Ultimately, you will need to conduct user testing with assistive devices to guarantee you have created an accessible site. Using the check lists and at least two automated test suites will find most of the problems in your site.

Check lists make the world a lot easier. They allow you to quickly review the work you have done and confirm it is complete. Completing a check list does not prove conformance with Section 508 or the WCAG guidelines, but it will help you to make sure you have considered each of the points.

• Accessibility Guidelines for Drupal 7: WCAG 2.0 and ATAG 1.0 (http://groups.drupal.org/node/18595)

• WCAG 1.0 Checklist (http://www.w3.org/TR/WCAG10/full-checklist.html)

• WCAG 2.0 quick reference (http://www.w3.org/WAI/WCAG20/quickref/)

• WCAG 2.0 Checklist, HTML format (WebAIM) (http://webaim.org/standards/wcag/checklist)

• WCAG 2.0 Checklist, Microsoft Word or PDF (web usability) (http://www.usability.com.au/resources/wcag2checklist.cfm)

• Section 508 Checklist (WebAIM) (http://www.webaim.org/standards/508/checklist)

Easy to See

An image is only worth a thousand words if you can see it. In your text, describe the concept you are displaying thoroughly so that people who can’t see the image can still understand what you’re saying. Within the image tag itself, use an alt attribute to describe what the picture is showing. If you are uploading videos, provide a transcript of the video for those who can’t hear or don’t have the necessary plug-ins to view the video. For more information on how to make rich text accessible, take a peek at the Accessible Rich Internet Applications (ARIA) guidelines (http://www.w3.org/WAI/intro/aria.php). This applies to JavaScript-rich sites as well.

Screen readers can’t guess what an image is. To make this content accessible to all of your site’s visitors, you need to provide a text description for every image you upload to your site. When you upload an image, Drupal will prompt you to add alternate text (Figure 17.2). You just need to fill in the box.

If you are adding an image to a Web page without using the Image widget, you will need to remember to include an alt attribute that describes the image. If the image in Figure 17.2 were being added by hand, the HTML would look like this:

Figure 17.2
The Image upload widget will prompt you to add an alternate description of the image once it has been uploaded.

Video, audio, and other “rich media” files need to have transcriptions. To make video even more accessible, you can add captions for the hearing impaired. Additional information on video captioning can be found at http://www.webaim.org/techniques/captions/. YouTube also offers specific guidelines on how to add captions to the videos you upload to its site (http://www.google.com/support/youtube/bin/answer.py?hl=en&answer=100077). Transcripts and subtitles can also be translated, making your content even more accessible to people around the world.

Easy to Operate

There are lots of different ways you can make your site easy to use, but the most obvious is the actual navigation system. Make sure your navigation is keyboard accessible. Navigate to a page on your Web site and press the Tab key. The first navigation element should appear highlighted or at least have a tiny dotted box around it. Wherever possible, avoid fly-out (also known as drop-down) menus that open in more than one direction. I don’t have mobility issues, and it still takes me at least two swings at a menu to hit the right menu item.

Computer programs can read only the information they are provided. Web browsing software can display visual enhancements for sighted visitors, but these enhancements don’t mean anything to a computer program unless the meaning is explicitly included with proper HTML tags in the Web page.

Screen readers can build in-page tables of content from the HTML heading tags that are used on the page. This allows visitors with screen readers to scan headings instead of having to listen to every single word. (Imagine if you had to read every single word of this book because there were no headings and no index. Yucky, right?) Content subsections should use heading levels h2 to h6 as appropriate. h1 is reserved for the title of the page—your theme will insert this tag for you.

Easy to Understand

Writing good content takes practice. Some people even go to school to learn how to write (we often refer to them as “authors” or “journalists”). Writing on the Web is not like writing for print. On the Web you need to write your text so that it is very easy to scan.

• Use subheadings to break a long page into multiple sections.

• Use bullet and numbered lists to break key ideas into easily digested information.

• Add illustrations, diagrams, and photos to enhance your message, but never use graphics to replace the written word.

• Add definitions for acronyms and other industry-specific jargon.

• Avoid the overuse of contractions (wouldn’t, can’t) and local slang or phrases (for example, “that’s sik,” which means “good”; “sick” is ill, which used to be good; and sic, which is still known to be wrong).

Read your page out loud before publishing it to the Web. This will help you spot errors. For larger Web sites, hire a professional editor. No matter how good you are, an editor will make your writing better.

Provide Help

Provide clear instructions to help users complete forms without error on their first attempt. Clearly explain what exists on the other side of a link. Don’t make people guess what a ducky icon means on your site. Make people feel smart, not stupid, when they use your site. Test your site with friends and colleagues. Ask them where you could have made things a little clearer. If it makes sense, include a “help” area that answers commonly asked questions and tours people through each of the features of your site.

There are a lot of ways to test your site for accessibility. One of the easiest tricks you’ll need up your sleeve is a simple one. In your Web browser, disable the CSS and the images and try navigating around your Web site. It won’t find all the problems, but it will often find quite a few.

Text-Only Browsers

Computer-aided browsing (Refreshable Braille Display, screen readers) can deal only with text. They can’t create meaning that isn’t there. They won’t describe a picture to you, and they certainly can’t perform mouse actions that are used as JavaScript triggers, because there is no mouse. Use a text-only browser to test your site. Figure 17.3 shows the home page of a Drupal 7 site in Links, a text-only browser. If you can use the Web site, chances are good that it will be usable by folks who can’t see your Web page.

Figure 17.3
Drupal sites appear as a linear page of text when viewed in Links. Note the accessibility enhancement “Skip to main content” link at the top of the page.

Text-only browsers are available online from http://www.delorie.com/web/lynxview.html and http://www.standards-schmandards.com/projects/fangs/.

You can simulate a text-only browser by using the Web Developer Toolbar plug-in for Firefox. Once it’s installed, use the Web Developer toolbar to disable CSS and JavaScript and turn off images. With CSS and JavaScript disabled, try browsing your Web site and see whether you can still find information and buy products.

Automated Testing Tools

After creating, or updating, Web pages, immediately check to see the page is using valid HTML markup and complies with your site’s accessibility standard. Retrofitting a site will take a lot longer than ensuring only accessible pages are produced in the first place. The tools for checking Web sites for accessibility guidelines will typically return either a summary table of errors that were found or an overlay of your site showing you exactly where the errors are. Figure 17.4 shows a WAVE report for Drupal.org reporting no errors. Figure 17.5 shows the same report run on Microsoft.com with a few minor errors. Figure 17.6 shows a second automated test for Drupal.org

• WAVE, online accessibility checker for Web sites (http://wave.webaim.org/http://fae.cita.uiuc.edu/)

• Truwex Online, web accessibility testing tool: WCAG and Section 508 compliance (http://checkwebsite.erigami.com/accessibility.html)

• Stanford Online Web Accessibility Checker for Web sites (http://www.stanford.edu/group/accessibility/cgi-bin/accessibilitychecker/checker/index.php)

• Worldspace accessibility checker (includes a test for PDFs) (http://-worldspace.dequecloud.com/worldspace/wsservice/eval/checkCompliance.jsp)

• Run FAE; by creating a free user account you can also test multiple pages via Web crawling and produce a sitewide report (http://fae.cita.uiuc.edu/)

• TAW Online also tests for mobile devices (http://www.tawdis.net/)

Figure 17.4
Drupal.org passes the WAVE automated accessibility test.

Figure 17.5
Microsoft.com fails the WAVE automated accessibility test with four very minor errors.

Figure 17.6
Drupal.org fails the WCAG 1.0, priority level 2, automated test using Truwex online.

Browser-based tools will perform checks of the page you are currently viewing. Figure 17.7 shows the pop-up window summary of the accessibility errors from one Web site, and Figure 17.8 shows the “summary” with additional information about the accessibility errors on this page.

• Firefox Accessibility Extension (https://addons.mozilla.org/en-US/firefox/addon/5809/)

• Firefox Colour Contrast Analyser (https://addons.mozilla.org/en-US/firefox/addon/7313/)

Figure 17.7
Firefox Accessibility Extension provides on-page summaries of potential accessibility problems.

Figure 17.8
A detailed summary of the accessibility problems is also available from the Firefox Accessibility Extension.

This excerpt is from the book, 'Drupal User's Guide: Building and Administering A Successful Drupal-Powered Web Site' by Emma Jane Hogbin, published by Pearson/Prentice Hall Professional, published Sept. 2011, ISBN 0137041292, Copyright 2012 Pearson Education, Inc. For more info, please visit the publisher site: www.informit.com/title/0137041292

© Copyright Pearson Education. All rights reserved.