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:
- 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?
- 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?
- Define common and generic interaction parts – for example navigation, some common forms if they exist, external plugins and tools that may be used etc.
- 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?
- 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.
