Tester’s tale on website accessibility mindset
I have been doing quality checks for digital products like desktop and web applications from last 10 years.
In this 10 years my focus was mainly on these 3 points.
- functional capability of application
- cross browser and platform compatibility
- API testing for core business logic and also evaluating performance capability
Recently I was involved in a program which had critical focus on CFR (cross functional requirements). The reason for this focus was the failure to build the similar product earlier.
That product proved to be a disaster when deployed in production. Users where not signing up for this new solution and preferred to stick to the older ways of working.
RCA (Root cause analysis) of this behaviour pointed to weak focus on CFR.
And one of the CFR was Usability!
Why Usability and Accessibility is important ?
Let’s understand the partial reasons for failure of similar product that I mentioned earlier.
Accessible website attracts more traffics and adoption by potential users, which includes people with disabilities, have a decent user experience and are able to easily access our solution. By Implementing accessibility best practices, we are also improving the usability of the website for all users.
Accessibility also overlaps with other best practices such as mobile web design , device independence, multi-model interaction, usability, design for older users and search engine optimization (SEO). Everyone over the age of 65 is a potential customer for more accessible products and services.
About 15% of the world’s population lives with some form of disability, out of which 80% are hidden. An estimated 1.3 billion people — or 1 in 6 people worldwide — experience significant disability.
There are 3 types of disabilities
- Temporary , hard to know how many people at any point in time, you might have recently had laser eye surgery, or you don’t have your glasses on
- Situational, could be any one of us at any time — you’re trying to use your mobile phone on a sunny day so you need really good contrast to see the content. And that is just visual disability.
- Permanent, let’s consider hearing impairment
So now we understand why accessibility is important and why that similar solution failed.
My struggles
I knew about the Usability and accessibility in very broader term. None of my previous stakeholders ever asked me if they needed an accessible solution, so I never bothered to increase my understanding on it.
However situation was different here. Stakeholders were worried for CFR and they asked me to check if we are building a usable product along with some other CFR such as Performance, Security, Recoverability, Maintainability , Compliance and Availability.
Usability requirements specify the attributes that make the system easy to use. This includes user interaction, application navigation, screen layout and display requirements.
To make our current application usable, my first step was to make it compliant to Accessibility guidelines.
Accessibility in web development means enabling as many people as possible to use websites, even when those people’s abilities are limited in some way.
Since I knew less about the accessibility, I started exploring how can I help build product keeping accessibility or people’s limited abilities to interact with application in mind.
To my little advantage, I attended a session over a11y few months back before enrolling to this assignment. This session educated me over some basics of accessibility and provided me some direction for where to start such as WCAG 2.1.
Ohhh, you might be wondering what is a11y.
Fun fact : Accessibility (often abbreviated to A11y — as in, “a”, then 11 characters, and then “y”).
Web Content Accessibility Guidelines is the way to go.
This guideline helped me to understand what are the principals around accessibility and various success criteria to mark our website compliant to the need of people with limited ability.
To my surprise, WCAG guidelines isn’t fun to read. It is very comprehensive document and at times I was lost while reading it.
To ease thing out I am sharing my learning and understanding here. So that you have a nice experience with it.
So WCAG is based on 4 core principles
These 4 principles are further divided In to 13 guidelines
And there are total 78 different success criteria to measure if website is Accessible.
These 78 success criteria are categorised into three levels of conformance in order to meet the needs of different groups and different situations:
A (lowest), AA (mid range), and AAA (highest).
Conformance at higher levels indicates conformance at lower levels. For example, by conforming AA, a Web page meets both the A and AA conformance levels. Level A sets a minimum level of accessibility and does not achieve broad accessibility for many situations. For this reason, its recommended to have AA conformance for all Web-based information.
Take aways
Going through these all 78 success criteria wont be possible in this blog. I would recommend you to follow the WCAG documentation for that.
But I can give you some key take aways to at least start with it
I have came across these common a11y issues
- Low contrast on text
- Missing alt text on images
- Missing link text, ambiguous link text
- Too many navigation links
- Empty form labels and unclear form controls
To fix them I first had to identify and report them to developers, designers and product owners.
Few best practices
I would usually use these practices to check the most common and demanding a11y needs.
- Use only keyboard
I check if all interactive elements are reachable and usable via keyboard. All elements have a clear focus indicator And TAB order is logical.
I use built in browser tooling, like the inspect tool in chrome that provides instant feedback to know whether given element is keyboard focusable.
2. Use screen reader
Activating screen reader and using only keyboard with my eyes closed provides me feedback on how usable and accessible the given design and page is. Since screen readers will read from the top of the screen to the bottom, it’s important that page has logical flow. Here I check if elements are reachable, understandable and usable. All images and multimedia has alt text. Navigation is logical.
First-hand experience with a screen reader is invaluable.
I ensure that the expected behaviour is the behaviour I see, and the link is been read out correctly.
3. Sufficient Contrast
I check if minimum 4.5:1 contrast ratio is maintained, if not chrome dev tool inspect element will complain.
4. Page Structure
I check if page is semantically correct, and I see appropriate heading hierarchy.
Headers are used by screen readers as a way to scan a page, for all uses that provide a way to scan and move to the section you are interested in.
If page is not structured correctly it may become non-sensical to a user if they are using a screen reader.
I also ensure to separate the structure and meaning from style.
I use chrome plugins like headings map and web developer to turn off the CSS of site and check if the structure is still logical and easy to understand
5. Use tooling
I usually use lighthouse, axe core chrome dev tools for quick accessibility validations. Including automated accessibility testing throughout the development process can help quickly catch issues, but can’t guarantee that site is accessible. I always combine automated testing with ongoing manual testing. Manual testing is the most reliable method to assess accessibility as per my experience.
A11y automation testing
I suggest developers to use linters in our code. Such as access-lint and axe-linter. These linters can review code as team write it and provide quick. These are timely and targeted feedback before team push any code.I also suggest team to write unit tests to make assertions on the ARIA attributes and alt-text. And I maintain good end to end testing coverage to validate state changes and user interactions in the UI.
Whose job is it anyway ?
What we need in our product team is capabilities, not roles. Regardless of whether I have an accessibility expert in my team, I need to think about who in the team will do these activities and develop these skills.
What can you do starting from today ?
I would suggest you to start using browser based accessibility dev tools like lighthouse , axe core chrome plugin. These tools will provide you quick feedback on how accessible your professional product, blog and personal website are. You can also Alt text on your social media today.
Incorporated into stories
Having accessibility standards defined as a CFR or NFR, we then can incorporate accessibility acceptance criteria at a more granular level in stories.
In Summary
- Promote the value of accessibility to your leadership
- Bring real data about your disabled users into discovery
- Define your default practices and ways of working for accessibility
- Identify responsibilities for accessibility within your team
- Address your capability gaps with training
What do you think ?
Let me know what do you think about ways to test accessibility and my opinion about it in comments below.
Please Note: Soon I will be providing reference of my github repositories for the end to end automation solution using various front end automation tools with axe-core. Please do stay tuned for this.
Edit: Here is my another blog to cover the automation solution around accessibility testing
See you in another blog
Until then Happy testing to you !!
