By Mischa Andrews
In this third and last (for now) post on accessibility, we’d like to introduce some of the ways you can test your website and content to identify areas for improvement.
Recently at Comprend we hosted a couple of accessibility-themed events: our breakfast seminar on the importance and context of accessibility, and the IxDA Stockholm meetup at our office.
It was wonderful to hear from our guests and meet the attendees – and thank you for everyone who came to listen, learn, and share.
There is a real interest in accessibility and a desire to do the right thing, but unfortunately, accessibility is rarely taught and rarely achieved when creating websites and content.
But as we learned from our guest speaker Ulrika Norelius Centervik, a website doesn’t need to be perfect in order to be usable. Even small changes can be the difference between a website that’s completely inaccessible and one that can be used independently.
If you’re completely new to accessibility, you may like to check out our 10 top tips or read about the legal framework in Sweden.
In this post, we’d like to introduce some of the ways you can test your website and content to identify areas for improvement.
Keyboard testing
Some people prefer to navigate websites with their keyboard. This might be because it is more comfortable for them; or they’re unable to physically control a mouse; or they can’t see a mouse cursor on the screen.
So making sure your website and content works without a mouse is an important part of accessibility testing.
An accessible website or document will:
- Let you move freely through the content when using a keyboard, and not get ‘stuck’ anywhere
- Clearly show you where your keyboard is ‘focused’ at all times, and
- Allow you to move through the content with as few keystrokes as possible – for instance, allowing you to skip through menus and not requiring you to tab through hidden content.
WebAIM has published more specific details on what to look for and how to test your website’s keyboard accessibility.
Screen reader testing
Screen readers are software programs used by people who are blind or have low vision, as well as by some people with cognitive disabilities. Screen readers do their best to read out what’s on your screen, like websites and web content.
You can download and use screen readers on your computer or phone, but it does take some time to get used to them – especially because today’s websites often aren’t built for screen reader accessibility.
Nevertheless, testing with a screen reader is incredibly useful, and will help you identify areas for improvement. Questions to ask yourself while testing include:
- Are icons and links read out in a useful way, or does junk labelling make it confusing?
- Does the order of content make sense?
- Does the heading structure make sense?
- Is there enough context provided when things change on the screen or you’re taken to a new page?
- For multimedia, are there screen-reader friendly alternatives or options?
Each screen reader operates differently and behaves in slightly different ways. Ideally, you would test with a range of screen readers – just like you’d test your website on a range of different web browsers. To begin with, we suggest you pick a screen reader you have access to, learn some basic commands, and start improving your website based on the issues you find – particularly for key actions like completing a transaction and navigating your main menu.
Here are guides for installing and using some common screen readers.
Colour testing
There are many forms of colourblindness. The most common one is sometimes called red-green colourblindness, meaning that red and green are difficult to tell apart. There are also people who may not technically be colourblind but have reduced overall vision, and may have trouble seeing the difference in colours when their contrast is similar.
To ensure your colours are accessible, we suggest you test them against the contrast ratio requirements of the Web Content Accessibility Guidelines (WCAG) 2.0.
When it comes to testing text, this means checking the colour of your text (the ‘foreground’ colour) against any colours it sits on (the ‘background’ colours). Aim to have all your colour combinations ‘pass’ for WCAG 2.0 Level AA (normal-sized text). There are plenty of tools to help you do this – like the browser-based colour contrast checker by WebAIM and the Paciello Group’s downloadable colour contrast analyser.
The earlier you check your colours in the branding or design process of a new product, the easier it’ll be for others in your team to use the right colours over time – so, like all other kinds of accessibility testing, it’s best to do this as soon as you can.
But colours aren’t only used as text. Sometimes you might have colour-coded labels on graphs, or colours that signal concepts – like when you purchase movie tickets and the available seats are green and the unavailable ones are red.
In these cases, the best bet is to use colour as well as some kind of non-colour marker. Patterns or icons (like crosses on the unavailable movie seats) are one way of achieving this. Another method is to physically connect labels to the items they are labelling.
Semi-automated testing
There are tools that scan a web page or content and give you a list of potential and actual issues. They come in a variety of formats, like the HTML CodeSniffer by Squiz.
We’re calling these semi-automated tests (instead of fully automated tests) because they can’t find everything.
For example: if you have a graph that’s uploaded as an image, a semi-automated test might tell you if it has no alternative text. But it can’t read what it says and tell you whether it truly describes the content of that image.
So, by all means, take a look at a scan of your website or content, and do what you can to reduce the errors you find – but remember that it can’t give you a complete assessment.
Manual inspection
Manual inspection is a useful technique that can mean many different things. Once you already understand what makes a web page or document accessible, you might inspect it in some way without doing other kind of testing (like screen reader testing) every time.
For example: if you have created a PDF and know it’s mostly accessible, you might manually inspect its reading order to see whether it seems to be in order.
User testing
The most valuable kind of accessibility testing is testing with real people.
While we can attempt to simulate how it might be for different people with different impairments to experience and interact with a website, this is only ever an approximation of their experience.
So invite disabled people to test your website. Don’t forget to reimburse them for their time, as you would for other testers. They’re the ones helping you, not the other way around.
And if you don’t have any disabled people on your development or communications teams, that may signal that there’s a problem with recruitment process in your organisation. Impairments are more common than most people realise, with some statistics suggesting that around 1 in 5 people have some kind of disability.
Other kinds of testing
In this post we haven’t looked at all the different ways you can test your website’s accessibility. But these are some of the key methods you should definitely have on your radar.
If you test with all these methods, that’s fantastic – your websites and content are undoubtedly better for it. If you’re not sure where to go next, try picking up a copy of A Web for Everyone by Sarah Horton and Whitney Quesenbery, or take the time to learn more of the details from the Web Content Accessibility Guidelines either directly or through resources like WebAIM.
Moving on with the results
With thorough enough testing, you’ll discover a lot that needs to be done. This can be confronting.
Our biggest piece of advice is to keep moving forward.
Accessibility is not just like usability – accessibility is usability. A ‘perfectly’ accessible website may not even exist – just as there may not be such a thing as a ‘perfectly’ usable website, especially as time goes on.
Good accessibility is a long-term journey, and small changes can make a big difference.
So keep testing, keep improving, and keep contributing to the creation of a more inclusive digital world for everyone.
