So you need an accessibility audit of your website?

Oh boy!

There are lots of ways you can approach an accessibility audit. Unfortunately, without knowing any better, lots of people approach it as an unpleasant task.

However, I have found that a good accessibility audit often reveals issues which can be addressed in a way that will improve the website and overall user experience.

The Importance of Web Content Accessibility Guidelines (WCAG)

At the most basic level, the WCAG are a set of criteria for measuring accessibility of web content.

However, the actual collection of WCAG documents goes a bit further than a simple list of rules.

Comprised of supporting documents to explain how to use the WCAG, explanations of success criteria, and the actual guidelines themselves, the WCAG is a robust collection of information designed to help alleviate doubt and misunderstanding about web accessibility.

Created by the World Wide Web Consortium (W3C), a non-profit collection of super smart people dedicated to maintaining the function and philosophy of the World Wide Web, there is no ulterior motive or profit driven agenda. The only interest of the W3C in creating and maintaining the WCAG is to help facilitate an accessible World Wide Web.

The WCAG is the definitive source and authority on measuring accessibility of web-based content.

At the highest level there are four guiding principles of the WCAG:

• • • Perceivable
    • Operable
    • Understandable
    • Robust

These are the broad strokes that organize a lengthy delineated list of criteria. The complete WCAG criteria are organized into a hierarchy of three levels, Single A (WCAG A), Double A (WCAG AA), and Triple AAA (WCAG AAA).

The WCAG have undergone revision, and are currently on version 2.1. Version 2.2 is currently being reviewed, and is expected to be released sometime in the not too distant future.

Currently, WCAG 2.1 AA is the accepted standard identified by courts and governments around the world as an acceptable baseline for accessible web content.

Basic Process for Auditing with WCAG 2.1 AA

In a nutshell, an audit is conducted by assessing the various content of a website according to the relevant criteria from WCAG. Some tools can help automate part of the assessment, but there is always a need for manual testing.

While the WCAG provides a good baseline for determining accessibility, there are additional concerns under the category of Usability which also need to be considered when auditing a website for accessibility.

Here is the Standard Operating Procedure I employ:

1. 1. 1. Initial Survey of Site
      2. Identify Representative Pages
      3. Assess Pages (Automated)
      4. Assess Pages (Manually)
      5. Assess pages with NVDA
      6. Consider Content
      7. Consider Interactivity
      8. Compile Report
      9. Review Report with Client

Simple, straight-forward, and at the end of it all there is a report identifying each issues as a line item inventory, referenced to relevant WCAG criteria, and identified by code and line number from the source HTML file.

It’s everything you need to clean up accessibility errors, and it provides a chance to assess your workflow to find places where you can add best practices in an organic manner that will help you create accessible content going forward.

Initial Survey of Site.

The first thing I do is perform a quick assessment of the site scope and purpose. I quickly browse through the main menu items, take note of patterns and different types of page content, forms, modals, interactive elements, general size, and complexity of the site.

If there is an obvious business function the website is supposed to deliver, I see if I can initiate the process via the keyboard and pursue it until something critical breaks, or they ask for a credit card number.

Depending on the size and nature of the site, this can take anywhere from a few minutes to over an hour.

Identify Representative Pages.

After I have an understanding of the size and nature of the website, I identify a sampling of representative pages from the site for audit.

As most websites repeat basic layout patterns through templates and content management systems, it is often not necessary to test every single page. The issues you find on one page will likely exist on every page created from that template, and you end up finding the same type of issue over and over.

It is also common to find a category of accessibility issue which exists throughout a website due to a systemic design/development practice, or from issues contained in source templates and themes.

Gathering a subset of pages with layout and content types which are representative of the rest of the website allows for more efficient and effective testing.

Assess with automated and manual tests.

There are several different tools available to help with accessibility testing. Some are dedicated software which monitor and report on accessibility over time, while others are on-demand scanners, providing a snapshot in time of the status of web content.

There are several free plugins for popular Internet browsers which can tell you whether a web page contains content out of conformance with the WCAG standards as well as other usability concerns.

It is important to remember that any automated tool is going to be limited in what it can determine.

Just like computers can’t identify an image with a crosswalk, traffic light, or bus, they also can’t determine all the accessibility issues which might be present on a web page.

Assess pages with NVDA screen reader.

There are many things which a computer can detect, but nothing beats the real-world test of using a screen reader. For best results with screen reader testing you should always employ the assistance of a blind individual if possible.

There are distinct and unique aspects of user patterns and behavior when approaching web content from a non-visual perspective. Getting beyond your ingrained habits (and limitations) as a sighted individual requires practice and dedicated awareness. It can be challenging, but it is not impossible.

Because I spent many years teaching people how to use screen readers, I know enough to be aware of common and typical usage patterns and expected behaviors for non-sighted interaction with digital content.

The end goal of all this is to identify usability issues beyond what can be detected from analyzing the underlying code.

However, I also know and admit freely that nothing compares with a bona fide usability test from individuals who use a screen reader every day as their sole means of accessing the Web. I know my abilities to use a screen reader are never going to be as robust, and I do not hesitate to enlist help from individuals who are blind when necessary.

Consider Content Issues.

The usage of different types of digital content brings an expectation of certain behaviors and capabilities. Specifically interactive content such as forms, audio and video, and web applications. End-users expect these things to function according to established design patterns. When the design pattern is not followed, the content effectively will not function for these individuals.

The World Wide Web, being designed to support a wide range of technologies and content, allows for great flexibility in how a person can design and present content. There are no requirements to follow any design patterns at all, which creates a wonderful sense of freedom for creators and a damning amount of chaos for end-users.

People being the ever-clever rule breaking upstarts that they are, continuously expand the envelope of how to mis-use, abuse, and generally confuse the expected paradigms, patterns, and procedures for delivering the many different types of content.

So it is that we end up needing to check certain types of content, much like a list of repeat offenders kept on the wall of a local police precinct.

As new content types emerge, accessibility specialists evaluate and determine authoring strategies to ensure accessibility of the content. These potentially problematic content types become known and tracked, a cause for concern wherever they turn up.

Tsk tsk tsk Mister Modal – back again, are we?

Consider interactive issues.

There are many ways an object can invite a user to interact with it. Unfortunately, without deliberately paying attention to the access strategies for interactive design, some content can fall short on their offer to deliver an interactive user experience.

Without expressly seeking to maximize the accessibility of your interactive elements, you can create expectations and disappointing user experiences without even knowing it. Effectively leaving your audience frustrated out in the cold as they see the party happening just beyond their reach.

Sometimes it is a case of missing identity where a critical piece of interactive content is present but not labeled, and is therefor invisible and unknown.

Other times a designer creates a widget that works wonderfully with a mouse, but it does not work at all with any other sort of input device.

Some interactive content is simply missing a required component, such as failing to provide captioning for digital video. These authoring failures can reveal ignorance, inability, or indifference on the part of the content creator.

Unless you are creating radical new content types, there is really no excuse for failing to deliver truly interactive content. There are known and documented approaches for ensuring accessibility with most known interactive content.

The solution to these interactive problems is usually pretty straight forward: get yourself to W3C and become informed about what you are trying to accomplish – so we can ALL go check it out.

Compile Report.

Understanding what to look for in an accessibility is only part of the challenge. Compiling the final report on what is found is where the ultimate value comes in.

More than a simple collection of issues to address, a web accessibility audit should present the issues in a way which facilitates the identification and remediation of accessibility concerns.

I always include a summary page with an overview of the different WCAG criteria which needs to be addressed, along with some helpful references to help explain the significance of the issue and how to address the issue to alleviate the accessibility concern.

I also provide a detailed inventory of issues for each of the representative pages I identify initially. Each occurrence of an issue is entered as a distinct line item, time and date stamped at time of audit, with corresponding WCAG criteria, severity of impact on accessibility/usability, source code and line number, and a link to an explanation of how to address the concern.

Additional data gathered from content, interactivity, and screen reader perspective are also aggregated and provided as separate categories.

With a detailed report of the accessibility audit, a designer/developer can effectively correct the accessibility and usability issues while also identifying the aspects of their workflow where accessibility can be addressed organically as a normal and ongoing part of quality control.

Review Report with Client

After the audit has been completed and the report has been compiled, I share the report with the client and schedule a meeting to go over the report and respond to any questions they might have.

This is typically adequate for addressing the accessibility concerns of most websites, though for some websites with greater complexity might require additional training.

While a good accessibility audit will reveal work to be done, it also provides peace of mind in knowing the extent of any issues affecting accessibility and usability.

Going through an accessibility audit the first time might be a little intimidating, but as you work through the issues, you are creating a quantifiable difference in your content, and eliminating potential cracks in the user experience where your audience might slip away.

After the first accessibility audit, additional recurring audits will find far fewer issues, and become much less exciting. Eventually, accessibility audits become part of the regular rhythm of a successfully designed and functional website, and ultimately become one less thing to worry about.