Everyone in the organization is responsible for accessibility at some level.

Knowledge on how accessibility fits into the development life cycle won’t make software accessible. Work needs to be done to create a culture of accessibility and inclusive design. This means set reachable goals, remove barriers, make it a routine and make yourself accountable.

Based on best practices throughout the organization and making sure individual team members know what their responsibilities are will result in success. Support will be delivered by providing training resources, tools, expert support and a network of accessibility champions.

User Experience UX

Accessibility originates with UX design.

Accessibility requirements should be considered, clarified and communicated via design annotations before the first line of code is written. The basis for these are the accessibility guidelines, the baseline we should not drop below.

Often when something is broken or hard to make accessible it's because the UX design doesn't quite work for all users and has a knock on affect of breaking content for disabled users. The guidelines should be used to form the basis of the accessibility requirements that can be applied to a project.

Where needed, wireframes should be annotated to include a structural outline, interactions and behaviour while UX should clarify colour contrast, provide alternatives for colour and meaning, and clarify hover, focus, selected and touch states, amongst other things.

Working in an agile environment it is likely that overall requirements and visual design will evolve. That's expected but by having the foundation for accessibility documented from the outset the product becomes less susceptible to embedding barriers to access further down the line and accessibility, if done well, has the potential to benefit all people and help innovate a product.

Developers Dev

Accessible qualitative code avoids costly retrofits later on in a project.

Overall developers are responsible for technical accessibility where following web and platform standards reinforces best practice and support for users of access technology. The basis for these are the accessibility guidelines, the baseline we should not drop below.

While QA and accessibility experts are on hand to test the code output, developers should check work day by day. Well documented UX Design Annotations outlining structure, interaction, navigation patterns and so on will enable developers to bring designs to life.

Developers should be familiar with the principles and all the guidelines, including those they would expect to be covered by design documents or by other teams. Developers are responsible for implementation and should use a progressive enhancement approach, building from a basic core experience to full functionality.

When possible use standard interface controls, as these usually come with accessibility built in. If creating a custom component, research how similar standard UI components have accessibility built in and mimic this as far as possible, testing interaction with screen readers and keyboard control.

If editorial colleagues need to add alternatives for non-text content like video or images, ensure that they are able to do so and that these are used correctly.

Editors Editor

Editorial teams are responsible for providing copy and text alternatives for products.

As well as visible text such as headings, form labels, page titles etc, hidden text that is heard by screen reader users should also be carefully crafted. The basis for these are the accessibility guidelines, the baseline we should not drop below.

This could include off screen text (headings, link text etc) as well as aria-labels, buttons, navigation and so on. It is essential that it is clear and a good user experience for screen reader users.

Audio and video - All video should have subtitles.

Notifications - Notifications must be both visible and audible.

Editorial - Consistent labelling of buttons, form inputs, headings, links and image alternatives should apply across different versions of products on different platforms. This enables better recognition and understanding. Work closely with UX designers on instructions for users.

Text equivalents - Alternatives for non-text content such as images will depend on context and should fulfil an equivalent purpose.

Customer Journey Expert CJE

A CJE might have the heaviest lifting to do as it’s their job to ensure accessibility is included in formule management, product ownership and marketing.

To actively incorporated inclusive design and accessibility into the planning and building of products and deliverables as key features require a thorough understanding of all customers and their particular needs and ways of how and where they use digital products. The basis for these are the accessibility guidelines, the baseline we should not drop below.

The focus on people with disabilities in the conventional / permanent sense is not what is needed nowadays. This exclusive definition is too narrow for the next generation of accessibility guidelines, we need to acknowledge that disability can be permanent, temporary, or situational, and that all of these are relevant to accessibility in the UI.

Product owner

The PO is responsible for maximizing the value of the product and manages this by working closely together with the development team. Following the accessibility guidelines and clear communication of your expectations on the quality makes an inclusive product. Key features need to be implemented correctly from the start resulting in less bugs to remediate afterwards.

Formula Manager

Implementing and managing channel formulas while applying inclusive design principles is key to create quality products for all customers from the start. When done correctly the development, implementation and realization of customer propositions will benefit all, and not only people with extra needs in certain circumstances.


The translation of the marketing strategy to the desired product range, the commercial pricing, the promotional activities and the use of the various touchpoints is all done by inclusive design principles. From an accessibility point of view: Control of product risks and product requirements in relation to all customers, suppliers and supervisors.

Accessibility Champions

Champions start early and act often. From the start of the project to the end, there are champions involved.

The champion will need to manage up as well as down and makes sure to keep up with the latest developments by following training and doing research.

The Accessibility Champions are part of the product teams across all different disciplines. They are responsible for securing the quality level of the products and are the front-line source of information for accessibility solutions and questions. They conducts a review before transferring to the next step in the Development Life Cycle, e.g. from design to development or from development to production.

Champion have far-reaching knowledge of accessible solutions and where they do not have an immediate answer, they know where to find it. This can be via the portal or through other champions in the network.

What Makes An Accessibility Champion?

A Champion is:
  • Passionate about the topic
  • Supported by management
  • Keen to learn
  • Collaborative / Enabler
  • A Change Agent
  • Proactive
  • Pragmatic
A Champion is not:
  • Doing it because they have been told to
  • A Necessarily a Very Senior Manager
  • Necessarily Technically Knowledgeable about Accessibility
  • Afraid of challenges
  • A Crusader / Blocker
  • Reactive
  • Dogmatic