Structure Your Web Accessibility Dream Team for Success

Does your team get lost in a long accessibility checklist and struggle to get a simple overview on who is responsible for what? You’re not alone.

Teams responsible for the overall website experience often cross departments and include a wide combination of diverse skill sets across roles such as digital marketers, content creators, quality assurance testers, user experience designers, visual designers, developers, and project managers. It can be hard to navigate who has responsibility for what when it comes to building and maintaining an accessible digital property, say your website.

Without careful planning, and clear understanding of ownership and accountability, it can be hard to ensure on-going web accessibility compliance. So what to do?

A successful team framework for web accessibility

Luckily there are some experts out there. The World Wide Web Consortium (W3C), the governing body of the Web Content Accessibility Guidelines (WCAG), has built a suggested roles and responsibilities framework for success.

W3C’s Accessibility Roles & Responsibilities Mapping (ARRM) project was created to “define an adaptive framework that will guide stakeholders to integrate web accessibility in all relevant aspects of a product or project life cycle. The result will allow users to take ownership of design and development decisions related to creating accessible content.”

Let’s break down what ARRM is and how you can benefit, no matter your team size.

How to structure your web accessibility processes and ownership across your team using ARRM

The ARRM framework encourages organizations to break down and assign their list of web accessibility issues and requirements for compliance with the Web Content Accessibility Guidelines (WCAG) into Primary, Secondary, and Contributor ownership.

Step 1: Map your team out by group and role


It’s important to map all primary and secondary roles that are involved in web accessibility processes in your organization. Keep in mind that depending on your team size, some team members may fall into multiple groups.

W3C defines role groups as follows:
  • Business analysis
  • Content authoring
  • Design
  • Development
  • Testing
  • Administration

Within these groups there are suggested specific roles. Check out the W3C website for a full list of roles and responsibilities.

Step 2: Distribute the accessibility checks among the team


Once you’ve mapped out your roles, you can assign primary, secondary, and contributor ownership for each accessibility task. Similar to how they sound, these ownership roles have varying levels of contribution to an accessibility task.

Primary owners

Primary owners are ultimately responsible for a given task and typically drive the decision-making process, delegate the work involved, and lead the team of secondary and contributor stakeholders to drive the project to completion. They typically also have the final sign off authority.

Secondary owners

Secondary owners are actively involved in seeing the task through to completion, and often have an execution-based role — but ultimately defer decision making to the primary owner.

Contributor roles

Contributor roles have limited participation in a task and provide guidance or initial input. They may typically be subject matter experts in a related field to the task, e.g. brand guidelines for design.

Step 3: Outlining deliverables by role and ‘go’

Involve all stakeholders in the process

Implementing a new process on how your team is working with accessibility tasks requires setting expectations, realistic goals, and getting the buy-in from all key stakeholders from the beginning. Hopefully if you’re reading this, better web accessibility is one of your priorities this year and to be successful you need everyone on board with clear goals in mind.

Identify your accessibility goals and tasks

Achieving perfect web accessibility is a bit of a pipe dream. It’s a journey, not a destination. The second you add new content to your website, you have some work to do to ensure it’s accessible. So it’s important to make realistic goals for what you want to achieve in improving and maintaining accessibility on your website.

Once you have defined a clear accessibility goal, e.g. to reach a certain level of WCAG 2.1 compliance or more concrete tasks e.g. to remediate all PDFs on the website, then you can identify required tasks and success checkpoints.

Assign ownership based roles

A clear and accurate assessment of the work required is a key criteria to success. Once you have an overview on your web accessibility tasks and checkpoints, it’s time to assign ownership to each task based on the groups and roles mentioned earlier in the post. It’s important to be specific about each of your team member’s responsibilities.

For example:
  • Who is responsible for reviewing weekly accessibility scans and potential errors to assign ownership?
  • Who is responsible for remediating PDFs?
  • Who is responsible for adding captions for your marketing videos?
  • Who is responsible for ensuring accessible-friendly color contrast on your website?

Monitor and document your accessibility progress

Documenting your process and progress are equally important. By documenting your processes new team members can smoothly jump into any work they’ll be responsible for. For documenting progress, not only is it a way to understand if you’re on target to reach your goals, but it can be helpful for compliance reasons (legal will thank you).

You can monitor your accessibility tasks and checkpoints in a several ways:
  • Accessibility scans - tools like Monsido scan your website every week to identify potential accessibility issues to review or remedy
  • Task creation and tracking within accessibility compliance software and/or within a project management system - we use both Monsido and Asana to keep on top of our marketing team projects and for development tasks we use JIRA
  • Accessibility history reports - get an overview of documented progress over time

You can do it!

It doesn’t have to be complicated to have success with web accessibility but it does require structure, team work, and persistence. Hopefully the ARRM model is helpful and something you can adapt to suit your unique team setup for success. If you’d like to know more about how Monsido can help your teams be more effective in managing not only web accessibility but web governance in general, reach out for a demo!