DHT

How to ditch the accessibility section of your contract

by Dylan Thomas
Published:
Last Update:
Reading time:
3 min

In contracts and project plans, accessibility-related work is often siloed away in its own section, if it appears at all, which undermines its pervasive role in a project. A better approach is to integrate accessibility thinking and tasks into all the “normal” project phases. Not only does this normalize accessibility being part of all processes, it also makes it harder to get rid of it all at once.

Below are strategies to integrate accessibility into a contract or project plan. This post will be updated with more strategies over time.

Supported Platforms

Background

Ask any project manager and they will tell you that “Supported Platforms” is one of the most critical, yet overlooked, items for scope clarity and budget predictibility. It defines what hardware/software combinations you will plan, build, and test with. A well written one provides unambiguous requirements and prevents scope creep. A bad one can lead to missed deadlines, budget overruns, and unhappy clients.

Aside from accessibility, a clearer “Supported Platforms” section benefits everyone.

“Supported Platforms” sections have a number of things going for them as a target:

  1. They are small and approachable, usually just a few bullets.
  2. They are often poorly written to begin with, ripe for improvement.
  3. A lot of people ignore it.
  4. Their whole purpose is to define what gets tested.

Example

Below is an example of a “Supported Platforms” section I put together for a university the design system. Given that this system was going to be the basis for thousands of pages, it is a fairly comprehensive list.

Supported Platforms:

  • Mac:

    • Current version of Chrome and Firefox.
    • Safari on current and previous OS major release version, latest point release.
    • VoiceOver screen reader
    • Mouse/Trackpad
    • Keyboard-only

  • Windows:

    • Current version of Chrome, Edge, and Firefox on Windows 10
    • NVDA, JAWS, Windows Narrator screen readers
    • Mouse/Trackpad
    • Keyboard-only

  • iOS:

    • Safari on current and previous iOS major release version, latest point release.
    • VoiceOver screen reader
    • Touch screen
    • Keyboard

  • Android:

    • Chrome on current and previous major release version
    • TalkBack screen reader
    • Touch screen
    • Keyboard

Benefits of this approach:

  1. It is exceptionally clear on what will be tested as far as hardware, operating system, browser, input mode, and assistive technology.

  2. It uses relative versions (“current and previous major release version”) which keeps the clause evergreen and allows adjustment without changing the plan. This is not always possible, but it is preferable when it is.

  3. There is no “additional cost” for accessibility testing. It is baked in.

This last item is of particular importance. If testing costs need to be reduced it is just as easy to drop Firefox or the previous version of Android as it is to remove a screen reader. Accessibility testing is included unless it is explicitly negotiated out.

Your Challenge

Next time you send out a contract or project plan, rework the Supported Platform section and see what happens.