The Drupal Developer's Guide to Web Accessibility Compliance

Before we start, I’ll use several common terms when describing accessibility so here’s a quick guide:

Common web accessibility terms

 

  • WebAIM - Web Accessibility in Mind, Center for Persons with Disabilities

  • W3C - World Wide Web Consortium, an international community that develops web standards

  • WCAG - Web Content Accessibility Guidelines, developed through the W3C process to develop standards for web accessibility

  • WCAG 1.0 - Web accessibility standards organized around guidelines that have checkpoints, which are priority 1, 2 or 3

  • WCAG 2.0 - Web accessibility standards organized around four design principles, each having its own guidelines with its own testable success criteria at level A, AA, or AAA

  • SEO - Search Engine Optimization

  • UI/UX - User interface/User experience

Who?

 

Disabled and elderly users

Who am I talking about when I talk about accessibility? Well, it really covers many groups of users including blind users and users with low vision or partial sight, reduced fine motor skills and cognitive limitations.

Blind users utilize various devices to browse the web including screen readers and braille keyboards. Luckily for us, the University of Wisconsin-Madison has created an informative “Accessibility Video Series" on the web that covers screen readers and magnification. Another video of a blind teenager testing an Inspris Super Braille keyboard helps to give a perspective of where braille devices are headed in the near future.

Mobile users

When I talk of accessibility, I’m also referring to users of different devices including mobile devices, laptops, tablets and even TV’s. (Note: For efficiency’s sake, I’ll refer to this group as “mobile users” in the rest of this blog post.) With the advent of responsive and adaptive web design, and even mobile websites when done properly, these users are also getting more of an accessible web experience than they were in the old days with static websites. Hopefully this positive trend will continue.

A great, eye-opening video on the future of the web is “Mobile First” by Luke Wroblewski which took place at An Event Apart in 2014. In it he discusses the growing mobile user movement globally, and how you’ll need to stay ahead of the curve by creating clean, mobile-first sites that in-turn help mobile users navigate through your site to get to what they want and need. See “How mobile is overtaking desktop for global media consumption, in 5 charts” to get a visual reflection of this data.

What?

 

Everything from image alt tags to labels for form fields should be included in accessible development. It’s good to start with a set of principles and guidelines created by the groups who have set the web standards, and go from there.

With WCAG 2.0, WebAIM created the concept of POUR for developers as HTML-related principals to encourage flexibility when building accessible sites. They include:​

  • Perceivable - Web content is made available to the senses - sight, hearing, and/or touch. See guidelines.

  • Operable - Interface forms, controls, and navigation are operable. See guidelines.

  • Understandable - Content and interface are understandable. See guidelines.

  • Robust - Content can be used reliably by a wide variety of user agents, including assistive technologies. See guidelines.

Source: http://www.oneguidelineaday.com/wcag-20/about-the-four-principles/

Another great resource for developers is the W3C Demo Site. It’s an informative before and after demo site showing an accessible and inaccessible version of the same site.​

When?

 

If you haven’t already, now is the time to start incorporating accessibility best practices in your daily development cycle. You can start by researching WebAIM, W3C Web Accessibility Initiative, WCAG Overview, or even by browsing the search results of the phrase “web accessibility”.

Where?

 

Everywhere! The standards for accessibility are already available to you. The real decision to decide is which set of standards to start our with: Section 508, WCAG 2.0 A, WCAG 2.0 AA, or WCAG 2.0 AAA. Luckily there are some helpful checklists and quick references available to guide you through that decision:

Once you’ve decided on the standards your organization is going to adopt, you’ll then need apply them to your team’s regular development process from beginning to end.

Why?

 

There are 3 main reasons:

1. It’s the law:

2. It’s good for business (and can be bad for business)

The Good:

Two good case studies according to W3C are the Legal & General Group (L&G) and Tesco.

UI/UX

If a user is able to easily go through a site, they will find what they’re looking for more easily and be more-likely to revisit that site in the future.

SEO

If the site is designed properly with accessibility in-mind, search engines tend to index them quickly which in-turn can mean higher search results. Best practices can equal better productivity.

Device independent (i.e. responsive web design)

A well-developed, mobile-first site means that all users get the same information while the organization doesn’t have to maintain several different sets of stylesheets.

​The Bad:

Target case

Target create a non-accessible site. In 2005 the National Federation of the Blind (NFB) went on their site and discovered that it wasn’t accessible and reported it to Target. Target would not remedy this. They fought Target in court in 2006-2008. Target tried to claim that they didn’t have to be accessible because they were a private business.

The courts ruled against them and Target settled in 2008 for $6 million and attorney’s fees of $3.7+ million. Target had to completely redo their site to make it accessible and pay the fine.

Source: https://www.w3.org/WAI/bcase/target-case-study

Sydney Olympics case

The Sydney Organizing Committee for the Olympic Games (SOCOG) created an inaccessible site for the 2000 Sydney Olympics. A blind web user attempted to browse their site using his refreshable braille display. Unfortunately he had issues with viewing alt tags on images, gaining access to the Index of Sports page from the Schedule Page (which would have simply required a link), and gaining access to the Results Table during the games on his braille device.

The respondent argued that they were working on the alt tags during continual development, that the plaintiff could copy/paste the UR to the Schedule Page in his browser, and development of an accessible table would cost them $2.2 million AUD over 368 working days.

They lost their case and the plaintiff was awarded $22,000. The consequences of this case were that Australia adopted the W3C Guidelines, and their Commonwealth Government required all agency websites to pass accessibility tests by December 1, 2000.

Source: https://www.w3.org/WAI/bcase/socog-case-study

3. It’s the right thing to do:

  • As we’ve seen, it’s not always easy to browse the interwebs for users.

  • People crave information, and it’s our job to deliver it to them in the most efficient way possible.

  • Instead of thinking from the organization’s point-of-view, we should instead think from the user’s point-of-view when selling, planning, developing and testing websites.

In Summary

 

In Part 1 I’ve gone over which users I’m referring to with accessibility, what steps you can take to start on or improve upon your path, types and levels of standards, resources for creating standards for your organizations, and motivations for developing in an accessible way.

Check out Part 2 next week where I’ll cover how you can apply these standards to your daily development with some simple code examples, as well as providing some web-based tools available to you for testing your site’s accessibility.

Need help getting started with acessibility compliance? We can help!

 

homepage audit button.png

Resources

 

  • “Accessibility Video Series” from the University of Wisconsin-Madison contains the following three individual videos: