How to use a framework to plan web accessibility better

Digital teams are made up of people with diverse skills, including user experience (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, you are only taking into account their contribution to a much larger process. Meeting your accessibility standards is achievable only when you involve the whole 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, and a clear understanding of ownership and accountability, is instrumental to the success of your accessibility remediation efforts.

That’s where using a framework comes in.

The new Accessibility Roles and Responsibilities Mapping (ARRM) framework, a new resource from the W3C, helps organizations break down their list of web accessibility issues and requirements for meeting the Web Content Accessibility Guidelines (WCAG) into Primary, Secondary and Contributor ownership. In a collaborative team exercise, accessibility issues and tasks or “checkpoints” are assigned to each role based on what is needed to complete the fix.

An example of this framework in practice would be images on a web page do not contain an alt attribute, and therefore, no description as a text alternative - creating an accessibility issue. For this task, the Primary owner is most likely the developer. They will add the alt attribute to the web page code. The Secondary owner is likely to be the content creator, who will provide the text description to to the developer to place inside the alt attribute. The Contributor ownership would not be necessary in this case.

As you can see from this example, accessibility remediation can be shared among your team based on their skills. The outcome of this exercise is 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.

To guide you, a master checklist (still in progress) of common accessibility checkpoints or tasks that your team can reference is available on the W3C website. It's helpful to note that the ARRM is not intended to be a conformance tool for the guidelines, but rather an exercise to help you manage accountability and ownership.

By distributing tasks smartly, you can integrate accessibility into your workflow from start to finish and reduce the risk of accessibility disproportionately falling to just one role.

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 assume that all accessibility fixes lie with development and code implementation. This approach ignores the unique expertise and skills present on your team and who is best suited to handling each accessibility issue or task. For example, some barriers for people with disabilities are caused by lack of labels, headings, text alternatives, and instructions - which lie with content creation - or poor page layouts with inaccessible interactions and patterns, which is often a UX team responsibility.

Step 1: Identifying cross-functional team roles

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

Role definitions

1. Business analysis roles. Generally responsible for establishing the 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
4. Quality Assurance (QA) roles. QA testers (automated and manual accessibility testing)
5. Business administration/management roles. Admin and management roles, e.g. Project Managers, Product Owners, Scrum Masters (Agile). This role may include accessibility subject matter experts

Step 2: Distributing accessibility tasks

Once you have mapped these roles, skill sets, and responsibilities, 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 role accountable for an accessibility task.

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

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

Secondary: The role 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 an informative description is available as a text alternative (i.e. alt text) for an image. It is generally the content author's responsibility to provide content for the description, but the secondary owner could be a visual designer, who selected the image and therefore provides additional context on its purpose and meaning.

Contributor: Those role that may be consulted about the work completed by the primary and secondary owners.

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

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 could include those responsible for:

• Project management
• CMS management
• Content authoring
• User interface design
• Visual design and branding
• Front-end development
• QA testing
• Agile Sprint Planning (Scrum Master)

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 (UID)
• Design systems/component libraries/pattern libraries
• Style and branding guides
• 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? For example, ensuring all PDFs are made accessible
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 Development/Implementation?
6. Is this checkpoint about Testing?
7. If the checkpoint doesn’t fit into these categories, or if no one claims ownership, 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. Looking back to the ensuring PDFs are accessible example given at step one: if this has not been a practice before, there may need to be a new process put in place with a dedicated owner.

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 or shared digital space, project boards, scrum boards
• Role and responsibility definitions For example, incorporating accessibility into employee job descriptions and tying it to their key performance indicators.

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 fixes for web accessibility and the tasks involved can become an uphill struggle, which can even lead to organizational apathy and discouragement within a team. Fortunately, using a framework can help your business integrate accessibility throughout the web design, development, and testing 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.