There should be no disabled users on the web

A few months ago, I came across a thought-provoking tweet, suggesting that businesses tend to prioritise IE8 support over accessibility, even though the latter comprises a larger demographic. It’s a statement that I’ve been pondering over for a while now, and it’s made me completely re-evaluate my own stance towards accessibility; hopefully after reading this blog post, it will hopefully change yours too.

To begin, we need to define the term ‘web accessibility'. It’s a term that’s thrown around in the web community (along with the infamous #a11y tag), a fair bit. Wikipedia’s description is:

…the inclusive practice of removing barriers that prevent interaction with, or access, by people with disabilities.

However, I think this is incorrect, since it implies a level of retrospect; rather, there fundamentally shouldn’t be any barriers in the first place that need removing. With this in mind, it can be shortened to:

The inclusive practice of ensuring everyone can use websites

And herein is where the problem I believe lies.

Why do we need to make the web accessible?

A better way of phrasing the question is why would you intentionally restrict certain users being able to use your site?. If, for some reason, you need further persuasion, then:

• it’s a basic human right [UN Convention on the Rights of Persons with Disabilities]
  

• it’s written in UK law [Digital Equality Act]

• 18% of the UK population are registered as disabled [Census 2011],

• 21% of the UK population are over 60 [UK Government],

• citizens in the UK who are classed as having a relevant disability, have £26 billion of combined spending power

The traditional approach

Put simply, the same priority given to ensure accessibility across browsers (using cursor/touch navigation), isn’t afforded to assistive technologies. These can include:

• screen readers, which read what the browser has rendered

• braille terminals

• screen magnification/page zooming

• speech recognition

• keyboard overlays

I strongly believe this phenomenon is endemic of the web community as a whole, although it's refreshing to see a changing rhetoric recently. Ask yourself this - how many teams have you worked in, where testing the tabbing interface, and/or using a screenreader is done during the development/QA phase?

Why are visual browsers given priority?

One theory I have as to why most of you will have answered zero to the above question, is related to the makeup of those stakeholders & developers with whom you worked with on those projects. It's safe to assume that, in the majority of cases, they were unlikely to be sufferers of the same conditions that the aforementioned devices are designed to help. Therefore, a conclusion could be made, that they're able to relate more to users of visual browsers.

The inefficient workflow

Traditionally, accessibility conformance has been treated as a separate task that’s carried out either, when the client gets panicky about legal implications and decides to carry out an 'audit', or the development team flags that there are issues with the site post-launch. Trying to work retrospectively like this, simply doesn’t work since:

• an audit is a static document; assuming the project’s under active development, more often than not, the audit becomes out-of-date as soon as it hits your inbox

• trying to mitigate the risk of code conflicts during component 'patching', especially when working in an Agile environment, is incredibly tricky

• it can be a touchy subject getting buy-in from your client to remedy the issues identified, when you're implying that you’ve delivered a product that not everyone can use

A better idea

For the purposes of this article, accessible UX and design is assumed.

Accept that a proportion of your users have a disability

This fact is easily demonstrated through available consensus statistics. If you're attempting to detect assistive devices (for whatever reason), in my opinion, you're doing it wrong - although there is a current proposal to enable this feature. Disability is an umbrella term describing a wide variety impairments; assistive devices are mechanisms designed to empower only a select disability demographic, and therefore using these metrics to represent the demographic as a whole, isn't appropriate. How can you accurately detect, for example, a user with a motor impairment, who relies on an intuitive keyboard interface?

Changes to development workflow

1. Test assistive workflows and devices. Obtain buy-in from your project manager to ensure this is done during the development phase. Incorporate new exit criteria into user stories to ensure that no user story can progress past development without the relevant conformance.
2. Implement WAI ARIA patterns. The WAI ARIA guidelines can be defined as providing rich semantics for users who can’t discern context through visual language. Technically speaking, it’s a declarative microformat that describes component patterns through the use of attribute labels on DOM elements to denote application composition and mutable state. Should be considered a mandatory requirement for screenreader users.
3. Ensure intuitive keyboard routing. This guideline is particularly pertinent for web applications that feature rich visual interactivity (dialogs/modals, submenus that can obscure content when visible, etc), where a natural navigation and reading order needs to be preserved.

Think differently from now on

As part of the delivery team for a project, you have a responsibility to deliver a quality product. Next time you're working on a user story, spare a thought for people who can't use a visual browser, and exercise your due diligence a little more to increase equality.

Here at Red Badger, we're currently transitioning to this new workflow, which will increase our coverage for assistive devices even further.