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.
I’m a bit new to testing, and I’m having some difficulty explaining that ease of use and accessibility aren’t a waste of time to more senior developers.
How would you go about this?
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!
Some of the testers in my team have spent a few weeks learning about accessibility testing. Are there any resources you would recommend to help put their new skills to the test?
Is it worth to do Accessibility tests to CI-pipeline, like with aXe example?
What are the most common pitfalls where softwares fail with accessibility?
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
I read an interesting blog posts a few weeks ago about designing user personas for different accessibility concerns. Of course I can’t find the link now!
I was wondering if either of you had experience with such an activity?
How would you suggest designing such personas?
Once designed, how would you approach testing for any of them? A single example would be cool/enough
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, The Importance Of Manual Accessibility Testing — Smashing Magazine
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, WebAIM: Contrast Checker is free. As is https://contrastchecker.com/
WebAIM is a great general accessibility resource so well worth a look.
Finally, I created my own checklist to work through each guideline. I’ve now published it in both PDF and Word versions so anyone can take a copy and add their own detail applicable to their context. I’ve tried to make it as general as possible but there is references to extensions only available for Chrome and Firefox. It may be of use, WCAG 2.1 Accessibility Guidelines with Test Hints — The Big Test Theory
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 (WCAG 2 at a Glance | Web Accessibility Initiative (WAI) | W3C) 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 - #7 by ThePirateTester
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.
Hello again Faith. I’m not going to apologise for referring back to WebAIM in the session. They have a great article on JavaScript here, WebAIM: Accessible JavaScript - Overview of Accessible JavaScript which calls out some common accessibility issues. There are quite a few articles on ensuring JavaScript sites are accessible from a build perspective but in terms of testing, I’d test in the same way I would any other site.
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.