ARRM framework introduction (old)
Parent document: https://www.w3.org/WAI/EO/wiki/ARRM_Project_-_Accessibility_Roles_and_Responsibilities_Mapping
Who owns accessibility?
When an accessibility issue arises, who should correct it?
How do you decide who should correct the issue?
These questions are fundamental to creating accessible products of any kind. They are typically treated as software bugs and assigned to a front-end developer. But should developers really be assigned tasks such as:
- Selecting colors
- Defining keyboard operation or global navigation approaches
- Identifying headings
- Authoring instructions or describing images
We are saying no: these responsibilities may fall to other roles within your team, namely those who made the decision to include these elements, such as UX designers, visual designers and content authors.
After developers, accessibility experts are usually called upon to resolve these issues. Though they can analyze the individual cases and suggest solutions, they themselves are not experts in the design decisions involved. Their proposals may not align with the branding guidelines, style guides, writing standards, user stories or requirements of the product. The roles who created and defined, documented and made decisions that negatively impacted accessibility should be the ones involved and maintain their ownership.
Accessibility issues are unfamiliar to most cross-functional teams which is why they appear in delivered products. Understanding what can and what should not be addressed directly by developers - and what likely requires input from other roles - can be very challenging. This is especially true when those in the role do not realize their decisions are the root cause. Understanding that the responsibility of accessibility is distributed across many roles and when each directly impacts it can reduce the time required to resolve the issue and maintain all expected standards.
What is needed is a method to review accessibility checkpoints or issues to identify who should be involved in resolving them and make the final decision. That's what the ARRM is designed to do.
Accessibility Roles and Responsibilities Mapping (ARRM)
The Accessibility Roles and Responsibilities Mapping (ARRM) framework is designed to help teams identify the roles involved in addressing accessibility issues. It provides a method (the "decision tree") to review and evaluate accessibility checkpoints to help in not only identifying the roles but their level of involvement or ownership. ARRM is designed as a process that can be applied to work with different organizations, team structures, and accessibility checklists.
Using ARRM
Web accessibility is all about planning. The most successful teams and organizations understand that in order to win the game, accessibility considerations need to be addressed as early as possible in the process. This oftentimes starts as early as the design phase, if not earlier. After all, it is now a well-established fact that teams and organizations which explicitly fail to plan for Web accessibility are typically the ones who implicitly plan to fail at creating accessible content.
To use ARRM, a team does not need to have in-depth expertise about the Web Content Accessibility Guidelines, nor deep technical knowledge of how people with disabilities use the Web though these definitely help. What can also help is a general idea of who in a cross-functional team typically holds the best expertise to address certain types of considerations for inclusion.
Where to start: Role-Based Decision Tree
Begin with the Role-Based Decision Tree.
This document will help you identify a process to distribute the many responsibilities of Web accessibility across your entire team. Whether your team is counting dozens of people or just a handful, identifying your key stakeholders by roles will soon allow you to start allocating specific responsibilities in a way that leverages the natural skills and expertise of each individual. After all, while it makes sense for a QA Tester to ensure that color contrast ratios are being met, doesn't it make more sense that such a responsibility be attributed to a Visual Designer instead? We believe so, too.
Of course, job titles are not often very descriptive, and what they actually mean in terms of responsibilities also varies greatly from one organization or team to the next. To help map these resources to the reality of your own team or organization, the Role definition document will help provide context to better frame what we mean when we refer to the various members of the cross-functional team identified with various roles in the process.
ARRM Main Documents
- Role-Based Decision Tree - A framework to define accessibility ownership in a cross-functional product team (primary, secondary, contributor levels).
- Role definition document - A list of all of the different roles that can exist within a cross-functional product team: business, design, development and QA Testing roles.
Comments or feedback about this resource
If you have any comments or feedback about this resource, please reach out to the lead editor: Denis Boudreau (db@deque.com).