Defining RACI Roles for Improving Digital Accessibility

Spend enough time in digital accessibility spaces and you’re likely to hear mantras like “Accessibility is everyone’s responsibility.” This is true, but any project manager recognizes that making everyone responsible for an outcome is another way of making sure that no one is accountable. This is especially true of organizations that haven’t yet successfully integrated accessibility into their workflows as a specific priority. When they try to change that, it may not be clear how their teams can accomplish this.

One common failure mode is that accessibility operates on a “last touch” model. QA testers and developers may be asked to find or address accessibility issues at the end of a project. Setting aside any number of issues with that model, at this point, it’s already too late. Developers cannot be responsible (for instance) for updating low contrast color combinations both because it falls outside of their core competencies, but also because it should have been addressed in the earlier design phase. This is the core reasoning behind why accessibility needs to be “shifted left” and incorporated into all phases of a project from the very beginning.

Creating a RACI matrix can clarify how different parts of the team can contribute towards improving digital accessibility along with the specific actions they should take.

What is a RACI?

RACI stands for Responsible, Accountable, Consulted, and Informed. A RACI is a simple table or matrix that assigns one of these modes of responsibility across a team for key activities and outcomes on a project. Here’s how we think about each of these modes for improving accessibility (and we apologize in advance for going out of order):

• Accountable (A) roles have primary ownership over an outcome. The buck stops here. There should be only one Accountable role per activity or outcome.
• Responsible (R) roles have secondary ownership and actively participate in decision making and work. Note that “Responsible” here is a term of art with a specific meaning. This is usually the team or person doing the actual work.
• Consulted (C) roles must provide information in order for an activity to be performed. This can be a teamproviding the initial inputs or requirements for a task, or the team that will take the baton on the next task. A role cannot be Accountable or Responsible for anything without having been Consulted on the inputs received. For example, if a designer is provided inaccessible brand color guidelines without the opportunity to raise objections, they cannot own that aspect of the design’s accessibility.
• Informed (I) roles may not actively contribute to or participate in specific accessibility activities but are included as recipients of information.

Defining your team roles

The first step to building an accessibility RACI is defining different roles on your team. Most team structures are similar, but not all roles will be divided up in exactly the same way. Especially on leaner teams, some roles may be fulfilled by the same person. And even similarly structured teams may have different names for specific roles or positions. Your team’s RACI should be at least a little unique. That said, here are some common roles relevant for accessibility:

Core project teams

User Experience and Design roles encompass planning functionality (how things work) and visuals (how things look); this covers everything from UX research and testing to visual mockups. In some organizations, this can include multiple distinct positions while others combine this into a single designer role. Common activities and deliverables for UX and Design include low-fidelity wireframes, information architecture and workflow mapping, usability testing, design mockups, prototypes, animation, and other production design.

Developers are responsible for actually building the experience as it is designed and specified. In addition to building out front-end and back-end systems (or extending off-the-shelf content management systems or frameworks), developers can also maintain component libraries to enforce consistency and scalability across projects.

Even on the most technically accessible systems, content plays a large part in driving accessible outcomes. Content roles lead the creation of a content strategy and policies, written content, and other media like video or PDFs. They also own content authoring within a CMS. Common positions falling within this role include Content Strategists, Content Authors, Copywriters, Content Marketers, Social Media Managers, and Producers.

QA and Testing typically have ownership over the quality of the implementation quality by ensuring work meets documented requirements. Besides manual reviews, QA also includes planning, building, and running automated testing frameworks.

Finally, Project Managers keep a project or deliverable on track, managing budgets, timelines, and scopes.

Business, legal, and governance roles

Just about all digital or web projects will involve design, development, QA, and management. Outside the core implementation group, other roles can influence accessibility from outside the project team. Defining these roles can help clarify and structure the inputs to your project and ensure accessibility considerations are incorporated.

Business roles are foundational to most projects in uncovering relevant requirements. Depending on an organization’s size or sophistication, this may be set by someone outside the implementation team or by a dedicated business analyst, product manager, or sponsor. For vendors, the business role may need to be assigned to their client’s primary stakeholders or project sponsor.

Procurement roles often sit outside project teams and can encompass various positions that participate in the acquisition of software or services including primary stakeholders, dedicated procurement specialists or offices, and attorneys assigned to write and review contracts. They play an important role in setting accessibility standards for third-party software or services incorporated into a deliverable and defining contractual expectations for accessibility of work-for-hire.

Branding can be owned by the same visual design team responsible for a project, but it’s common for branding to be a completely separate practice area in some larger organizations (or if presented by a client). Brand teams create and maintain logos, iconography, colors, and other style guidelines. Especially for larger programs or brands, these guidelines are typically presented as standards that a project’s designs must follow.

Finally, we have Legal and Governance roles that encompass or sit above these functions by setting overall policy for the organization. For example, a mandate for all products to achieve WCAG 2.1 Level AA accessibility by a certain date might generate business requirements with additional scaffolding for how this target should be achieved. Accessibility is just one of many considerations affected by these org-wide policies.

What else goes in an Accessibility RACI?

Now that we understand the range of roles that are important for accessibility, the next step to developing a RACI is determining the necessary tasks. Not all activities will apply to a given project or product, but this list will guide you on what types of things you should be doing:

• Set an organizational accessibility policy
• Review third-party software or services accessibility
• Accessible branding
• Accessibility requirements
• Incorporate accessibility into user stories and other requirements
• Design Accessible Wireframes & Mockups
• Annotate design deliverables for accessibility and other implementation guidelines
• Develop accessible code
• Identify accessibility bugs
• Identify accessibility gaps that may not have been incorporated into requirements or designs
• Accessible content creation (Videos with captions, Tagged PDFs, Images with alternative text, etc.)
• Training for content authors
• Develop an accessibility checklist or other SOPs
• Authoring in a content management system
• Draft an accessibility statement
• Document accessibility in an ACR or VPAT
• Ongoing monitoring for accessibility

Considerations for RACI assignments

For many of the activities above, it was probably obvious which roles (or even which people) should handle them. But part of getting serious about accessibility means ensuring that roles and responsibilities are clear. We considered developing a sample RACI to share as a starting point but decided a RACI starter structure with the ingredients for teams to develop their own would be more helpful.

Since team roles can differ and accessibility knowledge is unevenly distributed, we recommend aligning your organization’s accessibility RACI to your own ways of working. But while we can’t write your RACI for you, we would like to offer some considerations to help you get organized.

As a refresher, Responsible roles are expected to actively participate in a given activity. It will likely be pretty clear for most teams exactly who the Responsible parties are. And as we’ve noted above, it’s critical not to be stingy in keeping roles across the organization widely Informed about accessibility planning and implementation throughout the project.

Similarly, when in doubt, you can also Consult widely. But at minimum, it’s important that any team responsible for accepting inputs for implementation are brought into conversations early. The requirements may dictate that a feature be accessible, but you’ll want to make sure that your development team knows how to do it first (and that they can do so cost effectively).

Accountability is, in our experience, the trickiest type of ownership to assign. On some teams, it might be a Project Manager who takes primary ownership over outcomes (without necessarily participating directly in implementation). In other organizations, this may be distributed at a more granular level per activity.

Activities or outcomes?

We defined our starter RACI structure around activity types like “develop accessible code.” But another way to documentaccessibility responsibilities is around specific outcomes or criteria. For example, something as simple as alternative text for images can be broken down into specific outcomes with different primary and secondary owners such as:

• Writing informative alternative text for images
• Adding alternative text to images in a digital asset manager (DAM) or content management system (CMS)
• Setting a null alt attribute for decorative images in code
• Validating that alt text is replaced with a null alt attribute when images are already described in text on the page

This non-exhaustive list illustrates that even the most straightforward accessibility requirements require cooperation and accountability checkpoints across roles.

RACI across teams

Another wrinkle involves work with vendors or consultants. We’ve already addressed above the need for procurement of accessible third-party services, but similar concerns apply to websites, applications, or other software built by an agency or vendor. This will often mean that some roles remain within your organization while others, like development or testing, might be contracted. In these cases, it is especially important that an accessibility RACI is well defined so accountability for specific accessibility outcomes is clear. It’s also valuable that these expectations are included in MSAs and contracts.

Accessibility specialists

Some organizations have an accessibility lead or other subject matter expert. This may be a completely independent position that sits outside of any of the roles above but also often sits within UX, development, or QA practice areas. Depending on your organization’s accessibility maturity, the accessibility lead may focus more on setting strategy and policy along with consulting; in others, the lead may have specific responsibilities or even accountability for some activities. But while having an accessibility lead can be a valuable boost to your accessibility efforts, it’s no substitute for developing a RACI that brings your whole team into the accessibility matrix.

Get started now

If you haven’t ever performed a RACI exercise, it may seem daunting. Creating a clear accessibility RACI is an essential first step, but don’t worry about getting it perfect on the first try. The process of forcing yourself to define roles and responsibilities will drive meaningful progress and reveal opportunities to iterate and improve your accessibility processes over time. Your RACI should be a living document; review and update it regularly as your team and processes evolve. By taking the time to define how your team works together, you’ll be well-equipped to embed accessibility into your workflows from requirements to launch.