Accessibility, it shouldn't come last

By Greg Jotham, Chief Quality Auditor at AQuA

If accessibility isn’t considered at the design stage of app development it will get left behind, and become difficult to implement later – so why isn’t it getting the consideration it deserves?

AQuA was involved in the running of a discussion panel at Apps World London on the subject of UI/UX Design. One troubling pattern that emerged from the discussions was that accessibility wasn’t even on the radar of most designers: they would expect to do nothing about this and accessibility issues would stay at the bottom of the backlog. It simply hadn’t been identified as a priority at any stage of the development process.

Designing for accessibility is not hard to do and it’s difficult to believe that designers and developers would intentionally dismiss it out of hand. Rather it seems to have been unconsciously overlooked by people not aware of how important it can be to a significant part of their target audience.  Accessibility issues affect around 20% of the population worldwide, so why design an app so that it has the potential to be unattractive to a fifth of its potential users?

There’s really no excuse for skipping over this important area, especially since AQuA published its Accessibility Testing Criteria for all the main mobile platforms. Although the Criteria are designed to guide testing, the information they contain is just as valuable for the design process. Any designer or developer contemplating the production of a new app should download a copy and read through each of the tests, noting the issues each one is designed to address and asking themselves “Could I minimise this issue by good design?”. Some thought about this before user stories are written or code developed would result in a more usable product, simply through better awareness of the issues that can block usage of an application by someone with particular accessibility needs.

There are a number of quite separate areas in which accessibility limitations can manifest themselves, and the division of the Criteria into groups reflecting those separate limitations should make it possible to build up an understanding of the types of usability issue that can be avoided by careful design, whilst still making an application equally enjoyable to use by those not having those particular limitations.

In the past, it may have been a justification to say that there wasn’t enough information available about the needs of users with particular limitations. It certainly isn’t true now – apart from the materials published by AQuA, there are dozens of organisations making information available online. Governments all around the world have already implemented requirements for making web sites more accessible, and it’s inevitable that the attention of legislators will be directed to apps, particularly those for mobile devices, as these become the primary source of access to information and services for much of the world.

Doesn’t it make sense to be informed now, to design for accessibility now, rather than wait and perhaps have to scramble to meet new regulatory requirements after your product has been launched?