Some thoughts on practicalities of web accessibility reviews

Note: This post is older than two years. It may still be totally valid, but things change and technology moves fast. Code based posts may be especially prone to changes...

(Loaded 729 times)

Before we start with a review we should have a plan. We should think of providing real value, not just covering compliance. We should define real goals and lead to real results and improvements.

The more I and learn about accessibility, the more I realize how much more there is still to learn. It is not just the technical implementation details (and they come in abundance) – it is also the differences in user expectations, their behavior and different combinations of abilities and disabilities.

So when placing myself in the start phase of accessibility review I am trying to also understand the scope of all actions that are needed for it. And I think it is not enough to just dedicate to mapping non-compliance and exposing problems.
The results should be useful for the user. Not just to create a new backlog with compliance first tasks, but to really map the important user-first problems that enable a user journey for all.

Plan for scope of accessibility review

I was thinking to start dividing the review plan into practical parts so that they can be applied to tasks as soon as possible:

  1. Define URL scope – should we just parse the sitemap or dedicate us to templates, components and other parts – or is it maybe best to export the top 100 url’s from Google Analytics?
  2. If our site is so advanced that we need to map different user journeys – then it is crucial to map them as well. Are we offering some services to the user? Then we must know how accessible they are. Is it possible for everybody to use them?
  3. Define common and generic interaction parts – for example navigation, some common forms if they exist, external plugins and tools that may be used etc.
  4. We must not forget about other digital surfaces as well. Are our emails to the user accessible? Maybe we use some documents like PDF’s as well. Are they also accessible. And maybe we are even offering a native app. Is it accessible? On all platforms?
  5. Last but not least – do we have special compliance legislation requirements? Is our digital presence spanning through different countries with different accessibility laws? There are important legal implications based on these decisions, and it can also mean to re-test larger parts if we for example test only for WCAG 2.0 and not WCAG 2.1.

I think this should point us in the right direction. The goals should not just cover compliance but should also provide value to the real users.

Therefore it is crucial to also be involved in the user experience domain knowledge, ideally study the project requirements, design style guide or even review the code base alone. And if there is any living documentation on the accessibility we should get it as well.

What should be the outcomes of accessibility review

Here we should again not concentrate only on the compliance and legislation demands, but there could be different requirements for the results as well.

So we must make sure to cover the obvious that may be required by the law, but we should also provide our clients with more value added insights about the accessibility of their digital presences. Client’s management, user experience experts, their developers, content providers, marketers and so on should all be informed appropriately.
And we should be able to make implicit task descriptions and provide some guidelines or even describe the resolution suggestions so that they become action items that can be estimated and resolved by different experts.

Review itself is not the main goal

The review should be action oriented and should serve as a basis for remediation, adding value to users and also making sure the client is continuously investing in accessibility. It is not a set and forget type of activity. It should be a living document, with constant updates, revisions, improvements and status reporting. As accessibility is improved and errors are fixed we should also be able to provide accessibility statement updates and similar reports that show the progress and set further milestones.

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: