Shifting to an accessibility first mindset for product planning

What it takes to implement accessibility into product design and why it's important for everyone on the team to be onboard and practising accessibility standards.

Black and white photo with a wheelchair in the middle of a tiled room, shoes sitting on the wheelchairs foot rest

All too often, I hear the argument that people with disabilities are a tiny fraction of customers and not worth the investment to implement accessibility practices. This type of thinking, in my opinion, is very narrow-minded. It especially becomes so when we consider the broader definition of accessibility. Let me ask this, do companies making this statement think about the fact that persons with disabilities are a minor segment because the product is not being accessible?

When a product is in its early planning stages, the topic of accessibility is rarely brought up. Visual impairment and the fact that not many are visually impaired is the argument against implementation. Throughout the article, I will discuss accessibility and share a plan to implement your product.

Let's first take a moment to consider a few of the possible situations that could cause hindrance to the use of a product:

  • Deaf or hard of hearing renders audio cues useless. Other cases may occur when devices need to be silent, such as watching a video in the library or an infant is sleeping in the next room.
  • Minor and Major motor disabilities: Everything from a broken arm, carpal tunnel to the more extreme such as total motor failure or amputees.
  • People with anxiety, dyslexia, Alzheimer's, Dementia and other cognitive disorders can cause confusion with high-density content.
  • Visual impairment includes colour blindness, total blindness and near or far-sighted users.

The list given above is a minimal list of accessibility problems that may occur, but these were the immediate ones that came to mind when writing this article. As we see above, accessibility isn't limited to solving the most extreme cases' problems but will help resolve temporary or minor issues that often go underreported.

Depending on the product being built, the scope of an accessible product may not be limited to body and mind disabilities, but external forces too. For example, users with limited or unstable bandwidth, income level, access to food, transportation, healthcare, and any other infrastructural defects we may encounter can render the product inaccessible.

It's a lot to take in, but do not fret – every step taken towards an accessible product is progress, and that is precisely the goal we want to achieve. Make small steps toward the fully accessible product we all hope for.

Have you ever thought that people with disabilities are a minuscule number of customers because the product is not accessible?

Selling to stakeholders

Besides the more robust code standards and SEO improvements for the marketing website of products, the best benefit is accessibility to all. The return on investment may take a very long time to even out; however, if the product is accessible, the user experience is inevitably stronger than the competitors, leading to more customers.

I won't touch on selling to stakeholders too much, but when we design new products and services, the bottom line is that it's the right thing to do. Here is an excellent quote from Laura Kalbag on "The Clearleft Podcast" episode on accessibility:

Often it’s convincing your boss or your manager and it’s actually one of the things I hate the most about accessibility is how much time and energy is spent trying to convince people that somehow making a website better for disabled people will give them a return on investment or will give them good publicity. Like, I hate that about accessibility. I hate the idea that doing the right thing for people is not considered enough.

The road to accessibility

Nobody is saying it's going to be an easy journey. Designers and developers all need to be on the same page and understand the best practices for implementing accessibility.

Stop the train for a moment; before we arrive at the implementation station, it's best to ensure everyone on the team understands how accessibility works and how it may change the way we design and build products. We on the same team, therefore, we should all work towards the same goal.

Tweet card image by Anna Cook stating that accessibility must be driven by everyone in a company
https://twitter.com/annaecook/status/1469104421376172042

Anna Cook has a tweet discussing this exact viewpoint:

Asking your product team to work towards improved product accessibility should not mean you're volunteered to be the singular accessibility specialist. A single individual contributor is not empowered to create a holistically accessible product. It's gotta be everyone.

In small companies with a handful of people to manage and everyone reviews everything, a one-person team for accessibility could be done – as a checkpoint. However, in the larger companies, there need to be guidelines and best practices and processes put in place where QA teams and designers are the gatekeepers.

It's not just the employees on the ground; managers need to be on board. Timelines will not be the same duration as before. If managers are rushing to get features launched by skipping accessibility and putting it at the bottom of the backlog, then we may need to align our goals.

Areas of accessibility

The following section outlines four different categorical areas towards accessibility. Each of the areas definitely has overlap with one another, but dividing them will help create a systematic approach to implementation.

The following areas are in no particular order.

Keyboard focus

The first category is keyboard accessibility. Having a design system or component library will speed up the process since most of the functionality here will be non-destructive to existing functions of components.

We want to ensure that all components are focusable by the keyboard and that the tab order on user flows makes sense. Usually, tabbing by the DOM order is best, but there may be cases that require additional care.

If custom elements are created, we need to assign the proper role to them and implement the expected keyboard shortcuts. It's always best practice to first utilize the built-in elements for the language of choice before creating your own. For example, using the <button></button> tag in HTML instead of creating a new <div role="button"></div> component.

In this category, when it comes to existing products (and possibly new ones), we need to reinforce the idea that the browsers native functionality remain intact. The functionality like back and forward browser buttons and universal keyboard access should not be overwritten.

Resources:

Keyboard - Accessibility | MDN
To be fully accessible, a web page must be operable by someone using only a keyboard to access and control it. This includes users of screen readers, but can also include users who have trouble operating a pointing device such as a mouse or trackball, or whose mouse is not working at the moment, or…
47 Keyboard Shortcuts That Work in All Web Browsers
Each major web browser shares a large number of keyboard shortcuts in common. Whether you’re using Mozilla Firefox, Google Chrome, Internet Explorer, Apple Safari, or Opera – these keyboard shortcuts will work in your browser.

ARIA labels

Accessible Rich Internet Applications or ARIA is the additional markup that can be added to HTML for enhanced accessibility. These labels will often help tie two related elements together, give the state of an interaction for custom components and give an extra description for those who cannot see. Interestingly enough, these ARIA labels should only be added as the last option. As Carie Fisher states in her accessibility workshops:

The first rule of ARIA is to not use ARIA

This rule is telling us that we shouldn't reinvent the wheel. Much like my example in the keyboard focus section of this article, we should strive to use what is native to HTML first.

Unfortunately, in many projects, I've seen the common practice of developers using frameworks like react or angular to recreate components. This comes with the caveat that all the keyboard shortcuts and properties will need to be manually implemented, which is usually not the case.

Implementing and planning out what components require ARIA labels from the start of building a product will of course save time over backtracking. ARIA labels are more complex and may require custom javascript to be coupled with the component to function properly. This may then create more complications for existing projects. Thinking and planning accessibility from the get-go will save time and money in the longrun.

Resources:

Writing alternative text for images
Best practices for writing alt text for images. Practising with examples to tell a story to our readers utilizing screen-readers.
Accessible Rich Internet Applications (WAI-ARIA) 1.1
Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. This specification provides an ontology of roles, states, and properties that define accessibl…

Contrast ratios

Contrast ratios cover a range of topics from text to component styling. Coming up with robust colour schematics isn't always easy – especially if the product needs to be fully compliant with WCAG specifications. Luckily, the team behind the specifications has announced the upcoming method called Advanced Perceptual Contrast Algorithm or APCA for short. This new method will be much easier to understand, and you can read about some of the changes from Dan Hollick's Twitter thread.

The best way to tack colours is to either build the product as compliant by default or have two themes. If the product calls for bright and sunny colours, most likely it will not be compliant and a high contrast option will be required.

Typography scaling and font weight also fall into the contrast category. Allowing users to upsize or downsize the text and designing to accommodate the largest and smallest size options is a great way to improve the experience for everyone around. Be mindful, that as text reduces in size the colour contrast assigned to it may need to be changed. It's best practice to select text colours that are compliant regardless of the size options available.

Resources:

Designing Systematic Colors
How to make themable, flexible, WCAG 2.1 compliant color ramps for a design system
An article on colour systems from my colleague back at CA Technologies
Accessible Font Sizing, Explained | CSS-Tricks
The Web Content Accessibility Guidelines (WCAG), an organization that defines standards for web content accessibility, does not specify a minimum font size

Team culture

The final category is changing the team culture. This one isn't easy and one I admittedly struggle with. By creating workshops, documentation and training, the team needs to start thinking of accessibility as a requirement and part of their normal routine, not a nice to have.

Below is a great article that was written by Corey Roth to get started on changing the culture at a company, one that I have also taken some starting cues from. The article covers many details including content design, but here is one memorable quote:

True innovation comes when we invite diverse perspectives into the design process and include those we’re designing for as participants.
Creating a positive culture around accessibility
Everyone wins when we build inclusive digital experiences. Here’s why we should be excited about (and not dread) accessibility.

Accessibility First

Image summarizing the 4 areas of "Accessibility First", Keyboard focusable, aria labels, contrast ratios and team culture.

As you can guess by now, there is much to consider regarding accessibility. Tracking our progress in four different categories will also give us a greater sense of accomplishment, some areas are easier to track by numbers while others are not (such as team culture). Being able to break down and see progression can be an important motivation factor amongst team members.

If entire product teams are thinking with an accessibility first mindset, the overhead of having to implement accessibility will be minimized with the side effect of robust coding standards.

At the end of the day, the process will depend on the product, team structure and resources available. Feel free to reach out to me on Twitter or by email and let me know what strategy your team has or is planning to use to tackle accessibility!