Make any site you create accessible, (to a good standard – WCAG 2.0 AA), with the help of the UX Engineer’s “Accessibility Checklist” cheatsheet.
Having spent over fifteen years designing and developing complex web-apps for start-ups to large enterprise organisations, including a stint providing web accessibility recommendations for Apple’s websites; it’s shocking to see the general lack of awareness or consideration that most people in the design and development pipeline have for web accessibility.
Most designers and developers forget about the real-world impact an inaccessible site can have on their users. In some cases it’s a nuisance and you’re just providing a poor experience, in other instances you could be denying yourself their custom outright. With over 17% of the world’s population having accessibility needs, and an ageing population which have similar requirements, the business case speaks for itself – but more importantly building accessible sites is simply the right thing to do.
So who should be responsible for accessibility? The Product Owner, UX Designers, Visual Designers, or Developers? The answer: everyone, like any great product – it needs everyone to do their bit to help make it greater than the sum of its parts. That means great universal design and interaction, implemented using a standards based approach to facilitate any Assistive Technology (AT).
So, where do you begin?
In an agile environment it’s relatively straight forward to begin infusing accessibility considerations into your sprints, it won’t miraculously mean you’ll be AA compliant overnight; but as long as everyone is on board, you can make some drastic improvements pretty swiftly. Here are a few points to get you started on your learning journey (I’ll discuss each one in a little more detail).
- Understand users’ accessibility needs
- Use some Assistive Technology (AT)
- Embrace universal design
- Write semantic, standards based markup
- The audit process
I’ve also supplied a web accessibility checklist – which you can use to remind yourself of accessibility considerations during design and development, it can also be used to help audit your site.
1 – Understanding users’ accessibility needs
A little empathy goes a long way, start by familiarising yourself with different types of disabilities, and think about how those users would use your site. Simply by doing this, you’ll begin to understand their needs, and appreciate the problem at hand.
I’ve put together a list of the most common disabilities that you’ll need to think about when designing and developing your sites:
These users will primarily rely on the screen reader, like all users they each utilise their tools in different ways.
- Colour Blindness
Consider text and image contrast and the ability to distinguish elements without just using colour.
- Low / Impaired Vision
Tunnel vision, glaucoma; these users may use a screen reader as well as enlarge just the text, and not just screen zooming.
Audio is unusable, so transcripts will need to be made available for any time-based media.
- Motor Disabilities
Users without the ability to use a mouse or control a pointer, may utilise switch, puff and sip or keyboard controls.
- Cognitive Disabilities
Having clear navigation and uncomplicated layouts all help to reduce the user’s cognitive load, it’ll also make it easier for all users.
Before you can write any useful code or draw up some great designs, getting this user perspective is absolutely essential.
2 – Use some Assistive Technology
Would you write HTML without looking at a web browser to see how your mark-up and script rendered? Or write a responsive site but not test it out on a mobile browser? You’d probably think I was crazy to even suggest it.
So why is it that so many developers haven’t actively tried to use a screen reader? Yes, there is a learning curve, like any new piece of software; however it’s a good skill to have and as a developer or UX engineer makes you instantly more marketable, more importantly it gives you a better insight into those who depend on AT.
Start by educating yourself, and your team about accessibility – understand the people you’re facilitating and the impact your changes can have on their lives. The following are some commonly used assistive technologies:
- Screen readers
Narrates a web page, by utilising the page content and the data supplied in the accessibility tree.
- Screen magnifiers
Allows the user to zoom in on a section of the screen.
- Braille terminals
Outputs to a refreshable braille terminal that users can read.
- Keyboard / Switch
Users with motor difficulties may utilise the keyboard or a switch device which translates to key presses.
- Wands & Joysticks
Used to control cursors or access keyboards and switches.
- Speech recognition
Control and deliver input using just your voice.
By accommodating for assistive technology, you can really make a difference in how people use your products. Christopher Hills runs a video editing business and uses switch control to access his Mac and cut videos in Final Cut Pro. The following video, showcases how he’s used AT to gain independence and sucessfully run his business.
2.1 – Screen readers
Screen readers narrate the contents of the screen and the user’s actions, so those with limited or impaired vision can operate and access their device.
The most common screen readers are JAWS, ZoomText, Window-Eyes, NVDA and VoiceOver. Some of these are pretty expensive pieces of software and have been used by blind users for many years, however NVDA is free and VoiceOver is built into OS X/MacOs and iOS – both are great to begin learning how to use a screen reader.
Non Visual Desktop Access (NVDA) is an open source freely available screen reader for Windows created by two blind programmers, If you’re using Windows, download and install it now – get a feel for how visually impaired users interface with their device. NVDA is designed to work best with Firefox.
If you have an iPhone, iPad or Mac you already have access to a high quality built-in screen reader, all you have to do is switch on VoiceOver from the Accessibility settings. On a Mac you can toggle VoiceOver using ⌘CMD+F5. If you’re using VoiceOver it’s best coupled with Safari to get the optimal web browsing experience.
Android’s TalkBack is a built-in screen reader on all Android devices, it’s not as mature as VoiceOver but is steadily improving. Although it has some interesting gesture controls.
2.2 – Keyboard / switch control
Switches are designed to provide full system access with effectively a single (or multiple) input buttons, think of being able to operate the entire computer using just a spacebar. If you’re on a Mac, you can explore switch controls on OS X/MacOs – from the Accessibility panel in the System Preferences.
As a first pass you can utilise just the keyboard to control and navigate your browser. Start by tabbing through a web page, you should see a focus outline on the first focusable element (links, form controls, interactive controls) on the page. Can’t see a focus outline? Some sites supress the focus outline for design purposes, without realising the accessibility implications.
Without a visible focus outline it’s almost impossible to keyboard navigate pages. Check out bbc.co.uk/news – for an example of a page which facilitates keyboard access by providing clear visible focus outline.
Note: Mac users, Safari defaults to Alt+Tab for tabbing, you can change this to just Tab in the Safari preference.
2.3 – Screen magnifiers
Screen magnifiers, do exactly what you think – they magnify parts of the screen. These are particularly useful for those users who have poor vision, and difficulty seeing small detail or type on the screen. As you’d rightly guess this feature is used pretty commonly, as our ageing population are more technically literate with many having vision impairments.
Windows 10 has a built in magnifier, check out the ‘Ease of access center’ in Control Panel and start the magnifier. The Lens option allows you to magnify the area where you place your cursor and acts pretty much like a magnifying glass. Mac users will find similar tools available in the Accessibility section of the System Prefernces.
2.4 – Speech recognition
As speech driven interfaces become more intelligent – we’ll see this technology becoming more mainstream. Dictation is a powerful tool as it allows individuals to navigate the interface or input text by simply using their voice. So users who have next to no motor ability can write messages, and perform key controls.
A few years ago I personally suffered a serious hand injury which prevented me from using my right hand to operate the mouse or type as I normally do for a number of weeks. I found speech interfaces particularly useful – and they gave me the ability to compose long messages without resulting in left handed keyboard-pecking.
OSX/MacOs has some dictation features available – which you can easily enable. As Siri joins the dekstop – and now with developers having access to the API’s we should hopefully see leaps and bounds in speech-based interfaces. Similarly Cortana is built into Windows 10 and already offers much of this functionality.
2.5 – Summary
In a nutshell, accessible software systems are already here, and you more than likely already have access to one. All you need to do is enable the features and start playing with them, so now there’s no excuse to avoid learning how to use them.
Quick tip – use the defaults! Most accessibility configurations can be tweaked to the nth degree, to accommodate for all user types. To avoid complication – unless you’re designing for specific user groups, I would suggest you use the defaults, until you’re more comfortable with the software.
Now you understand the needs of your users, design for it…
3 – Universal inclusive design
As a rule of thumb, if you make your site more accessible you’re effectively increasing usability for all users, as you provide more clarity through your interface.
Universal inclusive design doesn’t mean black text on a white background and everything looking like boiler plate HTML without any visual design flair. All it actually means is ensuring your designs are more accommodating and that they provide clarity and enforce semantic meaning where necessary.
Most designs can be made accessible, simply by ensuring the mark-up is standards based and the site meets WCAG 2.0 AA standards. However just because a site meets these standards, doesn’t necessarily mean it’s a benchmark for a good accessible experience.
Factor in accessibility from the outset when you design, and you’ll be able to build compelling user experiences from which all users can benefit. From a design perspective there are a few key issues to consider,
- Colour contrast
- Scaling, and text-only zooming
3.1 – Colour contrast
Colour blind users can’t distinguish certain low contrast colour ratios, so it’s imperative that you use colours that provide sufficient contrast, especially on text. There a number of freely available tools for checking colour contrast ratios, WebAIM have an online checker that tells you if you meet the A, AA or AAA standards; Color Oracle is a particularly useful desktop tool for experiencing how your design will be perceived by a range of colour blind users.
- WebAIM colour contrast checker (Opens in a window)
- Colour Contrast Analyser (Opens in a new window)
- Color Oracle (Opens in a new window)
Another common design mistake that can have significant impact on colour blind users is when colour is used exclusively to communicate information. For example, this could be something as simple as a colour swatch list users might be presented with in order to choose an upholstery finish when buying a product like a sofa. If users suffer from deuteranopia (red-green confusion), they would not be able to make a decisive decision if colour swatches alone were shown. Similarly if you entered an incorrect email address in a web form – being show error feedback text in red would not help a colour blind user easily distinguish this message as an error.
The way to get around these problems is to include visible labels next to the colours, so a colour blind user can identify what the colour represents. In the example of colour swatches, simply having clear colour name associated with the swatch would help provide the necessary information. For the form with the error text – adding a prefix “Error:” to the message can help clarify to the user that this is an error message not just extra information.
As you can see – this extra rigour and scrutiny forces your designs to have more clarity from which all users can benefit.
3.2 – Scaling, text-only zooming
Users with visual impairments will need the design to be flexible enough that it doesn’t break when a user decides to scale the text but not the entire page. Why can’t users just zoom the entire screen, and the design remains intact? Well, the design remains intact, but the user experience goes out of the window, unless you find horizontal scrolling as well as vertical scrolling acceptable.
This means designs will need to be robust and flexible enough that they accommodate for text zooming, both scaling to increase text size and decreasing to make the text smaller (yes, users with tunnel vision can only see a small area of the screen so they may want to pack more into a small space).
Here’s an essential tip for mobile – don’t ever disable pinch zoom, you may have a perfectly optimised mobile site but without the ability to zoom it can make the experience particularly unusable for those with impaired vision who need the ability to zoom in and out.
3.3 – Animations
Animations if done sparingly can enhance the experience and provide visual cues to direct a users attention to specific areas, also animations can be fun, and bring some life to static pages.
There are a few cardinal rules with regards to creating accessible animations, they need to be subtle and also not exceed flashing 3 times per second – this can trigger seizures and should be avoided. To be honest, anything which flashes 3 times per second should probably be consigned to the design dumpster anyway -it’ll most likely annoy all of your users.
4 – Standards based markup & WAI-ARIA
Finally most forms of AT (Assistive Technology), mine the browser accessibility tree or APIs provided by the operating system to add the extra context that is needed by their users. This means writing to web standards and ensuring mark-up is valid, is a particularly important step in building accessible solutions. Invalid mark-up is unlikely to be correctly interpreted by AT and may confuse or worse provide incorrect information to the end user.
Good semantic mark-up also facilitates SEO, as the more context you provide the better any automated reader can access that information, be it a screen reader or a search engine spider.
With Single Page Application (SPA) architecture being the preferred approach for many web solutions – they brings a myriad of challenges that need to be addressed, and have a fundamental impact on the overall accessibility of your site. I’ve found simply accessible’s article on angular accessibility (Opens in a new window) particularly useful in highlighting and discussing solutions to these key issues.
4.1 – WAI ARIA
The WAI-ARIA spec provides some great recommendations that browser manufacturers and assistive technology developers can implement to provide better, accessible hooks that web developers can leverage to create richer accessible experiences.
However like all specs many of these recommendations have been implemented in a variety of different way and are still in their infancy – so don’t expect much consistent cross-browser or cross-screenreader compatibility just yet.
Which means it’s recommended to use the aria attributes sparingly and where you know they have good consistent support, ideally avoid using them if you can achieve the same effect using the better supported native HTML5 tags and attributes.
5 – The audit process
If you consider accessibility within your initial project requirements and have all stakeholders appreciate it’s importance, from conception through to development – you’ll find that there will be fewer issues that slip through the net and prevent costly audits and reengineering to retro fit your designs and code to make it accessible.
5.1 – The process and checklist
As you’ve gathered from this article building accessible web products isn’t simply an automated process, it requires some real thought, as you would with designing any interface. The following process has worked for me in the past to identify and addresss accessibility issues, it uses a combination of both automated and manual reviews,
- Run automated accessibility audit tools on your site
I recommend evaluating the site one page at a time – track all the accessibility violations raised in a spreadsheet. Some useful automated accessibility testing tools,
- tota11y (Opens in a new window) – JavsScript-based auditing tool
- aXe – the accessibility engine (Opens in a new window) – available as browser plugin, but also a library for automated testing to make it part of your build cycle.
Now you’ll have highlighted some of the issues. This pass mainly captures the clunkers, like invalid mark-up or missing tags and attributes.
- Manually audit the site
My Accessibility Checklist v1.0 provides a first pass methodical approach to manually reviewing your pages – follow each of the sections to review the pages in more detail. Again track the issues in the spreadsheet and prioritise them.
Now you’ve got all the issues in a prioritised list – work through them and fix them.
- Rinse and repeat
Once all the changes have been implemented, run through process again. This time the list should be a lot smaller, or if you’re really good – you’ll have no issues. You can now focusing on not just being accessible but crafting a great experience for those using assistive technology.
Few notes on the checklist, it’s been designed to help achieve accessibility to the WCAG 2.0 AA standard. It’s by no means exhaustive, but is there to jog your memory as you evaluate and review.
The main difference with my checklist is that instead of being structured around WCAG guidelines, it’s more user-centric and grouped by different user needs – so as a reviewer you can follow the checklist with each section being around a particular user type’s primary accessibility needs.
I authored this article to give readers a little more insight with regards to understanding accessibility on the web, and appreciate a little more of the why, than just the how – which in many cases gets easily overlooked. I’d also like to believe that some of the resources i’ve found invaluable, may be useful to other ux engineers and their project teams.
I hope it’s given you some insights to begin your journey into designing, architecting and building great web products everyone can enjoy.