Training: Easy Manual Web Accessibility Testing Demo

Transcript

So today we’re going to talk about manual web accessibility testing, specifically easy ways of manually testing your website without using special software, screen readers, etc. It’s really going to be a demonstration of, you know, sort of keyboard-only testing and just using, you know, the browser that you have on your machine.

Manual assessments are crucial for identifying about 60% of web accessibility issues that are not detectable via automation. You know, a lot of you may have sites that are being scanned by Siteimprove, our enterprise scanning platform. So those are, obviously, those issues are kind of within the 40% that can be detected automatically. And so for the remainder, we have to do manual assessment.

You know, as I said, conducting a manual test doesn’t necessarily require special tools or software or skills. Anyone can conduct a simple page assessment using just their keyboard.

And some of the things that we’ll go through today, that we’ll be looking for when when doing this kind of manual testing is, you know, focus indicators. So do links and buttons, form inputs, have a visual outline when they receive keyboard focus? Does the navigation or tab order of the page make sense and does it match the normal reading order? Items that should not receive keyboard focus. So if there are hidden elements or empty elements, they should not receive focus.

And then sort of related to that inaccessible custom widgets. So things like accordions or dropdown menus and that sort of thing, those all need to be accessible via the keyboard. And so, you know, doing this kind of testing will show whether or not those kinds of widgets are or are not accessible.

Now I’m going to switch to Chrome and I’m just going to go through two examples of this web page here. It’s called Accessible University. This was developed initially, I think, at the University of Washington. Some other schools have modified it over time, and it is intended to illustrate just a bunch of accessibility issues. Some that can be found by automation, but a lot that would require manual testing.

I’m going to use a tool here to show the keys that I am pressing. So, if you see a little dot like that, that means I’ve clicked with my mouse. That is a tab. Reversed tab. You’ll see me using arrow keys and the enter key.

So really to get started, you just start using your tab key. So we opened the page in Chrome here, and I’m just going to start tabbing through the web page and as I do that. You know, what we would expect is that you would see, you’d be able to tell, where my keyboard focus is at all times. So every time I land on a link, you know, it should be clear visually where on the page that I am.

So I’m going to start. I’ve tabbed once. Nothing. Now I’m on the Home link in the main navigation. I’m in the About navigation. Academics. And now I’m kind of into something I can’t see where I am. And then, there, Admissions. So I was tabbing through a bunch of links between Academics and Admissions. I think those were the links that are probably in this dropdown menu. So those were focusable even though they were invisible to me.

So I’m going to keep going.

I’m in the search now. I’m on the search button. It’s very subtle. Kind of hard to tell if I’m actually in there or not. Should be in the hero space. It’s kind of hard to tell. Now I’ve jumped down to this “click here” button. You know, again, as you can see, some of the elements on the page do have a focus indicator. A bunch do not. So it’s just really difficult to tell, you know, where on the screen you are at any given time. And so if you’re a, you know, a sighted user, but you have a mobility issue and you’re not able to use a mouse, you’re certainly going to be navigating the Web with a keyboard or some alternate input device that mimics the behavior of a keyboard, and not having these visual cues is really catastrophically bad for, you know, usability and accessibility.

Yeah. So you can see, like, the focus indicators are pretty much missing across the board here. Another. So that’s the very, you know, sort of baseline. Are focus indicators visible? Also are, you know, these custom widgets accessible? As you could see as I went through, there was no way for me to move through the hero space. So we’re stuck on this first slide here. If I use my mouse, I can advance the slides, but there’s no way for me to do that with the keyboard. Additionally, as we saw, those dropdown menus, they work on mouse hover, but they do not activate at all on keyboard input.

You know, most of the sites that are being built today are responsive, right? So the content is going to reflow as you move, you know, increase or decrease the size of the browser window. One of the things you want to check for is as you get to a lower or smaller screen, you don’t want to see horizontal scrolling. And as you can see on this site, as we get way down to the most narrow viewport I now have horizontal scrolling. It’s obvious that’s a problem because you have a lot of people don’t expect to have to scroll horizontally typically.

There are some exceptions to that, like mapping applications. But on a general, you know, website, all the content should be visible in the viewport at all times. And there’s actually a success criterion in WCAG about that called Reflow. And so, you know, if you’re working with a developer, let’s say, and you’re testing a dev site and you know, you kind of shrink the window down to kind of to mimic a mobile device and you see horizontal scrolling. You know, that would be a bug to to open with your developer. You know, there’s something going on here where it’s not properly responding to the size of the window.

A couple other things to just check for. This isn’t necessarily keyboard testing, but just a quick manual test is, you know, I’m seeing in the in the hero space here, this text is kind of blurry and, excuse me, weird looking. And that’s because the text is baked into the image itself. You know, so instead of using HTML text that would be accessible to a screen reader, you know, placing text like this directly into an image is going to be inaccessible. A screen reader is not going to be able to parse that content.

You could certainly add an alt text to the image, but you know, this would be pretty long alt text. And really the better way of doing this would be to, you know, just use HTML text. It also looks better in HTML text. As you can see, it’s kind of lossy-looking and blurry here. It’s not great.

Some other things to just take a look at when you’re reviewing a site would be color contrast. You know, this can be detected automatically. So if you have an existing site that’s being, you know, scanned by Siteimprove, it’s going to flag contrast issues. But if you’re working with a, you know, a dev site or something and you notice links that, or you know something is supposed to be a link, but doesn’t really look like a link or you can’t discern much of a difference between link text and non-linked text. That’s another thing that you’ll want to address.

As you can see here, there’s a link that’s called “Fictional University”, and it’s just inside this paragraph here. There’s a couple of links, actually. There’s another one, the text is “problems”. It’s a slightly lighter gray than the surrounding non-linked text. But it’s very difficult to discern, you know, that this is link text. And there’s also no focus indicator on it. There’s no hover state. So, you know, that’s another thing to keep in mind as you’re As you’re taking, you know, looking at these things manually.

And that’s right. For the most part, yes. You could rely on color alone if the contrast between the background color of the text and the link was, I think, all 4.5 to 1. But there’s there’s only a handful of color combinations that would satisfy that. You need to have basically a like a clownish looking color palette. It would be very unpleasant. So functionally, yeah, you should be using a secondary indicator on links that can be an underline, that could be a bottom border, it could be a color, you know, background color if you if that worked in your design. But yes, you don’t want to rely on color alone.

Another thing to take a look at, you know, this is more content related, but it’s not something that can be detected automatically is vague link text. So here in this “Can you spot the barriers?” section there’s a bunch of links, three of them, that all say “click here” and all three of these links go to different locations, which is a problem. And the text “click here” is really vague and uninformative. So there’s there’s two issues here. There’s the link phrase itself is vague. This is a problem for screen reader users who will often, you know, “scan” a website by having the screen reader just announce all the links on the page without any surrounding text to provide context. And so if you know, they hear a bunch of links that just say “click here”, “click here”, “read more”, “learn more”, that’s not going to be super helpful to them.

Additionally, if you’re repeating a link phrase on a page and so this one’s repeated three times, the expectation would be that those three links are all going to the same URL, but in this case they’re going to three different locations. So again, you know, that’s something that just kind of pay attention to when you’re doing web writing or, you know, just when you’re talking about any kind of editorial considerations on your website. Pay attention to link phrases and to make sure that they’re meaningful.

You know, again, with the kind with contrast we can see down in the footer here, this green on gray and light gray on dark gray. This is all, you know, really difficult to read. You know so here the focus outline on the forms are pretty good. You know, there’s like a blue outline there. Um. It might not be quite contrasty enough, but I can’t tell if this is a default browser outline or not. But you know, at least there is some focus outline here. But then once you get into the checkboxes, of course it goes away again.

And then we have a CAPTCHA, which just in general we would advise staying away from CAPTCHAs as much as possible because they just present a whole bunch of problems for folks who have disabilities. There’s there’s not a great accessible CAPTCHA solution, unfortunately, right now. So if you can avoid it, we would we would recommend avoiding CAPTCHA.

I’m just going to do a quick scan of this page with the Siteimprove Accessibility Checker. So this is obviously going to just hit a bunch of issues that can be found via automation. And as you can see, there are. So we have yeah, there’s some links that don’t have text associated with them. There’s some invalid ARIA that’s, you know, obviously there’s some of this is developer-related. Missing alt text on images. Language of the page hasn’t been defined. So you can see there’s a bunch of issues on this that are kind of found by automation and then a whole bunch that we were able to find just through some very quick keyboard tests.

I’m going to switch to this version of the page, which is accessible. As you can see, there are no issues found by automation here. And again, I’m just going to traverse the page with my keyboard and you’ll be able to see pretty quickly the difference.

So we have initially we have a “Skip to Main Content” block so that can quickly take somebody, you know, skipping over the masthead right into the content area. The logo has a focus outline on it. Now we’re into the main navigation, the Home button. Home has an outline, these all that outlines. If I hit my down arrow, the About menu will now become active. If I hit my ESC key that will close the dropdown menu. I don’t have to, I’m not forced to go through the dropdown menus if I don’t want to. I can tab to the next main item and, you know, just skip over the dropdown. But if I, if I want to get into there, I can use my arrow keys to traverse that content. The outline over that search button is much more prominent here.

We’re into the hero space. This is now fully keyboard accessible. There’s the link is on the headline. This is all HTML text right now. So a screen reader will announce all of this.

As you can see, we’ve put a secondary link indicator here. It might be a little bit difficult to see on the screenshare, I’m not sure, but it has a, this is what we’re doing on most of the University sites. It’s a sort of a dotted bottom border. And then the border goes solid on hover and on focus.

We’ve updated those “click here” links to have more meaningful link text. There’s a modal pop up here. And I can get out of that with the ESC key or via the two close buttons.

So I’m going to quickly go through. And as you can see, everything has a nice outline. It’s very clear where on the web page we are at any given time. So. You know, it’s these kind of small things that make a huge difference to folks with disabilities who might be using your website. And especially around issues like custom widgets, like slide shows and dropdown menus and accordions and things like that. It’s really easy to forget that these have to work with keyboard, you know. It’s very easy to kind of check something with your mouse and you’re like, “Yeah, it looks great”. And then, you know, the site launches and then you discover like, “Oh no. This, this whole thing doesn’t work with the keyboard”. And then you have to go back to your developer or something and try and fix it after the fact.

We’d really love to, you know, catch those things in the development process and and then not have to remediate stuff, you know, later on. That’s just more expensive and more difficult in general.

Do we have any tips for how to triage and decide which errors to fix first? So, you know, if we encounter both a focus error and a color contrast error, or should we tackle the focus error first since it could render the site unnavigable? We would consider lack of focus to be a blocker. You know, when we’re assessing websites, we kind of assign an impact rating to each issue. And, depending on how bad the contrast was, that could also be considered a blocker but not having any focus indicator. It really makes the page unusable to a lot of people.

You know, you could have a contrast issue. You know, it would be a violation, but you could have something that’s just on the edge of, you know, being sufficient. You know, I would focus on the focus indicators first. That said, if you have a situation where you have a white text on a white background for some reason and so like you have hidden links, we would consider that blocker.

So that is kind of the quick demo. I want to thank you all for attending.