On the 5th of June, Ady Stokes and Matt Parker will spend an exciting hour on The Club tapping away at their keyboards answering any of your questions related to accessibility testing. Accessibility issues can affect all of us whether we realise it or not so it’s important we are thinking about it and testing too. While it is a specialism of its own there’s a lot we can do on any project. Ask your question to get it answered.
@ruarig and I are here to answer your questions on accessibility testing, for example, you could ask us about:
Understanding what accessibility is
Getting started with accessibility testing
Tools you can use
Why accessibility testing is important and the value it brings
Get all your questions in by 5th June before 7pm GMT and we’ll do our best to answer them during our Power Hour!
For IE11 I typically make use of the WAT Toolbar to identify various issues on the page. The Web Accessibility Initiatives (WAI) Easy Checks will help explain some of the preliminary checks you should make on a page and includes instructions on how to use the WAT Toolbar to perform each check. Beyond the easy checks, WebAIM’s WCAG2 Checklist can help guide you through the additional checks that you need to perform. I also make heavy use of the Developer Tools, but IE11’s tools are notoriously slow and not as helpful as the tools you’ll find in Edge, Chrome or Firefox.
One thing that is important to keep in mind is that no tool is going to find all of the accessibility issues with a page; there will always be manual testing. The browser tools only make it easy to find the programmatically identifiable issues on the page; like missing alt attributes or unlabelled form fields.
Secondly: what tools or heuristics do you use to keep in mind the bits of accessibility that are less…technical I guess? So if you have a tool to check that contrast is okay and you can use a screen reader and things like that, how do you keep in mind things like clear icons and not violating expectations and making sure the design isn’t too distracting or the wording isn’t too complex. The stuff that’s a bit more human.
Can you talk about getting buy in for accessibility from Product Management and Dev, and higher ups in a company? What can testers do to make sure accessibility is being thought of in every part of the product and development process? I am finding it difficult to get a company commitment to accessibility – we need to define what accessibility needs we are meeting, and figure out how much time and resources they want us to spend on it for our software. Thanks!
I really want to be doing accessibility testing, but it’s hard finding what’s doable for online ads, which is what I test. If our ads were just images served on a page then we could add alternative text using the advertisement’s message, but they’re actually made of data-driven components that change based on the context in which they’re served. All the literature (online articles) about this topic have made assumptions that online adverts are either video or images, nothing else. Ads are also served in iFrames so I’m not sure how able readers and the like are of switching context to read the contents of an ad that’s in a different html document to the main page the ad is in… If that makes sense.
I guess questions would be
Where do I start looking for help and advice in testing the accessibility of online ads?
Are there non-technical considerations I could push for in the meantime, like idk how understandable our message is for different groups, not just concentrating on how a reader would interact on finding out ad on a page?
Also, thanks for doing this! It’s a super important topic, and I am excited to not just find out what I can do, but how the industry in general moves forwards on this front <3
We’ve just started Accessibiliy testing for our website and native mobile applications. I’ve taken the task of researching all tools I can find that are close to industry standard as possible. We’d like to have a balance of manual and automation test cases.
What manual testing tools are industry standard for web?
What automation testing tools are industry standard for web?
What manual testing tools are industry standard for mobile?
What automation testing tools are industry standard for mobile?
Can you give us an example of the SDLC for a team performing Accessibility testing?
Testing a story
What tools are you using to test the story
Create a manual test case
Creating an automation test case
Examples for web
Examples for mobile
Also, I’m automation is on everyone’s minds.
What tool are you using for Automation?
What’s everything an automation engineer try to automate?
I’m lucky to be in a position to decide if and how accessibility testing gets done, and developers have done a great job at embracing it by using aXe in their React tests and other tooling to improve our attainment “for free”.
I’m interested in your thoughts on priorities of the non-automatable aspects of accessibility? What’re gonna be the most common pitfalls that accessibility won’t catch?
I don’t do accessibility testing these days as I’m now working at the API level, but I used to do quite a bit around the time that mobile devices were really starting to take off; I used screenreaders and other accessibility test tools fairly regularly back then.
My question is, do you think that the shift in developmental focus away from the traditional desktop towards the touch-centric mobile device in provision of online services has improved or deprecated accessibility?
Hello everyone and thank you for all your great questions. I’m not sure we can promise to answer them completely but we will try our very best. If anything is unclear in the answers or you have any follow up questions please post them. They will be answered even if we run out of time in the hour. I promise to come back later, even if I’m in a heap at the end of the hour!
Hello Faith, please don’t apologise for asking questions. As testers it is what we do!
Tools and automation are useful but both have their limits especially when accessibility testing. For example, tools or automation can tell you that all elements on a page can be tabbed to, but not if there are any keyboard traps. This article is quite good for explaining accessibility automation, https://www.smashingmagazine.com/2018/09/importance-manual-accessibility-testing/
If your site is publicly available you can use the WAVE, Web Accessibility Evaluation Tool, website at https://wave.webaim.org/
As @poorgeek mentioned in his reply the WAT Toolbar can be used.
The above article also goes into detail about mark ups and aria-labels. As it is IE I strongly suspect it won’t be using HTML 5 which has a lot of accessibility support built in. See this link for more information, https://www.html5accessibility.com/
Coming back to your specific challenges Faith, there are other tools you can look at. For contrast assessment you can manually add the details in contrast checkers. The one WebAIM (Web Accessibility in Mind) provide here, https://webaim.org/resources/contrastchecker/ is free. As is https://contrastchecker.com/
WebAIM is a great general accessibility resource so well worth a look.
What I would consider however, and again this has been mentioned, is what you are trying to achieve. As with all testing, tooling should support your testing goals not be a complete solution. Have a read and explore the WCAG 2 guidelines (https://www.w3.org/WAI/standards-guidelines/wcag/glance/) and consider them in any manual testing you do.
Speak to developers and product if possible and understand what, if any, consideration for accessibility has been included in designing/developing the product. Keep potential users and disabilities in your mind as you test – remember accessibility is about being able to use the product.
I’ve been working on a mnemonic for accessibility testing identifying the things that should be considered for effective and inclusive accessibility. BUDI.
Build – Has the product been designed and built with accessibility in mind. If so what has already been considered?
Users - Accessibility is about users and how easily they can use the product. What do you know about your users?
Diversity – Disabilities and challenges are diverse and true accessibility needs to consider as much of that diversity as possible.
Inclusion – If you really want an accessible and inclusive product then you need inclusion in your activities and teams.
Aw, shucks Thanks Gem. Back to the question. Let’s start with tools. There’s potentially a big list of tools depending on your specific circumstances but for web a great start is WAVE, Web Accessibility Evaluation (yes, I know it doesn’t quite work as an acronym), available as an add on for both Chrome and Firefox as well as a website (link in the answer to Faith). Also as previously, tools and automation will only get you so far in my experience. As testers, when we explore a system we are never doing one thing. While we might have a clear charter, test case etc. We can’t help but emotionally react to what we are doing. Look and feel, ease of use, the language used are all things we think about while testing. If something annoys you or feels hard, there’s a good chance users will too.
In terms of heuristics as you probably know I like a good visual one so I created the Accessibility Quadrants to show that compliance is only part of a good and accessible site. I included some details in the post I did for the bloggers club on my first experience with accessibility testing. Mine and links to the other posts are on this link, Sprint 13: Your first experiences with accessibility testing
I don’t think there is a quick and easy answer if I’m honest because by its nature inclusion needs to be diverse. So by that notion something that is clear to one person isn’t necessarily clear to others. Getting as many people as possible to try using the product is a small step, ideally including people who have less/little/no exposure to it previously or people with disabilities.
Another thing I’ve tried in the past is building an emotional map of the product. Basically I just used the product and built a mind map of the steps/areas I visited, how they made me feel and why – i.e. frustrated because I couldn’t find the next button or confused because there was too much going on around the page etc.
Ultimately though, whilst difficult to get to, the most effective and human accessibility to create diverse and inclusive products comes from diverse and inclusive teams.