Accessibility – it’s not just screen readers and wheelchairs

August 2016

It’s amazing how ensuring everyone has access to facilities can have a polarising effect.

In the not-too-distant past it was common (as least in my semi-industrial Essex home town) to hear people complaining about the sudden emergence of ramps into buildings, dropped curbs, textured paving at road crossings, lowered cashpoints, and a plethora of other small concessions to ensure that people could move around freely. The usual refrain was of the type “how much is this costing?” with a further implication that the effort and expense could be better spent improving the experience for the wider populace, or that it made their personal experience somehow worse.

You don’t really hear such complaints anymore.

Why? The simple fact is that such changes are a natural evolution, and because people have gradually realised that they are beneficial not just to the nebulous group they label “disabled”, but to all. And that leads to a very important point – attempting to distinguish who is “able” and “disabled” is a specious exercise, because everyone benefits from making services easier to access and use.

And as it is in the physical world, so it is in the digital.

Accessibility has been an important topic in the web development community for almost as long as the web has existed – the first formal guidelines for web accessibility were drawn up in 1999, released by the W3C as “Web Content Accessibility Guidelines (WCAG) 1.0”.

At the same time, the Disability Discrimination act of 1999 stated that all service providers must make provision for accessibility, with the code of practicereferring to accessible websites making this even clearer when published in May 2002.

As a central tenet of development, however, accessibility was a victim of the gold-rush of the first dotcom bubble. Ensuring that sites looked attractive was all important, and the browsers and coding techniques available at the time made it difficult, time consuming – and above all costly – to ensure that sites were both accessible to all and met their designer’s requirements.

This perception coloured development for a great deal of time. Even though the law stated that accessibility was a requirement of websites, there were few legal precedents, and developers either weren’t aware or found it too complex to implement given the other demands on their time.

The advent of court cases regarding accessibility had some impact – particularly the cases of the Sydney Olympic Site in 2000 which was found to break discrimination laws, and of Ramada and Priceline heard in 2004.

Accessibility gradually started to become more of a consideration.

However, the perception by some was (and to some extent remains) that accessibility on the web was entirely about people with some form of disability. The justifications were therefore similar to those heard in the older arguments over accessibility in town planning – too much effort, too many restrictions on creativity, too small a number of users, the cost/benefit just doesn’t work out.

This misses something very important.

While the core drive behind web accessibility is of course to ensure the disabled can access the web – as defined by the W3C:

Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.

… it does in fact go much further than that. Reading on with the W3C definition, these arguments are widened to show that accessibility has many benefits for others as well.

Ensuring your site works for people using assistive technology – such as screen readers, screen magnifiers, and braille readers; those using larger font sizes, or different colour settings (helpful with dyslexia); or even those that prefer to use a keyboard (either through preference or a mobility issue) – means that your site is simply more accessible to all.

For example:

  • Code that is semantic, clean, and valid means that is more likely to render correctly. It improves “findability” as search engines can index content more accurately. It future proofs, so that devices we can’t even imagine now will still be able to access the site. And of course, it means that assistive technologies can render the site in a way the users can understand.
  • Rich media that has alternative consumption methods (such as videos with transcripts, or images with detailed alternative text content) mean that people with slow connections can understand what is going on without having to wait for assets to download. Transcripts are also more discreet, for people that cannot listen to audio. And again, it can help people with visual or hearing impairments, as content is still available to them.
  • Ensuring high levels of contrast can help people with visual impairments navigate your site. But it can also ensure that people in a less-than-ideal viewing environment can access your content – for example, someone using a mobile device in bright sunlight.

There are of course many other considerations, but each and every one can be dealt with in a similar way – they benefit all users in some way.

It’s also important to reflect upon some realities.

  • The general population is aging. And with age come conditions such as motor problems (making it difficult to use a mouse), loss of hearing, and poor eyesight (meaning people need to use assistive technology such as screen readers or magnifiers).
  • In times of economic uncertainty, it is more likely that technology will not be replaced – older devices and browsers will be used for longer. People will continue to use their older computers or mobiles rather than upgrading. A site that works well on all technology, and is accessible to all, will perform better on more varied hardware.
  • Consumption patterns will continue to change. From desktop to laptop, from laptop to mobile, from mobile to smartwatch – sites that are designed with accessibility in mind will be more resilient to different technology and methods of access.

In recent years, an extra push has also come with the Equalities Act 2010 (where accessibility is even more explicitly made applicable to all services, including the web) and the adoption of WCAG 2.0 (the updated accessibility guidelines from the W3C) as an International Standard in 2012.

Yet still many developers do not add this fundamental building block into their processes. For many, it remains an add-on. The notion that it interferes with creativity for very little reward is very hard to shake, even if other arguments win out.

Yes, ensuring your site is fully accessible can add time to your development processes. But with advances in coding and standards, it need not stop creativity. As it can make it easier for everyone to use your site, it is worth spending that extra time to unlock the full potential of your online presence.

So ask your developer (and if you are a developer, ask yourself). Is accessibility a primary aim? And if not – why not.