My First Experiences with Accessibility Testing
This post has been written as part of the Ministry of Testing Bloggers Club Sprint 13 https://club.ministryoftesting.com/t/bloggers-club-sprint-13-new-timelines/24995
The brief was; Your first experiences with accessibility testing. How you started, where your learning began and any assumptions you had to question, change or drop completely.
It was October 2015 and we had just begun a new project. The companies first foray into customer facing websites. They had one, supplied by a third party, but the cost of change and keeping the site up to date was prohibitive. It wasn’t very good to be frank. The list of things it wasn’t included; responsive, cross browser compatible and accessible. So, the decision was made to create our own replacement and yours truly was asked, amongst other things, to look at accessibility.
The brief seemed straight forward.
Understand what accessibility is and means in our context
Consider impacts on how we develop
How can we include accessibility in our test strategy and approach
I began with a number of assumptions, probably based on my biases, that turned out to be fundamentally incorrect.
Accessibility was exclusively about people with disabilities
It was required for only a small number of users
It is a specialism so by definition was very complicated
It was going to be a costly addition to the project
For the above I want to offer some key pieces of information I uncovered in my research. These will be by no means exhaustive and in some cases, I’ve replaced the original findings with more up to date links where appropriate. As an example, at the time this occurred WCAG 2.1 (Web Content Accessibility Guidelines https://w3c.github.io/wcag21/guidelines/) were not yet published so were not included in scope.
Accessibility was exclusively about people with disabilities
There are many facets to accessibility which are not limited to how content is presented to the user. There’s the content itself, layout and language tone. Is it understandable and uses inclusive language? Compliance is only one facet of accessibility and we should also be thinking about other areas such as;
Readability
55 million adults in the European Union between 15 and 65 years of age have literacy difficulties and are 'functionally illiterate.’ that’s 1 in 5 http://www.eli-net.eu/fileadmin/ELINET/Redaktion/Factsheet-Literacy_in_Europe-A4.pdf
Inclusive Language
It needs reminding that when we are referring generally to people, we should say people, or they or them rather than assuming a particular title or activity is solely for he or him. Groups or also people, or folks or humans, but definitely not guys! Do we really need to collect titles, or for that matter people’s gender?
Usability
We all have usability issues more often than we possibly acknowledge. Trying to type or hit a button while carrying something. Or on a train or bus. Scrolling when pop ups or notifications render over a section of text, or worse the button you were about to press.
Compliance
Whether it is the Web Content Accessibility Guidelines or Section 508 or something else that applies to your circumstances, ensuring your compliance to these is very much a requirement. There are more and more rulings reinforcing this such as the recent finding against Dominos Pizza, https://www.bbc.co.uk/news/technology-46894463
It was required for only a small number of users
Around 80 million people in the European Union are affected by a disability to some degree
There are estimated to be over 30 million blind and partially sighted people in geographical Europe
37 % of the European Union population aged 15 and over reported (moderate or severe) physical or sensory limitations
Figures from http://www.euroblind.org/ and https://euobserver.com/disability/118249
In the same way we all have usability issues better accessibility benefits all of us. Impairments can be situational and temporary as well as permanent. A great description of this is Microsoft’s Inclusive Design Toolkit which is available as a download at this address; https://download.microsoft.com/download/b/0/d/b0d4bf87-09ce-4417-8f28-d60703d672ed/inclusive_toolkit_manual_final.pdf
It is a specialism so by definition was very complicated
It takes very little skill to navigate with just a keyboard
Tools such as WAVE https://wave.webaim.org/ are available as browser extensions and are very easy to use
To use a screen reader is quite straight forward. Understanding what you are hearing and whether it is useful to a user is harder but far from unobtainable
A lot more than you would think is common sense once you begin considering users with other than perfect knowledge and understanding or even different to you
It was going to be a costly addition to the project
There have been lots said and written about designing quality in rather than adding it afterwards (http://www.designsmells.com/articles/understanding-software-design-quality/). Accessibility is very much the same as it is costly to try to add after the initial design is complete but a lot cheaper if it is just part of the design to begin with. Using principles like inclusive design (http://www.heydonworks.com/article/who-is-inclusive-design-for) or universal design (https://en.wikipedia.org/wiki/Universal_design) we can make accessible products, sites and services without breaking the bank.
Test Strategy and Approach
In the beginning of the project testing specifically for accessibility felt a little forced. Learning to use only the keyboard was tricky to begin with but over time, I mostly use the keyboard at all times, having to force myself to use the mouse on occasion. Screen readers are a whole other world and probably require their own post or posts to express how different this is to anything you have done before. The speed with which regular users hear information is amazing! This is a YouTube video demonstration to give you some idea, https://www.youtube.com/watch?v=q_ATY9gimOM. It does end somewhat abruptly but you will have the general idea.
Over time I developed a series of techniques and tactics for testing against all the different guidelines and have created a checklist specifically for my work and what tools are available there. I hope to update this to be more generic and share it in the future. I have also created a visual heuristic on the subject shown below,which I have shared several times and am developing more content. Watch this space!
I hope you found this useful and as always, I’m open to questions and feedback either in the comments or find me on Twitter @CricketRulz.
Some other links you may find useful in exploring accessibility:
https://mouseandelephant.com/path/
https://bats.fyi/2016/08/19/mastering-github-with-a-screen-reader-part-1/ (Bats is Blind Accessibility Testers Society)
https://accessuse.eu/en/ (Access & Use shows what it needs to make dynamic elements in websites accessible and usable for all.)
https://medium.com/@emilymears/getting-started-with-web-accessibility-2c7632c3a8bd