Shortcuts to WCAG 2.0 AA Compliance
Recently I was asked if there were any products or services that would give users equivalent or greater accessibility than WCAG 2.0 Level AA. This is part of the feedback process for a report on web accessibility for state and local governments.
In addressing this I wanted to make it clear that, at the root accessibility is about eliminating barriers to communications. Tim Berners-Lee saw the potential for the web being a great equalizer as it could allow people to communicate in a way which was completely inclusive. In practice, the web has evolved to provide barriers to 10-20% of the population.
In short, there are no products or services that you can purchase which will bring any website up to WCAG 2.0 AA or greater and there never will be. To meet WCAG 2.0 requires attention to both the system that creates the pages and the author that generates it. To help with this a new W3C accessibility guideline that has been recently released, the Authoring Tool Accessibility Guidelines (ATAG) 2.0.
ATAG 2.0 is a guideline which helps to guide content authors to produce more accessible content. It is an acknowledgement that many accessibility problems with websites are produced by not by the site’s design, but by choices made by the author. ATAG provides clear steps that can be taken to ensure that content authors are given proper guidance.
Drupal 8 has achieved a great deal in setting solid, accessible precedents. The centralized infrastructure makes it easier for modules and themes which extend Drupal to adopt best practices. Many developers will adopt Drupal’s best practices, simply because it is often easier to copy an existing default example, rather than code something from scratch.
Still, to achieve WCAG 2.0 AA you need to ensure that the organization has staff who understand web accessibility issues. WCAG 2.0 AA may require changes in corporate style guides, re-thinking how meaning is conveyed to visitors and changing procurement policies.
Fix or Rebuild?
I’m quite certain that most organizations will try to remediate their existing websites. For most instances properly remedying their old technology will cost them more than rebuilding it with a tool like Drupal. The challenges are very much like physical accessibility. If you’ve got an old heritage building you need to make accessible (many people’s legacy systems), it will be cheaper in most instances to build new than retrofit.
If accessibility is incorporated early in the process, it may not cost more than 5% more to see that the site meets WCAG 2.0 AA. The later that it is left, the more expensive it becomes. Unfortunately, most organizations assume that it comes for free.
The more complex and interactive a website is, the more difficult it will be to make it accessible. Often accessibility reviews also point out usability problems, particularly for big, complex sites.
Web pages really shouldn’t be built page by page any more. That was appropriate in 2006, but not in 2016. Any review needs to look at the system. A Content Management System like Drupal 8 will help raise the level of accessibility & usability for everyone. There are over a billion .gov pages according to Google. This is a big problem, but thinking of fixing it page by page will not resolve the problem.
The web is made up of libraries, like Drupal. Most of the internet is driven by open-source & open standards. If common libraries complied to open W3C standards, this would be a small issue. Governments need to adopt and invest in open-source tools that have made a commitment to accessibility. Rather than thinking about these problems in a page by page and site by site means, government should be looking at the systems that they use and how to adopt best practices going forward.
Process for Change
A good accessibility audit can cost $400/page. We understand that with a billion pages this will be an unbearable cost for tax payers. However, the only affordable way to proceed is to :
- Start with solid, accessible open-source tools like Drupal 8
- Build in automated testing so that it is built into the process of measuring standard site performance
- Train key people to do keyboard only testing on sites. If a page is keyboard accessible, it will be pretty accessible to everyone
- Hire experts to do screen-reader testing on specific areas to see that they are able to access all of the content
- Share first - find ways to contribute your findings back to the community
An accessibility review by an approved external 3rd party should be considered part of any web projects.
Like security, accessibility is a huge challenge which requires persistent vigilance. The web is constantly changing, as are our expectations of it. Governments can benefit from engaging with open-source communities to share both problems that their citizens raise as well as solutions that they have adopted to try to mitigate them.
About The Author
Mike Gifford is the founder of OpenConcept Consulting Inc, which he started in 1999. Since then, he has been particularly active in developing and extending open source content management systems to allow people to get closer to their content. Before starting OpenConcept, Mike had worked for a number of national NGOs including Oxfam Canada and Friends of the Earth.