Digital teams are made up of people with diverse skills, including UX designers, visual designers, developers, content creators, quality assurance testers, and project managers. So, when web accessibility issues surface on your website, who in that team should be responsible for handling them?

If your answer is the developers, then you’re doing accessibility wrong. Meeting your accessibility standards should involve the wider digital team.

But working out who should be involved in the accessibility process, and what exactly they should be responsible for, can be a headache – especially for larger websites. And this is doubly true if there is no established process for accessibility remediation: it becomes inefficient and ineffective. It’s clear that careful planning is instrumental to the success of your accessibility efforts.

That’s where using a framework comes in.

The new Accessibility Roles and Responsibilities Mapping (ARRM) framework, designed by W3C, helps organizations break down web accessibility responsibilities by role. Accessibility remediation can then be shared among your team based on their skills. The outcome? More clarity, ownership, and accountability – which ensures accessibility is never just an afterthought.

Why use a framework for accessibility?

First, let’s look at the challenges digital teams routinely come up against when trying to deliver web accessibility without a guiding framework:

  • Uncertainty over roles and requirements
  • Lack of communication or teamwork
  • No ownership over what needs to be done
  • Conflicting interpretations of accessibility requirements
  • Competing priorities

All these issues have one thing in common: they stem from a lack of clarity.

The purpose of ARRM is to clarify the accessibility process using a straightforward team-based framework. Your team does not need to have in-depth expertise about the Web Content Accessibility Guidelines (WCAG), nor deep technical knowledge of how people with disabilities use the web to adopt this approach.

By distributing tasks smartly, you can integrate accessibility into your workflow from start to finish and reduce the risk of accessibility disproportionately burdening developers.  

Three benefits of using a framework

  1. Increased team collaboration and accessibility knowledge-sharing
  2. Clear, documented roles and responsibilities. For example, Person A is responsible for X, while Person B is responsible for Y.
  3. Time saved by referring to a shared framework that informs daily decisions – so you can focus on getting things done.

How to use the ARRM framework

ARRM uses the "decision tree" method. The decision tree process helps teams to allocate ownership of accessibility tasks based on each team member’s role and strengths.

In many organizations it’s not unusual to assign all web accessibility responsibilities to developers, rather than distributing the accessibility workload across cross-functional teams. But this approach ignores the unique expertise and skills present on your team and who is best suited to handling each accessibility element. 

Decorative image

Step 1: Identifying cross-functional team roles

Before we begin, it’s important to map the cross-functional roles on your digital team using the ARRM role definition document.

Role definitions

  1. Business analysis roles. Business vision, rules and requirements, e.g. Business Analyst
  2. Design roles. Visual design, user experience design, and content authoring
  3. Implementation roles. Front end development and back end development
  4. Quality Assurance (QA) roles. QA testers (automated and manual)
  5. Business administration/management roles. Admin and management roles, e.g. Project Management, Product Owners

Step 2: Distributing accessibility tasks  

Once you have mapped these roles, you can begin to assign primary, secondary, and contributor ownership for each accessibility task. Formalizing responsibilities helps each team member allocate the necessary time to handle accessibility tasks related to their role and clearly identifies a lead for each area.

Primary: The employee accountable for an accessibility task.

  • Drives the decision-making process
  • Directly works with the secondary owner to discuss issues/gather information
  • Delegates sub-tasks to secondary owners and contributors
  • Has sign-off authority to say the task is completed
  • Accountable for the outcome of a task/decision
  • There should only be one primary owner

Example: Developers are responsible for a web page’s underlying code.

Secondary: The employees who are responsible for helping complete an accessibility task.

  • Directly supports the primary owner of a task
  • Involved in the decision-making process
  • Works to complete the task, but defers final decisions to the primary owner

Example: Ensuring informative alt text is present for all images falls under Design’s scope. It requires Content Authors and UX Designers to work together. In this case, Content would be the primary owner, with UX Design the secondary owner.

Contributor: Those who need to be consulted to successfully complete an accessibility task.

  • Not always required, sometimes primary and secondary is enough
  • Not actively involved in the decision-making process. Provides initial input or requirements, and may provide additional information to ensure task completion
  • Should be kept ‘in the loop’ with follow-up communication

Example: A Project Manager schedules focus time and sprint allocation for accessibility tasks.

Remember, the ARRM framework is adaptive. You can assign responsibilities based on what works for your organization.

Decorative image

Step 3: Checklist of actions for implementing your framework

Now, we all know our roles and deliverables and responsibilities, now we walk through the steps.  

1. Gather your digital team

This is the first – and the most critical – step.

ARRM is a team exercise that integrates accessibility from start to end, so you need all the key players involved from the beginning. Kick off the project by getting everyone involved in your web presence together in one room (or video call). This list might include:

  • Project management
  • CMS management
  • Content creators
  • User interface design
  • Visual design and branding
  • Front-end developers
  • QA testing
  • Agile Sprint Planning

2. Identify your accessibility tasks and goals

Once everyone is in one place, it’s time to begin the process of identifying your accessibility tasks, or success checkpoints. A clear and accurate assessment of the work required is important here.

Your accessibility tasks and checkpoints might come from several different sources, such as:

  • Website audit reports (automated and manual accessibility testing results)
  • JIRA tickets
  • Business accessibility project plan
  • Business requirements document
  • User Interface Design document
  • Design systems/component libraries
  • Style guide
  • Usability studies /user feedback sessions

 3. Assign ownership with the Role-Based Decision Tree

Now you have your list of accessibility tasks/checkpoints, it’s time to use the Role-Based Decision Tree to assign ownership for each task. Be specific about each employee’s responsibilities. For each issue, you should check these seven steps.

  1. Is this checkpoint driven by Business or non-functional requirements?
  2. Is this checkpoint about Visual Design?
  3. Is this checkpoint about Content Authoring?
  4. Is this checkpoint about UX Design?
  5. Is this checkpoint about Implementation?
  6. Is this checkpoint about Testing?
  7. If the checkpoint doesn’t fit into these categories, it becomes a management concern.

If any of the tasks remain unclaimed at this point, you should work together as a team to agree who should be hold primary, secondary, and contributor ownership for it. Remember, the ARRM framework revolves around collaborative discussion. What it’s not about is a single project manager assigning tasks in a silo.

4. Document everything

Documentation. Documentation. Documentation. For your framework to be effective, it’s vital to note down everything you need to do, and who will do it. Ensure employees know what is expected of them, and by when. This shared plan could take the form of:

  • JIRA tickets
  • Master spreadsheets
  • Web accessibility policy
  • User Interface Design document
  • Component library
  • Branding guidelines
  • On the wall, project boards, scrum boards
  • Roles and responsibilities. For example, incorporating accessibility into job description and KPIs

Tip: Create a master spreadsheet which lists each accessibility checkpoint/task, along with who owns that area, and the primary, secondary, and contributor owners.

Without careful planning web accessibility becomes an uphill struggle, which can even lead to organizational apathy. Fortunately, using a framework helps your business integrate accessibility throughout the web production process with a list of what exactly needs to be done – and who is going to do it. 

Learn more about how the ARRM framework works on the W3C website.