Welcome to the fourth video in this Accessibility Testing series. Please reference the blog article Performing an accessibility test.
Transcript
Rachele: [00:00:00] Hi, my name is Rachele DiTullio, and this video is part of my accessibility testing project. It’s a continuation of part two performing inaccessibility test. You can find all of the project resources on my website at racheleditullio.com/projects/accessibility-testing. So let’s get started.
Okay, so part three of this video series is going to focus specifically on how we do mobile accessibility testing. If you’re doing a WCAG 2.1 audit, you need to be concerned about things like orientation and reflow. And so while we covered some of looking at the mobile menu in the last video, I want us to specifically go over testing the mobile version of the menu because it is a little bit different than the desktop version of the menu.
So the first thing that we do when we’re testing for mobile to make it easier to continue to use [00:01:00] things like devtools. Instead of resizing the window down to the smallest viewport that we have to support, which is 320×256, what we can do is actually set our browser to 1280×1024.
Then if we go ahead and zoom in to 400% that actually simulates the 320×256 viewport size, but at a much larger size that we can look at on the desktop and do things like take screenshots and test whether components are working in a bigger viewport than trying to resize our browser down to a teeny tiny 320×256.
We can actually simulate that again by resizing the browser to 1280×1024 and zooming to 400%. So let’s do that. And the way that I resize my browser is I have a little browser extension here called window sizer for Firefox. If we open that you can see I have some preset browser sizes defined here.
So I’m gonna select my [00:02:00] 1280×1024 and we’ll see the browser window close up a little bit, and then we’re gonna go ahead and do that zooming to 400% and we’re gonna go ahead and trigger. So at 200% we can see we’ve already triggered the mobile menu, so we’re gonna keep going to 400%. And so this simulates exactly what it would be like to experience the website on a smaller handset.
So we can see some things like our navigation has disappeared behind this menu icon. We still have our search and our cart. If we go ahead and open up the menu icon, we can see that there is some navigation items behind the menu icon. And then we can close this and we come back to here.
So we’ve already noted a couple of issues with the mobile navigation in the last video, but I’ll go over them again. So one thing is that this icon that denotes the
menu button doesn’t have enough contrast with the background. It doesn’t have 3:1 contrast, so this might be hard for people with low [00:03:00] vision to actually see.
Another issue is when we actually opened this dialog here, it’s actually in the HTML not defined as a dialog. It’s, it doesn’t announce itself as a dialog. It’s missing the correct role and it’s missing an accessible name, identifying what it is. Because in theory, when a dialog takes up the entire screen like this, users should only be interacting with the dialog. It should act like a separate page, which means including an accessible name which acts kind of like a page title.
And then the last thing that we talked about a bit was focus management. So if I go ahead and start tabbing through all of these items here, we see when I get to the end I can, I’m still tabbing and if you look in the very bottom corner of the screen, you can see the URL is updating. So we know we’re tabbing to something that’s behind the dialog. So they’re not trapping focus to the dialog.
Those are all things that we’ve already talked about when we did the last video, but we’re gonna look a little bit further into some other issues that might [00:04:00] come up and things that we need to test.
Something that we noted too was that pretty much every control that we have tested on this page in the header does not have focus indicator. So I’ve had to turn on using a bookmarklet, a visual indicator of focus, so that I can understand where I am in the interface.
Something else that I wanted to try to do was actually run axe devtools on the page when the mobile menu is displayed rather than the desktop menu, so that we can see if they’re doing anything different with the HTML for the mobile display versus desktop display, we can pick that up.
So the first thing that I’m gonna do is I’m gonna go ahead and inspect the code here. And I’m gonna find, so here’s our header, which is what we’re testing. And then after that is a <div> with id="main". And I’m actually going to, in the CSS, I’m just gonna do display:none so that we’re hiding everything on the page that’s not part of the global navigation.
And then I’m gonna go ahead and [00:05:00] zoom back to our 400%. I’m gonna open devtools with F12. And you can see, we can still interact with devtools which we would not be able to do if this screen were at 320×256. So again, it’s really useful to just zoom into 400%. So let’s go ahead and open the menu and then let’s go to our axe devtools and run devtools on this part of the page.
All right, so we have zero automatic issues on the mobile version of the dropdown, so that’s really great. So now let’s continue on with some manual testing so we can test things, for example, like focus order; whether or not these controls that expand and collapse with a mouse are working with the keyboard.
First I’m going to go ahead and enable that force keyboard focus so I can see where I am on the page. When we opened the navigation menu, [00:06:00] the x close control is what had focus on it. So we can see if we move back in the focus order, we get to the search magnifying glass.
If we go forward in the focus order, we get to the close icon. Then it goes to something that’s hidden. And if we go ahead and check what that is. We can do document.activeElement, and that will tell us that focus is actually on a <div> with a class of av-burger-overlay-scroll. So I’m guessing that’s the dialog container itself.
If we have focus on that, we can see that we’re able to scroll with the keyboard. So that’s not necessarily wrong, it’s just that it is hidden in the focus order. So let’s go ahead and see if we can find that in the code. And we open F12 again, and let’s see. [00:07:00] So it seems to be this element right here that is getting the keyboard focus.
I think we should mark that up in our notes under focus order and just say that this element should not be getting focus. So let’s go ahead and grab this code snippet so we know which one we’re talking about. This.
Okay, let’s go over to focus order.
All right.
So we’ve already got that focus is not constrained to the menu dialog when it is focused. And let’s go ahead and add: A hidden [00:08:00] element gets keyboard focus. This may confuse keyboard users. All right? And then we can say: Ensure hidden content does not get keyboard focus.
And then we can go ahead and add our little code snippet number three. And we don’t need this whole thing. We just need the <div>, which I thought I had copied, but apparently not. All right. So just the <div> that we’re talking about. Okay, great.
All right. Let’s go back to our test page. All right, so after our hidden element, the first element [00:09:00] that gets focus is the “Order Tags” link, or it might be a button, I’m not sure. We’ll have to figure out in using it. So if I hit the ENTER key, it expands. And collapses. So we’ll have to check with the screen reader if it’s conveying the expanded and collapsed state.
Let’s see if the child elements get focus and it looks like they do. So we’re going through these. Okay, now we’re at items that don’t appear to have sub-menu items until we get to “About”. And let’s see if that expands and contracts. Yes, it does. All right, let’s make sure the child elements get focus. That’s all good.
There’s one other control that we need to check and that is the search control. So let’s TAB again until we find the search control. I think I lost it. [00:10:00]
Not sure where. Oh, there we go. Okay. So search. If we search, and we hit the ENTER key, we have a little box that’s expanded and focus moves to it, which is correct. We’ve already noted that the the search text in the box doesn’t have enough color contrast. Can we close this without the mouse. And no, we cannot use the ESC key to close this. So let’s see if we’ve already noted that under keyboard.
So let’s look at 2.1.1 keyboard. Okay, so we have not noted the issue with the ESC key. So let’s go ahead and write that up. So we’re gonna say: In the mobile dialog menu keyboard users cannot close the expanded search [00:11:00] control using ESC. This content obscures other content on page.
All right. And as far as remediation goes, we can say: Ensure users can close content that covers other content using the ESC key. All right. And I don’t think we really need a code snippet for this one because it is just referring to the behavior of a control.
All right, so let’s go back to our page. Let’s close this manually and. We can look at other things like [00:12:00] the text. Text contrast is still good. Non-text contrast of these controls seemed pretty good. What we’re gonna need to test are whether these controls are announcing their correct name, role, and value.
So let’s go ahead and test this using NVDA. Let me start up the screen reader.
NVDA: [NVDA tone] 2023 homepage.
Rachele: Okay, let’s see if we can get focus into the dialog.
NVDA: Clickable banner, boomerang, customer. Navigation landmark list with two items. Clickable search. Visited link.
Rachele: Okay, search visited link, that’s fine.
NVDA: Clickable menu visited link.
Rachele: Clickable menu, visited link. I mean, it’s not the greatest name. Having the name of “close” would probably be better since the other control when you open this menu is called menu, but they’re probably doing that because they’re reusing the control and it’s just not totally obvious. So I’m not gonna fail that. But at least it has an [00:13:00] accessible name. So now let’s go through the different links and controls in the navigation and see how they sound.
NVDA: List with nine items. Order tags, visited, link. List order tags, vis…
Rachele: Oops. So that started talking a lot. So let’s see if we can…
NVDA: List with. Order tags, visited link.
Rachele: Okay, so again, I think we already wrote up the issue that these are not identified as buttons and they do not convey their expanded and collapsed state. So if we trigger this, we don’t hear anything from the keyboard, so let’s go ahead and look. If we…
NVDA: boomerang, boomerang tags.xl…
Rachele: Let me exit from the screen reader.
NVDA: Exit NVDA [NVDA tone]
Rachele: And let’s look at what we’ve written up for name, role, value already. Just gonna be down here. Let’s see. [00:14:00]
Okay, so we haven’t written this up. Let’s go ahead and say: Controls that expand to show more links in the mobile menu do not convey their state of expanded or collapsed. Users of assistive technology may not be aware that there is additional content, additional hidden content.
Okay, so then as far as remediation, we can say: Best practice is to use a <button> element for controls that expand and collapse. If that’s not possible, [00:15:00] add role="button" to the control. Because it’s already a link and it will get tab focused already. And then we can say: Add the aria-expanded="false" attribute to the button and update the value to "true" when the control is expanded.
All right. We will need a code snippet for this one. So let’s see. It’s so number four. So let’s go ahead and look at our test page and see what this guy is marked up as. So it’s just, just a regular old link. So I’m gonna go ahead and grab that.
Put this in here. [00:16:00] Gonna prune out what’s in between the link tags cuz we’re only concerned about the link control. Okay? All right, let’s keep listening to this page with the screen reader. I’m gonna start NVDA up again.
NVDA: [NVDA tone] Order tags, pane. List with nine… order tags, visited link. Stainless steel, visited link. Brass, visited link. CollarTags trademark, visited link. Military, visited link. Plastic, visited link. Collars, visited link. About, visited link.
Rachele: Okay, this one looks like it expands and contracts too. So let’s see if how it’s marked up. Okay, so it’s the same as the other control. It’s probably marked up as a link and it does not have the aria-expanded attribute on it.
But let’s listen to how the child links sound.
NVDA: List with seven items. What tag will best protect your pet? Why our tags are better, link. About [00:17:00] Boomerang Tags pricing, link. Videos, link. Guarantee, link. FAQs, visited link. Shipping information, link. Contact, visited link. List with one item, zero visited link.
Rachele: And let me shut down the screen reader.
NVDA: Exit NV… [NVDA tone]
Rachele: So everything sounded great in the mobile view as far as having like link purpose in context. Our controls had label in name. So that was all good. One thing we didn’t test with the screen reader is the search. So let’s go ahead and do that real quick.
I’m gonna get. Focus back to that search control. Then we start up NVDA.
NVDA: [NVDA tone] Search landmark. Search, edit, has autocomplete, blank.
Rachele: All right, so search landmark. Search, edit, has autocomplete, blank. So that’s great. What happens if we perform a search. So it’s performing the search.
NVDA: ID tags for cats. April 18th, 2022, visited link.
Rachele: So if [00:18:00] we hit TAB, we can look at the search results.
NVDA: Plastic PET ID tags. March 29th, 2022. PET Identification, 101. November 22nd, 2021, link. Clickable search, landmark, View all results, visited link.
Rachele: So if we navigate back to the search, we can close it, but that’s a little bit clunky. It would be better if users can use the ESC key. So that’s why we’ve written that up. But I’m gonna go ahead and turn off the screen reader .
NVDA: Exit NVDA. [NVDA tone]
Rachele: Okay. So that was our name, role, value. Let’s just take a look through the list of success criteria and see if there’s anything else that jumps out.
Something to note. So as far as orientation and reflow, which is what we’re really trying to test with this mobile view is we can see the, the site works great in the portrait orientation at three 320×256, which is the smallest viewport that we need to accommodate for. So it passes orientation [00:19:00] just fine.
And then we can see that everything that was available in the desktop version of the navigation is also available in this version of the navigation. So we can say that it also passes reflow. So I think everything is looking good with this.
So we also, before we tested this version, we tested the zoomed in version of the homepage before we opened the navigation. So we did that as part of part two. And this one we’re just focusing on what happens when it expands. So I don’t think that there’s anything additional that we need to write up for this particular navigation component. I think we’re truly done this time. And so I’ll go ahead and upload the completed checklist to my website.
And you can go ahead if you want to contact me about any questions having to do with this or any of the other videos you can email me at [00:20:00] rachele.ditullio@gmail.com. You can reach out to me on Twitter @racheleditullio, or you can just visit my website racheleditullio.com.
Thanks for watching. Bye.