When we are doing functional testing, what part of accessibility do we cover?
What free accessibility evaluation tools do you recommend for mobile accessibility testing?
I see a pattern in this talk about making accessibility an expected attribute of the product, not something you specify in specific stories. How do you build up a list of those expectations that should be kept in mind for all work?
Are there are industries that are particularly bad for accessibility? I know my boyfriends who is colour blind has encountered a lot of issues when playing video games.
Any recommended tools / libraries that analyse accessibility at the time of development?
So there are two aspects to this. I first looked at accessibility in a role earlier in my career purely because I was looking at what gaps we had in the testing we were doing and included accessibility in a continual improvement approach. As I look back now this was relatively light touch introduction and we were experimenting with how to integrate it into testing.
Over the past few years my interest and learning around accessibility has grown in parallel to my engagement and learning in neurodiversity driven from wanting to build a more inclusive, diverse and accessible world for my autistic son.
There isn’t a right or wrong answer to this in my opinion. In fact I’d step back from defining when to do what. To a degree we can consider all parts of accessibility at all stages of delivery from asking questions of behaviours and requirements in respect to accessibility, to discussing accessibility considerations within three amigos or as part of a pairing/mobbing exercise while developing, to including some level of accessibility automation in the CI/CD, through to exploring the product and testing as part of release. I’d flip it on it’s head, identify what accessible behaviours are relevant and applicable to the user base and then identify a part of the entire delivery lifecycle how and where we can most effectively test against those behaviours.
It really depends on what accessibility problem/need you are trying to address. Mobile devices both apple and android have lots of accessibility features and tools built in from things like screen readers and voice overs to visual display/contrast support and interaction support. Testing while using these features and tools is always a really good start point. A tool called Accessibility Scanner on android is a good tool for picking up some basic accessibility issues. Maybe consider hooking up mobile devices for code capture… this allows you to use developer tools on your local machine to investigate the site/app on the mobile so for example you could use lighthouse in chrome dev tools to check on android devices.
Popular accessibility tools like WAVE and AXE support accessibility testing on mobile devices and Apple have Accessibility Inspector in Xcode. There are lots of options to look at.
As part of getting up and running with mobile accessibility testing this article is worth a look:
I’ve seen this managed in various ways. Quite often these expectations pop up in the form of non functional requirements alongside things like performance. All too often this tends to lead to specific requirements/stories moving across the board and then forgotten about once complete. The most successful ‘continuous accessibility testing’ that I’ve seen implemented focussed on the people. Lots of brown bag lunch sessions and team discussions to help build understanding and knowledge up. I think supporting this with a continually evolving checklist or reference guide with the things coming up in the discussions might add value but whether they are relevant to any given story will depend on context and risk considerations and needs to come out in early discussions. Ultimately we want to get this to form part of ongoing discussions about quality within the team from defining the customer ask to releasing the software. Another approach I’ve seen have some success in driving accessibility into discussions is including it in the definition of done.
I’m going to be honest and say I don’t have a definitive answer as I don’t have an over arching view across industries. Off the top of my head I think the online food industry has had some challenges - Dominoes for example were on the end of an accessibility law suit.
I think the there is a lot going into accessibility in the computer games industry and they have come a long way but still have a way to go to get to where they need to be. How much accessibility hits an industry tends to tie into how broad or specialist the industry is. More specialist industries with a smaller more specialist user base will potentially have a lower risk of falling foul of accessibility issues, whereas industries covering a broad spectrum of the public at large with billions of interactions fall into a much higher risk of being picked up on accessibility.
I believe the transition of many national health services to online hit some accessibility issues early on but again they seem to be heading in the right direction on the whole. I think banking is similarly heading in the right direction but I’ve seen some fairly in-accessible insurance web apps and sites. Similarly, gambling and sports related sites have never put accessibility high in the priority list from my experience.
Most accessibility tools can add value at the point of development to some degree. I think approach is the most important thing to consider with regard to how we build accessibility into a product as part of development. Including accessibility behaviours early (before developing) allows those to form behavioural tests that can be incorporated into the development approach.
Specifically tools and libraries that can be useful I’ve listed a few that come to mind but have a dig… I’m sure there are many more:
Dev tools in general - browser dev tools and also accessibility tools like Axe have there own dev tools.
There are a lot of pattern libraries around focused on accessibility such as Deque Pattern Library
If you are building mobile apps you can hook most of these tools in using code capture and complete accessibility analysis on the fly as part of your development process.