Accessibility is a team effort or we fail at it

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...

Number of words: 866.

(Loaded 750 times)

Common effort, interdisciplinary competence and early dialog can be the only best practice for assuring the accessibility of the final product. If we leave that team members live in their own roles then we are almost surely to fail and get into situations where the issues on the end prevent launching accessible products and flood the team with issues. Cooperation and dialog are key!

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:

RolesResponsibilitiesComments
Project owners, managers and stakeholdersSet accessibility as a requirement, assign responsibilities, define WCAG target level, monitor and reportLeadership must be aware of needs for accessibility beyond legal compliance.
Visual (UI) and interaction designersText 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 developersUser 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 editorsContent 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 usersTesting 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.
Table of team roles and their responsibilities

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.

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: