Welcome to the second video in this Accessibility Testing series. Please reference the blog article Performing an accessibility test.
After watching this video, check out part 2 of 3.
Transcript
Rachele: [00:00:00] Hello, my name is Rachele DiTullio, and I am here to talk to you about accessibility testing. You can reach my accessibility testing project page on my website at https://racheleditullio.com/projects/accessibility-testing. This is part two in a two part series where we will be going through performing a web accessibility test.
On this project page, you can reach the blog articles and videos for part one and part two, as well as download the accessibility testing spreadsheet. My contact information is my name: Rachele DiTullio, R A C H E L E D I T U L L I O. On Twitter @ racheleditullio. My email is racheleditullio@gmail.com and my website is racheleditullio.com. So let’s get started.
Okay. Let’s go to our webpage and [00:01:00] the first success criterion we’re going to test is 1.3.5 Identify Input Purpose. The description is the purpose of each input field collecting information about the user can be programmatically determined.
This is referring specifically to using the autocomplete attribute on form fields that are collecting personal information. Now, going back to the site, the only form field we have is the search box and there’s nothing, that’s not collecting personally identifiable information, like your name, first name, last name, email address, that kind of thing. So we can go ahead and say that’s not applicable because we’re not identifying input purpose.
Okay. Next we have Link Purpose in Context. So what this is basically asking us to do is make sure that any text that’s part of the name of a link, makes sense out of context. Assistive technology [00:02:00] users can bring up a list of links on a page and navigate purely by links.
So it’s really important that links don’t have generic text like “click here” or “read more” or empty link text or anything that will prevent an assistive technology user from understanding what the purpose of a link is. So what we need to do then is go ahead. We’re going to, I’m going to start up the screen reader again. We’re going to go through each of these links and make sure that the names that we’re hearing for the links make sense. Let’s start up NVDA.
NVDA: Boomerang tags, clickable banner shop visited link card visited link navigation, landmark list with 10 items, clickable order tags, visited link store boomerangt….
Boomerang tags, clickable banner landmark navigation, landmark list with 10 items, stainless steel visited link.
Rachele: Now the [00:03:00] “Order Tags” has a menu that drops down when we hover over that element. But because the menu can not be triggered with the keyboard, we’re going to have to use the mouse to try to determine if the names of those links are correct. So I’m going to go ahead and hover now.
NVDA: Order tags, collar tags, trademark
Rachele: I’m going to use the browser inspector to try to inspect this element. And I know that it drops down a menu. So I’m going to try to inspect the menu. Let’s see if that works. So we found, so here’s the menu. It has visibility hidden. See if we can get this menu to display all the time.[00:04:00]
Okay.
All right, there we go. So I turned off the CSS settings on this menu, it had opacity set to zero and visibility set to hidden. So I undid those so that I could get that menu to display. Now let’s turn NVDA back on and see if we can now tab through these links,
NVDA: boom navigation list with eight items, collar tags, trademark visited link
Rachele: And notice it said, “list with eight items” so we know that this is a list and it appears to be marked up correctly because it’s telling us the number of items.
NVDA: Plastic tags, visited link stainless tags, visited link, brass tags, visited link, military style tags, visited link rivet on stainless link tags for cats visited link collars with collar tags link.
Rachele: Good. So all of those are are announcing correctly. So let’s keep going down the list.
NVDA: Clickable stainless steel visited link, [00:05:00] clickable brass visited link, clickable collar tags, trademark visited link, clickable military visited link clickable plastic visited link, clickable collars, visited link clickable about link.
Rachele: Now this says clickable. It doesn’t actually do anything. We know there’s another menu, so we’ll have to try to trigger that as well, but let’s just finish the, yeah. Let, let me turn off the screen reader. And again, I’m going to use the inspector to find this list. I’m going to turn off the visibility, display hidden, and now we’ve got this menu displayed. Whoops. And I ended it. Don’t mouse over it. You will trigger the CSS. Turn this off again, and then I will start up NVDA.
Clickable about link. [00:06:00] Okay. Now we’ve got our menu expanded. So let’s go through those links.
NVDA: List with six items. What tag will best protect your pet? Why our tags are better link, about boomerang tags, pricing, link guarantee, link FAQs visited link shipping information, link, clickable contact visited link, clickable search visited link.
Rachele: Clickable search visited link.
So something I want to point out is we know that this pops up a little widget. So we know that this is missing that aria-expanded attribute that we talked about earlier that lets an assistive technology user know if the search is open or not. So we’ll have to mark that in 4.1.2, but I just wanted to point that out since we’re using the screen reader right now.
NVDA: Search landmark search edit has complete blank
List with one item zero visit list search landmark [00:07:00] search edit has autocomplete blank.
Rachele: Okay. So something I noticed is when I hit tab next
NVDA: List with one item, zero visited link
Rachele: It is not going to the button next to the search field with the magnifying glass. So that’s a keyboard issue. Now let me turn off the screen reader again so we can get rid of this menu and test that last link.
So I’m gonna, okay. So the last object that was getting some kind of link text was that shopping cart icon. So let’s test that real quick.
NVDA: Order banner landmark clickable navigation landmark list with one items, zero visited link
Rachele: Okay, so that says that it is a link, but it does not tell us that it’s our shopping cart. So let’s hear that again.
NVDA: Main [00:08:00] landmark, banner landmark, clickable navigation, landmark list with one items, zero visited link.
Rachele: Yeah. So it’s just announcing itself as zero. It’s telling us the number of items in the cart, but it’s not telling us that this is a shopping cart. So this is an example of a failure of link purpose.
So let’s look at this link a little closely. I’m going to inspect the shopping cart. We can see it is a link. And we can see it has an icon and we can see that the text here just says zero. There’s a hidden link text under here that says “shopping cart”, and it looks like they were trying to maybe add some text for a screen reader, but they’re using display:none and display:none will hide content from both the screen reader and visual user.
So we’ll have to flag that. So what we can do is we can say first we’re going to grab our code [00:09:00] snippet. So let’s see, we’re going to copy the outer HTML. We’re going to come over to our spreadsheet. We’re going to say we found a fail for Link Purpose in Context. We’ll say the shopping cart link in the navigation does not communicate its purpose. Screen reader announces the link as zero.
All right. So we’ve written up our issue. Then we can come over to go into the source code and we can pop in our little source code snippet. [00:10:00] We can say recommendation: Ensure link announces its purpose of shopping cart. Text is currently hidden from all users with display:none. All right. So I would normally write a bit more you know, to the issue and recommendation text here, but I want to keep this moving. So, I’m just giving kind of a brief overview of what the problem is, what they need to do to fix it.
And we provided our code snippet and I don’t have any notes for this one. We’ve got our first issue, so, yay. All right, next, we’re gonna look at Label in Name. So for user interface components with labels that include text or images of text, the name contains the text that is presented visually.
All right. That’s kind of a [00:11:00] mouthful. But what we’re concerned about is anything that is a control, not a link. So our controls are the search widget, the search field and the search button. So first we’ll look at the search button in the menu and we’ll see a couple of different things.
So the button itself has an aria-label of search. So it does have a name and it gets keyboard focus. So that’s good. All right. So let’s fire up the screen reader again, just to make sure that that control is announcing the accessible name that we see search. So I’m going to turn on NVDA.
NVDA: Clickable search visited link
Rachele: Clickable search visited link. So it’s announcing its name and that’s great. So let’s go ahead and activate the control and see what [00:12:00] the names are on the other controls.
NVDA: Search landmark search edit has autocomplete blank.
Rachele: Okay. So the search box has a name. Turn off NVDA. Now let’s look at this control, and this is kind of an interesting issue. So this button is not getting focus for some reason. Oh, I think it’s in the wrong. We can see it doesn’t match the source order. Ah, so let’s try this. Ah, so that’s, what’s going on. You can see when I open the search box, focus moves into the search field and when I press tab the focus actually moves to this control. That’s because this button is not in the right order. It’s not in the logical focus order. So that’s another issue that we’ll have to log. So we can see that the source order of the button and the input are reversed to what makes logical focus order. [00:13:00] So let’s go ahead and mark up that issue. So let’s see.
Let’s see. Focus order. So if we look at focus order here, it says if a webpage can be navigated sequentially and the navigation sequence affects meaning or operation, focusable components receive focus in an order that preserves meaning and operability. Okay. So we know that the focus order is out of sequence. So we’re gonna mark this as a fail. We’re going to say controls do not receive focus in a logical order that preserves logical meaning. The search button is located behind the search input in the tabbing order. Okay recommendation: Ensure [00:14:00] the DOM order elements matches the logical focus order. Move the search button after the search input in the DOM. I’ll just say to make sure the order of elements matches the logical focus order.
Okay. So that’s good. And we marked that as a fail. So we have, now we have two issues that we’ve documented. Let’s keep going. Something else that I noticed is this button does not appear to have an accessible name. So what we can do is now that we know where it is in the focus order, let’s fire up the screen reader again and make sure that we can verify it’s not announcing its [00:15:00] name.
NVDA: Boomer, boomerang tags, trademark pet button.
Rachele: Yep. So…
NVDA: Search edit has autocomplete blank button.
Rachele: So it’s just announcing “button”. So we’ll have to write that up as well. And since that is an issue where the screen reader is not announcing the name of the control, we know that that is a 4.1.2 issue. So we’re going to come down to 4.1.2. Like I said, this one is a catch-all and you probably will end up marking up multiple issues for 4.1.2, generally. We’ll see if we have that issue as well, but let’s write up the first one.
So we know that the search button next to the search input does not have an accessible name. Users [00:16:00] of assistive technology will have difficulty understanding its purpose. Ensure controls have an accessible name. In this instance since it’s a button with a graphic, there’s no visible label, I will suggest that they use the aria-label attribute to provide this control with an accessible name. So let’s type that up. Add the aria-label attribute to the control to provide an accessible name.
Okay. And then we also need to grab our code snippet of that button so they can see exactly what we’re talking about. The fact that this does not appear to have any accessible name in the code. So we’ll copy HTML. And now [00:17:00] that’s a very easy way for a developer to come in and say, oh yeah, it doesn’t appear to have any accessible name.
Cool. Now, if we do end up logging an additional 4.1.2 issue, if we find one, what I suggest is you can either mark these as like number, you know, first issue. First issue. And then, you know, if we come up with another one, by the way, the keyboard shortcut for making a new line in Excel is ALT ENTER or return.
So we would put the next one here, and it’s not the most easily readable thing, but this is to get you used to the process. You may find that later on, you want to actually insert a new row every time you have an issue. But for now I highly suggest you just keep all of your issues on one row item of the WCAG success criterion.
It just makes it easier to [00:18:00] ensure that you’ve adjusted everything and addressed all of the criterions. You can see a count that, you know, you’ve completed rows two through 51. It just gets a little bit messy and difficult to know if you’ve covered everything early on when you’re learning to testing if you’re putting additional rows. So that, you know, you certainly can, not saying you can’t, but you might find it easier to just write all of your assertions for that component on a single row.
Okay. So. Now that we’ve gotten out of order, let’s go back to our… okay. So for Label in Name. If we look at the site, the only control that has a visible label is the search input. And we determined that the name that is announced matches this visible label of search.
So we can go ahead and say this passes. [00:19:00] Remember all the other ones were links. So we determined if their visible label match their accessible name with link purpose. All right. So. Next is On Focus. So when any user interface component receives focus, it does not initiate a change of context. Yeah, nothing, nothing was really changing when we were tabbing through any of those links or controls. So we can say that’s a pass.
On Input. So the only input we have again, is that search form. So changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. All right. So what we would expect then using this component is if we change, if we type in something like “cat”, is that causing any change in the interface?
And it’s not other than the fact that apparently this search has an autocomplete, which I [00:20:00] believe I heard it announce it had autocomplete. So we’ll have to test whether this list now is also configured accessibly. So let me go ahead and first we’re going to say that On Input doesn’t cause any change in context, that’s absolutely true.
Next let’s go ahead and tab through. Remember our focus. There’s no focus indicator, so let’s force focus so we can see. So again, oh, we can see that so we can see the buttons, not in the right source order again. As we tab we can see it’s going to these links, so that’s fine. One thing that may not be apparent to the users of assistive technology is that these links are available, but it does says that it has autocomplete. All right, so let’s turn on the screen reader and find out how this autocomplete widget is announcing itself.[00:21:00]
NVDA: Boomerang tags, trademark pet ID, collar tags for cats and dogs and people document banner landmark navigation, landmark list search landmark search, edit cat ID tags for cats. April 18th, 2022 visited link plastic pet ID tags, March 29th, 2022. Pet identification 101 November 22nd, 2021 link. My qualification slash what make me a pet identification expert, October 30th, 2021 link boomerang pet tags site index, October 29th, 2021 link view all results link.
Rachele: Okay. So all of those links appeared to announce their link purpose correctly. So we don’t have to worry about marking up anything for that. [00:22:00] What I do want to do is look at the markup for this list and just see what we’re working with. So there’s a little header that says pages and then each of these links are just marked up in line. So I don’t, there’s nothing in particular that has to be announced for that.
However, there is another 4.1.2 issue that we have come across. Basically when this control, the search control is expanding and collapsing, it is not announcing that to users of assistive technology that this is a widget that’s opening and closing. And there’s a couple of reasons for that. One, they have marked up this control as a link, but it acts like a button.
Now, some people will say, this is not a failure because the control still functions. But what is a problem is that it’s missing that aria- expanded [00:23:00] attribute, which can only be applied to a button. So they really need to mark this up as a button and add the aria-expanded attribute so that users of assistive technology understand when the search is displaying or not. So let’s go back. First, I’m going to copy this code snippet, and we’re going to go back to our 4.1.2., which is near the bottom.
Okay. I’m going to go over to our code snippets here and I’ll go ahead and mark, this is code snippet one. We’ll paste in our next code snippet as code snippet two and something that you can do is you don’t necessarily have to have the entire inner HTML if what we’re really just concerned about is that outer control. So I’m going to remove this inner form thing that’s going on.[00:24:00]
And I will just put three dots to indicate that there is something else inside of that element, but we’re really just concerned about this control here. What I’m going to say is the expand, or display search acts, or I’ll say search control. The display search control acts like a button, but does not convey the proper semantics. Okay.
We’ll say our recommendation is use a button element or, add [00:25:00] role="button" to the <a>. Add functionality for SPACE key because controls are expected to work with both enter and space keys. And then we also want to add the aria-expanded attribute to "false" when collapsed and change to "true" when expanded. All right. So that takes care of that 4.1.2. problem. Okay. All right. Let’s see where we are in our list of criteria.
Okay. Labels or Instructions, 3.3.2. So this success criterion [00:26:00] is concerned with whether particularly with form inputs, they have a visible, persistent label and if there are instructions for how to complete a form field, for example, if date needs to be in a particular format that content is announced along with the control.
So looking at our site again, we only have the one input the search box here. And there, while this field is using placeholder text, which generally is not permissible, the button for the search field shows this magnifying glass and that’s enough of a convention now to indicate search that even though there isn’t a visible persistent label. And what I mean by that is when I type in “cat”, it no longer says it’s the search field, but this magnifying glass icon and the accessible name announced by the search field are enough to [00:27:00] satisfy this criterion. So we can go ahead and mark this as a pass.
And that gets us through dealing with active controls. The next set of content is of content tests is on the adaptability of the interface. That involves four success criteria. Orientation: Is the site locked to a particular orientation or can it be viewed in landscape or portrait? Reflow: Does the content resize down to a viewport of 320 pixels by 256 pixels without requiring two dimensional scrolling?
So it’s fine to scroll up and down, but there should not be any left to right scrolling. The next one is Text Spacing, and this is concerned with whether font text on the site can be modified by the user. So we have a bookmarklet that will [00:28:00] essentially attempt to change the text according to the specifications listed in the description here.
So we’ll test that out. And then the fourth one is Resize Text, which is important for folks who need to zoom in and see the display at a larger size. It really dovetails with orientation because typically if orientation works, resize text works. But it, it’s not always a hundred percent.
So we have to make sure that we can resize our browser window to 200% and still have the same functionality. We’re also looking for whether the content has been set to not allow zooming in on a mobile device. So you would see some kind of meta viewport element that has user-scalable="no".
So let’s, let’s look at all of these things. So first orientation, let’s go ahead. And in the browser dev tools, there’s an emulator [00:29:00] control that will allow you to resize the window to different viewpoints without actually resizing the whole window. So if I go ahead and click that emulator button we see this is set at 375 by 812.
So we want 320 by 256. Okay. And at 320 by 256, we see this big cookie thing is kind of taking over everything. But if I drag, let’s see three that’s 320, let me just make this taller. Actually I want to show you something. So 320 by 256, we see that this cookie banner is taking up like pretty much everything.
And there’s only a very little bit. Of area to like scroll and see the content that might seem like an accessibility issue, but it’s, it’s technically not, we, we can click okay. To get rid of the banner. You know, there is still viewport to see content we’re not getting the horizontal scrolling.
But it is annoying. So you could point that out to the [00:30:00] client as a best practice, but it’s not an accessibility failure. So I’m just going to increase the height here so that we can see more of the nav bar. Okay. So it looks like our navigation shrinks up fine using a responsive design.
Now we need to test each of the widgets. So what happens with search? Okay. So search is there. Our autocomplete displays correctly, it looks like. If we click on the menu button, what do we got? Hm. There’s a bunch of white space, but technically that’s not it does seem like maybe it’s hard to get to content. Let’s see what’s going on.
So it’s a little bit funky that X button is sticking in the middle of the window, but it does look like our content is available. So let’s go ahead and test it with the keyboard.[00:31:00] So we’re able to open and close this menu. We can tab through the other links.
So something I’m noticing here is… we would call this a dialog that’s displaying over the content is not actually hiding the search icon. So that’s kind of a problem because we can still click on that, even though we’re in this middle dialog. So that’s going to be another issue we need to write up.
We can look at this control here, this X control and see if it has an accessible name. Has the name of menu, but we need to figure out if that’s being announced. So let’s go ahead and fire up the screen reader.[00:32:00]
NVDA: List with nine items ordered list with two items, clickable navigation, landmark navigation, clickable. Clickable search visited link, clickable menu link
Rachele: Clickable menu link. So that’s going to be another 4.1.2. Error issue that I’m going to write up, because again, this is a control that expands to display a dialog, but nothing about the control indicates that it would open a dialog because it’s coded as a link.
So in this particular instance, I’m going to write that up as a 4.1.2. issue. Now let’s open the menu. K, focus moves to the close control…
Clickable menu link
But it it’s name remains clickable menu link. So again, this is a good example of why [00:33:00] using the aria-expanded attribute is important. I’m going to mark this up correctly and then we’ll listen to how that sounds. So let me close and let’s look at this control. This is our menu link, but since it’s marked up as a link and not a button it doesn’t announce itself correctly. So let’s edit this HTML instead of an <a>, we’ll make this a <button> and we’ll say aria-expanded="false".
And it looks like their JavaScript is keyed off of the <a> element. So okay, let me do this again. So again, we’re going to change the link to a button [00:34:00] aria-expanded. Yeah. Good equals false. All right. So this is the control’s collapsed state. So let’s turn on the screen reader again.
NVDA: Navigation tab control developer, clickable vet navigation, landmark clickable menu button collapsed
Rachele: Clickable menu button collapsed. So now we know it’s a button and it’s in the collapsed state. It’s not going to function because their code is keying off of the <a> element. But we know that this is now announcing itself correctly. So let’s go ahead and write up that issue.
Go down to our 4.1.2. And we can actually we can just key off of [00:35:00] this one that we already have in here. We can just add another condition. So we say the display search and menu controls act like button, but do not convey the proper semantics. Okay. And same thing we can say, use the button element or add role="button" to the <a>. That’s still true. Add functionality for the SPACE key and add the aria-expanded attribute. So let’s go ahead and just go ahead and put in another code snippet here.
Refresh the page so I get the actual <a> element. Okay. So we’re going to grab this HTML. Paste this, and I’m going to do the same thing where I’m going to delete all of the content that’s like inside the <a> element, because we’re only really concerned about that control.[00:36:00]
So we want them to be able to find it. So we’ve got, we can see it’s another, <a href> with an aria-label of menu. So they should be able to find that control pretty easily. All right. What else?
All right. So. This menu is expanding and collapsing. You can see they’re changing the icon on the button. So what this will do now is if it’s marked up correctly, this button, even though it says it’s an X, it’ll say menu collapsed. So yeah, anyway so we determined that we could… let’s turn on the force focus again.
We could tab through these controls, but it’s not really obvious what’s happening, but basically focus is not constrained to this widget. Even though this is the only thing we can see on the page, I’m able to tab all the way [00:37:00] through these links, which is hard to tell, because it’s hidden. I’m going to go ahead and let’s just delete this cookie banner from the DOM so we can see past it.
So there’s another thing I noticed. The escape key. I’m not able to use the escape key to close this menu. Now, the close button or collapse menu widget has disappeared somewhere. So now I have no way to to close this. So that’s a keyboard trap. All right, so let’s go ahead and write that up. It’s pretty low this page one more time and see you. Let me just show you the force focus thing again because this can be tricky. All right. So menu opens. We have focus. I’m gonna delete the cookie banner cause I want you to see where the focus goes. So we can see, as we scroll, go down the order we get focus on the controls, but then it appears that we are outside of the control.
So even though this is a dialog the [00:38:00] focus is not constrained to the dialog, which means keyboard users can get lost because now they’re tabbing onto focusing on the content that does not exist in the dialog. And I just noticed that when we move that focus out of the dialog, that’s when the control disappeared.
So. You can see, oh, there, the close menu button disappeared because we lost focus on the container. So again, that’s a good reason why having ESC to close the control can be useful. But also we need to note that the focus order is not constrained to the dialog. So we’ve got a few things going on here.
So let’s see, how do we want to write these up?
Okay. So let’s first add the issue with the dialog to 4.1.2. So we’ve got another 4.1.2. assertion. So this time our issue is that the dialog does [00:39:00] not follow the established design pattern. And what are the issues here? The dialog lacks the correct role. The dialog is not announced as a dialog. Dialog lacks an accessible name, when the dialog is focused. And those are really the only 4.1.2. issues. So let’s go ahead and oops. I wrote, I put them in the wrong column.
Sorry. Issues column. So here in our recommendations, we’ll say add the role=”dialog” attribute and provide an accessible name using aria-label. [00:40:00] Okay. So let’s go ahead and grab our code snippet. See if we can figure out what this container is.
Okay. So it’s this ordered list, unordered list.
I’m actually.
And again, we don’t need this whole, like everything in it. I’m just going to put the a unordered list that’s acting like a dialog. They may want to put a container around it or something with role="dialog". But for right now, that’s what they’re using. Okay. Now let’s do the focus order. So…[00:41:00]
Focus order. Sorry. Okay. So we already have a fail there. So we’re going to add, let’s go ahead and add the number one to this. Okay.
We’ll add a second issue for focus is not constrained to the menu dialog when it is visible. Users are able to tab to content behind the modal, including the search. The display search. Okay. And we’ll say, so our recommendation will be ensure [00:42:00] focus is constrained inside the dialog when it is visible. All other page on the content should be hidden with aria-hidden="true".
Okay. Now there’s a whole way to create you know, accessible dialogs. That’s outside the scope of what we’re doing here. You should probably provide a link to an example or something like that, but for now this is, this is fine. We’re going to go ahead and put our same code snippet in there.[00:43:00]
Okay.
So we have a 4.1.2. for the dialog not announcing itself as a dialog, and we have a focus order issue for content not being constrained to the dialog. Okay. But going back to our original criterion we were addressing, which was the orientation we can see that, that passes. Basically all the content is functional and accessible.
At that 320 by 256 viewport. So let’s go ahead and say orientation passes.
And reflow also passes. So we can use it in both orientations, the content reflows. Text spacing. So this is where we’re gonna use our first we’ll use another bookmark. So we’re going to look at whether text spacing changes. So what the text spacing bookmarklet does is it applies certain linespacing and text spacing CSS rules to the [00:44:00] text on the page.
Basically you’re allowed to provide your own user agent style sheets if you want to. And we’ll see if the text in the navigation actually responds to this text spacing bookmarklet. So let’s go ahead and take a look. Yeah. So it pops up and it’s available, although it looks like this about menu is kinda hanging off the page.
So we’ll actually have to write that up, but let’s look, make sure that the the search widget responded to text spacing. Yup. It’s not messing anything up. This tool to looks like it’s responding. Let’s look at the dropdown list. Okay. So that’s all good. And if I do the text spacing bookmarklet again, you’ll see it goes back. So that’s good.
Let’s just make sure that in this orientation the text spacing works as well. So I’ll open the menu and I’ll say [00:45:00] text spacing, and we can see yep. This all looks pretty good. Okay. So we’ll go ahead and pass text spacing.
And then the last one is Resize Text. That’s where we’re zooming in on the browser. So I’m going to go ahead and the hot key for this is CTRL +, and you’ll see, in the address bar, it’s indicating how much we’ve zoomed in on the site. So now we’re at 200%. And like I was saying before the browser resize zoom and reflow are often controlled by the same sort of CSS rules.
So you should expect that at this browser size, you would still be able to access the proper content. Even though it’s in a different view size. So we can see that yet we can still access this menu. Something I just noticed though, is we’re going to have a contrast issue, this control to close [00:46:00] the menu. It’s not really visible against this black background at this viewport.
Oh, and one other thing I forgot to mention is when we’re doing text spacing, we have to do it at a specific browser size at 1024 by 768. That’s just the standard for testing browser zoom. So we’ll just, so it looks like it 1024 by 768 that control is on this white background, so it looks okay. But that is something I’m still going to mark that it becomes invisible if the browser is a little bit wider and zoomed in. So let’s go ahead and let’s just mark that up for now. Before we forget, so…
Got that aria-menu="false". I’m going to copy the HTML and we’re going to say, we’re going to go to Non-text [00:47:00] Contrast. Okay. So Non-text Contrast is concerned with things like graphics and graphical, you know, parts of charts or graphs. Making sure that adjacent colors have at least the 3:1 contrast contrast ratio.
But we can tell that that button doesn’t have a 3:1 contrast ratio. It’s just too dark. So we’re going to mark this as a fail and we’re going to say the menu button does not have a 3:1 contrast ratio with the page background when zoomed in. Then we’ll just say when [00:48:00] zoomed in. Okay. So, and we’ll say for our recommendation ensure graphical objects used in controls have at least a 3:1 contrast ratio. Something else I usually do when we’ve got something indicating a color contrast issue is, we like to tell them what that contrast is.
So we’ll say the foreground color, the background color, and then what that contrast ratio is. So the way that we do that is we can check out that Colour Contrast Analyser tool. So that’s here. We’ll go back to our webpage and we can see our control here. So what the color contrast analyzer tool lets us do is use a little dropper tool to actually zoom in [00:49:00] there and we’ll suck up this gray color that’s in the control. And then we’ll suck up the background color. So you see that the control has a hex value of 333. The background is 000 w G, which gives us a contrast ratio of just 1.7:1.
So then that tells us that this fails all of the, it fails the contrast minimum success criteria for text. And it also fails non-text contrast. So let’s go ahead and write that up. So our foreground was 333. Our background was 000, and our contrast ratio is 1.7:1. Okay. And all we have to do is tell them to use the 3:1 contrast ratio.
Cool. Okay. So let’s close that. We’ll bring our zoom back to regular and refresh the page. [00:50:00] Hmm. Oops. Home page. Okay. So let’s go back to our spreadsheet and see where we were in the list. So we were at Resize Text, which passes. We were able to resize the text. Let’s just look real quick for that meta viewport. So we’ve got our meta viewport rule right here: initial scale one, width equals device dash width. That’s great. So there’s nothing here saying user scalable. No. So that passes. K, what’s next in the list?
Okay. And as it so happens, we’re up to Non-text Contrast and Contrast (Minimum). So these have to do with either graphical objects, focus indicators, that kind of [00:51:00] thing for non-text contrast. And then plain text for contrast minimum. All right. So let’s see if there’s anything else graphical wise that seems like it might not pass color contrast.
You know, you can always test anything. So let’s go ahead and test. Let’s go ahead and test this button. Let’s say it’s got kind of a blue color on a white background. And the contrast ratio is. 3.8 to one. So that’s fine. And then let’s go ahead and invert these. So we say the white on the blue, this white icon on the blue background, that also passes.
Something you might notice here is that the search input itself is a really light gray color on the background here. And if this placeholder search label, were not here to denote that there’s actually an input field, we could fail this background, color, this [00:52:00] control, not having a 3:1 contrast ratio with the white background, the light gray, it’s really hard to distinguish. However, since there is a label, that negates the background having to define the component.
And now we’re only concerned about the contrast minimum of the search placeholder with the background. So we’ll get to that next. But you know, the search icon here is white on black, so that’s plenty of contrast. Same with the shopping cart icon. It’s plenty of contrast. If we look in any of these drop downs, there isn’t any images, but there were some images in the mobile version of the drop-down. So one we’ve got we’ve got the menu icon itself. So let’s go ahead and test that for color contrast.
Suck up this gray color and the background color. [00:53:00] And even though it looks kind of dimmed, it has a contrast ratio of 9:1. So, so that’s fine. Let’s open up the menu. And we notice that is that there’s like a little arrow here indicating that there’s a sub menu. So let’s go ahead and test that icon.
And sometimes if it’s really tiny little guy like that, it’s not really possible to, to use this contrast checker necessarily. So what I’m going to do is inspect the element and I’m going to see if in the CSS it has a defined color.
Yeah. Maybe not. Okay.
Yeah. So it’s set at 333. So we’ll go ahead and grab that 333, and we’ll open Colour Contrast Analyser. We’ll put [00:54:00] 333, and then for the background color, we’ll pick the white. So again, even though it’s small and it looks kind of dimmed, it actually passes with a 12.6:1 contrast ratio.
So that’s something you’ll notice that when, when fonts are smaller, when images are smaller it affects the color contrast. But even if it seems like it might fail, it doesn’t always. So that’s why it’s important to check those things. If we pop open this navigation here we can see there’s also little icons next to each of these list items, but they’re also indented and they don’t, you know, I wouldn’t really necessarily check those because they’re not conveying any particular information. All right. So I think we’re good on our non-text contrast.
So next we should worry about text contrast. So we had our one non-text contrast failure. Contrast (Minimum). And so generally what we’re looking for for [00:55:00] what we call regular scale texts, we’re looking for a 4.5:1 contrast ratio, so that smaller text. Larger text, it only needs to be 3:1. Of course you can always make it more visible. So let’s go ahead and check the contrast ratio of some of this stuff in our header.
So first we’ve got just the plain link color, which appears to be white on black. So we know that that has enough contrast, but what about when we hover? So these links up here when we hover they get an underline. They don’t change color. What about these guys? Oh, now these other ones in the main content here, turn a light gray when we hover over them. So we’re going to have to check if that light gray works against the black.
So the easiest way to do that is to inspect one of those links. So inspecting the “order tag” link. Then in the inspector, you can right-click and you can force it to actually display what it would look [00:56:00] like on hover. So we can change pseudo class to hover, and we can see that the link color changed.
Now, if we come over here and show the CSS inspector, we can see that the color setting here is 8A8A8A. And if we put that into our Colour Contrast Analyser and suck up the black background, we can see, even though it looks like it’s kind of dim, again, it still passes with a 6.1:1 contrast ratio against the background color. So that passes just fine.
Next let’s look at the contrast that we get when we hover over some of these items in the dropdown menu. So now we’ve again, we’ve got the background color gets a little darker and the text color gets a little lighter to show that it’s the currently selected one.
So there’s a couple of [00:57:00] issues here. One let’s go ahead and inspect our menu, force it to open again. We’ll inspect this first. Oops. That wasn’t good. Let’s try this a different way. We’ll display the menu. We’ll highlight this first option and then the menu, “What tag will best protect your pet?” And we’ll go to the right click change, pseudo class to hover.
And now we can see that it’s got some different colored text. Again, it appears to be that 8A8A8A color, which we’ve already got in here, except now it’s on some kind of like light gray background. So let’s see if we can figure out what the background color is. Ah, here we go: F8F8F8.
So put that into our Colour Contrast Analyser and we can see that that text now [00:58:00] fails regular contrast minimum. It’s only a 3.3:1 and for regular scale text, it needs to be 4.5:1. So what we’ll do is we’ll write this up similarly to what we did with the contrast minimum for the control.
And we’ll let the site owner know that this text does not meet contrast. Okay. So we’ll say regular text does not have a 4.5:1 contrast ratio. Users with low vision may have difficulty seeing text and w like we did with the other one, I’m going to say what the foreground color was, the background color, and the contrast ratio.[00:59:00]
That foreground is the gray color. Background is white color. And the contrast ratio is 3.3:1. The recommendation is ensure regular scale text has at least a 4.5:1 contrast ratio.
Right. And then… oh, something else we need to say is, which text this is. So we can say here, oops.
We can say hover text in the navigation links and the… okay.[01:00:00]
All right. So let’s, oops, let me get to the right spot again. We can mark that as a fail and then we can give a link snippet. We’ll just use this one as an example, even though there are several of these links that have the issue, we don’t need to call out every single one. That’s okay for this exercise. But we should give them at least an example. So let’s come over to our source code, go ahead and pop that in. They can see that it’s a link, so they understand it can have hover text. And then here’s the text. Here’s perhaps the class that’s modifying the text on hover and that gives an idea of what to fix.
Okay. Let’s see if there are any more color contrast issues. So when we opened up the [01:01:00] search, we have the search placeholder text and placeholder text is notorious for not having enough color contrast. So we’ll see if any. So we see the background color is defined again as F8F8F8 but the text color is AAA.
So let’s go ahead and plug that into Colour Contrast Analyser. Yep. We’ve got just a 2.2:1 color contrast ratio on that placeholder text. So let’s go ahead and write that one up too. So here we can just say copy paste this and we can say search placeholder text. See, so our foreground, is this. Our contrast ratio is 2.2:1.[01:02:00]
Perfect. And it’s the same advice. We don’t have to put additional advice. But what we should do is provide another code snippet. So see this element. Now here you might want to say like, this is the first example. This is the second example. So the hover text on the navigation links is the first example. The search place holder text, the second example. So we may want to then denote that in our source code. So the link is the first example. The input is the second example.
But the recommendation is still the same of regular scale texts needs to have a 4.5:1 contrast. Okay. [01:03:00] Let’s see if there’s anything else.
Okay. So we’ve got a little tool tip widget here, and it looks like this text is probably the same as that search text. So let’s go ahead and inspect that tooltip. L et’s see if I can get it to display all the time. Having difficulty getting the tooltip to display.
Let me refresh the page and start over. [01:04:00] So we can inspect the widget. We’re having trouble getting it to display, but that’s okay. We can still look over here and see if we can find the background, color and text color. The background color is white, it looks like, and the text color is, but… got a border color. Ah, text color also AAA, but on white. So we’ve got the AAA, but it’s a white color instead. That gives a little better color contrast ratio, but it’s still not perfect. So let’s put that here. [01:05:00] Copy and paste this. So this is the cart.
Tooltip. It’s 2.3:1. Okay. And we can go ahead and grab just the text node.
Change this to three.
Okay, great. And I believe that is all of the text that we had to deal with. Oh, [01:06:00] let’s just double check this. We had this drop down text too. I think that… Go to our Colour Contrast Analyser. Let’s go ahead and suck up this blue color. And the blue on white though has poor contrast ratio.
So, and that’s interesting to note, so this image is fine because it’s 3:1 contrast ratio, but this text is not going to be good. And actually. We’ll have two issues. So one is the default color. We’ve got both this date text and this blue text, both in that standard link format and then also in hover.
So let’s do a couple of things. One, let us look at this text and see if it’s the same color as our tooltip. And it is, so we’re going to say copy this HTML, and we’re going to say not just the [01:07:00] cart tooltip text, but also search autocomplete date. Oh, go ahead and just add this to our third example.
And now… we’re going to have a fourth example. We’ll have search autocomplete link text[01:08:00] and also text on hover. All right. So let’s look at, let’s grab our link, text color on the white background, and that gave us a contrast ratio of what? 3.8:1. And then on hover. We inspect this. [01:09:00] Okay. And we’ve got the blue text, but we need to suck up the gray background. And that is a 3.5:1.
Make sure our foreground color. So we got the blue on the gray and the blue on the white. Both have color contrast issues. Okay. And then, so we can see, you can save for it. Sorry.
So for examples four and five, you’ve got this link. [01:10:00] And for this example, I’m just going to take out this little font icon. I’m going to put three dots and that way we’re just looking at this text because that’s what we’re really concerned about. I’ll also take out the date, cause we’re talking about that in a different one.
All right. And that I believe is all of the color contrast issue.
Okay. Let’s sort our spreadsheet by status again and see where we’re at. I’m going to just look at pass, fails and blanks. Actually just let’s just look at the blank so we can see how many are left. So we’re [01:11:00] down to 15 of 50 success criteria. I think this is a good place to stop for our initial testing video.
I will create a follow-up where I complete the testing of this component so that we can cover all of the success criteria. If you have any questions or comments in between now and the next video, you can reach me again at Rachele DiTullio, R A C H E L E D I T U L L I O on the internet. So that’s @racheleditullio on Twitter. That is racheleditullio@gmail.com for my email. And then my website is https://racheleditullio.com. So I hope you will return to join us for the conclusion of this test and have a good day.