How to get engineering teams on board with accessibility

To build products that are usable for all, developers need to prioritize accessibility. Here’s how to get teams on board.

For individuals without a disability, technology makes things easier. But for individuals with a disability, technology makes things possible.

One in four adults in the US have a disability. But in a recent study, ITIF found that nearly half of popular federal websites are failing basic accessibility tests on at least one of their three most-viewed pages.

Accessibility testing isn’t something to brush off or take lightly. It is vital for software engineering teams, especially when building user-facing applications. But too often, products aren’t designed with accessibility in mind, and we discover – often too late – that they aren’t going to be accessible to participants who use screen readers or other assistive technologies, or who are physically unable to use a mouse, or who depend on live captions or sign language interpreters.

Accessibility isn’t just the right thing to do, it’s also the smart thing to do, saving businesses from bad product reviews, expensive legal fees, and lost customers.

‘The power of the web is in its universality. Access by everyone regardless of disability is an essential aspect.’ – Tim Berners Lee

Whether you’re an engineering leader or accessibility tester, the earlier you advocate for accessibility in your team’s development cycle, the more accessible your product will be.

So how can we shift left and build accessibility testing into our teams’ processes? Here are three steps for getting started, and a pocket checklist for making sure your products are accessible.

Step 0: Building an open, collaborative culture

Introducing accessibility into a team can go several ways, from quite easy and smooth to very disruptive. To walk the smoother path, we need to have already built a team culture where people feel psychologically safe to speak about ideas and collaborate as much as possible. I’m calling this ‘step 0’ because hopefully you’re already doing this!

Step 1: Researching accessibility and your applications

The next step is to learn as much as you can about accessibility and your applications through some dedicated research.

If you have a frontend application, whether it’s B2B or B2C, you need to take accessibility into account. I would start by considering:

• What Web Content Accessibility Guidelines (WCAG) standard does the application require? (A/AA/AAA)
• To what extent is it meeting the required standards currently?
• Has there been any accessibility done before for this application?

Some accessibility laws can be slightly confusing. It’s important to learn and understand them as you never know when you may have to comply with them. I suggest using your government website to find your national standards (here for the US, here for the UK, etc.). It can also be interesting to compare standards across different countries.

Step 2: Convincing an engineering team to prioritize accessibility

Now that you understand the current accessibility state of the application, and where you need to get to, you’re ready to convince the engineering team that this is critical work that should be prioritized.

Put time in the calendar to speak to the team about your research and why you’re doing it. I find it helpful to begin with a story – perhaps a case study you’ve come across about firms who’ve done accessibility well or haven’t taken it into account. This sets the stage and clarifies the expectations for the session. Adding a short demo of how users might access (or have trouble accessing) your application is a great way to provide real perspective.

Once you’ve given a broad overview of why your accessibility vision, you can then start showcasing the results of the tests you’ve been running. You could create a document with the areas you’ve already tested and the reasoning for why you wanted to test that specific feature for accessibility. Here are some tools you could make use of for this:

• Lighthouse (Chrome plugin)
• Axe DevTools
• Emulations (colourblind checks)
• DevTools Colour checks
• NVDA ( check both screen reader + transcript)
• When you have achieved it, what next?

Sharing this information will help backup your vision, and should convince the team that accessibility needs to be an integral part of your quality engineering principles and best practices.

Communication skills are vital here. Be clear on what you want from the conversation, and the overall outcome you want for the application. Speak with integrity, and help the team understand why accessibility is important.

The tricky bit is knowing whether the message is landing. As George Bernard Shaw observed, ‘The greatest problem with communication is the illusion that it has been accomplished’. To maximize your chances of communicating effectively, have a clear meeting agenda and ask questions during the session to make sure everyone is onboard.

Once the show and tell is done and you’ve clarified the next steps, work closely with your product owners and business analysts to make sure accessibility-focused development tasks are added onto your backlogs. I would also strongly recommend running an Agile ‘Three Amigos’ session with your developers, business analysts, and folks from the user experience team. It’s always great to collaborate and make sure everyone is on the same page.

A pocket checklist for ensuring a product’s accessibility

• Text and contrast
  Check that any text has a strong contrast against the page background. This enables content to be read by those with moderate visual impairments and in various light conditions. Black text on a white background is typically the best option.
• Text and style
  Don’t just use color to denote differences, emphasis, and meaning in your content. In addition to contrasting colors, consider adding text, shapes, and patterns.
• Heading and styles
  Use descriptive heading styles to designate content organization. Using headings (e.g., Heading 1, Heading 2) indicates the hierarchy of content. Predefined style headings in text editors allow readers to more clearly understand the structure of your document or web page. On long pages of content, consider using a table of contents to help readers jump more quickly between headings.
• List styles
  Use bulleted or numbered list styles to denote list structure. This also ensures consistent formatting and helps screen readers understand content structure and organization.
• Alternative text
  Provide alternative text for images, graphs, and charts. Descriptive alternative text explains what is being illustrated for folks using non-visual browsers. If images are decorative and don’t directly relate to the content, add that information to the alternative text.
• Multimedia
  Supply multiple avenues for multimedia content (e.g., audio with a transcript, video with captioning). Video, audio, and interactive media requires captioning or an alternative method to deliver the same information. Read up more about video captioning resources.
• Added context 
  Use descriptive titles, headers, and hyperlinks to provide added context. Where you’re linking text, describe what you are linking to to help readers scan and anticipate where they will go when clicking a link. Phrases like ‘Click here’ provide little context to where the link is actually going. Don’t solely rely on references to shape, size, or position to describe content.
• Tables
  Format and use simple tables with column and row headers. Split nested tables up into simple tables, and don’t use tables to control layout.
• Capitalization
  Use capitalization sparingly. Capitalizing all letters in a word or sentence can be visually difficult to read, and it causes a screen reader to read each individual letter instead of the word.
• External links
  Any text, media, or activities that you provide from an external website or resource should be accessible.
• Keyboard navigable content
  Make sure content can be navigated via a keyboard. Keyboard navigation is the primary means used for navigating content on a web page by users who have visual or mobility impairments.

Reflections

Accessibility shouldn’t be treated as an afterthought. It’s an integral part of your product, and your team should be putting in the effort as soon as you know you’re working on a frontend application or dashboard.

If you’re working on a bespoke tool, it’s worth conducting a usability session with users who have disabilities to make sure they can navigate through the entire application.

If you’re using a third party tool and wondering what accessibility measures have been taken into account, I’d suggest scheduling a session with the suppliers. You can share or work through the above checklist with them as a starting point.

Otherwise, the most important thing you can do is advocate for this change within your teams, coach your team members, and save yourself from a situation(s) of being faced with fine(s). Be socially aware, be innovative, and reach a wider audience.