Many organisations appreciate that accessibility, intended to help people with disabilities, helps everyone. They understand that there are also considerable business benefits such as improved reach and influence.

But many companies still struggle to embed accessibility into their software development and maintenance models. Even with the best of intentions they turn out products that either aren't accessible, or blow their budgets in belated accessibility retrofits.

Consequently their products are not as usable as they might have been, costing them valuable time, money, reach and sales.

Accessibility isn't something new and it isn't something special. It's just one facet of strategic product usability.

If your product is more 'usable', more people will use it! As obvious as this seems, I'm amazed at how often this simple logic is overlooked.

Here are some arguments I often hear and how they can easily be avoided.

Argument: "We don't have time for accessibility testing"

A client asked me to review a mobile phone app in the leadup to product release. It was a fantastic app, and colour contrast, tap size and functionality labelling were well in-hand.

However I found fundamental accessibility concerns. For example, some key swipe actions weren't supported for iOS VoiceOver screen reader users.

The app was released anyway to meet scheduled marketing needs, on time but not sufficiently accessible. My findings were backlogged for post-launch remediation.

The reality

Accessibility wasn't planned into product development. It was looked at too late and there wasn't enough time to address the findings.

Most people who are blind use the Voiceover screen reader on Apple smart phones (2017 WebAIM Screen Reeader User Survey), and these users could not use key parts of the app.

Some backlogged issues were addressed after launch, but many were left because the teams were assigned to other projects.

Better approach

Plan the project to deliver an accessible solution from the start, on time and within budget.

  • Consider all user's needs at the outset. Write and test user stories that include needs of people with disabilities.
  • Develop iteratively and test frequently against user stories.

Argument: "It passes automated accessibility testing?"

I checked an ecommerce website that testers had passed as 'ready for launch'.

"We tested the product with an automated accessibility checker. It found some problems and we fixed them."

On review, I found that the site's 'checkout' button was not keyboard accessible. Customers that don't use a mouse or pointing device would not have been able to buy, would have probably bought elsewhere after a frustrating experience, and not recommended the shop.

The reality

This tester relied only on quick automated testing, which can find at best 30% of Web Content Accessibility Guidelines (WCAG) accessibility issues. Keyboard access (WCAG SC 2.1.1) is one of many checks that mostly need manual verification. It would have been easily found by simply putting their mouse aside.

In this instance the checkout button was a <div> element with incomplete scripting, avoidable with a semantic <button> element.

Better approach

Testers develop test cases to check that the requirements of user stories are met. They verify iterative product builds throughout the development process and are ideally placed to catch issues early. But they must know how to test for accessibility concerns.

Write, then test against user stories like:

  • As a keyboard user, I must be able to reach all interactions using my TAB key so I can follow links, trigger actions and complete form fields
  • As a keyboard user I must be able to trigger any action using my spacebar and/or enter key so I can do everything I need to do, like buy a product.

Value and empower your testers.

Do I recommend using automated accessibility checkers? Absolutely. They can help find many issues and speed testing. But don't rely on them for overall verification because they cannot test for everything.

Argument: "It passes WCAG?"

A company was about to launch a new brand. They designed a logo and some marketing assets that contrasted poorly against their background.

I asked some people with various vision impairments to comment on them. People had trouble reading the logo. "It looks like a yellow blob" said one woman.

I recommended some minor modifications. "But they're logos and brand assets" said the designer, implying correctly, that they are legitimate WCAG exemptions.

The reality

The designer relied on WCAG guidelines as a definitive checklist for accessibility.

Many people with impaired vision would have trouble recognising their logo, which is arguably the main purpose for the logo.

This could cost sales unnecessarily, and not just from people with low vision. Did you know that 8% of men are colour-blind, that vision loss affects many people progressively from middle age or that mobile phone screens are harder to read for most of us outdoors?

Yes, logos and brand elements are recognised as an exception to WCAG Colour Contrast (SC 1.4.3), but that's mainly because the World Wide Web Consortium (W3C) doesn't want to force changes to existing brands.

This issue would likely have been found early in testing with people who have impaired vision.

Better approach

WCAG is a great set of guidelines to help you overcome many accessibility fundamentals. But it's certainly not a definitive, all-encompassing rulebook.

Making the brand easily visible will help drive recognition by more people. Consider this carefully when designing the brand.

Use WCAG as a guide, but add people with disabilities into your user research pool. Their feedback will yield valuable insights to improve your product for everyone.


Accessible products mean great experiences for everyone. They'll broaden your reach and influence.

  • Plan for accessibility early
  • Add the needs of people with disabilities to user stories
  • Upskill all stakeholders and roles so they know what their involvement is, and when and how to do it
  • Test against your user stories regularly and iteratively
  • Thoroughly verify your product for accessibility compliance before release
  • Broaden test demographics to include people with disabilities

a11y Australia can help build accessibility strategy into your software design and development model. How our services will help you.