WordCamp EU Accessibility Testing Workshop On-Demand

Amber: So this, that’s me obviously. Uh, a picture on the screen. I am going to be doing some describing of what you see on the screen as well, uh, just in case there’s anyone who cannot see the screen, which is an important thing to keep in mind when you are giving presentations.

You want to always try to be accessible to everyone. So yes, I’m the founder and CEO of Equalize Digital. I have my email up here. It’s amber@equalizedigital.com. If you have any follow up questions, because this is a workshop on accessibility testing, that is going to be a bit of a crash course, feel free to email me. And I am on X or Twitter @HeyAmberHinds and on LinkedIn as well.

So I’m curious because it will help me, who is in the room today. So if you are a developer, can you raise your hand? Great. If you are a designer, can you raise your hand? How about a content specialist person, who does that? Yes. Okay. Uh, any accessibility specialists? Wonderful. All right, thank you. Uh, I have slides that you can access and you will want to access this if you go to EqualizeDigital.com/WCEU24slides, and that is the number 24.

Uh, there are going to be a lot of links and resources that you’ll want to be able to get off the slides. That particular webpage also has a plain text version of everything that is in the slides, so you don’t have to get them out of the slides. You can also just get them if you scroll down on that webpage.

So what we’re going to be doing today is a brief intro to accessibility testing. We’re going to do some automated testing. Oh yes. I will go back and give you another minute. So it’s  EqualizeDigital.com/WCEU24slides.

So we’ll do some automated testing, keyboard testing, and screen reader testing. And I have Q&A at the end, but we’re gonna have a lot of time for Q&A throughout. This is going to be an interactive session, so if you have a computer that is most ideal. Also, you might want to have headphones handy because I have a goal of everyone today having heard a screen reader from their own computer.

If you don’t have headphones, I will also share one from mine. So a little bit of background on testing. When we are testing a website for accessibility, this is the basic process. We first run an automated bulk scanning tool to check for obvious accessibility problems. Uh, why do I start with automated scanners?

Because automated scanners can help us find a lot of very basic problems that can actually be very major problems. Things like empty buttons or links, ambiguous text, images missing alt text. And these are the kind of things that we want to find quickly and resolve, and we don’t wanna have to pay a human to find these problems for us because if an automated tool can do it, speed things up then is great.

Um, we require at our company that all of our developers use automated testing tools. Um, there are a variety, which we’ll talk about in just a little bit, before they submit a website for QA. If I get a website and it does not have a 100% on a page that a developer on my team built in Accessibility Checker or in WAVE, then it immediately gets sent back with a message that, hey, you’re not paying attention. So, uh, an important thing to remember is that these tools are really intended to speed up things and help us build better products. And everyone should be using them no matter what their role is. And it’s not just left for the QA person.

Uh, so once we’ve done automated fixes, we find all the automated problems, we fix it. Then we would do a manual test of a representative sample of every page type. So what do I mean by that? I mean, like your homepage, if you have custom post types, you’d look at the archive for the custom post type, you’d look at a single post.

You might sometimes have to look at multiple, if you’ve got maybe different configurations of custom fields outputting on different types, you wanna make sure you’re getting that representative sample. And then any pages with special features. So contact pages that have forms, or a page that has a map embedded, or pages that have a carousel or a slider or tabs or something like that.

If you don’t have it on your homepage, but you have it on the about page, then you would wanna make sure to go test that. So you wanna get a representative coverage with manual testing of all of the components that make up the website. Maybe you’re not looking at every use of that component, um, but you are looking at at least one instance of the component.

And then when we’re doing that, we’re going to test with our keyboard only, and then we are going to do the exact same test again with our browser zoomed to 200%, and then again with our browser zoomed to 400%. And then after we do all of our keyboard testing, we do screen reader testing. So in, in our company, we then resolve all of the issues that came out of our manual testing and we would then move into user testing.

And user testing is a little bit different from having an accessibility specialist test something, because basically what you’re doing with the user testing is you’re more having a user go through a journey and experiencing something. So we would bring in people who are blind and they would be on the homepage of the website and we would say, you want to purchase a pair of knee-high socks. Go do that.

And then you find out how do they go about finding the sock category on the e-commerce store, the specific height of socks, and can they add it to their… Can they find them, can they add it to their cart, can they check out, right? So it’s more of a, a journey and a flow, which gets some accessibility.

You also frequently get other just general UX things out of that. Um, why do we bring in users later? It’s sort of the same thing. Uh, you need to have a really thorough review and a screen reader user is not always going to look at every element on the page. Uh, a lot of times screen reader users have techniques that they use in order to, uh, skip through the content and find what they’re looking for faster.

Most of us, when we go to a webpage, we don’t read literally every word on the page. We skim the headings, we sort of jump around. We maybe even use the search feature to search for a specific string of text. Screen reader users are much the same way. Um, so you wanna have a thorough audit and fix all of those obvious things.

Again, you don’t need to have a blind person tell you that you have an image missing alt text. Um, so, so that’s sort of the order that we go about when we do testing. So I’m gonna talk for just a minute about some of the reference materials that I have on here, because unfortunately this is an hour long accessibility testing workshop, so I don’t have time to go really in depth on all of the things.

Um, so what you are going to be referencing when you’re doing accessibility testing, and you’ll have to forgive my resolution a little bit here. Uh, I may have to zoom in on some of these, but, uh, let’s see. So the references that we’re going to have is Web Content Accessibility Guidelines 2.2, and this is the thing that as you’re testing, you’re going to need to learn.

And, um, these are the specific, we call them success criteria or success criterions that you would reference in order to see if something passes or fails. I’ll talk a little bit more about this in just a minute. Then I also have linked for you on the slides, and I’ll return back to this URL in just a minute for anyone who came in.

Um, let’s see. Oh, not what I meant to do. See, the zoom is a accessibility problem in and of itself. Uh, I have a Google sheet here. This is a tool that we use internally. It has all of the success criterion, and it has, um, what the version of WCAG is. So 2.0, 2.1. Uh, and I actually have not updated this for 2.2 yet.

It’s going to come shortly, but a helpful reference and there’s an explanation field here that explains some of the things that we’re specifically looking for in order to qualify for a pass. So this might be a helpful reference as you’re comparing against, uh, web content accessibility guidelines, which I’m going to be calling WCAG.

And then, um, the other helpful reference as you’re learning, um, how to make things work for screen readers is you need to learn a lot about ARIA, which are HTML attributes that can be added onto tags to help make them work better for screen reader users. So the best resource for that is the Mozilla developer docs, and you can read through that.

And then I have a Shift Left with Accessibility Checklist. This is a list of things that we look at and it’s broken out by phases of project because we, you need to think about accessibility. As I mentioned, it’s not just a QA thing, so happening earlier. So we have things by discovery, content, design, development, testing, all of those sorts of things. Um, and so for example, under content we’re looking at is link anchor text meaningful, that’s something that is here. Content is formatted in HTML lists where applicable. So all of those sorts of things. This would be helpful as a reference when you are testing as well.

And then I have an example audit sheet. So this is sort of showing you one of the ways that we go about reporting issues when we are testing. Um, so we give things an issue number so that they’re easier to reference. We typically do deliver these to our clients in spreadsheets. If we’re doing internal testing for ourself, we’re creating GitHub issues.

Um, but if we’re doing auditing for external, we give them a spreadsheet because then they can import it into GitHub, JIRA, whatever they’re using for tracking. Um. We’ll give a code snippet of the specific element. We have check, which is sort of like a title of what the issue is. If relevant, we’ll have an image.

Um, we typically, for us, these end up being links to Google Drive, stored images, uh, a description, so an explanation of what the problem is, where it’s located. So in this instance, it just says header. Uh, we have the recommended fix, the severity. So for our company, the way we approach this is we only look at severity in terms of high, medium, and low.

I’ve seen other companies when they do audits and they’re going, critical and they have like medium-low and like all those things. The way we approach it and how we explain this with our customers is we look at high as things that are like those critical failures. They’re literally blocking. They would stop someone from being able to do something.

These are the things you need to fix first. Then we think about medium as um, things that are web content accessibility guideline failures. So they would stop a website from being conformant with WCAG or compliant with applicable laws that require WCAG conformance, but they are maybe not blocking. A user might be able to get around this or it’s less severe.

Perhaps, you know, one image on a blog post that is maybe a little bit decorative. It doesn’t have alt text. We think it should because it’s not totally decorative, but it’s also not gonna block someone from fully understanding the blog post. That would be medium because it is a failure in that instance, but it’s not blocking, for example.

And then low, very few low items make it onto our spreadsheet. Most are high or medium, but low is things that are not WCAG failures. They are more best practices or recommendations for better user experience. Then we give them what the relevant success criterion is or whether it is, um, whether it’s a best practice.

This actually maps back over to the WCAG tab, which is the same thing that I have in a separate sheet as a reference, and so it can pull in. And then I have the WCAG version, level, impacted populations. And that’s, and that’s what we’ve got on here. So this is how we typically document things. Uh, I actually have a website that we’ve built that uses a custom post type for the success criterion with taxonomies for the population, the WCAG version, all of those sorts of things.

And a separate custom post type with an issue library. And then we have a Gravity Form, which our auditors use. They fill it out and they can submit, they can select a WCAG success criterion, and then it will give them all of the possible issues that we’ve already found on other websites for that and recommended fixes and it pre-populates.

You can edit it or you can just add the code snippet and the things that moves faster. And then at the end, when we’re done submitting, every time we go export the entries from Gravity Forms, paste it into the sheet. Goes much faster than typing in the Excel sheet. So there are ways that you can automate and speed up reporting of issues.

And then the other thing that is useful on this reference if you’re using Chrome, um, is how to use Chrome with multiple profiles. Sometimes you want to set up one that is specifically formatted for testing. So that’s what this reference is.

So, circling back to web content accessibility guidelines or WCAG. Uh, basically what you’re going to see when you look at this and you start reading through it, is there is going to be a success criterion, number and name. So, for example, I have up here 1.2.2 Captions Prerecorded, and there’s going to be a level.

There are three levels for WCAG, A, AA, AAA. Most laws require AA. You need to meet all of the A and all of the AA in order to be AA compliant. And then you, and then there’s AAA, which some guidelines have both AA and AAA version. A good example of this is color contrast. There is a color contrast that’s considered sufficient, which is AA.

And there is a color contrast, which is a higher level of contrast, which is AAA. And that would be even better, like above and beyond the best practice of color contrast. So we always recommend where possible meet AAA guidelines, but you may not always be meeting every AAA guideline. Um, but if you want to be compliant with laws, you would need to meet all A and AA.

And then below the level there is a description that explains it. So in this one it says, captions are provided for all prerecorded audio. You’ll notice there’s some underlying links here. So if you weren’t sure what prerecorded audio means in the context of WCAG, you could click that, it would give you a definition. There’s a glossary.

Uh, except when the media is a media alternative for text and is clearly labeled as such. So for example, if you had, um, an audio player at the top that just read out the content of the blog posts. Well that is, you don’t also need captions for that video because all of the text is on the page.

Um, in this specific rule. Uh, so that’s what the description is. Very helpful. A lot of people miss this, but on the right there are two links, one to understanding and one to how to meet. These are very detailed documentations that further explain this. So as you’re going through WCAG referencing those as really helpful.

They’ll have pass examples, fail examples, explanations of why this exists, who it’s supposed to help and how. Um, so that is sort of my basic, and I’m gonna go into doing some automated testing in just a second, but I’m gonna circle back real quick for anyone who came in late. These references can be found at EqualizeDigital.com/WCEU24slides.

All right, so automated testing I mentioned, this is the first thing that we do. There are a variety of tools that you can use for automated testing. Uh, I have broken these out into tiny helpers, WordPress plugins, single page scanners, and SAAS scanners.

So tiny helpers are things like browser extensions that do one very specific thing, and I’ll show you a couple of these in just a minute. So what I have listed here is the Headings Map plugin, which has both a Chrome and a Firefox version, Tably for Chrome, and Color Blindly for Chrome.

Um, Headings Map gives you an outline of all of the headings on a page, which is very helpful because you always want to make sure that you’re using headings in the proper order to create a meaningful outline of the content on the page.

Tably shows you in a visual way what the tab order of the page is. It is not a replacement for manually tabbing through everything. However, I have found it very helpful, um, when tabbing or when using Tably to be able to show it to developers in an issue. You can screenshot Tably.

Color Blindly will simulate different versions of colorblindness so you can make sure that there’s a sufficient difference.

So let’s look at a couple of those real quick. And I’m actually going to, I should have loaded this. This is the website for my city, which is a WordPress website.

I am gonna, I’ll talk a little bit about some of the things. There is a video that auto plays on this website, which is the first thing we notice. It does not have any way for me to pause it. This is a Web Content Accessibility Guideline failure. Anything that auto plays, videos or carousels, sliders has, if it’s plays for more than five seconds, animated gifs that loop and are longer than five seconds, has to have a pause button. So this is a failure.

So some of the extensions that we could use here, trying to decide what zoom, and I haven’t tried this, so we’ll see. Oh, good. All right, so this is the Headings Map. It gives me a nice outline. I can see that my H1 is City News, which is right in the middle of my screen. Not what I would think the H1 for the homepage of my city website is. It probably ought to be like Georgetown, Texas City Website or some, you know, something that tells me I’m on the homepage of the Georgetown, Texas website. Uh, and then you’ll notice that everything below this is a heading two, this is a list of posts with read more links.

Uh, not, there’s no real content below those. I wouldn’t make those headings at all. You really want to have headings that give you sub content. So I would just make this a list, like a literal list with the titles inside the LI tags. Um, then we have a Juneteenth celebration, which is a heading two. And then special topics down here is a heading three, which makes me think that it’s a sub item of our Juneteenth celebration, but clearly visually on the page, this is not a sub item and is not related to that at all.

So right here I can see on this outline that the heading structure on this website is just completely off.

Uh, the other browser extension that I wanna show you here, and let’s see where it went, is Tably. So I apologize, this is a little small. I’m not sure how to zoom my UI settings, but, uh, once you open the extension, you can basically say run Tably. And what it’s gonna do is it’s going to run through the page, it’s going to look at all tab stops. Tab stops are interactive elements, buttons, or links is generally what you would expect to be a tab stop. And then it puts an order. You want to see your tab order on the page to reflect the order of the page, visually left to right, top to bottom.

So what I’m seeing here, and we can go back, is it goes to my search form on the right first. Actually, no, it goes to a button here, which I’ll show you in just a minute. That’s actually the submit button for the search form to the left of the form, which also has no label. I don’t know why the button, they’re using the, the submit button as the label.

So the first thing is the submit button, and I’ll circle back in a little bit. I don’t know if anyone knows what we’re missing, what the first tab stop ought to be. Does anyone have any ideas? Skip link. Yes. Uh, if you’re not certain what a skip link is, I’ll show you one in just a little bit. Uh, so we’re missing a skip link.

We go to that button. Oh, then we go over to, did I lose my mic? I maybe. No, you can hear me. Okay. Uh, then we go to the search form, then we go to the item in the right of the menu. We’re going backwards to the left. And then you’ll notice there is a giant link of tab stops. Uh, that is because on this particular website, the navigation is not accessible and it’s hidden.

It stays hidden. You can tab to it, but you can’t see it. Uh, so hidden elements shouldn’t get tabbed. So this is Tably, uh, which is pretty helpful. I’m gonna just hit clear to clear that off there. So those are two examples. I’m not gonna demo Color Blindly right now or some helpers. There’s a lot of these different browser extensions. These are probably the two that I use most commonly.

Um, so then the next section of automated testing tools are WordPress plugins. There are three. We make one Equalize Digital Accessibility Checker. Uh, Editoria11y comes from Princeton University and Sa11y comes from, I, I’m gonna get this wrong because they used to be Ryerson University in Canada, but they’ve changed their name. So the artist formerly known as Ryerson University.

Uh, and these are plugins that you can add into your WordPress website to help you find problems, uh, in the site. Our plugin does the entire page. Editoria11y and Sa11y are more focused on content creators, and so they only test the content. So literally the post content field, they wouldn’t get any meta, they won’t get header, footer, sidebars, but they are still very useful, especially for a content creator.

Um, and then the third group are single page scanners. These are tools like WAVE, which they have a browser extension. They also have a website that you can go to. You enter a URL and it will scan that page and give you a report. And, um, Deque makes something called Axe, which has both a free and a pro version. IBM makes their equal access Accessibility Checker. So these allow you to scan one page at a time.

And then the final group are SAAS scanners. Site Improve, Monsido, Pope Tech, which actually is a platform that uses the WAVE API. So it’s the exact same reports as WAVE, but it allows you to crawl whole websites and get WAVE reports for whole websites. Um, so you sort of have to decide depending upon the client and the platform you’re using and the specific needs, which of these make sense.

And I don’t have time to, you know, go into all of them at this point. Obviously with the SAAS’s, there’s going to be a higher price point than using like a WordPress plugin or just a free browser extension to do your automated testing. Um, I would highly advocate having something that can do a full site crawl for you.

Um, because if you can’t, and you can only do one page at a time, that almost removes the benefit of using an automated testing tool to a degree if you’re trying to get a full picture of a website.

So this is Tably, which we talked about. Um, so I’m gonna do a little bit of automated testing and talk about some things and, um, and then I wanna give everyone a little bit of time to use any one of these tools that looks interesting to you. Uh, so I’m gonna go over to my College University website, which is a fake website ’cause I don’t, I, I’ll call out my city a little bit, but I don’t have access to the back end of that. So, um, so on this website, if I were to use the WAVE extension for example, which is one of those free browser extensions that I mentioned. Um, let me find it. Oh wait, it’s up here.

So I have run WAVE on this website and what it does is it opens a panel on the left and then I have a details tab and I can see it’s telling me I am missing alternative text on one element. If I’m not sure what that means, I can click the info and it will take me over to the reference tab and I’ll see it says alternative text is not present. Um, and then why it matters, how to fix it. If I go back to details, I can also click on the icon and it will jump me, and it’s telling me I’m missing alternative text on this image here of Mary Jackson in my testimonial.

Then I have, um, two contrast errors. So two elements. It’s finding that have low contrast. And some different things. So suspicious alternative text, it’s sort of saying, Hey, maybe this doesn’t have good alt text. So for example, this image has alt text. It says Image of student. And you can sort of walk through. One thing I will flag about WAVE that is pretty important to pay attention to.

A lot of people say, I’m looking at the errors, I look at the alerts. Green is good. I can ignore that. So an issue that I have with WAVE is that they call null or empty alternative text a feature, and therefore it is green. It is good. In some instance, it is correct to have empty alternative text if an image is purely decorative.

However, if we are, let’s see if I can find one looking at this page. And we see this image of people in a library around a computer, high fiving. In our section about why you might choose College University. I don’t actually think it’s a feature that this image is, has empty alternative text. This is an image that provides meaning, it tells you something. Oh, there’s people of multiple genders, ethnicities, you know, there, it might convey something about the resources that are available to students, right? This needs alternative text.

So just because something is green in WAVE does not mean that it is perfect the way it is. So, so you always have to keep these things in mind and this is why you can’t rely only on automated tools because it does take some judgment when you’re testing.

So I will show you, let me get rid of WAVE. So, I have our Accessibility Checker plugin on this website, which has a few different ways that it can be used. There’s a free version you can get off WordPress.org and install if you wanna play around with it. Um, in the free version, you can see it on any posts or page.

It’s gonna run anytime you do a post save. So you either save draft, you update, or you publish and it will scan, like I mentioned, the entire page. There are also plugins I mentioned that only do the content area. And then there’s a couple of ways to see it. So it puts a report right down below and you can see we’ve got a reading level, number of errors, warnings, things that have been ignored because it saves.

This will be forever and you could track and if there’s something that’s a false positive, you could ignore it. And then we could see things here where, so for example, images with empty alternative text is a warning. Um, ambiguous anchor text, things like, oh, we’ve just linked the word here, doesn’t tell anyone about where this link goes.

Uh, so this is an example of doing that. If I wasn’t sure where that is, I could just click view on page and it will show it to me on the front end. You can also move through things on the front end in WAVE. Um, this is improper use of link because I’ve actually forgotten to put a link on it. It just has a hashtag.

Um, so this is an example of a WordPress, as I mentioned, there’s multiple which are linked on the slides. So what I would like to do is give everyone a quick minute to find one of these tools, any one of them. One of the browser extensions, um, or a WordPress plugin, put it on a website. We’re gonna take a few minutes and, um, maybe like four-ish minutes.

So let’s all do that, do some automated testing real quick.

So I will put back up for everyone while we’re doing this, the names of things that you could try, whether it’s a browser extension. Or whether you want to try a WordPress plugin.

Has anyone tried one yet and found, okay. What did you try?

Audience: Uh, I used your tool. 

Amber: Okay. Used Accessibility Checker. Did you find anything that surprised you? 

Audience: Uh, yeah. One thing was, uh, an improper use of button. Sorry, bold button. But in WordPress you can’t add roles to buttons because they’re not buttons you’re using. They’re just links. 

Amber: Uh, but you’re using the link, the WordPress button block to actually create a button, not a… 

Audience: Button something. 

Amber: Yes. 

Audience: One button. 

Amber: So there is a block editor plugin that’s called Attributes that allows you to add custom HTML attributes to anything. It’s free on WordPress.org. And that might not be the exact name of it, but I could find it for you later.

That will solve your problem and allow you to do that. But that is a thing that’s important. Like sometimes we build websites in WordPress and we think this is a button block, but the reality is the button block is not a button block. It is a link styled to look like a button block, which would be a great name for it.

So did anyone else use a tool? Yes. What did you use? Sorry? 

Audience: WAVE. 

Amber: WAVE. Did you find anything interesting with WAVE when you tested it?

Uh, sorry. Something about images.

Just a second. Okay. Okay.

Thank you. All right. Sorry, can you say that again? What did you find when you used WAVE?

Audience: Okay. Uh, missing alt. 

Amber: Oh, missing alt. Yeah. Yeah. So this is an interesting thing. So both WAVE and, and we have this, um, where missing alt and empty alt are different checks. And missing alt means that it literally isn’t outputting alt equals quote on the image.

Um, and so that’s why you’re gonna see that different. For anyone who’s not familiar. That typically is caused by your theme, potentially a plugin. But typically your theme, uh, isn’t coded properly to add the alt attribute at all. Yes. What did you find? 

Audience: Header WAVE.

Amber: Okay, so he has a sticky header and when he uses WAVE, he can’t see, uh, most of what’s there. This is a great thing to note about sticky headers. Sticky headers are very bad for accessibility. Um, when we zoom in, which we’re about to do, uh, they, for low vision users, sticky headers can really cause issues for them.

Uh, so what I would recommend if you want a header to be sticky is that it should hide when you scroll down, but it can come down when people start scrolling up. And I would also not have a sticky header on mobile at all. So that will help you. Yes. We’ll do one more.

Yeah. What tool did you use? 

Audience: Is it on? Yeah. Uh, yeah. I, I used the, um, your, uh, Equalize Digital tool. Mm-hmm. Um, and I actually have, um, I used it on a, a website that I’m working on, and they, like, the designer gave me, um, the design for the homepage and it doesn’t have an H1 or not like an obvious H1. And I feel like every design I get from designer is like that. And so I was wondering like, can I, what, what is the best practice for like H1 on homepages? 

Amber: So ideally you would make the first heading an H1, um, but if it’s maybe a slider at the top, which we frequently see, I try not to do, we don’t do sliders, but, sometimes it’s hard to argue with the client. Um, then you won’t.

Uh, so the way we would handle that is you can add a screen reader only H1. If you’re building in the block editor, there is a plugin called Screen Reader Text Format that allows you to be able to add screen reader text in any block. So you could have an H1 and do that. Uh, if you’re building with a page builder, most of the page builders support use of screen-reader-text as a class.

So you would add your H1 block and then wherever you can put CSS classes on the, that in the screen reader or in the page builder, you just put that class and will hide it visually. But it will be there for Google. ‘Cause Google cares about H1s too and for screen reader users. So, yeah. All right. So we’re gonna talk a little bit about keyboard testing.

So when we are keyboard testing, which is the next thing we do, uh, we want to look for a lot of manual functionality. So the idea behind keyboard testing is that many, many people cannot use a mouse. This would be people who are blind, who literally can’t see where they’re pointing a mouse. Um, or people who are sighted.

There are a lot of sighted users who can’t use a mouse. For example, if you went to Rian’s talk yesterday, she mentioned her father with Parkinson’s. He had a hand tremor. And so using a mouse was very difficult for him to control where it was clicking. Um, so there are instances of that. So what we are looking for when we keyboard tests is we want to have clear focus indicators.

We wanna have the ability to interact with all elements with a keyboard alone. So anything that you would expect someone to do with a mouse. Opening, closing accordions, changing tabs, if you have tabbed content, submitting forms, adding a product to a cart, anything that you’d expect them to do, uh, changing slides on a carousel. They have to be able to do without using a mouse.

And then we’re looking for keyboard traps. This is somewhere where I get put into something and I cannot leave it. I can’t tab out of it or shift tab, reverse up the page. I’m stuck. That’s a keyboard trap. And then during our keyboard testing, we’re also looking for a lot of content accessibility issues while we’re doing that. Um, and you can reference our checklist for what those are.

And then we will test zoom to 200 and 400%, which I mentioned. The main thing that we’re looking at when we do that is we’re looking at, uh, WCAG 1.4.10 reflow, which requires that no loss of content or functionality occurs, and you cannot have horizontal scrolling when content is presented at a width of 320 pixels.

Basically the website needs to be responsive. Um, don’t cut things off if zoomed in or on a mobile. Um, you can best test this by sending the browser window to 1,280 pixels wide and then zoom the page to 400%. Um, any content that requires horizontal scrolling such as data tables, complex images, maps, toolbars, are exempted from the horizontal scrolling.

So there is some of that, but most like text content should not require horizontal scrolling. So let’s look at that in practice and then I’ll give you a minute to do a little bit of this. Um, so we can go back to, um, my City of Georgetown website. And what I’m gonna do, let me just refresh to make sure I’m focused at the top.

On this is, I’m going to tab, so I’ve got, this is where we missed the skip link. So the first thing you want to see when you go to a website and you focus on it is a link that says Skip to Content or Skip to Main Content. And that should be the first focusable element. So the first time I hit the tab key, this should pop up. And then if I were to hit the return, this is a link links work with the return key only, it would jump me down. I can see it’s focused me there.

And then if I hit tab again, it would take me into the next focusable element, which in this instance are link buttons, but they’re links. Um, so this did not have the skip link and so therefore it, uh, fails because it doesn’t have one at all. On, uh, my college university website. Let’s close Accessibility Checker here and get my focus up to the top.

Let’s see, let’s see if I got this fixed. So this scrolled me down and I hit tab, oh, nope, they fixed it. I forgot this theme. I reported it and they fixed it. Uh, I wasn’t sure if I’d updated the theme. Sometimes what happens when you do this is it will, um, it will visually scroll you down, but it won’t actually shift the keyboard focus.

And so if you hit tab after you hit the return, it scrolls you down. After you hit return, you hit tab. And you’re then up here in the nav, um, you’re still up there, then that means it’s failing to actually shift focus. This most commonly happens when you have smooth scroll enabled, uh, if the smooth scroll has not been done right.

So you have to make sure that you don’t just watch it scroll down. You need to actually hit the tab key again and make sure it shifted your focus into that. Um, so then I am basically going to tab through everything in this website, right? So I’m looking and I’m seeing things like, okay, my, my order, this is me tabbing down, my order’s going reversed, right?

We looked at that. I’m gonna tab and try and figure out, oh, hey look, my outline went away, so I want everything to have an outline. This was good. Now it’s gone. Don’t know where I am. Uh, there’s a really handy thing you can do in your browser, which if you just Google this, uh, you can add a live expression that will help you track keyboard focus and in your console.

Then, uh, this is what I do. We’ll see how tiny this is.

So when you turn on that live, you can then see, so right now I’m on this body short codes. Sometimes this is kind of helpful, right? I’m on an input right now. So that will help you if your focus disappears. Span item, link a, these are links, right? So then I’m kind of like, oh, this is where I am. I’m in the nav, but it didn’t open.

So that would be a fail. Um. And so basically you’re gonna tab through everything. You’re gonna make sure you can get to all the things that you want to get to, that there is a clear outline. Nothing that is hidden receives focus. So either it gets focused and moves into view in the case of your dropdown menus, um, that sort of thing.

And then I also, you can wait to do this with a screen reader, but I also, very frequently you are gonna have to sort of get familiar with HTML. I’ll also frequently just inspect things. So when I look, for example, at this search field, um, I can see it has an ARIA label of search. It doesn’t have a visible label there.

Uh, we in an audit would fail this. We are gonna require a visible label technically in WordPress accessibility ready, the current version, as long as there’s an ARIA label, it’s okay. Um, but for an actual accessibility audit, this would get a fail and it needs to have a visible label. Um, for people. But you can do things like that where you’ll inspect the code and, and look through and try and identify problems.

Are there areas where I’ve lost the outline, those sorts of things. Um, so I wanna give everyone maybe, uh, two minutes on any website to use your tab keys. So you tab forward and you tab hold the shift plus tab to go backwards. Um, if you encounter a button, and this is an interesting note, talking about using the button block to build buttons.

Just adding a roll of button isn’t sufficient because the expectation with a button is that you can also open and close it with the space bar. So a button should work with the return key and the space bar. So on this website it will go here. This is a button to open this. If I do this. The return key, it opens and closes my dropdown.

If I do the space bar, it just scrolls me down. Why is this? So my first thought is they’re incorrectly using links. Perhaps it’s not a button at all. So we can look and then I do see a button, right? So this is where I would start to explore and figure out why. Why is that not, oh wait, this might not be my actual let, let’s see. That might be my mobile.

Just make sure I’m focused on the right thing. There we go. Okay, so, so this is why, right? They have, added, I think. No, that is it. Yeah, so, so this is something I would have to explore, like why does this button not work with the space bar? Because space bars should function on buttons natively. So I don’t know if they’ve done something odd here in order to actually make it work.

So it is a little weird because they have this, no, I think actually there’s a button here that’s not visible right now. So sometimes I spend time looking at the code and I’d say, is there CSS? Like this button might actually only be on the mobile menu, right? So go ahead and tab through. While you’re doing that, I’m in a demo doing something, which is the zoom.

So this is important, right? A low vision user might always en encounter your website in this way because they need the text to be larger. And so you, when you’re keyboard testing, you gotta make sure your mobile menu works. Space bar, space bar worked on that. Space bar works on this. I think the button that functions is the mobile one, which isn’t visible and they have a different one on desktop, which is the span.

So, so just take a minute. Yes. Uh, can we get a mic over there? Yep.

Audience: Sorry, just a question for understanding. I do not know if that is the expected behavior. Mm-hmm. Um, when you have a button and you click, um, uh, space as you said, then you then, then it fires the function behind that and to follow a link, you use return. Is that correct? 

Amber: Yes.

Audience: Okay. 

Amber: So buttons work with space bar or return. Links work with return only. 

Audience: Okay, thank you. 

Amber: Yes. And a screen reader user is gonna know this. So when they hear button, they, they may default to using a space bar. So if you’ve turned something that’s not a button into a button, which could be a div and you’ve given it a roll of button or a link and you’ve given a roll of button and you don’t add a space bar handler, then that can cause a usability problem. Uh, there’s someone over here. Yes.

Audience: Um, are we supposed to be using the Tably browser extension? 

Amber: Uh, no. You don’t have to use that. So for keyboard, so that’s an automated tool. So for keyboard testing, you really just using your keyboard. So it’s a combination of using the tab key to move around and the space bar and return key to make sure you can interact with things.

And then I do a lot of, as I mentioned, just inspecting code while I’m doing it to try and figure out what am I seeing or why. 

Audience: Okay. I think I ran into an issue. 

Amber: Okay. 

Audience: Because I’m on my test site. And I’m, I’m in the browser tab. Like first I go to the open a new tab, then I go to the bookmark section and I’m just staying up there.

I’m not even getting into the website. 

Amber: So you found what’s called a keyboard trap. 

Audience: Okay. 

Amber: If you can’t tab beyond it, then there’s something, and I’d be happy to later actually look at that and try and help you figure it out. So I’m gonna move forward and talk a little bit about screen reader testing. So there are two different screen readers that most of us are going to use. There are three screen readers. Um, so on a Mac, you have VoiceOver built into your Mac, and if you are on a Windows machine, then the screen reader you’re most commonly going to use is called NVDA.

It is a free open source screen reader that only functions on Windows. Uh, there is also JAWS, which is a very commonly used screen reader by blind people that works on windows. It is a paid screen reader. It is quite expensive. It is rapidly using losing user share to in NVDA, even among blind people because of the fact that you have to purchase it, to use it.

Um, so what I have on the references here that are very helpful is there are links to VoiceOver documentation on how to turn it on and off, which there are shortcuts for that. Um, and also keyboard shortcuts. Um, and I have these for both. So this is the Apple keyboard shortcut for VoiceOver, and then, uh, a resource from Deque. Oh, nope, sorry. This is actually from NV Access that has all of the screen reader shortcuts for NVDA.

Um, the biggest thing, before you turn it on, I know some people it’s going to start talking to you, and some people find that a little bit overwhelming, so whichever one you’re going to use, I would find out how you quit it just so you know how to turn it off. So you’re gonna wanna reference this, um. So basically when we’re screen reader testing, what we’re doing is listening for a few things.

So one, we’re anything that interrupts or makes announcements without prompting. So if you load a page, a lot of times pages that have carousels that are auto-playing, if they’re not set to be what’s called ARIA live polite, then there could be a carousel somewhere else on the page, not where you are. And you’re gonna hear every time the slide changes, it’s gonna interrupt whatever, even though you’re not focused on it.

That would be an example of something that interrupts and is not correct. Um, you wanna look for any sort of ambiguous or unclear links, buttons, or other elements. So things that just don’t make sense to you out of context. So like for example, we saw that Accessibility Checker flag a link that said here. Screen reader users, as I mentioned, they don’t always go through the page. And one of the things that exists in screen readers is the ability to just get a list of all of the links on the page. So if you have a list that says, link here, link learn more, link learn more, link, click here. What is that link about? Where does it go? I don’t know. Right?

So listening for things like that. Um, same thing with buttons. Even things like download or add to cart, right? If you are on a product page with a single, just add to cart is fine. If you’re on an archive page, your add to cart buttons need to have context add shoes to cart, add red shirt to cart, whatever the product name is, right, so that they’re unique and distinguishable.

On your blog archive, read more can’t just say, read more. It needs to read out to screen readers. Read more of post title. Right, so thats what you’re listening for. Um, then you wanna make sure, we didn’t demo this, but you wanna make sure when you are testing forms that any error or success messages are announced by the screen reader.

So you’ll want to go submit your form using your keyboard only have your screen reader on, and make sure that when it says, you know, first I go to it and I don’t fill anything out, and I just hit the submit button. Does it tell me auditorily, not just visually that there was an error. Um, and then I fill out all the things I’m supposed to fill out and I submit it again and I figure out, did it tell me auditorily yes it was submitted? And whatever the message is that is communicated to people when they submit the form.

And then I listen for some missed opportunities to manage focus. What does this mean. If you have a popup on your website, sometimes in some page builders nav menus on mobile are popups. They’re modals. And when a button is clicked to trigger a popup, it needs to move the keyboard focus into the modal, and then it needs to keep them inside the modal.

So you would tab in a circle. You can’t get anything behind the page without closing it. Uh, so we’re looking at that like, are we managing focus appropriately? If we have a load more on a group of posts and we load more, does it shift us to the new one? Or are we stuck down here and now we don’t know how to find the more that loaded.

Those sorts of things. And then we’re also checking for elements that are missing from headings, links, buttons, things that we think should be there and are not. Uh, so I will very quickly demo this and then I wanna give everyone a minute to try and I will reset my zoom a little bit. So I am on a Mac, so I’m just gonna use, uh, function command F5.

Voice over on ra admissions college, university ra, window admissions college, university web content test focus currently on web content inside the group. To enter the web area press control option, shift Daniel to exhibit group press control option shift audio.

So that is VoiceOver. You can change the speed in your VoiceOver settings.

I know I have mine a little bit fast. I meant to turn it down, but we don’t have a ton of time, so I’m just gonna go. So what I’m gonna do is I like to do a, um, VoiceOver for me it’s caps lock A from the top and just have it read and I watch it and I have it read the whole page. And then I will go back with like tabbing and stuff and listen to things that seem weird.

But for me it’s helpful to just hear the whole page and observe it and be like, is it doing what I think it’s going to? So let’s see where we are.

Map list where items link, visit link. Skip to content. You’re currently on a link inside of web content. To click this link, press control option space to this area. Press control option shift.

All right, so also, I don’t know if it’s being a little weird for me since I’m just displaying, but um, so one of the things I’m gonna listen for is I wanna hear that this navigation menu is a navigation and it’s gonna tell me how many items.

Visit link. Skip to content site navigation. Top menu navigation list. For items, link, current students link maps, link directory, link giving link, search icon link visit link image College University visit link College University, educational institution site navigation. Primary navigation list seven items. Collapse link about menu table collapse link, academics menu, ta, current page VoiceOver off.

All right, I’m gonna turn off for a second. So, so that was something I was losing for. It told me it was a navigation, and you’ll notice I heard top navigation and then I got to this one and it said primary navigation. That is good. If you don’t, if it doesn’t tell you what navigation it is, that’s a problem because how would you distinguish between the different navigations?

It also shouldn’t say the same. I’ve seen some themes where it just says navigation, primary navigation for all of them. That’s also a problem. ‘Cause how would I know how to get back to the primary navigation if I wanted to do that? It gave me a list. It told me how many items.

Something I wanna watch for, and I see this a lot in themes where they have something styled as a button, like the contact, but they’ve added it in a widget area, so it’s not actually in the navigation. That’s a, that’s a significant issue because that would mean the screen reader user is not as likely to find it. Um, so, so basically I’ll read, I’ll listen, go through the page, those things.

So I wanna give everyone a minute or two to try turning on a screen reader user, you probably need to make sure you have headphones. Listen to a page and then we’ll circle back. 

Audience: Hi. Um, I just had a question about using screen readers with websites that are in different languages. Are they available in all languages like Greek, for example?

Amber: Yes. So in your screen reader, you can enable different voices for different languages, which is pretty helpful because then you can distinguish. Um, but yes, they are available in all languages. Uh, has anybody found anything interesting or anything they wanna share while screen reader testing? There’s someone over here. Okay. Yep. I’ll go to you next. Uh, no.

Audience: Thank you. Uh, I tested a form and it told me this field is required, but it didn’t tell me which field it was. 

Amber: Ah, yes. 

Audience: So I’m now going in and changing the, uh, the, the alerts to say the name field is required. Which, um, yeah, I wouldn’t have thought about if I hadn’t to use a screen reader. 

Amber: Yeah. So sometimes if it’s missing form labels or depending on what form plugin you’re using, if it’s not connecting the error appropriately, it won’t read the name of the field.

Yeah. Yeah. And that’s something you wouldn’t know unless you had listened with the screen reader. Yeah. Uh, there’s someone over here. Right here.

Audience: There we go. Here we go. Alright. Yeah. Hi. Um, I’ve got, got a different issue about buttons, which I discovered by on tabbing, which is related to Gutenberg button groups or something. I’ll talk to you later and see if you can guide me on that. But actually on screen leaders, readers, I, I’m surprised I’m the only WordPress developer that uses Linux. It’s a… 

Amber: I think you should be able to use NVDN Linux. 

Audience: Uh, no, I can’t. But, um, Orca, um, Joe pointed out there’s a, a tool called Orca. For anyone who does use Linux. And, uh, I’ve also discovered it doesn’t work with Firefox, so you have to use it with Chrome. But, uh…

Amber: Yeah, that is a thing to be aware that screen readers will announce different things in different browsers and in different operating systems. It’s not fully consistent across all browsers. So if you are a Mac user, like I use Mac as my daily device, most computer screen reader users are on Windows using NVDA. You also need to test with Windows NVDA. I have a Windows machine that I use just for screen reader testing and a few other random things.

And that’s pretty important to note. Um, so I would just sort of be aware of that. I’m gonna throw up our meetup and my contact info, but I have time, I think two minutes for maybe one more question. Um, yep.

Audience: We have an interesting conundrum in that we have an interactive element on our homepage to showcases where we, uh, pull them in using an iframe. And the thing is that for screen readers, and these iframes actually work, they work if you go to a direct link as well. So for screen readers, we’ve set a screen reader only and added a button for that.

And then we wanna hide the buttons for the non-screen readers. But that’s not allowed accessibility wise. You’re not allowed to hide things from screen readers. But we’re actually helping users, so we’re getting an error even though we’re helping users. With the device that they’re actually using.

Amber: Because you’re sending them, you wanna send the screen reader users to to the actual URL because eye frames can be very problematic. 

Audience: Exactly. 

Amber: For screen reader users, there’s, yeah, you do frequently get issues if you hide things from screen readers, and I think most people would fail that. So I like in an audit, yeah, that you’re hiding a whole section of content. So I think rather than hiding it from screen readers, I would just have a clear notice or potentially put that button right inside the iframe, like the link inside the iframe. So it’s the first element that they encounter if they enter the iframe and then they could choose to open, like you could literally have texts like open iframe, you know, in new tab or whatever.

So it’s, whatever the correct language would be. Sure. And that might be a way to handle that. And then the I frame’s still available to them, but they could choose to use the iframe or they could choose to go somewhere else. 

Audience: Okay. Cool. Thanks. 

Amber: Um, that might be our last question, so I am happy to talk to people after.

View the presentation slides on Google or access a text version lower on this page.

Intro to Testing

Website Testing Process

1. Run an automated bulk scanning tool to check
   for obvious accessibility problems 
2. Manually test a representative page of every type (home, archives + singles, and any pages with special features):
   1. With keyboard only
   2. With the website zoomed 200% and 400%
   3. With a screen reader
3. Resolve all issues from scan and manual testing.
4. Bonus: bring in screen reader users or other users with disabilities for user testing to confirm accessibility.

Reference Materials

• Web Content Accessibility Guidelines 2.2
• WCAG Quick Reference
• MDN Web Docs: ARIA
• Shift Left with Accessibility Checklist
• Example Audit Report Sheet
• How to make different Chrome profiles (if you want a testing-only profile)

Get to Know WCAG

Each success criterion has several key parts:

• The number and name.
• A Level, A, AA, or AAA.
• A description that tells you how to measure if the criterion is met.
• Links to two different types on helpful guidance: an understanding doc that explains the criterion and a “how to meet” doc with examples of passes for the criterion.

We don’t have time to learn WCAG today. Our WCAG Quick Reference is helpful as well for summarizing somethings that need to be tested for each criterion.

Automated Testing

Automated Testing Tools

• Tiny Helpers
  • HeadingsMap Chrome, HeadingsMap Firefox
  • taba11y Chrome Extension
  • Colorblindly Chrome Extension
• WordPress Plugins
  • Equalize Digital Accessibility Checker
  • Editoria11y
  • Sa11y
• Single Page Scanners
  • WAVE
  • Deque’s Axe Free/Pro
  • IBM Equal Access Accessibility Checker
• SaaS Scanners
  • SiteImprove
  • Monsido
  • PopeTech (uses the WAVE API)

Other Automated Testing Notes

You’ll need to get familiar with HTML and using the browser inspector.

Tools demonstrated live: Equalize Digital Accessibility Checker (free) and HeadingsMap Chrome extension.

Keyboard Testing

The Goal

• “Keyboard” testing is more than just keyboard functionality – this is when the bulk of manual testing happens.
• Look for:
  • Clear focus indicators.
  • Ability to interact with all elements with a keyboard alone.
  • Keyboard traps
  • Content a11y issues – see Equalize Digital’s checklist

Test Zoomed to 200% and 400%

• 1.4.10 Reflow requires that no loss of content or functionality occurs and horizontal scrolling is avoided when content is presented at a width of 320 pixels – I.e. the website must be responsive.
• Best tested by setting the browser window to 1280 pixels wide and then zooming the page content to 400%.
• Content that requires horizontal scrolling, such as data tables, complex images (such as maps and charts), toolbars, etc. are exempted.

Screen Reader Testing

Screen Readers

• VoiceOver – built into Mac and Apple devices
  • Keyboard shortcuts for VoiceOver
• NVDA – open source, free, Windows only
  • Keyboard shortcuts for NVDA
• Jaws – paid screen reader

Listen For…

• Plus check for elements missing from the headings, links, buttons, etc. panels.
• Anything that interrupts or makes announcements without prompting.
• Ambiguous or unclear links, buttons, or other elements.
• Status messages (success, error, etc.) that are not announced by the screen reader.
• Missed opportunities to manage focus.