Book Excerpt: Drupal User's Guide: Building and Administering a Successful Drupal-Powered Web Site
Chapter 17: Accessibility
Creating Accessible Content
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.
Accessibility Check Lists
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
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:
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.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
Web Development News
|Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform||Jan 23, 2015|
|Designing with Linux||Jan 22, 2015|
|Wondershaper—QOS in a Pinch||Jan 21, 2015|
|Ideal Backups with zbackup||Jan 19, 2015|
|Non-Linux FOSS: Animation Made Easy||Jan 14, 2015|
|Internet of Things Blows Away CES, and it May Be Hunting for YOU Next||Jan 12, 2015|
- Designing with Linux
- Wondershaper—QOS in a Pinch
- Red Hat Enterprise Linux 7.1 beta available on IBM Power Platform
- Internet of Things Blows Away CES, and it May Be Hunting for YOU Next
- Ideal Backups with zbackup
- Slow System? iotop Is Your Friend
- New Products
- 2014 Book Roundup
- Hats Off to Mozilla
- January 2015 Issue of Linux Journal: Security