It is sometimes difficult to know where to start with accessibility. You know it’s important, and you want to get it right, but how do you translate that into positive action?
Every journey starts with a single step, as the old saying goes, and accessibility is just the same. Everyone on a project team has responsibility for accessibility, and if each of those people takes just a single step towards accessibility, it soon starts to look a lot like progress. Here are some suggestions for those first important steps towards accessibility…
Product owners
This is a general term meant to represent the person responsible for initiating the project. It might be the person who commissions a project with a third party, the person who puts together a proposal for a client, or the person who initiates a project for an internal team.
Make sure accessibility is in the project requirements. If it isn’t there, it will be much less likely to be achieved.
The question the requirements need to answer is: what level of accessibility must the project deliver? Typically this will be Level AA of the Web Content Accessibility Guidelines (WCAG), since this is the standard required by law in many regions of the world, but there may be other guidelines or standards your project needs to reference.
Project managers
Make sure accessibility is an integral part of every step of the project, no matter which methodology your team follows.
Include accessibility as a success metric for each user story in a Scrum sprint, or build in accessibility checks at every stage of a waterfall project. It doesn’t matter how you do it, but the trick is to make sure that accessibility is being assessed and verified at regular points throughout the project, so there are no sudden surprises (in time or cost) at the end.
Interaction designers
Design for “keyboard first”. Designing for “mobile first”, and numerous other variations on a theme, have been made popular over the years, but the one form of interaction we still get wrong more often than not, is keyboard interaction.
Questions to consider include: How will a keyboard user submit this form? How will a keyboard user interact with this carousel? How will a keyboard user cope with this infinite scroll?
Designers
Think about topography. Most products are intended to convey information, or enable people to carry out certain tasks, and in both cases there will be a quantity of text involved.
Questions to consider include: How easy is the font to read at default size? How well does the font scale when magnified or zoomed? Does the colour scheme for text make it difficult to read (perhaps in bright sunshine, or if someone has Dyslexia)?
Copywriters
Remember that not all copy is visible. Alternative text descriptions for images are an important part of content authoring, and they’re often an integral part of the OX for someone unable to see the images themselves.
Questions to consider include: What is the purpose of the image (is it to entertain, inform, evoke, instruct)? How can that same purpose be conveyed in text? Does the alternative text capture the same (or equivalent) experience as the image?
Developers
Find the simplest solution possible. Code consists of lots of moving parts, and the more there are, the more easily things will break. Often, the most robust solutions are those that have been there all along in HTML.
Questions to consider include: Is there an HTML element that does the job? If not, is there an established pattern I can reuse that will work? How can the code for this custom control be kept as simple as possible?
None of these things will achieve accessibility on its own, but as the first step they can start to make a difference to a significant number of people. If each of these steps is taken, then already accessibility for people with visual, mobility, and cognitive disabilities will have begun to improve.
