Accessibility: Understanding, Designing and Coding Accessible Products
Accessibility is important to us at FutureGov. Understanding and ensuring a high standard of accessibility helps our projects grow from hacks and prototypes to stable products that everyone can benefit from.
Accessibility to me is about ensuring every one of your users get a similar experience. These users could be people new to the web, people living with disabilities, learning difficulties, motor problems or even alternative devices.
We are building the future of public services and every single person must be able to easily access those services and have the same experience.
The aim of this guide is to show you how we approach accessibility at FutureGov and give people involved in the build of a product, site or service enough of an introduction to accessibility to feel confident to develop their knowledge further.
First Steps with Accessibility
Getting my head around accessibility felt a lot like my first steps into responsive web development. I began by doing a web search for “responsive design” and was faced with plenty of stuff on the subject.
This is great when you understand the basic terminologies, but as a newbie I was overwhelmed, I simply wanted to make my site work on mobile and learn more later on.
After a few hours reading various articles I finally found that I could simply write one line of code for mobile, and my site was looking great (well it worked, and that was a start) on my phone.
This overview of accessibility will help you to understand just what you need to know.
‘Digital inclusion’ is a term you might hear often, it’s about ensuring everyone benefits from a digital service by providing help for when they may need it, links to information about setting up an email during a sign up process, or implementing a clear step by step walkthrough highlighting the benefits of each stage.
It’s great that we are going online with better, easier user centred services, but what about those who are missing out? If you search the web for digital inclusion it won’t be long until you come across statistics like this one; 1 in 5 people across the UK lack basic levels of digital literacy, ‘digital inclusion’ is about ensuring those people get the same benefits as everyone else.
Tristan Wilkinson from GO-ON UK summed this up best:
"The divide is getting smaller but it is deepening."
This is why its important to consider alternative ways to access your service, perhaps you could provide a postal version or phone number.
Think about linking to existing resources that can help. The BBC recently removed accessibility specific controls in favour of teaching users to customise and control accessibility options in their own browsers.
Understanding the User
To provide an equal experience for everyone we need to understand our users before we begin to design.
Consider creating personas that include various disabilities or even better, find some of your target users who might regularly face issues regarding accessibility and talk to them.
Watching a person with visual impairment using a screen reader is an amazing experience. It’s difficult to understand how to design an interface for this until you’ve seen how the content will be scan read and interacted with.
It’s common to provide alternative views or extra functions for specific user needs, I would personally find this a little insulting, as if it has been implemented as an afterthought. A better route may be to link to existing resources on accessibility controls in the browser.
[caption id="attachment18028" align="aligncenter" width="717" caption="Laurence giving accessibility training to the FutureGov team"]<img class=" wp-image-18028 " title="Laurence Berry Accessibility" src="http://s3.amazonaws.com/wearefuturegovdev/public/system/imports/photo-2-1-e1392120634574-1024x617.jpg" alt="Laurence Berry Accessibility" width="717" height="432" />[/caption]
Code-wise, if you are building well structured HTML you are already laying down pretty stable foundations for accessibility.
People using screen readers navigate through headings before committing to read any content, so it’s important to ensure these headings are in order and make sense when they stand alone.
The next step toward a more accessible site is to use HTML5 elements. They aren’t fully supported in all browsers but that’s not a problem they will eventually, and if like us support IE8 and below can't be avoided there are simple fixes you can implement to get them working.
These elements are more descriptive, you can see right away that replacing a standard <div> with a <nav> for a navigation makes everything nicer.
You may have also heard about ARIA elements before. ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) works like an add-on to your code. Its job is to help paint a more descriptive picture of your application and its interactions.
Get used to navigating with your keyboard or using a screen reader when testing, as it’s great to be able to understand how to use your site from another perspective. Any awkward interactions or bugs should get flagged early on.
It’s a good idea to avoid non-user initiated actions like carousels that automatically scroll content across the screen, as these can be distracting and confusing. I have heard that you should provide play, pause, forward and back controls if you do use them, but this sounds like a poor fix to a problem that could easily not exist.
If people want to open a page in a new tab they can. It might not be a great idea to do it for them as it can be annoying, especially on assistive technologies.
Design for when things go wrong.
Think of someone with cerebral palsy using a tablet computer, they may mistakingly select an option that takes them to another part of your app, make it easy to return and undo and provide opportunities to review and amend at any time.
Bear in mind how much easier inline error notifications can be for your users, jumping up to the top of a page to find out what you did wrong somewhere in the middle results in a clunky experience and many people forget the exact error by the time they navigate back.
Promoting exploration is an important part of digital inclusion, nudging ‘cautious clickers’ to engage with your service using words like “discover more like this”, “explore results”, “at your fingertips”, “make it easy with…”. Who knows if you will be able to return after clicking a button that says “click here”.
Make wayfinding easier by using action words for links and including images or icons that can be useful to help a user orient themselves. Visually represent the users location and provide multiple methods of navigation.
A simple example of putting these methods into practice comes to mind. I recently worked on a form made up of several categories, the user can navigate back and forth using buttons provided but also back to any visited category through a ‘breadcrumb’ trail of links.
If you have a navigation of more than two links, then you should provide a visually-hidden link to “skip to content” for screen readers. But don’t go over the top with these.
Creating Clear Landmarks
Help people familiarise themselves with your website or app through consistent use of headings, layout and visual cues like icons.
Group similar elements together and differentiate differences.
Don’t rely on colour alone and make links clear and make sure your design won’t fall apart when zoomed in to 200%.
Its worth considering creating a story, visualising progress, giving rewards and incentives and disclosing information at the right times.
Feedback loops, rewards and incentives are at the core of games design but really they are all about providing meaningful experiences for your users especially people with Aspergers and other levels of Autism.
Digging Deeper into Accessibility
If you want to know more I’d recommend ‘A Web For Everyone’ by Sarah Horton & Whitney Quesenbery it’s got some great personas you can download too.
If you’re designing, then check out communities like We Are Colorblind they post some of the best and worst examples of sites for colourblind people across the web.
Coders should run through the A11y project checklist before pushing their code live and use tools like this Page error detector.