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.
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide
- SUSE LLC's SUSE Manager
- Tech Tip: Really Simple HTTP Server with Python
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Google's SwiftShader Released