The Accessibility Roles and Responsibility Mapping (ARRM) is a framework developed by the W3C’s EOWG to help teams break down Web accessibility requirements by roles.
The idea of breaking down accessibility requirements by roles in the web development lifecycle has been floating around for about 10 years, ever since it was first introduced by Accessibility Consultant Denis Boudreau at the 25th CSUN conference, back in 2010.
Back then, the idea took everyone by storm, because it was so disarmingly simple; instead of putting all the pressure of the web accessibility implementation on the shoulders of the QA testers (which had been most people’s strategy up until that point), why not get everyone on the team involved in parts of the effort, by breaking down all that needs to get done and distribute it across various members of the lifecycle, at different phases.
Since then, many new concepts came to be and added to the idea, such as shifting left in the lifecycle, being more purposefully agile about digital inclusion, and actually creating checklists specific to designers, copywriters, front-end developers, QA testers, and everyone else involved in the creation of an accessible product or service.
But while all these ideas came together, a single challenge remained: none of these lists, grids or tools ever went beyond the distribution of WCAG Success Criteria. And experience has shown us that stopping at the Success Criterion level is just not sufficient to help people understand what needs to be done for accessibility to be successfully implemented across an entire organization’s process.
Over the years, many accessibility specialists have attempted to address the concept, adding their own ideas as to what constitutes a viable approach to breaking down accessibility requirements in the lifecycle of a cross-functional Web design and development team. Every presentation that has been given on this topic has helped hundreds of stakeholders wrap their heads around the complex topic of distributing the accessibility workload, and likely, each one of these presentations has helped shape where we are today as an industry.
However, none of those presentations have ever innovated beyond the simple idea that came into existence about 10 years ago, because no one ever went beyond the conceptual level. Until today.
About two years ago (circa 2017-2018), Denis Boudreau brought a new vision for the Roles and Responsibility Breakdown to the W3C’s Education and Outreach Working Group (EOWG). A vision that meant to go far beyond what had been developed up until that point and meant to create a matrical system that could truly adapt to the varying realities of any organization.
The vision was quickly adopted by the Education & Outreach Working Group, and before long, the rest of the presenters that are part of this proposal (Bill Tyler, Sean Kelly, Lewis Phillips, and more recently, Jennifer Chadwick) collaborated to make this vision a reality. Taking the best ideas that each one had worked on individually, the team came together and started pulling together this vision.
A vision that would allow any organization to build their own adaptable, extensible and—most importantly—granular accessibility RACI matrix. One that would allow them to successfully and easily build their own checklists and distribute the workload across every stakeholder in their process.
Our goal with this workshop is not only to share the results of our work so far but also teach participants how they can leverage this powerful tool to more successfully equipping their own teams to be more effectively tackle the many challenges of web accessibility in the project development lifecycle.
Should this workshop proposal be accepted, we will work towards providing the attendees with a highly interactive session, where they will not only sit passively through our lecture but rather, an experience where they will get to actively take part in shaping the future of this important resource.
The future of web accessibility roles and responsibility mapping is here, and it begins with our call to ARRMs.
- Understand how to break down accessibility requirements by roles in the lifecycle
- Approach accessibility in a more pragmatic way, so participants are more successful tackling requirements
- Develop the critical thinking skills required to start looking at accessibility in a more holistic way