The 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 benefits the most from web accessibility compliance?

Everyone, definitely. But most especially the following groups:

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 do we optimize for web accessibility?

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.
• Operable - Interface forms, controls, and navigation are operable.
• Understandable - Content and interface are understandable.
• Robust - Content can be used reliably by a wide variety of user agents, including assistive technologies.

When should we start incorporating these practices?

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, and by checking our articles on web accessibility.

Where do we apply accessibility practices?

Everywhere! The standards for accessibility are already available to you. The real decision to decide is which set of standards to start out with. Luckily we have written a couple of articles on web accessibility. Check out how to bake accessibility in your design and development, our quick guide to WCAG principles and perspectives, and how to perform an accessibility audit.

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 should we comply with web accessibility guidelines?

There are 3 main reasons:

1. It’s the law.

Check out these resources to understand the legal side of accessibility:​

• Section 508 of the U.S. Rehabilitations Act of 1973, as amended in 1988

• UN Convention on the Rights of Persons with Disabilities

2. Non-compliance is bad for business.

Here are some ways it benefits your business:

• 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, that means your site is set up really well, making search engine crawling and indexation easier. This in turn gives you better visibility. 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.

Here are two cases to show how non-compliance is bad for business:

Target case: Target created 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, so they fought 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.

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.

3. It’s the right thing to do.

As we’ve seen, it’s not always easy to browse the internet for users with disabilities.

People crave information (and need services), 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 web accessibility compliance? We can help!

Promet Source offers a simple, straightforward path to achieving ADA digital accessibility compliance for your websites, web applications and technical products. Request a free introductory consultation with our Promet Accessibility team.