Tonight we were joined by the wonderful @Ruarig for an Ask Me Anything session all about Accessibility.
Iāll make sure to add any questions that we didnāt get to and any resources mentioned during the session to this thread.
If you missed the live session, a recording will be available on the Ministry of Testing website for all Club level members once weāve edited it and added captions.
Have you got any more questions youād like to ask? Add them here 
For the question on resources asked tonight
Power Hour myself and Matt did last year
Good at explaining the WCAG (Web Content Accessibility Guidelines)
The government accessibility blog, lots of good stuff here
My site and article on being an accessibility advocate
Testing native apps and mobiles for accessibility
Great all round resource and creators of the WAVE (Web Accessibility Evaluation Tool) Iāve put a link to an article about a million page review they do but look around for lots of good information
https://webaim.org/projects/million/update
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:
eslint-plugin-jsx-a11y
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.
Finally got caught up on this - thanks @ruarig for a great AMA session - especially like the idea of an āemotional reviewā of the product - I might try it with my team!