Anyone who works in digital accessibility understands that it’s overwhelming at times — from the number of issues you may find to the necessary tasks to address them. The Web Content Accessibility Guidelines (WCAG) aren’t written in plain language and are often not relevant to the person looking at them, and there are a lot of them. What’s more, when legislation and policies are built to embrace WCAG or Section 508, it isn’t just meeting a percentage of them, but both Level A (the most basic) and Level AA (what most organizations need to comply with) success criteria.
The web has gotten increasingly complicated. I started making websites professionally in 1999, back when WCAG 1.0 was released. At that point, one person could know enough to manage a whole website if they knew HTML and maybe a little coding. Today there are many front-end professionals who are involved in building websites. Developers, UX, designers, and content strategists all contribute to a professional website’s development — and accessibility — in addition to the back-end developers.
Government Approaches
The US Digital Service created the Accessibility for Teams guide to help break down how product, content, UX, visual design, and the front end all have a role in accessibility. This is an early attempt to break down the “need to know” information for each of the roles used to implement government websites.
The UK government did something similar with the DWP Accessibility Manual. The UK government included more roles: business analyst, content designer, delivery manager, digital performance analyst, interaction designer, product manager, QA tester, software engineer/front end developer and user researcher. These names are different, but the point that they were driving home is the same. Web professionals need to know how accessibility aligns with the definition of quality work that applies to their specific discipline.
Now, this can be expressed in fun posters, or with role specific trainings, or just other lists of roles, but the key point is that breaking these issues down makes them easier to understand and therefore, more likely to happen. These resources highlight other roles such as user research, human resources, procurement, and legal.
However, what happens to those barriers when accessibility roles aren’t clearly defined within a team? What if the barriers we find are not just for a few individuals, but actually the responsibility of multiple teams? For some government websites, there are multiple organizations involved in creating and maintaining websites, so this is additionally complicated.
World Wide Web Consortium Builds Definitions
Fortunately, for more complicated sites, we can now begin to lean on the W3C’s new Accessibility Roles and Responsibilities Mapping (ARRM). This has been an idea that was gestating within the minds of multiple accessibility professionals since Denis Boudreau started building out the concept in 2010.
I have been involved with a number of accessibility professionals including Jennifer Chadwick, Julianna Rowsell and others. The team has combed through WCAG success criteria (SC) and broken them down into smaller subunits, each of which is broken down to include primary, secondary and contributor roles. This is primarily an example that teams can look at to get a sense of how each WCAG SC might be aligned to different roles. Each team and each project is different, thus we’ve also created a role-based decision tree to help web professionals understand how they should address determining who has responsibility.
Now the team has tried to abstract the types of roles involved in digital projects, breaking it into six categories: business (business analysis), author (content authoring and content publishing), design (user experience, design and visual design), development (front end and back end), testing (QA testing, automated QA and manual QA), administration (product ownership, project management and governance).
We’ve just mapped WCAG SC to business, content authoring, visual design, UX design, and front end development. Roles like QA and administration are involved throughout the process, so aren’t tied to any specific success criteria. Their expertise is needed across the entire process.
The matrix that our team has developed is a good guide, but ultimately this is something that large teams can benefit from doing on their own. If there are outstanding issues in the issue queue that keep getting ignored or punted between different teams, ARRM is a great tool to leverage to help assign primary, secondary and contributor roles. When it is everyone’s responsibility, it is nobody’s. Being able to hold a few people accountable is much more likely to see results.
CivicActions and Large Government Sites
CivicActions is involved in some very large government web projects. Centers for Medicare and Medicaid Services, Veterans Affairs and National Science Foundation all involve multiple teams inside and outside of government. The websites often contain legacy content that wasn’t developed by anyone currently involved in the project. The design systems are maintained by other teams, and often are out of step with the US Web Design System. It is often the case that whole different technology stacks can be used within what appears to be a single site.
A framework like ARRM can help shape the discussion to make sure those accessibility issues that aren’t clearly any one team’s responsibility are properly addressed. At the end of the day, what matters is that teams working on websites have a plan to ensure that people aren’t caught in the gaps in the sidewalk of our disciplines and contracts. The decision tree structure helps to direct teams on how they might agree who should be involved in addressing lingering issues in a project’s backlog.
There are roles that aren’t as directly related to the WCAG SC, but still have a key function in delivering accessible outcomes. ARRM does not touch the roles of web accessibility engineer or accessibility specialist. That doesn’t indicate that their expertise isn’t needed, but frankly there is already a lot documented for these roles. Having an accessibility subject-matter expert (SME) is important, but far too often they have borne the full responsibility, where a more mature team would have a SME, but also have expertise in each practice area.
More is Needed
We need more user researchers, particularly those with experience working with people with disabilities. We also need project managers who can ensure that accessibility is prioritized appropriately. ARRM doesn’t discount this, but is specifically working to find an approach that can deal with the accessibility issues that fall through the cracks, and often simply do not get addressed. Both of these roles are also equally important across all WCAG SC.
In ARRM, ultimately responsibility comes back to business priorities. Business analysis has responsibilities to set the context of the work. Their role is to “help steer the team towards an end result that meets the organization’s needs and expectations.” If there isn’t an agreement between the roles on how to address an issue, then it is up to the business to clarify.
If you are part of a large cross-functional team working together on a digital project, consider looking at ARRM to see if it can help resolve those issues that have been stuck in your issue queue. How do the roles defined in ARRM align with your current set of roles?
Mike Gifford is a Senior Strategist at CivicActions and a thought leader on digital accessibility in the public sector. Previously, he was the Founder and President of OpenConcept Consulting Inc., a web development agency specializing in building open source solutions for the open web. OpenConcept was an impact driven company and Certified B Corporation. Like CivicActions, OpenConcept worked extensively with the Drupal CMS. Mike was also part of the Government of Canada’s Open Source Advisory Board. Mike spearheaded accessibility improvements in Drupal since 2008, and officially became a Drupal Core Accessibility Maintainer in 2012.
Leave a Reply
You must be logged in to post a comment.