I’ve managed to investigate quite some accessibility audits made from external companies specialized in accessibility auditing and here are some thoughts about how to act most efficiently on them.
WCAG has it’s proposition for this kind of reports and how to generate them and I think it is worth of knowing about evaluation methodology before acting on audit reports. It will make some details like scope and conformance more clear, sometimes it may even help with extraction of results into other project management tools like Atlassian’s Jira or Microsoft Azure DevOps Azure Boards.
Project role responsibility and mapping the tasks
If we are working in teams chances are we have different roles working on a project or product. There are a lot of possibilities and variations but usually we have some subject matter experts as members;
- designers (user experience and user interface designers,…),
- developers (front and back-end, sometimes so called full-stack),
- testers (quality assurance,…),
- content providers (content designers, editors, translators,…).
WCAG is a common responsibility. That should be clear from the start. But should a back-end developer fix the color contrast issues on a website? I hope not. So there are some parts of WCAG that can be a responsibility of some and not all in the team. I’ve searched the official resources and managed to find the ARRM Project – Accessibility Roles and Responsibilities Mapping (opens in new window). The project will “define an adaptive framework that will guide stakeholders to integrate web accessibility in all relevant aspects of a product or project life cycle.” and “The result will allow users to take ownership of design and development decisions related to creating accessible content”.
So ARRM Project can also be useful when we have to fix findings of an audit – who in the team, which role, will need to fix what. But it is still in progress and I needed to act on the audits. So I had to make a more pragmatic approach that is especially suitable for small teams.
Simple way of project member’s accessibility responsibilities
ARRM Project will for sure define optimal mappings based on community of experts, so I am looking forward to it but I needed a simple and quick solution, so I thought about it in the following way;
| Audit area | Project role responsible | Comments |
|---|---|---|
| User interface and user experience | UI and UX designers | Colors, contrasts, typography, responsive design planning, keyboard interaction, component interactivity with different assistive technologies and other parts of user experience. |
| Components, templates and all code related parts | Front-end / full-stack developers | Automatic testing and linting can help a lot here but coders should know the limitations and ARIA best practices. Third party code based accessibility issues should also be a part of this responsibility. |
| Images and texts | Content providers | Information architecture, heading structure, page outlines and structures, descriptive links and buttons, alternative texts for images and everything it has to do with content |
| Audio and video | Content providers | Transcripts, captions, audio descriptions, narration – that must be planned in advance to make it work and a lot of errors can be prevented when thinking about end results in advance. |
| Document (PDF, Word, PowerPoint, Excel etc.) | Content providers | Document accessibility is it’s own specialty and I think editors and content providers should hold main responsibility, making original files accessible before converting and publishing them. Sometimes it may even be better to just publish in HTML format. |
Before creating tasks we could split the report into different parts, so that each responsible team member can then make and estimate their own tasks (bugs or epics) in their project management tool.
Then it will be easier to give best estimates and save some time on task delegation. Accessibility is still a team effort, but some parts need subject matter experts that can lead the tasks.
One example is alternative image text – designer should annotate it, developer should make it possible in the code and content editor should know what to actually write based on the context.
Another example is for example a podcast – designers can design the player and the interactions of it, with annotations that would define details for development, and then content providers can add the audio track and transcript to the player.
Or in case of video – designers and developers must create an accessible video player that must support desired captions (for example closed captions), transcript and when required also support alternative track for audio description.
Documents are often also a part of the audit and a part that is maybe totally forgotten about before we receive an audit. It’s quite simple to scan a bunch of pages to a PDF and publish it on the website. But we should make them accessible and that can be quite a time consuming task if we do not plan for it. Optical character recognition can help us a lot but the document still needs to be structured properly. And it can get quite complex when we have to add proper semantics and relationships to document. Infographics, tables, forms and so on make this quite time consuming if not difficult. So I would suggest to maybe just make the information available in accessible HTML.
Prioritization of tasks based on user impact
After we assign issues to team members that are responsible to fix them they should be able to prioritize between them to fix the issues with most negative effects sooner and make a positive impact on end users. I know, this can be difficult, how can we prioritize if we do not have the numbers to support us. Which accessibility error exposed in the audit has more weight – causes more problems? Are there any end-user complaints already that we should maybe prioritize? Is color contrast more important than screen-reader only status message?
I will not dare to provide a one-for-all answer here as it really depends. Some people like to base their prioritization on some sort of analytics, but that can be very difficult because we can not get real numbers. Assistive technologies and users that have a disability can not be tracked in the same manner as for example countries of origin. That is a good thing in terms of ethics and privacy but I’ve noticed that many stakeholders would prefer to have the numbers before making priorities. Same goes for people that need to prioritize the tasks they got.
As WCAG is divided into levels A, AA and AAA we could take that as a starting point, but in reality it can be more difficult to do so, especially when some errors might have much greater impact on the end-users. So yes – difficult case-by-case evaluation.
Breaking audit errors into work tasks
To be able to estimate the work needed we need to break errors into tasks and then estimate the parts. As always we need to break tasks into small enough pieces, so that we can make better educated guesses (as estimates really are). With experience and cross-team knowledge it gets easier, but can also be a quite difficult task in itself.
We need to be clear about acceptance criteria before we can estimate the tasks. Otherwise we may turn into unpleasant situations when we forgot to involve critical parts.
WCAG knowledge is therefore key and we need to check the suggested parts as well as required ones. WAI-ARIA Authoring Practices should also be used as a good basis and both designers and developers should get familiar with them. Keyboard interactivity and user experience, common code and visual patterns will for sure help us a lot and can also serve as our acceptance criteria when not implemented before.
Reaching beyond WCAG
When organization or a team really integrated accessibility into their processes it may also be worth reaching beyond WCAG. At least beyond level AA conformance. Some level AAA success criteria can really make an impact but we must remember that sole WCAG conformance is not a guarantee for accessible solution. So testing with real world users, people with different (combinations) of disabilities, user of assistive technologies can demonstrate even further improvements that can stretch beyond WCAG and really make a difference.
