The three levels of accessibility

Level up your projects' accessibility through strategy, design, and development.

blayne phillips
UX Collective

--

A 3D pyramid divided into 3 horizontal sections, strategy and reach, design and clarity, implementation and inclusivity
The three levels of accessibility pyramid

I was recently asked:

“What does accessibility mean to you?”

I listed off the top of my head the key points… contrast, size, screen readers, hardware, etc… etc… Suffice to say I thought about it a lot afterward…

How could I answer this better?

To help, I created something called the 3 levels of accessibility. There are 3 crucial points throughout a project where accessibility should be influenced. Each level supports the next and depending on its execution will vary in strength. For example, if level 1 was poorly executed it would be difficult for your users to reach the 2nd level or your product altogether.

Level 1 - Strategy & Reach

Poor strategy and reach would prevent the design and implementation from being seen or accessed.

A 3D pyramid broken into three horizontal sections, the bottom section named strategy and reach is highlighted
The three levels of accessibility pyramid (strategy and reach)

The first and arguably the most important level, the one that provides a solid foundation for accessibility. It requires an understanding of who the users/customers are, what the product is for, how will it be accessed and includes:

  • Supported devices & versions (mobiles, tablets, laptops, desktops, TVs, watches, etc.)
  • Supported software & versions (screen readers)
  • Supported hardware (mouse, keyboard, braille display)

If the accessibility requirements are not discussed during the projects planning stages and included as principles to support the project moving forward then the project will fail. The team need to:

  1. Agree on the supported devices, software, and hardware
  2. Agree on the supported versions (devices, software)
  3. Include the level 1 accessibility guidelines in all requirements (Jira, etc.)
  4. Test that each requirement passes the guidelines

A poor example

As seen with the UK's Covid Test and Trace app, it was only available on the most recent mobiles due to the QR scanner code but required at least 60% of the population to use for it to be effective in tackling Covid… obviously, this strategy was never going to work. The app needed to be accessible on all devices for it to have a chance of reaching that 60% goal line.

If during the planning stages they had agreed that the app needs to be available on all mobile devices new and old then using the QR code would have been ruled out in the design or development stage.

Level 2 - Design & Clarity

Poor design and clarity would prevent users from comprehending and using the product. It would also inhibit developers from implementing accessible code. For example, a poorly structured page would make tabbing orders difficult and messy.

A 3D pyramid broken into three horizontal sections, the middle section named design and clarity is highlighted
The three levels of accessibility pyramid (design and clarity)

Although accessibility is a team game the next level is primarily for designers to incorporate and think about when designing products. Input from developers is also crucial at this stage to ensure ideas are technically possible and won’t impact level 1's agreed with accessibility guidelines. Make sure to think about:

  • Responsive design for supported devices, content can reflow, no 2-dimensional scrolling
  • Non-text content, text/audio alternatives (video scripts, image captions, sign-language, etc)
  • Colour contrast and colour alternatives (don’t just use colour to convey information)
  • Content should not flash or cause seizures (animations, etc.) and allow enough time for users to react and take action (temporary/timed components)
  • Provide visual cues to indicate user interaction (hover, focus, etc)
  • Structure pages to be accessible with keyboard only interactions
  • Keep it simple, don’t be technical, remove jargon, remain consistent…

For a full list see the W3 link below:

If the designs are not clear, understandable, and structured in a way that developers can implement accessible code and users can navigate, understand, and reach their goals then the next level will be difficult to achieve. To assist with the accessibility of a design:

  1. Refer to the agreed with level 1 accessibility guidelines
  2. Create an accessibility checklist to refer to (use the link above if needed)
  3. Perform an accessibility design review using the checklist
  4. Confirm with developers the technical feasibility and if any ideas would break level 1 accessibility guidelines

Level 3 - Implementation & Inclusivity

Poor implementation and inclusivity would prevent impaired users from accessing the product. In the real world, this would be like a building only supporting able-bodied/minded people from entering it.

A 3D pyramid broken into three horizontal sections, the top section named implementation and inclusivity is highlighted
The three levels of accessibility pyramid (implementation and inclusivity)

In my own experience, this is the level that is typically the most difficult to attain. It can be an uphill battle if accessibility is squarely left to designers and not the team. It is crucial that developers also have the mindset to apply accessible code. Regardless of how users interact with a product whether that be through sight, touch, or sound. Make sure to think about:

  • Compatibility with past, present, and future tools and devices (ensure code meets agreed on level 1 accessibility guidelines)
  • Supported hardware/inputs work, mouse, keyboard, touch, screen readers, etc.
  • Text alternatives for non-text content, alt text on images, names on inputs, etc.
  • All functionality is available via a keyboard, tabbing is ordered correctly and watch out for keyboard traps that prevent tabbing back
  • Error messages are understandable and actionable

If during implementation accessibility is forgotten about then the project will fail to be inclusive by excluding your impaired users. Developers have a responsibility to be inclusive in their work as an architect would with a public building. Make sure to:

  1. Educate and involve developers on the importance of accessibility
  2. Include accessible code guidelines in each requirement or task as a checklist (Jira, etc.)
  3. Test, test, test… browsers, screen readers, devices, keyboards, multimedia content, etc…

So, what does accessibility mean to you?

Accessibility is a critical part of a product's strategy, design, and implementation. Each stage in turn provides product reach, clarity, and inclusivity. It can have serious consequences on the success of a project by influencing the overall user experience. It is not just for designers but a project team as a whole to take responsibility of and own.

How would you answer this question? Let me know in the comments!

The UX Collective donates US$1 for each article published on our platform. This story contributed to Bay Area Black Designers: a professional development community for Black people who are digital designers and researchers in the San Francisco Bay Area. By joining together in community, members share inspiration, connection, peer mentorship, professional development, resources, feedback, support, and resilience. Silence against systemic racism is not an option. Build the design community you believe in.

--

--

A strategic product designer with some developer experience who is competent at all stages of the design process.