We need more awareness on the importance of accessibility and when we achieve it we need another kind of awareness – the common effort one!
It is unfortunately still very common to treat accessibility as a (front end) developer and tester responsibility only. And I feel that this is just wrong. If we let this to happen we end up with a huge backlog of errors in best scenario. Or most likely with inaccessible product.
Should a developer solve poor contrast? She could but it could lead to huge design issues.This is only one proof that we need to split the different responsibilities to cover all WCAG success criteria.
There are some parts of WCAG that need a developer, but there are also parts that need other roles first and even some parts that are totally non development ones.
I will try to present this in a table and then elaborate on it:
Roles | Responsibilities | Comments |
---|---|---|
Project owners, managers and stakeholders | Set accessibility as a requirement, assign responsibilities, define WCAG target level, monitor and report | Leadership must be aware of needs for accessibility beyond legal compliance. |
Visual (UI) and interaction designers | Text contrasts, interactive component contrasts, use more than color alone, keyboard focus indications, consistent navigation and presentation, define landscape and portrait orientation, plan for animations, dark and high contrast modes. | Some responsibilities scope between user experience and user interface designers. |
UX / interaction designers and front-end developers | User journeys that work for all kinds of users – keyboard only, screen-reader, incorporate WCAG best practices like extending time limits, allowing users to stop, pause audio and animations, content design and consistency of overall experiences and more. | Defining visual to semantic mapping, together with visual designers and developers. |
UX / interaction designers and content editors | Content must be planned for multi sensory users – this means in practice alternative text for images, audio and video, descriptive titles and headings, form design with clear and simple instructions, clear text and when necessary dictionaries and explanations that explain special terminology etc. | Interaction and content need to work together, content must support beyond visual only, semantic |
Developers and designers (UI and UX) | Semantics from visuals defined by visual and interaction designer must be translated to correct code. Name, role, state are the basic blocks and should be cross-checked and synced from both sides. Use of semantic HTML over unorthodox patterns should be encouraged and user agent support should always be checked. Enabling general and by component properties – like for example language – by the developer should be synchronized with designers. Also assistive technology user experience should be a common effort and goal. | When developers understand the accessibility acceptance criteria, the complexity of user agent support and also get accessibility annotations from designers it is much more efficient to only discuss the remaining parts. |
Quality assurance, designers, developers and end users | Testing early, testing features and regression testing should also be a team effort, especially when team is in early phases of accessibility experiences. Defining common goals and acceptance criteria can save time and prevent accessibility errors later on. After we do our best internally we should also invite end users – and people with disabilities – to test and confirm that things are working for them. | If we do not cooperate we risk wrong interpretations and wrong expectations or in some cases abundance of errors that pollute our backlogs. Selecting best practices and methodologies together makes this part of cycle more robust and predictable as well. |
I hope this table makes the situation more visual and present the co-dependency of some of the most important things that the team needs to discuss, plan and estimate before they get too far and potentially cause problems.
The “shift left” methodology that is used by some experts is also defining this in a similar matter. They also include testing (automatic and manual) and linting of the code as early as possible and I support that as well. It’s not so effective to run automatic test on the evening before launch just to discover hundreds of minor issues that cold be prevented in the early stages. But that goes also for the visual to semantic design – it is much more efficient to define them early, test them earlier and then prevent regression bugs on them.
Shifting left can therefore applies to whole process, not only developer oriented tasks and the key to success is the awareness of interdisciplinary responsibilities that whole team needs to respect and act upon.