A P P E N D I X  E

Accessibility

by Mike Gifford

Drupal 7 has made a huge leap towards universal accessibility thanks to the contributions of almost 400 people over the last three years. Drupal 7 core is one of the most accessible content management systems/platforms available today. Both public and administration pages have been reviewed for accessibility problems, and many barriers to participation have been eliminated. Drupal's modular structure uses APIs and hooks to make core functions available to themes and modules, which means that many of the enhancements in core will be inherited when developers are customizing sites. Unfortunately, this does not mean that every site developed with it will be accessible.

Recent Enhancements

The Forms API has seen a great many enhancements to ensure that interactive elements of a site are as accessible as possible, including the following:

• Skip navigation has been brought into all core themes, and there are default approaches to dealing with hidden, invisible, and visible display settings on focus elements.
• There are improvements in providing sufficient color contrast and intensity for people with low vision. In addition, images have been added to system messages to provide additional visual cues for all users.
• Likewise, there have been enhancements to the password management system to encourage everyone to have good passwords, including a progress bar that uses WAI-ARIA to alert screen readers about the level of security. (For more on WAI-ARIA, see the “Bring in WAI-ARIA” section in this appendix.)
• In most cases, drag-and-drop interfaces present barriers for blind users. To address this, drag-and-drop re-ordering can now be disabled by the user as required.
• Alerts have been added for some of the interactive elements that are added by jQuery. A screen reader user is now informed of the short list provided by auto-complete.
• Drupal core can now be both installed and administered by blind and/or keyboard-only users. The web site's content can also be viewed effectively by more people with disabilities.

What Are the Standards?

The World Wide Web Consortium (W3C)'s Web Accessibility Initiative (WAI) has been leading the development of international standards for accessible technologies. In the United States, the national standard is Section 508; however, it's being revised and will likely reflect Web Content Accessibility Guidelines (WCAG) 2.0.

Drupal is global community, and therefore we chose to test against WCAG 2.0. We also used some of the draft Accessible Rich Internet Applications (ARIA) Suite options, which allow screen readers to receive alerts when content changes dynamically.

Released at the end of 2008, WCAG 2.0 has broadened its scope from the web and aims to be technology-neutral. Rather than focusing narrowly on HTML, these guidelines offer the more general requirement that a site should be perceivable, operable, understandable, and robust (POUR). There are a number of techniques defined within these guidelines to help ensure that a site does not present barriers to its users.

As we begin to expect more dynamic, interactive web behavior delivered to a wider range of devices, it becomes increasingly important to have a generic set of guidelines that are flexible. This is why in WCAG 2.0 was built around the POUR principles, which essentially ask you:

• Can all users perceive your content? Simple things like testing color contrast and providing alternative text and captions for images and non-textual content can help with this.
• Can everyone operate your site? The tools people can now use to interact with web sites range from a mouth stick and head pointer to specialized software, keyboards, and screen readers.
• Is your site understandable? Does the user interface operate in a predictable manner? Are there ways for users to quickly identify their mistakes and correct them?
• How robust is your site? Is it future-compatible and based on open standards? What existing technology will you support and use for testing?

Who Benefits?

Yes, blind people will benefit if accessibility best practices are followed, but you already knew that. They represent a minuscule sub-section of the population, and they're just one group of users with disabilities to consider. In a 2005 survey conducted in the U.S. by the Survey for Income and Program Participation (SIPP), it was estimated that there were 54.4 million people with disabilities.

The classic icon for accessibility is the wheelchair, but when using the Internet, many people who use wheelchairs are in no way disadvantaged. The above estimate of people with disabilities includes people with mobility impairments but probably doesn't include those who are colorblind or dyslexic. We can only get rough estimates for the number of people with the latter two afflictions, but it's a significant portion of the population—and a somewhat invisible one as it's not possible to tell at a glance if someone is dyslexic.

The enhancements in Drupal 7 aren't just going to benefit those we readily recognize as being disabled. Most countries are facing a rapidly aging population; this means an increase in users who have problems with their vision, fine motor control, and hearing. By developing for the more demanding requirements for accessibility, we are able to ultimately find solutions that improve everyone's user experience.

Accessibility issues will affect everyone, even if only temporarily. As we age, our bodies and our minds change in ways that make technology harder to use and accessible design more important. And as we collectively live longer, the number of people who will benefit from accessibility enhancements grows. Accessibility issues are ultimately ones that are about our humanity.

It's the Law

There is a good chance that you are living in a country that has signed the United Nations Convention on the Rights of Persons with Disabilities. This convention is a commitment to allow inclusive participation by all. Furthermore, many countries have or are developing their own legislation for accessibility. In the USA, the Americans with Disabilities Act has shown leadership by recognizing the right for people with disabilities to live life independently and participate fully in all aspects of life. Australia, Belgium, Canada, Denmark, Finland, France, Germany, Hong Kong, India, Ireland, Israel, Italy, Japan, Korea, the Netherlands, New Zealand, Portugal, Spain, Switzerland, and the United Kingdom also have laws governing accessibility and information communications technologies.

Accessibility is becoming a legal requirement, and organizations need to be aware of this. In fact, government agencies and for-profit companies have been sued because their sites presented barriers to disabled people. This doesn't happen often, but both Target and the International Olympic Committee have been successfully sued for failing to implement accessible web sites.

Nine Ways to Make Your Site Accessible

Drupal 7 provides you with a solid framework to build a very accessible web site, but it isn't enough to ensure that your site is accessible. The implementation of contributed themes and modules can easily set up barriers for your users. The structure of user-generated content and the implementation of image fields can create further barriers.

There is a lot that could be written on this, but we'll be limiting this to the basics of choosing good modules and themes. We will take a look at color and contrast, as this is one aspect of accessible design that is often overlooked. We'll then look at how to set up automated testing and do your own simulation. Finally, we'll look at how to keep your site current regarding new standards to ensure that it stays accessible to everyone.

Accessible Modules

Drupal modules range in complexity and reliability. Drupal Core's hooks can be called from modules and themes, which can alter much of Drupal's core functionality. This means that if a module isn't developed with accessibility in mind it can degrade the accessibility of your site. You can search for accessibility issues for modules within the issue queue to see if there are any known issues with the modules you are installing (see drupal.org/project/issues/search/?issue_tags=accessibility).

If you run into an accessibility issue that isn't listed in an issue queue, please add a bug report to the issue queue so that it can be addressed. It is only through actions like this that we can improve Drupal's thousands of modules and themes, and develop best practices for accessibility.

The goal of the Accessible Helper module (drupal.org/project/accessible) is to make it easier for your site to be accessible. There are also sub-modules that allow you to easily implement improvements in accessibility for your site's theme, modules, and content.

Theming Your Site

There are good contributed base themes like AdaptiveTheme, Genesis, and Zen that work well for Drupal 7 and have been tested for accessibility. Starting with a solid base framework will help make sure your theme is accessible.

When developing your theme, don't forget to add alt tags to all of your images. Meaning is often conveyed to users visually through images, and it's important to take the time to think how to express that to someone who may not be able to see them. Using automated testing tools (discussed later) is a great way to catch missing alt tags for images.

The Drupal guide to theming accessible sites (drupal.org/node/506866) is quite good, and there are many ways to make the job of producing an accessible web site easier. Using CSS3, you can now provide some of the same effects you previously needed to use images for, such as rounded corners and great 3D effects. The CSS border-radius property and proprietary extensions for Webkit and Mozilla allows you to add depth to objects. Eliminating images makes web pages more accessible, faster, and easier to maintain.

Be very cautious of the use of the CSS display:none property, as screen readers interpret it literally. When an item is styled with display:none, it's invisible to screen readers as well as on-screen displays. Make sure that any lists of links (like a menu) has a header (usually an H2). If it needs to be hidden from sighted users, use the new Drupal CSS class .element-invisible.

Developing to a standard will save time and money over the life of the project. Ensuring that your theme validates against W3C guidelines will ensure that your site is future compatible and also that it will present well for a broad range of browsers. Using free tools like the W3C's (validator.w3.org) or Validator.nu (validator.nu) will help you find problems in your CSS and HTML.

Contrast and Color

Understanding the many different ways people see the world will improve your ability to design for them. The Drupal docs have some great resources about the use of color and the need for proper color contrast; see drupal.org/node/464500.

Many sites don't provide enough text contrast for the content to be easily read by all users. There are simple tools to ensure that your site provides enough contrast for low vision users, such as webaim.org/resources/contrastchecker.

Color is often used to convey meaning to users, but not everyone can differentiate between all colors. Eight percent of the male population has trouble seeing color. If you want to communicate important messages to your users, use color along with position, proximity, and graphical elements like icons. This extra attention to clarity will also help people with learning and cognitive disabilities decipher and navigate your site.

Automated Testing

Once you have done all this, the next step is to use automated testing tools to evaluate what you might have missed. WebAim's WAVE (wave.webaim.org) is a great tool for testing sites for known barriers. They offer a Firefox toolbar that is especially handy for determining the impact on interactive pages that require a user to be logged in. The Functional Accessibility Evaluator (fae.cita.uiuc.edu) evaluates a single web page and offers additional features after you register. Tools like the Mozilla Firebug Ainspector (code.google.com/p/ainspector/) can extend the popular Firebug tool to allow you to produce reports on accessibility.

There are a number of tools that can help you get a better sense of how others are perceiving your web site. Google's search bot remains the largest, richest, blind web user, so the more you provide semantic information for your content, the better your SEO is likely to be—and also your accessibility. Although screen readers don't work in the same way, it's worth checking out a site in Lynx to get a sense of how it's viewed in plain text; see en.wikipedia.org/wiki/Lynx_(web_browser).

Simulation

It's also good to unplug your mouse and try to navigate around your site. The core themes and the ones suggested previously have an option to skip past or straight to the navigation links in a site. This allows keyboard-only users to navigate your site more easily. For more information, see the AIM site (webaim.org/techniques/keyboard/).

The most powerful, and arguably the most popular, screen reader is JAWS; however, other free screen readers are quickly picking up in popularity. Anyone using a modern Apple computer, iPad, or iPhone has VoiceOver built right into it. Windows users can download the free software application NVDA (www.nvda-project.org), and Linux users can use ORCA (live.gnome.org/Orca).

A sighted person can learn to navigate a site using a screen reader, but it is just an approximation of what a blind user would experience. Even someone who is recently blind will navigate a web site differently than someone who was born blind. A web developer will learn a great deal in navigating their own web site using a screen reader, but they bring with them the visual knowledge about how the information architecture works. To really understand how to best facilitate blind users' (or any disabled users') navigation of your site, it's always good to encourage feedback from people who have those disabilities themselves.

Bring in WAI-ARIA

Some elements of the Accessible Rich Internet Applications (WAI-ARIA) standard were brought into Drupal 7 core. WAI-ARIA is still a draft document so its use was limited. It was added in places where there was no other way to communicate to a screen reader an important piece of information. WAI-ARIA can offer more tools for adding semantic information to your site.

WAI-ARIA landmark roles define keywords for specific blocks of HTML to convey more meaning to screen readers. Landmarks allow a web developer to divide up a web page to make their content easier to navigate. The Juice Studio Firefox plug-in offers support in identifying the landmark roles that are defined in your site (juicystudio.com/article/examining-wai-aria-document-andmark-roles.php).

Drupal 7 and jQuery provide many interactive elements. The more dynamic elements are used, the more important it will be to add support for ARIA's live regions so that their messages can be effectively communicated back to the screen reader. By being able to define the importance of the interactive element as “polite, “assertive,” or “rude,” a screen reader can be instructed to either interrupt the existing text it is reading or wait until it's finished.

Maintenance is Critical

People often approach accessibility guidelines as another thing to simply check off and be done with. Ultimately, though, this isn't a very useful practice. What's really needed is a code of practice rather than a list of checkboxes.

WCAG 2.0 provides an important set of success criteria for accessibility, but this is only so useful in isolation. Having a perfectly accessible web site (WCAG 2.0 AAA) just is not attainable in anything but the very simplest site. Sites should attempt to achieve as many success criteria as they can, but it's important to schedule regular reviews for ongoing enhancement and to make sure that the publishing practices of the site continue to create accessible content.

Drupal is a powerful framework, and any user-generated content is likely to be a source of accessibility problems. Modules like HTML Purifier (drupal.org/project/htmlpurifier) can help ensure that all xHTML is valid. Other modules, such as the Accessible Content module (drupal.org/node/394252), offer specific accessibility enhancements to Drupal core.

Schedule Regular Reviews of New and Old Pages

Commonly accessed pages should be regularly reviewed by automated testing tools, and a structure of regular randomized tests will help keep your site as accessible as possible. Ideally, a large site would bring in a focus group periodically to provide feedback. Ongoing evaluation is the only means by which a site can be perpetually upgraded to reflect the changing technology and behavior of its users.

When testing, be strategic about your process. Working with Drupal 7, you can reduce your testing workload by eliminating some of the unknowns. After that, it's a matter of picking a few strategic pages to test representative functionality.

Get Expert Feedback

Consider bringing in an accessibility professional to assist you in improving your site. Best practices in delivering accessible content are changing constantly, as are the software and hardware that disabled people use to access your site. As new standards are developed and adopted, best practices need to be reconsidered to ensure that the content is being effectively displayed.

Bringing in an external person or team to review your site and look for enhancements can be well worth the investment. They will know how to look for and eliminate common barriers that an automated testing tool won't be able to detect. Also, consider hiring someone with a disability to do this review; we all learn to use technology in different ways, and the experience of disability is something that can't be fully simulated.

If you have a question, you can post it to the Accessibility Group (groups.drupal.org/accessibility) and you can read the documentation about Drupal's Accessibility initiatives at drupal.org/about/accessibility.