Welcome to the third video in this Accessibility Testing series. Please reference the blog article Performing an accessibility test.
Video 3/3 will be about testing the mobile version of the header.
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 the video performing an accessibility test. You can find all of the project resources on my website at racheleditullio.com/projects/accessibility-testing. So let’s get started.
Last time when we started this accessibility test, we were using a website called boomerangtags.com, which I have here.
We have the homepage here on the screen, and we were specifically testing the component of the header with the main navigation for the website. And if we switch over to our testing spreadsheet, we can see that we left off looking at text contrast or contrast minimum, and we had found five different examples of text in the header that did not meet our color contrast ratios.
And [00:01:00] what I wanna do now is take this opportunity to now look at our automated accessibility testing results using axe Devtools and see how that compares with the manual testing results that we found. So let’s go ahead and first, I want to show you how devtools works here.
So let’s go ahead and open devtools again, that’s F12 and what you should find in your tabs here is one for axe Devtools. And you’ll see a little pane that says let’s get started, scan all of my page. So let’s go ahead and do that.
All right. So we have 58 results and if we scroll down on the left pane here, we can see the categories of results. And here we have elements must have sufficient color contrast. But there are 10 results there for color contrast, and it can be difficult [00:02:00] to know which of these results pertains to the part of the page that I’m actually testing right now.
So rather than run a scan on the full page, I’m gonna show you a little trick. So let’s go over to the inspector. And if we scroll down the code a little bit here…
we will find the header that we’re trying to test. And then there’s a div with an ID of main. So a quick trick that you can do is actually use the CSS property display:none. And we can actually hide all of the content on the page that we don’t wanna test. And we don’t wanna have axe Devtools look at right now because we’re really only concerned with the main navigation.
So now let’s go back to axe Devtools. Let’s rerun our scan and see how many results we get. All right, this time we only got three results. So[00:03:00] that shows us a couple of things. One, if you notice, there are no color contrast issues that came back through our automated scan. And again, this is why manual accessibility testing is so important.
The reason that none of the instances of color contrast failure that we found didn’t come back in this result is because in this state right now that the page is in, all of the color contrast is fine. We’re just seeing the white text on a black background, but if we go ahead and do another little trick with the DOM here, we can run the automated scan again and see if it picks up the color contrast issue that we introduce. I’m gonna go back to the inspector so that we can see these dropdown menus right now. We removed the rest of the page so the menus aren’t working properly.
I’m gonna go ahead and again, using just some CSS on the header element, I’m gonna increase the height to 500 [00:04:00] pixels to see if that lets our menu show up and it does. So now let’s go ahead and inspect. Oh, the menu might not work as well now. Let’s inspect the menu. So here’s our menu. Right now it’s not displaying anything because it is hidden with CSS.
So we can go ahead and display the dropdown menu there for the “About” parent element. And then let’s look at the very first link in that dropdown. So another trick you can do with the Firefox devtools, you can right click and there’s an option in the menu called change pseudo class. And what we can do here is we can emulate the hover state if we select “hover” out of that list.
And now we see that our menu item has that kind of gray text on a gray background that we had failed with our manual testing of this element. So now if we go back to axe Devtools and we run our scan again, we should see [00:05:00] that color contrast issue show up. So let’s rerun the scan.
Yeah. And now we have four automated issues that it’s found. And one of those is elements must have sufficient color contrast. And if we look at the example source element, we can see “what tag will be best to protect your pet” and that’s the list item that we had changed, the link that we had changed, to have the hover state.
So you can see that when the page is in a state where there’s a color contrast issue, the automated scan will flag it. But when we’re talking about hover states and focus states and states for things like our search widget that pops out, that is not visible when the page loads, those kind of things, won’t get flagged by the automated tool.
So again, we have to do that manual accessibility testing. It’s super important and it’s where you’re gonna catch most of your issues. Now let’s look at the other ones that the scan [00:06:00] returned for our header element and see if there’s anything that we need to be concerned about.
Now, since we hid everything else on the page, it’s flagging three issues at us that aren’t really issues because these things probably exist on the rest of the page, and they don’t really pertain to just our heading element. So the first one is that the document should have a main landmark. And that’s absolutely true, but it really is not. The main landmark would not be part of the header. The header landmark is part of the header.
So this doesn’t actually affect this part of the page. It affects the overall page, but it does not affect this component that we’re testing. Same with the second one. So ensure landmarks are unique. So our header landmark also contains a nav landmark for our navigation menu. Now if there are multiple navigation landmarks on a page, we wanna make sure that those have a unique, accessible name using aria-label, but we really only have this one [00:07:00] nav item on the page.
We’re not too concerned with whether or not it has an accessible name. It’s okay because it’s the only nav item, but if there are multiples, you wanna make sure that they can be differentiated by assistive technology users using aria-label.
And then the fourth issue that was flagged is the page should contain level one heading and again because this is not the part of the page that would usually contain an <h1> element, we are not too concerned that that’s coming up in our automated scan, but it’s good. We don’t have anything else that we have to worry about. We’ve seen all of the automated issues that have come up and we can continue with our manual test and make sure that we cover everything else.
All right. So let’s continue with our manual testing. I’m gonna go ahead and close the devtools. I’m gonna refresh the page and let’s look at our spreadsheet. Okay. So we ended with color contrast minimum. Let’s see what’s next in the list.
Next we have [00:08:00] timing adjustable. So this is actually gonna be another, not applicable. Let’s go ahead and set this to not applicable. For timing adjustable, we’re concerned with two things primarily. One, session timeout. So if you do set a session time out that’s less than 20 hours, you need to provide your users a way to extend that session if they need to continue working.
The second use case is if you implement some kind of timer for completing a task on a website; for example, you may have seen a timer for purchasing tickets online. You may only have 10 minutes to complete the task. But for users that would need more than 10 minutes, you have to provide a way that they can extend the amount of time that they have to complete.
But we don’t have any timer, we’re not concerned about session time out. There is no session right now. So we can go ahead and just set this one, timing adjustable, to not applicable. And that is the [00:09:00] first first success criterion in the type of “Dynamic Changes”. So let’s continue on.
Next we have pause, stop, hide, which we’ve already set to not applicable because there is no animation in the header and there is no auto-playing video or anything like that.
Next, we have our type of success criterion of “Errors”. And we’ve already marked several of these as not applicable. The only form field that we have in the header is for the search box and there is no error message that needs to be returned there. There’s no way to fail filling out that form. And the form does not complete any type of legal or financial commitment so we can set all of those to not applicable.
All right, next, we are into the success criterion type of “Interactivity”. The first one is content on hover or focus. And we do have something that we can test [00:10:00] for this. So let’s go back to our website. I’m going to turn on our bookmarklet for forcing focus, because that is not working on this website. And I’m gonna go ahead and tab through our options here. So shop, cart, order tags. Now we know if we mouse over that, that there is a dropdown menu. But that menu is not appearing nor is there a way to trigger that menu.
So if I hit ENTER right now with the “Order Tags” element selected, it’s just gonna take me to the page for order tags. There’s no control to actually drop down that menu. So we actually have two issues here. Let me go ahead and turn on force focus again. So we have two issues here.
One, the menu does not display on focus and two, there’s no way for a keyboard user to trigger that menu. Let’s go ahead and test the other dropdown menu, which is “About”, and we have the same experience. Nothing [00:11:00] displays on focus. So it’s gonna fail this success criterion and if we go ahead and hit ENTER, we’ll see that we’re not able to trigger that menu with the ENTER key.
You know, what’s interesting is. This dropdown here, it’s not an active link the way that “Order Tags” was in an active link. So they could pretty easily make this control work with ENTER. They could make that a button so that a keyboard user could facilitate dropping down that menu with a keystroke, or they could just make the menu appear on focus.
All right. So let’s go ahead and write up those findings. So we’re gonna have a fail for content on hover or focus. And the first thing that fails is the order. Let’s see, sub menus do not appear on focus of the “About” or “Order [00:12:00] Tags” parent element.
All right. And then for a recommendation, we can say ensure sub menus appear on focus of the parent element. And let’s go ahead and grab a code sample so they know what we’re talking about. So let’s go ahead and look, let’s use the inspector on the, “About” link and we’ll go ahead and just copy paste that into our spreadsheet.
Okay. And now they know which one it’s referring to. Okay. Now, related to content on hover and focus, we noticed we’re gonna [00:13:00] fail the next success criterion for keyboard operation. So this will be a fail because again, there’s no mechanism that works with the keyboard for users to be able to view those sub menus for the “About” or the “Order Tags” elements.
So let’s go ahead and say, we’ll just, we’ll just repeat the same. We’ll say, sub menus do not have a trigger that allows keyboard users to display the sub menu.
Oh, let’s actually change this to, parent links do not have a trigger that allows keyboard users to display the sub menu. Okay. And then over here, we can just say, ensure sub menus can be reached by keyboard [00:14:00] users by implementing… display on focus or with the activation of a control, like a button. Okay. And then let’s go ahead and just we’ll copy the “Order Tags” link for our code example this time. Okay. All right.
Let’s go ahead and make sure there’s nothing else that’s not working with the keyboard because we also have our search widget. So let’s make sure that when we hit the ENTER key here, that the search widget opens and it does. That’s great. We know that we can search for cats. And if we select the button, we actually go to the search page. So that’s [00:15:00] working as well with the keyboard.
All right. So I think that we’ve got these working fine. Only problem is that these sub menus are not displaying on hover or with keyboard. Okay. So let’s go back to our spreadsheet and look at the next success criterion. So the next one is no keyboard trap.
Now we have just demonstrated that we can use the keyboard except for those sub menus and we demonstrated that we are able to go and use the search widget. But let’s see if we can exit the search widget while we’re using the keyboard. So let’s go ahead and turn on force focus. We’re gonna go to this search and let’s see if we can escape out of the search. So the ESC key doesn’t work, which is a problem, [00:16:00] and we can see that that content remains visible.
There’s no way to actually close it. That’s not so much a keyboard trap as it is a hover issue. So let’s actually go ahead. And so there’s no keyboard trap. We’re able to actually move focus outside of the search, both forwards and backwards, but the search box remains. I mean, we could say that in this case it’s not such a big deal because it’s not currently obfuscating any content underneath, but let’s say we performed a search that had autocomplete. Well, now when I TAB out of there, that content is continuing to display. If I hit ESC, it closes, oh, that’s good. If I hit ESC, it closes the autocomplete menu. So we could say that, you know, it’s not actually a fail that the search box remains visible.
It’s not ideal. I would suggest implementing that [00:17:00] the keystroke of ESC to close that search box and return focus to the search disclosure button. But in this case, since ESC seems to work to close our autocomplete menu, which is the only thing that was… that’s interesting. And the autocomplete menu doesn’t seem to work if you have already used it.
So, oh, nope. There it goes. Okay. But again, so I’m gonna hit ESC now and we’ll see that that clears out the search. It may not be the best thing that it clears the search, but it does close the autocomplete menu. So that’s sufficient. We’re not gonna fail that right now. And I would say that there’s no keyboard trap because we can get out of the search widget. It’s just a little annoying that it remains visible, but we’re gonna go ahead and say that this passes. There’s no keyboard trap.
All right. Next, we have character key shortcuts. This is one where we’re gonna use one of our accessibility bookmarklets, and it’s simply going to emulate pressing every single [00:18:00] character input on the keyboard. And we’ll see in the console here, and I’m gonna clear the console. And then when I run this accessibility bookmarklet, we’ll see whether any of the single print characters cause any functionality to occur in the webpage.
So we’re gonna go down here to trigger character key shortcuts. We can see all of those character keys being pressed in the console, and we didn’t get any warnings or errors that something happened. We didn’t see anything happen on the page behind it. So we can go ahead and we can say that this passes as well. There are no character key shortcuts that cannot be remapped or anything like that.
All right, so next we have pointer gestures. This is gonna be a not applicable because there is no functionality that uses multipoint or path based gestures. For example, you might encounter this in an application that’s asking for your signature. You could use your finger on a touch [00:19:00] screen or use the mouse to draw your name, but there’s nothing like that in our header. So we’re gonna go ahead and say that this is not applicable.
All right. Next, we have pointer cancellation. So this has to do with how the mouse works and when functionality actually takes place. So the idea is that functionality should only happen on the up event of the mouse pointer, not on the down event. Let’s go ahead and test something for that. We’ve got all these links here. We know if we do a single down event on a link, it go ahead and takes you to a new page. So that’s working properly. Let’s look at something that we know is custom functionality.
When does the search actually show up when I click on the search icon. So I’m gonna go ahead and click down and we see that that search box is not displaying on the [00:20:00] down event. What that means is I can go ahead and move my mouse cursor to prevent anything from happening. I can undo the action, but if I click down and then let go on that up event, that’s when the search box appears.
So that’s exactly what we wanna have happen. We can also test this search button. So let’s say we search for cats again. We’re gonna get our auto search, but if we want to actually go to the search page, we can click the down event on the button and now I’m gonna lift it up. And that’s when it’s actually gonna go to the search page.
So that appears to be working correctly as well. You know, you can go through and click every link. That’s not wrong, but generally, if things are marked up as links, we know that they’re gonna work correctly. Again, I’m pressing down on the mouse key over “FAQs” here. When I release, that’s when it’s going to take me to the new page.
We’re more concerned with testing custom functionality like the [00:21:00] disclosure widget for the search and making sure that things don’t happen on the down event. But typically links and buttons are gonna be fine if they’re implemented natively. All right. So let’s go ahead and mark pointer cancellation as a pass.
All right. Okay. Next we have non-text content and this pertains pretty much to images and icons in the interface and whether or not, if they’re decorative, are they hidden from screen readers? If they’re not decorative, do they have appropriate labels?
So let’s go ahead and look at our page and see what kind of icons we’re dealing with. All right. So there are some icons next to the shop and cart links in the utility navigation. And we’ve got a magnifying glass icon for our search disclosure button. And we also have a magnifying icon on the search form button.
So let’s go ahead and take a look at these and [00:22:00] see how they’re marked up. So for these shop and cart links, the little icons off to the left, I would call those decorative. They’re not giving any meaning to those links. They’re just kind of little quick eye candy, something to help you recognize the link a little bit better, but those icons are not necessary for understanding the role of the link itself.
So let’s go ahead and see how they’ve implemented these. So here’s the shop link and the inspector. And if we expand this, we can see they’re using a Font Awesome way of displaying a CSS icon. But it’s not hidden from screen readers. So let’s go ahead and copy this HTML. And we’re gonna go over to our non-text and we’re gonna say we have a fail and the issue is decorative [00:23:00] icons are not hidden from assistive technology. And we have the example of the bone next to shop. Let’s go ahead and add our source code example. Oops. Looks like I didn’t copy it properly.
Right. There we go. So the way that we would fix this is we say add the aria-hidden="true" attribute to decorative icons. All right. Now let’s see if the other icon next to the shop icon is the same. So let’s inspect this card [00:24:00] and again yep. We’ve got another Font Awesome icon being loaded there. So let’s go ahead and just add that to our source code example. Well, here, let’s see in the description, we’ll go ahead and add the card icon next to the cart link. And we’ll just go ahead and include… the other Font awesome icon as an example.
All right now, let’s go and check our other icons and see if we have any issues. This search disclosure, magnifying glass. What we would expect to find is that this icon would have an aria-label attribute that gives a name to this icon because there is no text label. So there’s nothing, [00:25:00] there’s no text to provide an accessible name for this control. So we have to add that using ARIA.
And if we look at the control, there’s a link for this control and it does have aria-label of search. So that’s perfect. We’ll go ahead and we’ll test that with the screen reader here in a second, but let’s go ahead and look at our second icon here. The search button that’s using the magnifying glass and we’ll see this one, however, does not have an accessible name. They’ve used the value attribute on this input type="submit" to display the magnifying glass icon, but there’s no text to provide an accessible name. So let’s go ahead and test how this sounds with the screen reader. So we can demonstrate what we’re talking about. I’m gonna start NVDA.
I’m gonna turn on force focus.
NVDA: Cart… [00:26:00] clickable search visited link.
Rachele: So clickable, search, visited, link. So we know that it has a name. Now I’m going to use the keyboard to expand this.
NVDA: Search landmark. Search, edit, has autocomplete, blank.
Rachele: Okay. So we know the input search has an accessible name of search. If I go to the button though, will that have a name?
NVDA: Button
Rachele: Nope, it’s just saying button. So just like we saw here, this value is just an icon. There’s no accessible name here, so let’s go ahead and see if we added an aria-label, does that fix the issue? So aria-label="search" and now it should tell us it’s called search button. So let’s turn on NVDA again.
NVDA: Search, button.
Rachele: Perfect. So that’s the advice that we’ll give. Okay. So [00:27:00] we have a second issue then, which is, active icon for search button does not have an accessible name.
So we’ll say add the aria-label attribute to the search button to provide an accessible name. And let’s go ahead and grab our source code example. So I’m gonna go ahead and edit this again. So my fix is not actually in there. Let’s just get the original source code here. So we’ll copy outer HTML. Come over here. We’ll say for the second example, we have this. All right. [00:28:00]
Okay. Let’s continue. Now we have, so that was under success criterion type “Multimedia” and if we look, we had already preset the rest of these multimedia ones to either not applicable because they have to do with audio and video, which our header does not have. Or the last one was images of text and we passed that because there were no images of texts.
All right, next we get into type “Order and Focus”. And the first one there is meaningful sequence. And I’ll just go ahead and read the description for that: when the sequence in which content is presented affects its meaning a correct reading sequence can be programmatically determined.
So let’s look at our page for reading order. And what we’re looking for is does it make sense going left to right for English top to bottom. So if I’m going along here, I see the shop and cart [00:29:00] links. That makes sense. And then these navigation links take me, you know, in a sequential order. When the display Is becomes more narrow. If we do this, they start to wrap, which makes sense as well. I think that’s fine. So I would say, you know, reading order makes sense. This passes there’s no concern here. So let’s say pass.
All right. Next we had already logged a couple of issues with focus order. And we also noted that the visible focus is missing from all of the links. So we’ve already got those taken care of. We can keep moving.
Then we get to the “Page Level” ones that we had already previously said we’re not applicable because we’re not concerned with the page level for just the heading component.
All right. So next we get into a really important one under the “Semantics” type and it’s called info and relationships. And it’s basically concerned [00:30:00] with the semantics of the elements. Are lists announced as lists are headings announced as headings and so forth. Buttons are buttons, links are links and whatnot. So we’ve already done a lot of testing with this using a screen reader and everything appeared to announce properly to me. I wanna test one last thing though and see what it does with the unordered list that contains some of these elements. So let’s go ahead and start up NVDA.
NVDA: Boomerang tags, banner landmark, clickable. Navigation, landmark list with 10 items, clickable order tags visited link.
Rachele: Yep. So navigation landmark with 10 items. So that’s what I wanted to check was if it was announcing the number of items. So in addition to announcing the semantic nature of the element, for example, this is a navigation, it’s also telling us the number of items. Sometimes it’ll tell us [00:31:00] state things like that. So let me go ahead and see if I can trigger one of these dropdown menus and we’ll see what that sounds like.
NVDA: Clickable about, link. List with seven items. What tag will best protect your pet?
Rachele: Yep. So this dropdown menu is also an unordered list, as we saw previously when we were inspecting the code, and it tells us that it’s a list with seven items. So that sounds correct to me. One thing that might come up if this were all working properly for a keyboard user, and remember right now a keyboard user cannot get to this dropdown menu, under 4.1.2 (Name, Role Value) we would want to let a user know that the “About” control has a menu. It doesn’t tell us that right now. And then we would want the menu itself to possibly identify it as a menu. It identifies itself as a list. And so that’s fine. It’s, it’s not necessarily important that it says it’s a menu. As long as [00:32:00] the user understands that something is happening with that control and displaying new content.
So that’s something you would wanna test with your users and see if it makes sense to them. All right. So for info and relationships, I think everything passes. We don’t have any headings. Our links and buttons and lists all sounded correctly. So I think that’s fine.
Next we have headings and labels. And what this is telling us is that if something has a visible, there’s a visible, heading, visible label that it properly describes the purpose of the topic. There are no headings in our examples, so we don’t have to worry about that, but we do have one label, which is for the search.
I would say search is an appropriate label for both this control here and for the actual search input. So our labels are perfect. So we can go ahead and say that passes. All right. We already [00:33:00] looked at language of parts. There’s no content in another language on this page.
Next is consistent identification. So this is where components that have the same functionality within a set of webpages are consistently defined. So we’re just gonna do a quick test. Let’s go to the “Order Tags” page. And let’s see what the header looks like on that page. Oh, so it’s similar, but it’s not exactly the same.
So we’ve got this Trust Pilot thing going on. If we go back a page we can, so we’ve got two things going on. One we’ve got like a home link with the boomerang tags logo in the upper left. And we’ve got this “Trust Pilot” thing showing up. Let’s see if we can find any other permutations of this top navigation. So let’s go to let’s go to “Collars”. Let’s see what that [00:34:00] looks like.
All right. So it appears to be the same kind of navigation that’s on this page, just with a different color scheme. And so this would be something, if you were going to assess the rest of this site, you might have to assess the header a second time, or you might need to take into account this light mode version of the header and amend your findings that we’ve done for this first component.
Depending on what we found on the rest of the site and how much the client wanted us to look at it, you know, we’re gonna have different color contrasts here. So this yellow now on the “Shop” may not have the correct color contrasts, things like that. And so we would wanna check. But for right now, I’m gonna fail consistent identification and say that this Trust Pilot thing shows up in the header. And even though it’s not, well, it’s kind of, it’s kind of iffy. So right now we could kind of say that consistent [00:35:00] identification didn’t really apply to our page if we were only checking this page. But if we were checking multiple pages on the site, we would definitely say that the header is not consistently identified. There are some differences there we can see.
So I’m just gonna mark that up. We’ll say there’s a fail and we’ll say subsequent pages display a “Trust Pilot” link in the header. Ensure “Trust Pilot” is displayed consistently. And. Not quite sure what to call it because it’s showing up behind here. So there’s like some ordering issues again. You might wanna come back [00:36:00] through here if you were doing multiple pages on the site and say the reflow was not working correctly.
I’m not quite sure how I would mark this up because the layering is just kind of weird. So we’ll just say, make sure “Trust Pilot” is displayed consistently. And then we’ll go ahead and grab the source code for that. If we can, let’s see if I can even find it. Hmm. See if it’s after the navigation. Hmm, let me try resizing this. All right. Let’s inspect that. Okay. There we go.
Ah, so that “Trust Pilot” link is wrapped in a main landmark, which I would fail because the main [00:37:00] landmark should encompass all of the main text on the page, not just one little widget. But I will go ahead and grab this as our example. And since we’re not really sure what they’re trying to do with the “Trust Pilot”, maybe it’s just not showing up in the right place.
Because it’s not actually located in the header. It’s just displaying at the top of the page. We would just wanna let the client know that we’re seeing some weirdness and they can try to figure out what they wanna do. I’m gonna go ahead and reduce this example down just so it’s not huge. Cause there’s a lot of SVG it looks like in there. Oh, my goodness. All right. So we’re just gonna, we’ll just make sure that the link is there and they can figure out what they wanna do with the rest of the content.
Okay. [00:38:00] So let’s continue on. Next we have parsing. Okay. All right. So let’s go ahead and grab just the HTML that pertains to our header. Because we don’t wanna run parsing on the entire page because that will give us results for the things that we’re not testing right now. And we’re really only concerned about the header. So we’re gonna copy the HTML just for the header. We’re gonna go to the validator, the W3C validator. And there’s an option where you can actually paste in source code rather than having it check a URL. And it will give you some boilerplate so that it’s not violating things like not having a DOCTYPE or not having the HTML tag, et cetera.
So inside the <body>, we’re gonna go ahead and paste that header code. And we’re gonna just check that. All right. And let’s see what kind of, so all we have are warnings, so this is a [00:39:00] pass. You can just stop there and not even worry about it. But we can see kind of what it’s telling us. For example, we’re using the header element, so we don’t actually have to include role="banner" on top of that; that’s redundant.
That was done probably to support older browsers, but at this point it’s not really necessary. But again, it’s just a warning because there’s nothing here that is causing errors in parsing. There are just things that can maybe be cleaned up. So that’s good. We can go ahead and say for parsing that passes, we have no parsing failures.
All right, let’s continue. So next, we’re going to look at the last type of success criterion, “Sensory”, and that starts with the sensory characteristic success criterion, which basically advises that you should not rely on a sensory characteristic alone to convey meaning.
So you don’t [00:40:00] wanna say select the circle to continue. Someone who’s not looking at the page may not be able to determine that a shape is a circle or a triangle. We also don’t wanna rely on locations saying, look at the links on the left, because you know, maybe they’re in a mobile view and the links are stacked. That’s sort of thing.
That being said, I didn’t see anything. There were no instructions here that are telling us to do anything based simply on a shape or anything like that. So I think we’re good and we can go ahead and say that we pass sensory characteristics.
The next one is related. It’s use of color and that’s where we’re saying specifically, make sure that color is not the only thing conveying meaning. This comes up a lot in two instances. The first is noting errors. So sometimes people will just make the border around an input that has an error red and have no other indication that there’s an error, like an actual error message; or sometimes they’ll have the error message in red text, but [00:41:00] they won’t have something like an icon that further emphasizes that this is an error.
Another place that this happens is with links. So sometimes link texts will be the same color as text that’s not linked and that can be confusing. So that’s why we always suggest underlining your links. That will give them a visual distinction other than color, that something is a link, but there’s a lot of gotchas when you’re dealing with that. So you definitely wanna make sure that something’s actually violating use of color and is not one of those strange use cases in WCAG where it’s not actually a failure. So we’ll go ahead and say use of color passes because there’s nothing indicating… well, we can look at some examples.
So everything that is a link in the header here is this white text. So there’s nothing to compare it to. It doesn’t have to be different than anything else. So it’s fine that they’re just white, bold text without underlying. So it’s very common in a navigation. Same with the dropdown menu. All of the text here [00:42:00] is a link. So there’s nothing that it needs to be differentiated from, that’s why it’s not underlined and it doesn’t pass the use of color criteria.
Same with our dropdown menu. Everything here that’s in blue is a link to go to a search page. So again, there’s nothing that this is really needing to be differentiated from in order to say that this is a link versus text that’s not linked. So we’re good on all of our use cases here.
With that we’ve completed our initial assessment. So let’s go ahead and see what our numbers look like. So let’s go ahead and sort our status by total number of failures so we can see just what needs to be remediated. And when we do that, we can see that we have failures for 10 of our 50 success criteria. And they were all pretty straightforward issues, nothing that would take a whole lot of effort to fix. So [00:43:00] this would be something that you could go ahead and send to your client and explain to them what needs to be remediated and answer any questions that you can.
And at this point, you know, you would just move on to the next component, if you had additional things that you were testing. And you might consider then also the next thing might be logging some of those common issues that might affect multiple pages on the site, such as whether there’s a skip link and things like that.
Yeah, but I think this is a good place to stop and that’s pretty much what it’s like to run an accessibility test or an audit on a single component. And I hope that you’re able to start doing this on your own and give it a shot.
If you have any questions, again, I’m Rachele DiTullio. You can reach me on Twitter @racheleditullio. You can email me at racheleditullio@gmail.com. Or you can go to my website, racheleditullio.com. Thanks.