Learning to test for accessibility made me a better designer. You should give it a go.
When I began learning how to test websites and apps for accessibility, it was to lend support to my unit, which needed products to have accessibility reports and statements. I was also intrigued as a user experience practitioner; if I could understand what it’s like to use assistive software to navigate a digital environment, this could bring me closer to being able to design for the least included person, bringing our standard for content just that bit closer to the human-centred ideal we say we want.
Test for accessibility early and often
We say we want human-centred design, and that’s a good thing. But I must ask; is it necessarily enough to design and test things based on whether they are usable? I don’t think it is, because when we describe usability we tend to mean universal usability, and our bias skews us towards our most visible, abled audience.
Design for cognitive bias – David Dylan Thomas
For accessibility, our tendency is to design first and test only when the product is mature, because providing an accessibility statement is our legal obligation.
Our accessibility statements list the items that need fixing and include a date for when we think we might be able to fix these issues. But because we can move that date to later with every statement review, it means some of our products may be slowly, or never, fixed. As a culture our focus is on the legal drag, rather than the humane possibilities, of accessibility.
Prioritising early and often accessibility testing as part of the iterative design of products would save the University time and money. This would mean giving more time to understanding what makes a design accessible, to design, to testing and iteration.
It’s important to be clear that informal early accessibility testing is not a replacement or substitution for a formal accessibility test and statement. Rather, this can be used as a way to catch accessibility problems early in a design so that your team doesn’t spend time and resource developing something that may later be found to be inaccessible.
Early informal accessibility testing on the Web Publishing Platform
An example of how our team put this concept into practice was during the latest sprint developing our megamenu, part of the new web publishing platform.
I did a very quick, very light touch accessibility test on the megamenu prototype using JAWs, TextHelp Read and Write, Webaim.org contrast checker, and mobile accessibility settings. A formal accessibility test would have included testing on multiple browsers with Dragon and Zoomtext, and used Android and Ios mobile phones.
What I did took about an hour and helped us pick up issues early in the design process before they developed into a problem.
Issues I was looking out for:
Keyboard navigation
Can a user use a keyboard only to navigate? Any surprises? Any places where a user might suddenly have to use a shortcut, or swap from using tab to arrow keys without warning? Any traps, or areas where the user can’t use the keyboard to escape? Can a user reach all the content? Is all the content readable and visible, and highlighted by a high contrast outline? Is there a Skip to main content link?
Keyboard accessible – WCAG 2.1
JAWS
Job Access With Speech (JAWS) is one of the major screenreaders and it’s one used in formal accessibility testing. It’s used to help users listen to the content on a page, so it’s important to see if JAWS describes page layout and reads all the content in correct order, and if the usual keyboard shortcuts for JAWS work as they should. As a general rule, keyboard testing tends to show where problem areas are likely to come up for screen readers.
Texthelp Read&Write
Texthelp Read&Write is available to all staff and students at the University and is primarily used as a study tool. It can be used to read content like a screenreader does, and to use colour to highlight text in specific ways, among many other useful study tools. Like JAWS, I used it to listen to the megamenu, noting the order in which content was read and looking out to see if it became stuck or confused at any point.
Colour contrast
I used the WebAim colour contrast checker tool to see if colour contrasts meet the accepted guidelines laid out by Web Content Accessibility Guidelines 2.1 AA standard.
WebAim colour contrast checker
Mobile accessibility settings
I used my little old Android phone to listen to the megamenu with the phone’s screen reading tool, and used accessibility settings to try adjusting font size and colour contrast.
I also used the pinch and expand gesture to find out what happens when a user tries to make the content of the screen bigger. I was looking out for things like clarity and reflow, which is when magnified content is presented so that the user doesn’t have to scroll in more than one direction to see all of it. I also checked to see that objects in the mobile view were no less than 9mm apart.
In general I was looking for anything that might not meet WCAG2.1 standards, or jump out at me as being not quite right that I could ask the accessibility team about later.
Because I was testing a megamenu, there were things I would normally look for in a test which I knew wouldn’t come up, such as alt text, video captions, and animations.
Results
Although we found nothing that failed the WCAG2.1 standards, we did find that some of the decisions we’d made about the megamenu would need to be revised because they impacted the way a screen reader user would experience it.
We learned that the beauty of informal accessibility testing in this case was that we could take these non-fails in the WCAG sense and think of them as usability problems encountered by people who use assistive software.
In the absence of being able to do usability tests with real users of assistive technology, this quick informal test helped us to make decisions. (Usability tests with disabled users of assistive technology is of course preferable, but not always possible in a tight timeframe with limited resources).
A separate strand of work running usability tests on the megamenu with randomly selected, coincidentally abled users allowed us to make observations about their critical issues. Together with the accessibility test, we were able to decide to change the number of levels in the megamenu.
Using accessibility tools to test early and often
If you are making a product, you will need to work with the Disability Information Team to conduct a formal accessibility test, and write an accessibility statement.
Having said that, your product doesn’t have to wait for maturity and release before you run an accessibility test. Doing so early in your design can help you to pick up outright fails, or areas that just about pass but could be improved with simple changes.
If you don’t have access to paid software licences, use what you have in your pocket. Phone accessibility tools can help you listen to your content and help you to identify logical flow problems, lack of alt text, missing link text or poorly written link text.
There are many free tools that can be used to help guide your accessibility checking:
5 Accessibility checker cheats and when to avoid them
Although this blog gives an example of a team using assistive software to help develop a product, I can’t emphasise enough how helpful it can be to quickly listen to a page to check that your writing is accessible.
Although I still have plenty to learn, using accessibility tools has made me a better designer. You should give it a go.
W3 WCAG 2.1 Understanding Docs
Accessibility training sessions
If you’d like to skill yourself or your team up, the Disability Information team runs training sessions on:
- Accessibility Statement Writing
- Creating Accessible Content
- Equality Impact Assessments (EqIAs)
- Website and Applications Testing
Accessibility Statement Writing
- Monday 25 March, 10am to 11am
- Wednesday 10 May, 10am to 11am
- Thursday 20 July, 11am to 12pm
- Wednesday 13 September, 10am to 11am
- Thursday 30 November, 10am to 11am
Creating Accessible Content
The Accessible Content course covers how to create both physical and virtual accessible content. This will help ensure that your materials are accessible to disabled users.
EqIA Training
EqIAs are a legal requirement for all policies, practices and procedures within the University, and this session will focus on the practicalities of undertaking an assessment and completing the necessary form.
- Tuesday 4 April, 11am to 12pm
- Thursday 25 May, 10am to 11am
- Wednesday 5 July, 11am to 12pm
- Wednesday 27 September, 10am to 11am
- Thursday 9 November, 11am to 12pm
Website and Application Testing
Website and application testing is required in order to create an Accessibility Statement, which is a legal requirement for public sector body websites and applications, whether used internally or externally.
- Tuesday 18th April, 10.00am to 12.00pm
- Wednesday 21st June, 11.00am to 1.00pm
- Wednesday 30th August, 10.00am to 12.00pm
- Thursday 26th October, 10.00am to 12.00pm
- Thursday 14th December, between 10.00am and 12.00pm
You can sign up for any of these courses, or contact the Disability Information Team:
Viki: Viki.Galt@ed.ac.uk
Lori: Lori.Anderson@ed.ac.uk
Christopher: Christopher.Maclachlan@ed.ac.uk
