In order for projects to be truly accessible, the whole team needs to collaborate. But, who does what? In this post, Mark helps us unpack how each role can contribute to making something that works for everyone.

It’s tempting to think that accessibility is for developers and accessibility specialists. That’s how it’s commonly viewed in many organizations. For large organizations, it’s convenient to think: Accessibility is a technical thing, so let’s leave it to the technical team. We’ll decide what we’re building, and those folks will make it work for everyone and everything, right?

Not exactly.

If everyone works on the assumption that a product’s accessibility is solely the responsibility of developers or specialists, then these same developers and specialists can find that even with the best will in the world, they can’t produce an accessible end product. Why? Because decisions have been made (or not made) throughout the project’s lifecycle which make that impossible to achieve.

Producing an accessible product or service requires input and buy-in from all the colours of the corporate rainbow. The development skills needed to build an accessible website are of little use when the project doesn’t have the cooperation of other teams outside of the IT space.

For accessibility to become embedded as best practice in an organization, all team members have to understand the part they play in producing a product which everyone can use.

Initially, it can be a challenge. You can have a development team full of accessibility superstars, but if the marketing and brand folks are running with corporate colours of pale blue on a light grey background, or you don’t have access to assistive technology to check what you build, then you’re on the back foot from the get-go.

The need to create sites and applications accessible to people with disabilities shouldn’t be surprising for anyone on the team. If teams, or parts of teams, are unaware of accessibility’s importance, those that do get it need to help their colleagues understand. For an organization to successfully create an accessible experience for its customers, everybody should strive, both in their own teams and as part of the wider team, to ensure that people with impairments are considered.

But what part of the accessibility spectrum does your role bring to life?

Marketing or online brand team

If you work in the marketing and design team then you take responsibility for the accessibility of all the brand elements, including corporate palette, typeface and language used. That should extend to any external agencies you commission, too. If any external agency produces brand and style guidelines for you, they need to be aware of the impact of creating inaccessible content and that accessibility is a key concern for you, their client.

The marketing and online brand team also needs to work closely with the UX team and the developers to ensure that any changes they make to global styling or brand doesn’t negatively impact accessibility, and that the two teams aren’t heading in different directions leaving developers wondering exactly which style or design pattern should be used.

Content team

Teams producing content for the web represent a really critical link in maintaining the accessibility of a site. Often they’re responsible for interacting with content management systems, adding images to the site, and creating link text. It’s not uncommon for this content to bypass formal testing, and the good work you’ve put in increasing the accessibility of your site can slowly start to leak away if you’re not careful.

It’s important that as a content team, you’re aware of how to optimize content for people with impairments. Tone and corporate voice are often clearly prescribed for brochureware sites, for example. Equally important is the heading structure within content, and the need to write content at an accessible reading level. Also, the ability to add key semantic HTML tags and elements to content should be a prerequisite when procuring a content management system.

Project management

Project managers need to allow time for the team to check for accessibility issues, to raise bugs, and to fix and retest any issues found. It’s not sufficient to identify accessibility issues as ‘enhancement’ in a ‘Phase 2’ development which might never see the light of day. Ideally, accessibility is part of the project from its initial planning and budgeting stages. Project managers have a great opportunity to advocate for accessibility from the ground up.

As project manager, it’s essential that you create an environment where accessibility issues aren’t considered to be bugs, but key features which have been incorrectly implemented and need to be resolved.

Software testers and QA teams

Testers should know how to spot basic accessibility issues. Not to the level that an accessibility expert could, but they should be able to test for obvious issues like keyboard accessibility, text alternatives, and basic colour contrast—even if they don’t necessarily know how to resolve these issues.

However, in most organizations, accessibility testing isn’t something that is currently considered part of the testers skillset or role profile. To integrate accessibility awareness into the test team, the project manager should make sure that they are given the training, time, and autonomy to be able to raise accessibility bugs in the testing phase.

Security and procurement teams

Security and procurement teams perform a very important role within organizations, but they can also be a huge blocker to accessible design and development. These teams need to quickly authorize the tools an organization needs so they can validate and maintain the accessibility of its website. Some assistive technologies, such as JAWS, are expensive, but others are free or low-cost. These tools are critical for testing and validating a site’s accessibility. It won’t help if purchasing screen readers or any other assistive technology is subject to a months-long procurement exercise.

For the security team, approving software that can quickly and easily carry out usability tests remotely is central to the success of any project.

UX team

User experience designers are the champions of accessibility in the team. They should ensure that accessibility is a priority—and that it’s implemented correctly. They also spearhead usability testing, making sure it’s done regularly with users who have a range of disabilities, and who use a range of assistive technologies. They should provide support to all other areas by educating teams on how best to improve their part of the product to create better experiences for users.

The UX team should embrace the role of accessibility evangelists, acting as the gel holding all of the disparate corporate strands together.

Accessibility is everyone’s responsibility. If a single piece of the puzzle is missing, it becomes significantly more difficult to create and nurture a lasting accessibility culture within an organization.

How have you integrated accessibility into your organization? What strategies worked to bring your teams together? Share your experiences in the comments below.

One thought on “Accessibility is everyone’s job: a role-based model for teams”

Read comments

Hi there! We've closed the comments after a week of spirited discussion on this post. If there's something we've missed, please reach out and let us know.