About the Topic
Thanks to Our Sponsors
WP Engine, a WordPress technology company, sponsored the live captions for this event. They provide the most relied upon and trusted brands and developer-centric WordPress products for companies and agencies of all sizes, including managed WordPress hosting, enterprise WordPress, headless WordPress, Flywheel, Local, and Genesis. WP Engine’s tech innovation and award-winning WordPress experts help to power more than 1.5 million sites across 150 countries.
About the Meetup
Learn more about WordPress Accessibility Meetup
Watch the Recording
If you missed the meetup or would like a recap, watch the video below or read the transcript. If you have questions about what was covered in this meetup please tweet us @EqualizeDigital on Twitter or join our Facebook group for WordPress Accessibility.
Links Mentioned in This Video
The following resources were discussed or shared in the chat at this Meetup:
- WordPress Accessibility Facebook Group
- Equalize Digital Web Accessibility Resources
- Equalize Digital Focus State Newsletter
- Equalize Digital Website
- Equalize Digital on Twitter
- WP Engine Website
- Follow WP Engine on Twitter
- Empire Captions Solutions Website
- Follow Empire Captions on Twitter
- Web Content Accessibility Guidelines (WCAG) 2 Level AA Conformance
- Web Content Accessibility Guidelines (WCAG) 2.1
- WCAG 2.2 Quick Reference
- Put it on my TAB – Web Accessibility Testing and the Power of the TAB Key
- Stylus Google Chrome Extension
- NVDA Screen Reader
- JAWS Screen Reader
- Training Screen Reader User Testers: Nick Corbett
- How to Use NVDA (Screen Reader): Glen Walker
- WebAIM Screen Reader User Survey (2021)
- WebAim’s Contrast Checker
- WAVE Browser Extensions
- deque’s axe® – The Standard in Accessibility Testing
- HeadingsMap Chrome Extension
- TPGI Colour Contrast Analyser (CCA)
- ARIA Authoring Practices Guide (APG)
- WordPress Meetup Zoom Chat
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Read the Transcript
>> If you are just attending for the first time, this is our WordPress accessibility meetup. We’re going to be talking about basic accessibility testing. I have a few announcements to go through and then we will get started. I always like to start by letting everyone know that we do have a Facebook group that you can join. If you are interested in connecting between meetups, if you go on Facebook and you just search WordPress accessibility, then you will find the Facebook group. It’s a good place to ask questions or get help or share things you’re working on in between meetups.
If you are interested in finding out about other events that are coming up, or if you want to get the recording of this, this is a question that we always get. This meetup is being recorded. It will be available in about two weeks once we have corrected captions and a full transcript available for it. We will post that on our website. You can find it by going to equalizedigital.com/meetup. The best way to get notified of upcoming events and to find the recordings is to join our email list. You can find that if you go to equalizedigital.com/focus-state. It should also theoretically, if I’ve done things right, pop up on your screen as a thank you message after you leave the meetup.
If you join the email list, you’ll get emails twice a month with upcoming events links to the past recording with some other news, and information for accessibility and WordPress. We do rely on sponsors for the meetup to help us cover the cost of live captioning. We are hoping that we can offer sign language interpretation again in the future. If your company might be interested in sponsoring the meetup, please reach out to myself or Paula. You can also email us at meetup@equalizedigital.com to get information about sponsorship.
I am Amber Hinds. If you aren’t familiar with my company is Equalize Digital. We have a accessibility auditing plugin that helps you find some of the problems that can be found with an automated tool on WordPress sites and puts reports on the post edit screen. We also do accessibility auditing and consulting. That was what led us to create the meetup because we wanted to have more opportunities to learn and connect with other people in the space.
That’s who we are. If you want to learn more about us, you can go to equalizedigital.com. We’re also on Twitter at Equalize Digital. We have two sponsors this evening, who I would like to thank. The first is WP Engine. WP Engine is generously covering the cost of the live captions for tonight’s meetup and ensuring that it can be fully accessible to all of our attendees.
WP Engine, if you’re not familiar with them, they are a technology company. They started just with managed WordPress hosting. They also own the hosting company Flywheel, but they’ve grown beyond that and they have a variety of dev focus plugins, and themes. They’re doing a lot in the block editor and full site editing land of WordPress. You can learn more about them at wpengine.com. We also always encourage people to thank our sponsors. Send them a tweet and say, thank you for sponsoring WordPress accessibility meetup, because we want to encourage them to keep doing it. If you want to tweet a thank you to them, they are at WP Engine on Twitter.
Then after the meetup, we have a sponsor, Empire Caption Solutions, who has generously donated their services to help us create that corrected caption file and full transcript of the meetup. In addition to providing transcripts and captions for both live and recorded media, they also do audio description, sign language interpretation, and a lot of other services around ensuring that video and audio files are accessible for everyone. You can learn more about them at empirecaptions.com and they are at Empire Caption on Twitter. I don’t think they use it too much, but it doesn’t hurt to say thank you to them as well.
We have a couple of upcoming meetups that you’ll want to bookmark on your calendar. On Thursday, October 6th at 10:00 AM Central Time, Daniel from Empire Captions will actually be speaking for us about the different types of transcripts that are available for both real-time and recorded media and the different options and how to create those. That would be a great one if you’re interested in captioning and transcription.
Then on Monday, October 17th at 7:00 PM Central, so in the same time slot, Colleen Gratzer from Gratzer design will be talking about how to make accessible PDFs in InDesign. She’ll be highlighting some of the common mistakes and how to fix them. Accessibility on the web extends beyond your website. It also includes any documents that you upload. This will be a great talk if you, or if you have clients that are creating PDFs that need to be accessible as well, and then save the date for November.
We will not have our normal morning meetup because we’re going to be doing WordPress accessibility day, which is a 24-hour conference. It’s running November 2nd through the 3rd. It’s very exciting. We should have the schedule out soon because we just sent out all of our speaker notifications, but you can learn more about that on wpaccessibility.day. It’s not shown on the slide but maybe Paula doesn’t mind throwing that in the chat for you all if you want to go check it out. I think in about a week or two, we’re going to open registration and it’s totally free. Definitely watch for that.
I’m super excited to introduce today’s speaker Glen Walker. Glen has spoken for us before and did an intro to NVDA and it was very detailed and thorough and gave a ton of great information. If you haven’t seen that go watch that. He walks through all of the settings in the NVDA screen reader. He also is a frequent attendee of our meetup who provides tons of value and great information in the chat. You may recognize him from there as well.
I’m going to stop sharing and I’m going to let Glen take over sharing his screen, and then we can start diving into accessibility testing. While he’s pulling that up, please note we have the chat, we also have a Q&A feature. It is a little bit helpful for us if you can put questions in the Q&A feature. I will try to watch the chat in case you forget. If you are able to put them in the Q&A feature that is helpful.
>> All right, so we have about an hour and 15 minutes. Is that right, Amber?
>> Yes. Sorry. I was on mute.
>> All right. One last plug before we jump in. One more cute kitty picture. I almost put a video up here where they’re playing, but that would’ve been way too distracting. There you go. If anybody has any recommendations on kitten names since they were just adopted yesterday. I was waiting for their personalities to come out before I name them. Always open to ideas. Maybe something will come up through this presentation. About an hour and 15 minutes. I wanted this to be less formal of a presentation and more of an interactive session, because I’m going to talk about just some basic accessibility testing, and this is going to be for website testing, not documents, which was mentioned earlier.
I’m going to go through some basic testing. It actually– well, I was going to say it takes a bit of time really to become proficient at accessibility testing, but I didn’t want to discourage people from trying to do it. If you’ve never done it before, where do I start? What’s the best thing to test? What tools should I use? What should I look for and things like that? I really wanted to start with keeping two things in mind for basic accessibility testing. The first in, I might actually get some feedback on this is that accessibility testing is easy, actually. Yes, there are a lot of requirements if you look at the web content accessibility guidelines, WCAG, and if you’re looking at, and all these terminology things, I won’t go into full detail, but if you’re looking at version 2.1 level AA, which is the standard today at least, 2.2 is still being worked on.
If you look at WCAG 2.1 level AA, there are 50 requirements. That can be a volume of checkpoints to do, but try to keep it simple. A lot of accessibility really is fairly easy. I just listed three rough areas you can test with, tabbing, the page structure, and colors. Then I add, not to make it less important, but then I also add images at the end. Not that images are an afterthought, everything is super important. If you have images on the page that convey information, if an image for example is part of a link and that link doesn’t have any text, it only has an image, then that image is pretty important and you want to make sure that it is accessible. I was trying to keep this a little bit simple, where do I start and what should I focus on first? Maybe if your website is very multimedia-driven, if it has a lot of images, then images might be one of the first things you need to check and make sure they have alternative text and that they convey meaning, things like that.
It’s somewhat dependent on the type of site you have. For now, I’m going to talk about tabbing through the page, page structure, as well as colors. Keeping it simple and keeping it easy. The second thing is your accessibility testing doesn’t have to be exhaustive. I miss issues all the time when I’m testing a site. It might be because of the data I had, I might not be able to get to a certain part of the page or there might not be enough information on the page that populates and fills stuff on the page, I might not be able to get to it. I might miss things that way or maybe it’s a color contrast issue. There could be a color contrast that is 4.4 to 1 where the required minimum is 4.5 to 1. It’s just barely below and using my rough eye-catching tool.
I look at a page and I look at some colors jump out going, well, that doesn’t look like it might have enough contrast and rather than using a tool to try to catch that, so I might miss a color contrast. Any issues you find are going to help your page and it’s a step in the right direction. Don’t worry about trying to be so exhaustive that you feel like you need to catch every single thing on the page. Certainly, that’s a goal, but don’t fret about that. Keep it easy, keep it under control, tabbing, page structure, colors, images, and there’s a few other things. I wanted to start off with that first just to ease people into it or ease your mind on accessibility testing. It feels like a very large topic. It doesn’t have to be. What I’m going to talk about today is how I personally test. This is based on years of doing this, almost 20 years of accessibility testing.
There really isn’t a “correct” way to test as long as you are testing against WCAG, which I’ll bring up in a second. You can test things in any order that you want. I’m going to show you what I do, the order of things that I test. Again, that’s just how I do it. You don’t have to do it that way. You might see something I do is like, “Well, that doesn’t make sense. I don’t feel like testing that right now or that should be part of something else.” That’s perfectly fine. It might be something I do, you’re like, “Oh, I didn’t think about that.” Great, you got something out of it. You can test in whatever order you want to test with, you can use whatever tools you want to test with, anything that’s comfortable for you. That was one of the things in a previous job when I was running accessibility testing, I did not dictate what tools that a tester needed to use because some tools just work better for some people than others.
It all depends on your learning style and things like that. There really aren’t any prescribed-here’s the best tool to do this or the best tool to do that. It’s whatever you feel comfortable with in using. As I mentioned, when you do testing, you are essentially testing against WCAG 2.1 AA. You can go to the official website on w3.org. You can see a list of all the guidelines on the left side in the table of contents. There’s numbers in front of all of them. I won’t go into what the numbers mean, but this lists every guideline, single, double and AAA. There are a lot of them. Over in the right side of the page, you can scroll down, you can get to one of them and start seeing Success Criteria 2.1.1, that’s to do with keyboard support, 2.1.2 is keyboard traps and so on. You have all this information.
This really is what you’re testing against. Might be why a lot of people think it’s very overwhelming because this is a very big page. There’s a lot of stuff on here. How do I test through all that, that’s a lot of stuff. Well, I like to use this little shortcut page that a friend of mine put together and it’s not official, it’s not W3C sponsored or anything like that, it’s just a way to see all the guidelines on one page. The website is 3, the number 3, pha.com/wcag2. This is going to show, there’s a little preferences drop down here. It’s showing single, double and triple A. I’m going to turn off AAA because I’m not going to test for that. You can look at 2.0, 2.1 or 2.2, I’m going to turn off 2.2 because that’s not official yet. That will leave me with 50 checkpoints when I’m testing. Here’s really what I am testing anytime I look at a website.
Again, there are 50 checkpoints here, that’s a lot of stuff to check for. Going back to my previous slide, I talked about tabbing through the page, looking at the page structure and looking at colors and maybe looking at images. Well, not maybe, you will look at images but if you want to hold off on that, depending on your site. This is really everything that I’m looking at. I mentioned that if you want to test in order, if you want to start with the very first one, 1.1.1 which is images, that’s fine. You can go to the next one. All the 1.2s, these are multimedia. If you have videos or if you have podcasts on your website, then these will be important. Then go to the next one, 1.3.1 info and relationships, and so on. All the way down that first column and go to the next column, 2.1.1. You certainly can test this way.
It might be a lot of, I don’t know, it might take longer if you do it this way because there’s a lot of testing you could do that overlaps. When I talk about tabbing through the page, there’s a lot of stuff that I’m testing as I’m tabbing through the page other than just keyboard support, there’s actually a lot of other things. I’ll point that out on, I think, maybe the next slide. This is really how I test these things we’re going to talk about today. Again, you can use whatever you want to use for testing and whatever order you want to do testing and things like that. As I mentioned, you could test numerically start at 1.1.1 all the way through 4.1.3, which is the last one, which is new in 2.1 and has to do with dynamic content on the page. What I like to do is group things together.
This is a very rough– This list of, what? Eight. It was eight bullet points, might not cover all 50 checkpoints, but it will cover most of them when I do this. With these first three bullet points, which is a quick test to the Tab key, tab with custom focus style [inaudible] and tab with the screen reader. If I only do that, I’m going to catch a pretty significant number of accessibility issues. In this case here, you can cover almost or not almost, you can cover 14, maybe even more WCAG checkpoints and that’s almost a third of your accessibility testing right there with those first three bullet points tabbing through the page, looking where the focus indicator is and running with a screen reader in the background so you can listen to how things are announced.
It’s fantastic. One of the– Did I go through that slide already? I think I mentioned some previous testing or some previous slides you can look at our presentations. I have one that talks just about using the Tab key and testing and how much accessibility testing you can do with one simple key on the keyboard. I think that’s coming up in the next slide. I also talk about code inspection. I have that highlighted here on the page. Don’t let code inspection scare you. If you’re not a coder, that’s okay. It really doesn’t take much to learn a handful of HTML tags. That’s really all you need to know.
Part of it is the next bullet point page structure. When you’re looking at a page and you’re trying to figure out, all right, this thing looks like a heading or this thing looks like a list or it looks like a table, is it really coded as a heading or a list or a table? Well, that’s where most often at the time, I bring up the code inspector in the browser and just see, all right, well, which HTML tag are they using? If it’s just bold font and a larger font for something that looks like a heading, well, then it’s not really a heading and that is going to hurt some users that rely on the actual structure of the page.
Don’t let code inspection scare you. It’s just a handful of HTML elements. If you learn those, that will go a long way in helping you to test. Then again, I mentioned page structure and I’ll go into a little bit of detail on each one of these bullet points, but I also want to do a demo as well, so we can see how easy it really is to find some accessibility issues. I have colors and images and some low-hanging fruit, some real simple testing you can do to catch a few issues.
>> Hey, Glen.
>> Yes.
>> We received a question. Steve Horn is asking, “Is max voice-over any value for the method you’re talking about or does it require a windows screen reader in order to do this approach that you’re talking about right now?”
>> No, this is a platform agnostic, I guess you’d call it. You can do this on a PC or a Mac or even mobile. It doesn’t matter which platform you’re on.
>> Great. Thank you.
>> That was the question. Now, when we’re talking about which I’ll have a screen in a second, when I’m talking about the custom focus indicator, there’s a way you can do it with Chrome and Firefox, which if you’re using that on a Mac, then you can use this plugin. If you’re using Safari, then you have to go into Safari settings and point your browser to an external CSS file. I will show that slide. I have that slide hidden. It’s coming up on slide eight, I believe.
I had it hidden because I figured there’d be Mac users, but I didn’t know if I’d get a Mac question. I might actually show that slide. This list here, this is really generically. It doesn’t matter if I’m on a PC or a Mac doing it, but I do have another bullet point at the bottom that says do it all again in responsive view. In other words, most pages, when you’re looking at them on the desktop, if you were to look on that same page on your mobile device, typically a lot of the menus collapse down. Then what sometimes is called a hamburger menu or could be a kebab or a snowman menu three vertical dots or three horizontal lines, same thing with the footer.
It might collapse things. Other parts of the page might collapse. You now have different interactive elements on the page that you want to test. Make sure that it’s going to work in a responsive view. Now, things like colors typically are not going to change in responsive view. See, it’s not like a full retest when you’re looking at a smaller screen size. Images. Typically if an image has alternative text, that alternative text typically is not going to disappear, just because you’re in responsive view.
Same thing with the page structure. If you have headings or if you have tables or lists, typically those are going to stay there even in responsive view. It’s not like a full retest, but you do want to either bump up your font on your desktop machine, which will hit the breakpoint at some point to show you what it would look like on mobile, or you can use a mobile emulator within the browser and I’ll show you both of those real quick or you can just get on your real mobile device and try it there.
All right. Let’s just talk about these first three bullet points tabbing. Doing a quick test of the Tab key, just to see if you can access, if you can get your focus on every element on the page that you can click with, with a mouse or click on with a mouse. That’s just making sure every interactive element, because oftentimes you’re going to find elements that might be just a DIV or a span tag, and they have a mouse click handler. Only mouse users can actually interact with that element and a keyboard user can’t tab to it, or even if they could tab to it, they might not be able to select it.
This is really important to check because there are lots of different types of users that are keyboard-only users. It might be a mobility issue that they have to use a keyboard. My father had Parkinson’s and so he had hand tremors and was very hard for him to hold a mouse still to click on something, but it was much easier just to press a Tab key and then press the Enter key to select something.
Screen reader users, somebody with lower vision or no vision. That’s using a screen screener. They’re going to navigate through the page using a Tab key, because typically you can’t see where your mouse pointer is. They’re going to navigate that way. Some people just prefer the keyboard. A power user can be much faster using a keyboard. There’s a lot of benefits for supporting keyboard as well as just tabbing, and there’s other keys left right key or up down key when navigating through a list or a list box or a drop-down left and right, maybe to expand and collapse an element.
There are other types of keyboard elements, but tapping is pretty frequent. As far as these other two bullet points using a custom style sheet and using a screen reader, so regarding a custom focus indicator using a style sheet, I go into a pretty good detail of this at a previous meetup. It wasn’t a WordPress meetup. This was the Nebraska digital accessibility meetup. This link was posted on today’s meetup comment page. If you need to get to that, I have it on the slide here, but you can get to that easier probably from today’s meetup page and just go click on it.
All I really do is, excuse me, I run with a one line of CSS and that’s highlighted in yellow and what this says, again, I’m not a CSS guru, I’m a very much a novice. This one line of CSS that I use says has star colon focus, which means every element on the page that can receive focus. That would be links. It would be form elements. It could be something with tab index of zero. Anything that you can tab to will have a focus indicator.
When I tab to that element, I want the outline to change to purple, which is FF00FF, so it’s full intensity, red and blue. No green. Green is set to zero. I’m going to have a solid outline. I want it to be four pixels wide. I want it to be thicker than normal and I want it to be important. I want to override everything else on the page. Just to show you real quick, well, we could see it here. There’s a purple outline around preferences.
If I tab, skip to operable, non-text content 1.2.1. There’s actually a focus indicator on the page itself, which changes the text to light and the background to black when it recieves focus. I’m also getting this purple outline and it may be easier to see on our test page today. We’re going to go into this at some point, but when I tab through here, I’m getting a purple outline around all the elements because I am running with my own custom style sheet because I want it to be very, very, very obvious to me where my focus is.
I want to see what elements might get skipped over. Sometimes maybe there’s a hidden element on the page and it’s not really hidden, hidden like display none with CSS, it’s hidden by setting the position off to the left or up above the top of the screen. When you push it off the screen, that doesn’t hide it from the keyboard, I can still tab to it. It just means my purple outline is going to disappear because it’s way off the screen and I can’t see it. That’s a really important thing, excuse me, to check.
The way I’ve set this, both in Chrome and Firefox, there’s a plugin called Stylus, S-T-Y-L-U-S. You can just do a Google search on that for both Chrome and Firefox. I’m actually a big Firefox user even though Chrome has been gaining ground, well, I guess it’s past Firefox now. Used to be Firefox was very popular, but I’ve been using it so long. Generally when you find an accessibility issue, for the most part, it doesn’t matter if you found it on Chrome or Firefox or Safari or Internet Explorer, really it’s going to be a problem on all these browsers.
There are some minor differences and I don’t want to go in too much detail on that, what the differences would be. A real simple thing like a frame element in Firefox is an automatic tab stop, whereas on Chrome, it is not. When I tab through it, my focus will land on it on Firefox. If that frame does not have any kind of label associated with it, then I won’t know what it is and so that would be an accessibility issue. Whereas on Chrome tab is going to jump over it.
There’s kind of not an accessibility issue there. Same thing with scrollable containers. If you have a container on your page, whether it’s a DIV or whatever that has scroll bars on it, whether vertical or horizontal Firefox will make that container a tab stop so that I can tab to it. Then I can use my up and down and left and right arrow keys to actually scroll within that container. It’s a great feature. Chrome does not let the focus go there by default.
Again, you have a case where, okay, well, I could tab to this on one browser. It probably should have a name so I know what it is. Whereas the other browser doesn’t let you tab to it. There are some minor differences, but for the most part, if you see something that maybe should be a heading, but it is not coded as a heading, that’s going to happen everywhere and you can find that with code inspection. Again, if you go back to this other meetup page, you can watch more information about– more detail on Stylus, plug-in, and how to set the focus indicator. I think I mentioned on our comments, it’s a 40-minute presentation, but if you set your playback speed to 1.5 times faster, then it only takes about 25 minutes. Let’s see. I think I’ve got– Let me go to slide eight, hidden slide secret.
>> Can I ask you a question real quick, Glen?
>> Yes.
>> Do you test with that focus indicator turned off first to figure out what things might be missing focus indicators on the website?
>> That’s a great question because if I go back to this slide where I talk about using the Tab key with these things, I can catch about 30%, about 1/3 of all WCAG issues. Over on the right side, I list a few of them. 2.1.1 Keyboard, 2.4.4 Link Purpose, these are things you can catch using the Tab key and a custom style sheet and a screen reader. I did list 2.4.7 Focus Visible with an asterisk next to it. Down to the bottom, I say when testing for focus visible, you have to turn off the custom style sheet because I want to see what the page really does for this particular guideline. I do turn it off when testing for that particular guideline, but otherwise, I have it on 90% plus of the time, otherwise, if that makes sense.
In this case here, I’m running with the plug-in. I can actually turn it off. Now I can start tabbing through the page. I’m already down on the link. I got a blue outline, which I think is probably Firefox’s default. In this case here, they’re just letting links have whatever their default outline is. Let me tab backwards up to the menu. In this case here, the menu goes from gray to white and has an underlying. That’s my focus indicator. I can tell where my focus is. I will tab through the page with my style sheet turned off to test that specific guideline, 2.4.7, but otherwise, I have it on all the time just so I can see things.
>> Thanks.
>> If you’re going to use Safari on the Mac, you can go into preferences. You can use command plus comma to get to preferences, go to the advanced tab, and then about halfway down the screen is something called style sheet. The default is non-selected, it’s a dropdown moment, so if you select it, there’s a couple of different choices there, but one of them is Other. When you select Other, it brings up a file selector, and then you can go– This one line of codes, *: focus outline, blah, blah, blah, if you put that into a separate text file, typically a CSS file you have a .CSS extension, but it doesn’t matter. You could have a .TXT extension or whatever you want to call it, but basically, you would point Safari to that external file, and then you would get the same benefit on Safari.
You would get the purple outline or whatever color or whatever outline style or thickness you want to use for your focus. If we had more time, maybe at the end, I could play around with it. Sometimes I don’t use the outline. I’ll use maybe font size so when I’m tabbing around something, it’s really big when I focus on it or background color, it could be anything. If you’re a CSS person, have fun. I just use outline on mine. That was using the Tab key, using a custom focus indicator, and tabbing with a screen reader. Regarding screen readers, which a screen reader is a separate piece of software that actually lots of different types of users use a screen reader.
It’s pretty common with low vision or blind individuals, but you could have someone who has cognitive issues, maybe they have trouble focusing when they’re reading, whether it’s a dyslexic issue or not. Using a screen reader at the same time, they’re navigating through the page helps keep the person focused. Maybe English isn’t the first language on a page and maybe if someone’s trying to learn English better so they’re listening to the screen reader. If you use one of the more naturally sounding voices instead of the robotic voice, then that can absolutely be helpful as you’re learning another language.
There’s all different kinds of screen reader users out there. On the PC there’s NVDA and JAWS. These are two popular screen readers. NVDA is free. There’s a link on this slide and we can maybe send the slides out as well. If you go to nvaccess.org, that’s the company that makes NVDA and they have a download page, it’s free, but they do all this work for free. They accept donations if you wanted to do that. Job Access With Speech, JAWS, they have a free trial mode. It works for 40 minutes and then you have to reboot your computer. You don’t have to, I’ve actually run with the 40-minute mode, let it expire, and then the next time I run it.
I think it runs for about a minute or two before it says, “Hey, you’re in trial mode, you’ve used up your 40 minutes. You need to reboot if you want another 40 minutes ” Usually within a minute or two, I can figure out the issue I need to check with JAWS. Sometimes I only need it for that long. If you wanted to use for more length of time in the US, at least, and sorry for those who are not in the US, JAWS has a home license. It’s $95 per year, so it’s not a perpetual. They have a unlimited license. If you’re going to use it for 10 years or more, it might be worth it. I think it’s like $1,000.
If you do use the home license– For me, I could not use the home license because it’s not for commercial use, and so when I do accessibility testing for a client if I wanted to– Well, not if. When I honor the ULA agreement, I’m not going to use it for commercial purposes. I’m not going to buy JAWS’ home license and use it for commercial purposes. If you need it for yourself, maybe you’re just learning about accessibility and want to play around with it, you want to test websites for fun and not get paid for it just because you want to improve your skills, then absolutely go ahead and do that.
Then on the Mac, you have VoiceOver which is free. It’s built-in, you already have it. You don’t have to do anything other than hit command F5 to turn it on. It comes on MacOS and it’s on iOS as well. I don’t really talk about mobile much today, but if you have an Android device, you have TalkBack built-in as well. I’ve found that it’s a little bit different to interact with VoiceOver when it’s running– or it’s a little bit different to interact with the webpage when VoiceOver is running than it is on a PC when JAWS or NVDA is running.
NVDA and JAWS don’t really do anything funky to your keyboard other than there’s a forms mode and browse mode, which I don’t know that I’ll get into today. It’s a little bit easier, I think, starting off with the screen reader on the PC than it is on the Mac, but VoiceOver, there’s lots of tutorials. You can look on YouTube for a VoiceOver tutorial or go to apple.com. They have tutorials there as well. It’s just a little bit steeper learning curve if you’re going to go that route.
>> Glen, someone had a question about– Si was wondering if you can use the narrator under accessibility options in Windows 11. Does that work sufficiently or do you recommend installing a third-party screen reader?
>> It’s gotten a lot better. I think you can do, it’s either Shift Windows N or Control Windows N. The windows logo will turn Narrator on or you can go into settings and turn it on yourself. There’s a shortcut key for it. I’ve used it a bit when I didn’t have– If a computer was locked down, if I was using maybe a client’s laptop, maybe I’m doing work for clients and they want me to do it on their laptops and they’re very IT locked down and I can’t install a screen reader, typically Narrator is there because it’s part of Windows and I can use that. It’s decent. It’s gotten a lot better.
It has some very similar shortcut keys as NVDA and JAWS. I can use H to navigate to a heading, T for a table, L for a list. I think it might have some different voices you can install. Well, I don’t know if you can install or not. It might come with some different voices, but, yes, you can use Narrator. It’s not a very popular screen reader, but if you had to use it, you could, and– Oops.
>> I don’t know that I’ve ever heard a blind person tell me that they use Narrator, so that makes me hesitate to want to test with that because I would rather test with screen readers that more people are using. I don’t know if you feel the same way.
>> If you have availability to NVDA or JAWS, then absolutely use those. If for whatever reason, like I said, if it’s locked down and you only have Narrator, then okay, use it, but I don’t recommend it as a first choice. This is a survey. This is on a website or survey of screen reader users commonly used. You can see JAWS still has a slightly bit of a lead over NVDA. I think the results here if somebody uses both they’re going to mark them both. This is an exclusive list. Like a person uses just one of them and not the other ones. JAWS used to be way, way, way higher and NVDA had been slowly catching up.
I thought NVDA had passed them but apparently not. Then you can see VoiceOver because if you’re on a Mac sometimes that’s your only choice or if you’re on iOS that’s your only choice. It’s actually pretty high. 40% of people using it. It used to be down to the teens, so it’s come quite a bit. Narrator, that’s pretty respectable in fourth place there at 36%. It’s not totally unheard of but– Then you’ve got these outliers. ChromeVox I would not recommend using it all. It doesn’t seem to work that great as far as the types of screen readers you want to use. NVDA and JAWS so that’s why I have those listed here. That’s why I don’t have Narrator.
About two weeks ago, I think about 18 days ago, beginning of September, Nick Corbett was here at WordPress meet up and talked about training screen reader users, screen reader user testers, so people that test using a screen reader. You could tell that Nick is very much a keyboard shortcut guy if you watched that or if you go back and watch it. I love it because I love keyboard shortcuts and he was doing keyboard shortcuts of everything. Inside of Excel and in other documents that he was looking at. If you want to go back and look at that and watch that recording I have the link here. I don’t think– I didn’t put that on the meet up page. [inaudible] was probably going to post it here in the chat. I also have details as mentioned, as Amber mentioned earlier on. I talked about NVDA. How to set it up. Changing some of the settings.
Typically you want to use a screen reader out of the box. Don’t change any settings because you don’t want things to be different than how a user might have it. Although most screen reader users are going to change their settings anyway. Sometimes using it right out of the box isn’t that great. I go through details of the setup and I change some of the settings that don’t affect the accessibility testing. They just make it a little bit easier to use.
Setting up some shortcuts with a screen reader and a few other things to make things a little easier to test. If you want to go back not quite a year ago, November of last year, and there was a link on Equalize Digital. Again, that was posted in today’s meet up comment page. If you want more details on how to set that up. Let’s go ahead and then do a short demo. I think I saw Christina’s name earlier in the cat naming section. She volunteered her website to do some testing. It’s called crownpointgardenclub.org. I’m going to pop over there real quick and I’m only going to–
Well, I have a hard time when I go look at a website. I have all these– I get flooded with information. I’m like, oh, there’s a list. There’s a heading. Oh, there’s some color issues or there’s an image. You get really flooded once you’ve been doing this for some time, so it was really hard for me. I’ve only talked about tabbing and custom style sheet and running with a screen reader initially. That’s what I’m trying to keep my blinders on and focus on that. I might see a squirrel run by and get sidetracked on another issue.
For now, I will try to keep it just to talk about tabbing on the webpage. We’ve got Crown Point Garden Club. I didn’t mention earlier but I have a very wide monitor and I’m sharing my whole screen because I’m going to pop over between the browser and the code inspector and maybe even some text editor to show you some code. I like to put those side by side. I want you to be able to see it and I try to bump up the font and I can bump it up a little more if it makes it a little bit easier to see but you can let me know in the chat if somebody needs a little bit bigger.
The first thing I’m doing so as soon as this page comes up I’m just going to tab into the page. I have my custom style sheets. I see a purple outline around things. The first thing I see is skip to the content. Which almost sounds like I want to be an active person and skip around and skip to the content. This is a great one. 2.4.1 I believe the number is. It’s called bypass box and bypass blocks.
All we’re doing now is again I’m just using the Tab key with my focus indicator. I didn’t start up the screen reader yet. I’ll do that in a second. Skip to content is one of the things you can test with a Tab key. This basically says if you have a common list of things that is on every page which almost describes every single page you go to because you almost always have the same menu at the top of the page where you might have a login page or whatever. A whole bunch of stuff on the main menu. It’s repeated on all the different pages you go to.
Well, for a keyboard user, having to skip over all of that stuff just to get the main content, kind of the meat of the page, could be difficult if I’m using a sip and puff device. Where I have to navigate all these elements here. I have to puff every time to do a tab I might get lightheaded having to puff all those times if you had a very big menu to tab through. Having a skip to content is awesome as the first element on a page.
As you probably, well maybe you didn’t notice. If I tab off of it, it’s gone. As a mouse user, and this should delight the designers out there, you don’t necessarily have to have a skip to content always visible on the page. It can be helpful to always have it but it doesn’t have to be there. This case here if I were a mouse user I would never see that because I don’t really need it to skip over the content. I just go the mouse to whatever I want to get to.
As a keyboard user, as soon as I tab into the page, it suddenly appears so it’s a great feature to have. If I tap in, so Crownpoint Garden Club, the main heading, I’m guessing of the page, maybe it’s not a heading. I didn’t check. It receives focus which must– Well, doesn’t must mean but it probably means it’s an interactive element. You typically do not want your focus to go to things that are not interactive. Things that you would not normally click on. This case here because I’m looking down at the bottom left corner of my browser I can see a URL listed. Yes, indeed this is a link and it just goes back to itself but that’s okay. Let me pop back up. Let me turn on the screen reader and I’m going to use NVDA. You should have heard a piano note. That’s when NVDA starts.
>> Meet Crown Point Garden Club growing in East [inaudible].
>> I’ve slowed to speech down a little bit so hopefully it’ll be easy to understand. I don’t run with it like super-fast like a native screen reader user would. That would be–
>> Rate 35. Crow Point Garden Club [inaudible]>>
>> That’s probably because it’s slow for a native screen reader user, believe it or not.
>> Rate 20.
>> [inaudible]>> about 20.
>> Rate 10. Crown Point skip to the content link.
>> Skip to the content link. Great, it’s a link that’s going [crosstalk] to navigate me. Yes, go ahead.
>> Do you mind increasing the speech viewer size?
>> Yes, we talked about [inaudible], totally forgot. Okay.
>> Thank you.
>> Skip to content link. I heard that it was a link. That’s fantastic. I know it’s going to navigate me. I tab again.
>> Crown Point Garden Club visited link.
>> Another link. Crown Point Garden Club.
>> List with five items home visited link front page.
>> Several pieces of information here are announced by the screen reader that you might take for granted as a sighted user. The first thing was list with five items. It doesn’t say that anywhere on the screen but there’s a menu and that menu if I look at it, home, post, contact us, next meeting, garden tours. Okay, yes there are five items in the menu. That’s fantastic.
Now as a screen reader user I know there’s five items in the menu that I’m going to have to tab probably five times to get past it and whatever is beyond it. Now that’s because this menu was coded using a real list in HTML. I’ll talk about lists in a little bit when we talk about page structure. Again, I’m trying not to get distracted by the squirrel. I’m only doing tabbing right now and that page structure. It’s really fantastic when it’s coded as a list. As a sighted user you look at this list, you can probably with a split second go, “Okay, yes, there’s five items there. I can kind of see five items. The cross and the screen reader user got that information well and then it read home because that’s the text. It said current page, which I’ll talk about in a minute, but let me do this tab across this menu.
>> Post/News visited link.
>> Post/News. Whether the slash is announced or not, doesn’t really matter. Does it add anything? Maybe, maybe not. There are actually slashes between each menu item. It might be hard to see. I don’t put my focus on it, but if I navigate with the screen reader to every element on the page, then I might hear those, but let me stay focused again real quick. Now listen to the next one.
>> Contact US visited link.
>> Contact US visited link. Visually, it looks like contact us, and that’s what it is, but the problem here is some screen readers when they see all upper case letters, it’s kind of hit or miss. It depends on the words. It might announce all the letters separately because it thinks it’s talking about the United States. It saw uppercase U-S. That’s usually how the US is used, so it said contact US instead of contact us. Is that a WCAG issue? No, it’s not. It’s more of a usability, a user experience type thing. Is this something you want to fix? Maybe. This is a low priority, UX depends on what you want to focus on. If we inspect this.
>> Developer tools crown point garden clan VDA.
>> Over on the right side is the code inspector. I’m looking at the link for contact us. Again, if you’re not a code person or, or not a CSS person, there’s only just a handful of things you need to look at and understand. For now, I’m just interested in this link, this anchor tag. If I go over and look at the CSS, there is a text transform upper case. I don’t know if you can– Well, I clicked on it, but if I turn it off, so I turned off the style in the code inspector. If I go back and look over on the page, now everything is mixed case, which for me personally, I find that easier to read, having mixed case instead of uppercase. That’s a design decision, whether you want it all upper case or not. Now when I tab to it.
>> Contact us visited link.
>> Contact us instead of contact US. That’s just a little thing you might want to check. As I was tabbing through the page, this is why I’m running with a screen reader, so that I can hear how things are announced. This might be something I want to change, might not be. If I do want to change it, maybe I still want it all uppercase. Let me turn back on.
>> Speech turned off.
>> I got to turn off the speech for the screen reader for the second while I’m changing this because I don’t need it telling me all the code. If I really want it uppercase, but I still want to say contact us instead of contact US, I could. This might get a little too nerdy, but I could change it, and I can change it on this page just to see how it sounds, but this isn’t obviously going to change the real website. Whoever owns it, would’ve to change it.
I could add an aria label and say contact us and use lowercase. Or I could have the C in contact uppercase and the U in us uppercase or mixed case, whatever. I could have it like that. Actually, let me just to prove I’m not making this up. Let me mislabel that just so it’s not going to use it. I turned uppercase back on, so it should say US again. All right.
>> Contact US visited link.
>> Now let me give it an aria-label.
>> Developer tools, crown X.
>> All right, now let me tap back to still uppercase, but I gave it an aria-label of contact us in lowercase. All right.
>> Contact us visited link.
>> Now maybe you get the best of both worlds. It says contact us, and it also shows it all uppercase if that’s your design decision to do so. That’s just a little thing to catch with pronunciation. Again, there is not anything in WCAG that says things have to be pronounced properly. That’s something that’s always good, to try to do, but you do have to be careful when you start using aria tags. If you use them properly, it’s fantastic. If you use them improperly, it could be worse than if you had not used them at all. Let me just show you an example, and let me pause for a second. Are there any questions on that, Amber?
>> I don’t think I saw a question specific to that.
>> Let me just show you. I used an aria-label. An aria-label is going to override whatever text is in the link. In our case, because I used the same text, contact us, but just all lowercase, it didn’t matter, but it can go bad if I go to this next meeting, and I go to RSVP required, which is going to go outside of the site. It’s going to go to Eventbrite. Just to show you an example, I’m going off script a little bit. Let me bump this up a little bit, font.
They have a menu in the upper right, it says browse events, organize, help, login and sign up.
>> Menu drop-down link.
>> That’s the drop-down on it. They have a skip link. That’s great, it popped up. I want to navigate over to the menu on the right side. [crosstalk] Quick-click link. The link at the end is just because it’s a link. Quick link is what it’s announcing. Browse events, is what I see. Oh, that’s weird. Let me go to the next one.
>> Menu drop-down, link one of one.
>> Menu drop-down. I’m seeing organized. What is menu drop-down? Let me go to the next one.
>> Menu drop-down link, one of one.
>> Another mini drop-down. Another quick link. Another quick link. This is bad. It looks great, but with a screen reader, and if I were not running with a screen reader, if I were just tabbing to the page, I’d go, “Well I can tab to these things.” Maybe I can get to the menus. Oh, everything’s great on this page, until you listen to it. That’s why I always run with a screen reader at the same time. If we look–
>> Quick-link link. Developer tools. NVDA. Developer tools Crown Point Garden Club, August meeting tickets. Wednesday, August 24th, 2022 at 7:00 PM Eventbrite HTTPS.
>> Just something about Eventbrite that really confuses or sometimes confuses NVDA. I got a spinny cursor now, and NVDA locked up. It’s still there. There it is. No, it just died sort of.
>> [inaudible].
>> I was looking at browse events, and I had that link up. Let me just make sure there’s NVDA is not running the background. Control, shift, escape. I love keyboard shortcuts as mentioned, control shift escape, if you want, a little handy keyboard brings up the task manager directly. Actually, if I look for NVDA. Okay, I don’t see it, so it must have properly died, but this website, or maybe it’s Firefox that’ts having a problem, but at least I still have the code up. The browse events link anchor tag has an aria-label of quick link. It’s doing what we were trying to do with the contact us.
The problem is that whatever developer that works for Eventbrite and was coding this, maybe they thought that aria-label was an additive thing. In other words, it’s going to read my aria-label, and is going to read my text that’s inside the link. That’s just not what it does. It shows that, first of all, the developer maybe had a misperception of what aria-label does. Secondly, the developer didn’t test it. They just stuck it in there. They didn’t try running with a screen reader, otherwise this would’ve been a very obvious issue. That bothers me more that there are developers out there who are throwing some aria attributes around. Maybe aria will be the name of my cat, one of my cats.
They’re throwing aria attributes around and not even trying it right. It really bugs me that something so simple as this, so easy to test, is missed. Apparently, it really hosed up my browser. I’m going to kill Firefox and bring it up, restore my session hopefully, because I have 250 links open. It’s terrible, I know.
>> I’m pretty sure the number of open tabs that you have at any given moment helps us understand how awesome of a developer or accessibility tester someone is. The more open tabs, the better.
>> I don’t know if that’s true or not, but definitely, if I were to go through here’s all the links tabs I have open, because I do all kinds of testing on all kinds of different stuff. Anyway, so we’re back on the browser events page. As I mentioned, this link had aria-label equals quick link. Same thing with organized, which is probably under this next div. I should have just done a inspect ton of it. Here’s an anchor tag, roll equals menu tab in. Your aria-label equals menu drop down link. They actually have the word link in it, which is you’re going to hear a link, link because it’s already a link.
No, they have roll equals menu. They’re actually changing it from a link to a menu item, but they still want to hear a link for some reason, even though it’s a menu item, but they’re not actually going to hear the word organize because they’re misusing aria-label. You have to be careful when you use aria, and if you go back to WebAim, so WebAIM is a fantastic research company. They’re actually based right down the street from me. I’m in Northern Utah. They’re based at Utah State University, and they have fantastic resources on their website, W-E-B-A-I-M.org.
They have the WebAIM million, where they analyzed the homepage of the top one million websites. The million websites are based on remember whatever they- Majestic Million Alexa Top Million, DomCop Top 10 Million. They didn’t just pick randomly a million. Well, that would take forever to pick a million pages to test, but they tested the homepage of the top one million websites, just to see how accessible they are, but with a caveat that they’re running a scanning tool. Scanning tools, depending on who you ask, catch 20%, 30% of accessibility issues. The other 70 to 80% of accessibility issues have to be found manually by hand, by a human being instead of scanning.
Now, if you’re a scanning tool vendor, if you have your own scanning tool, then your number is going to be probably a lot higher because you’re a marketing guy, and saying, “We can actually catch 50% or 60%.” I generally have not found any scanning tool that can do that because there’s a lot of subjectivity. Something that should be a heading, scanning tool can’t really look at well, maybe it could to see if the font size of something is bigger than the surrounding text. Then it might go, “Well, it’s bigger font. We think maybe it’s a heading.” A scanning tool might be able to do something like that.
Anyway, the reason I brought this up is because they have the section about pages that have aria attributes on it. Aria attributes are just part of HTML. It’s just additional information you could add to an HTML tag to give a hint to screen reading software. They tested 1 million homepages. They found 60 million aria attributes were used, which 60 million divided by 1 million is 60 aria attributes on average on the homepage. That’s a lot. Aria-label equals this, aria expanded. It could be roll equals menu, roll equals button. I don’t think they include tab index. Oh, it says down here. They do it. They do actually include tab indexes in aria, even though it’s been around a lot longer in aria.
Excuse me. The key thing here is that it says that homepages with aria generally have 70% more errors than pages without aria, because it’s being used incorrectly. Typically, aria is great and fantastic. It helps a lot of things if you use it the right way, but if you’re not sure how it should be used– I’m kidding on my soapbox again. Generally, most aria attributes are pretty simple and easy to understand. This aria label overrides all the texts. Well, it’s documented that it does that, so why would you do that and not test it and then make it public on Eventbrite? I don’t have any sympathy for those developers.
I just wanted to point out that using Aria can be good. Well, can be good if you use it the right way. It will be good if you use it the right way. It can be bad if you use it the wrong way. While I’m on this page, I just want to do a real quick side thing. If I scroll down a little bit, they have a list of categories, which is really cool. On average, there are about 50 errors, 50 accessibility issues on every homepage on average. They have this table here of pages that do better than average. They have less than 50. Then pages that do worse, they have more than 50.
It’s interesting that the top category of website is law government and politics, because generally there are laws governing law or .gov websites to say they have to be accessible. Because there are requirements to make them accessible, they have still not great. There are still 30 issues, 30 errors on the homepage compared to 50. It’s better than 50, but it’s still not that great.
Social media has come a long way, whether you’re on LinkedIn or Pinterest or whatever. Those have come a long way and have improved their accessibility. Science and technology. That’s great, and those are, are good as well. Education, we would hope that education would be very, very high. A lot of times .edu websites, if they receive government funding, then they have to adhere to some government accessibility regulations. It’s forced onto them. I guess, religion, not doing so good there. It’s right about average at 52. Home and garden, I don’t know, travel pets. Oh man. Pet websites are worse than average.
Just an interesting thing to look at, shopping. Shopping something so common to do, but it has tons and tons of issues, whereas food and drink, which is really shopping as well. Specifically, I don’t know why food and drink is separate from shopping, but it does a lot better than generic shopping. Some of you may have noticed there’s actually adult content, which is horribly inaccessible, which maybe is a good thing.
One of the companies I worked for, we had a client that had- I don’t know who it was. They had adult content, and they wanted us to test their website. I said, “No, thank you.” The salespeople, the financial guys people, they they wanted the income from the customer. I said, “I’m not going to ask any of my accessibility testers to test this. Sorry, I draw the line there. Maybe yell at me if you want to, but we’re not going to check that images have alt text or that headings are correct or anything like that.” It’s nice to see there’s almost a hundred issues on per page. It’s 80% worse than the average. Anyway, side topic. That was my squirrel. I was trying to focus on tabbing and stuff.
If you look at the domain name .gov, again, because of requirements, .edu, that’s great. Now .edu, you can see there’s 13,000, almost 14,000 homepages. If we went back up to education, there were 58,000 pages. I’m not sure. Category-wise, I guess there are some non-.edu. They’re not university pages. They fall under education. I’m not sure how all those things work, but government EDU, Canada. Way to go. Canada’s way up there, maybe because of AODA or who knows what?
The UK is up there, and then down on the bottom, China and Russia. Sorry, they’re not focusing on accessibility, I guess. Italy is not too much, further behind than Poland and India. It’s a bad step. .com is right there in the middle 50%.
>> Hey, Glen. Sorry to interrupt. I just wanted to make sure you knew that we were at 8:15 in case you wanted to do more like working down this page.
>> All right. I think we heard- let me bring this backup. We’re on the next meeting.
>> Next meeting, Crown Point–
>> Remember this time.
>> List with five items, garden tours.
>> If we look at the menu, home, post, contact us, next meeting, garden tours, we’re on the next meeting page right now because it’s white. The menu is white, and it’s underlined. As a visual user, I can tell which page I’m on, because I can see that one’s highlighted compared to all the other ones. Well, what about a screen reader user? Are they going to know that that’s the currently selected menu item? Well, let’s double-check.
>> List with five items. Garden Tours. The pipeline pollinator paradise, visited link.
>> That’s a really long link, so it’s hard to hear all that. If I tab to next meeting.
>> Next meeting, visited link, current page.
>> Current page, so there’s a little bit of extra information at the end. If I go to contact us.
>> Contact US visited link. Post/News visited link.
>> All the other links just say the link name, and then they say whether it’s visited or not, and then link, but next meeting also has a current page.
>> Next meeting, visited link current page.
>> That’s fantastic. That means somebody is using aria-current.
>> Menu.
>> We look at the code. There’s an anchor tag, aria-current equals page. An aria-current can have several different values. It can be true or false. It can be a step in a process. It could be a lot of different things. The main point was that somebody is using aria and aria attributes correctly. It makes it sound better. This is something I would look for as a sighted user. As a sighted tester, I see that one of the menu items looks different than the others, but let me listen to it and see if it actually sounds different, if there’s something else about it. Let’s go back to the homepage because there’s one other thing I wanted to show you.
Let me just tab through all these links. [crosstalk] search. I’m trying to get to the map below the Crown Point Garden Clubs. Let me tab a couple more times.
>> Search button. Figure data equal 4M131M73M73M610X882C994 link.
>> That’s my link. Figure says data equals 4M13 blah, blah, blah, blah, blah. That’s my link name. I mentioned this earlier, we have an image that is inside of the link. The link itself doesn’t have any text to display, and the image doesn’t have any alternative text. Even though I listed the images later in my list of things to look for, this is actually a really, really important issue to fix because the user won’t know what this is. It’s trying to read the URL.
Different screen readers and different browsers will do different things. It might say blank if it can’t find anything or it might try to read the URL, because it’s trying to be helpful and let you know that in this case, the URL is actually just a bunch of numbers and letters and special characters. It doesn’t really help me in that case. Let’s have a few more slides here. We’ll probably jump back to that page.
We talked about tabbing focus indicators with a screen reader. We did code inspection because code inspection I do all throughout my testing process. It’s not like I do all the tabbing once and then I go, “Oh, let me go do code inspection now and read all the code.” I don’t do that. I actually use code inspection as a supplemental augment to my testing of all of the different things I do.
Now, page structure, this is really important. The page structure, 1.3.1 is one of the WCAG requirements. There’s probably a handful, three or four top failures, and this is one of them. This basically says, and I have a picture of a duck or a duckling maybe on the page, because I like to think of this as 1.3.1 info and relationship as the duck test, which is, if you haven’t heard of that, if it looks like a duck, swims like a duck, it quacks like a duck, then it probably is a duck. Well, if something looks like a heading, then it should be a heading. If something looks like a list, then it should be a list. That’s really all this is saying.
When I look at the page, that could be here. Here’s some big text. The word home is much bigger than the stuff in front of it. This is where I typically do a combination code inspection or use a bookmarklet. Right now let me just do inspect on the home. It’s an H1 tag. Here’s one of the handfuls of HTML elements that you should probably learn. H1 is the heading level one. That looks good. Scroll down. Here’s meetings, our mission, our activities. Let me just take a peek at it. Meetings is really just a paragraph text, and it has strong around it to make it bold. The screen reader user will not be able to navigate this page by headings using the H key.
That’s one way you can figure out and test for headings is just using the H key, or there’s what I call bookmarklets. Not what I call them. They are called bookmarklets. I think I actually have a page on how to test, and I’ll show you that in a second. Bookmarklets are really just a little piece of JavaScript code that runs on the page. In this case here, I have one called headings, and if I double-click on it, it will go through the page and highlight all my headings on the page. Put a box around [sound cut] and put an H1 in [sound cut] meetings and around [inaudible] because they are not headings.
This is one way for me to see, well, it looks like a duck, it looks like a heading, but it’s not a heading. Well, that’s a failure, pretty easy to test, and pretty easy to see. Pop back over here. The other screenshots, I had Home and Meetings on the left screenshot. On the right screenshot is a list or looks like a list. It has numbered things on it. First thing you do is install. The second thing you do is migrate. The third thing you do is rank. Well, and as a sighted user, I can see very easily there’s a block of stuff on the left. That’s my first step. The block of stuff in the middle is my second step.
As a screen reader user this really should be coded up as a list because it looks like a list. It looks like a duck. It should be a duck, but it’s not in this particular case. Super easy to fix but this is a case where you’re looking at the page, you’re going, “Well, here’s some numbered items.” Usually, numbers are a list. Let me see if it’s coded as a list. Code inspect, or use a screen reader and see if it says list when it comes across it, and it doesn’t.
I mentioned in the test for page structure, you can use code inspection. We just inspected the H element. Bookmarklet, we use that to highlight the heading or use a screen reader. I can navigate using the H key, and it’ll jump to all the headings. If there’s no heading, then it won’t find it, and that’s just another way to test it. I probably use in this case, maybe bookmarklets to highlight all the headings to see what’s marked as a heading. As far as bookmarklets, if you do a Google search on accessibility bookmarklets, you’ll find a whole bunch of them. Again, they’re just JavaScript pages, and we’re not going to run out of time. I’d love to talk about them more, but won’t have time for that.
We’re almost at the end of the slides, which is a good thing. Five minutes left. Then I mentioned colors. A scanning tool, you can use a scanning tool to catch colors, but they can often be tricked or faked out by CSS. Depending on how you code your CSS, a color contrast issue might not be flagged by a scanning tool, in which case you’re missing an issue or the opposite. It might flag an issue as a color contrast issue. When you’re looking at it, visually, there’s no problem, and it’s just the way the CSS was coded. Scanning tools are okay, but they can be fooled. Wave at WebAIM, we talked about WebAIM earlier. Axe is another. These are both plugins for your browser.
I typically do just manual checking, but how do I know what colors to check? That comes over time. If I go back to Crown Point, for me, when this page first came up, red flag went off with a light gray text on a black background. I’m like, “I don’t know if that’s got enough contrast.” Then same thing with the- I don’t know what you would call that color. It’s kind of a light brown or a dark yellow. That link text on a yellow background, to me, again, would flag in my head that that might not be good. I scroll through it, but there was a couple other ones.
With the color contrast one of the issues here, there’s a color contrast analyzer tool, and I mentioned this on the- I’m going to bring it up first, then I’ll pop over to this slide. If you do a search on color– Oh, well, technically, I misspelled it. Color contrast analyzer has the British or maybe Canadian spelling has a “u” in color. Although if you search for color, C-O-L-O-R contrast analyzer, you’ll still find it. It’s a tool from DQ, I think. Maybe it’s TPGI, sorry. It’s one of those two.
I have two screenshots here. The one on the right is what it currently looks like, and it’s their newer- it’s probably five maybe older years old. I didn’t like it. I didn’t get anything out of their new version. I still use the older version, which is my other screenshot on the left, which looks like an old-school Windows dialog type thing. Problem was when the new one came out, they initially had broken the keyboard shortcut for capturing foreground and background colors. I’m a keyboard person, and I was thinking an accessibility tool that broke keyboard support is not a good thing. I didn’t like the new version, so I always stick with the old version.
I know we’re getting low on time, but if we just want to look real quick, I bump up the font. One of the problems with color contrast droppers is that when you have a font, sometimes it could be hard to pick the right color in the font. Let me bump this up really big. Let’s look at the word east in East Hamilton. I use my color dropper, and I want to go pick that gray. There’s some anti-aliasing going on. I don’t know if you can see on the left edge of the E, there’s a bluish color because it’s going between the dark gray background to light gray text, and it picks a color in between which, I guess, is blue. Even on the horizontal lines and the E, there’s like a dark gray on the top of one. There’s like a lighter gray.
There’s an anti-aliasing, and you don’t want to pick that color. If I were to pick that, it’s a bluish color, and there’s no way to bump the font up of this dialog, sorry. Oh, I didn’t choose the background. Background says white. Background is actually this darker gray. 2.9 to 1 actually fails contrast color, but I didn’t actually choose the right color. If you look for letters that are vertical or horizontal and pick somewhere in the middle, you can usually get the right color. All right. Now it’s 8e8e8e, which is a form of gray. Now it’s 5.1. That passes. Great.
Just be careful when you’re using a color dropper that you don’t pick an anti-aliasing. Usually, I go to the CSS. I’ll do an inspect, look at the CSS, see what color really is, and use that color in my analyzer tool. Then this yellow, if we wanted to check it real quick, get a vertical line like the letter T. Background color is yellow. 2.4 to 1, again that fails contrast. We’ve talked about images already. Code inspection, bookmarklets, scanning tools. It’s not the last one to do, but it is there.
Low-hanging fruit, this is simple stuff you can test. Make sure the page has a title. Look at the browser tab. For this one here, if I hover over the tab, it says ground point garden club growing in East Hamilton. It has a page title, great. Check, that one’s done. Make sure our language is specified for the page, and that’s in the very first HTML page. If I bring up code inspector, go to the very top, very first line HTML Lang for language equals en-CA. I guess that’s Canadian English instead of just English. I don’t know if that means it allows it to have a and take off or what some different versions of Canadian. Sorry.
I saw somebody from Hamilton earlier, and they said this is in Hamilton. That’s what? Just outside Southwest of Toronto, I think. I know there’s an accessibility Hamilton group alley Y, alley ham I think. Anyway, but that was the last thing. Oh, keyboard shortcuts. I didn’t really go into this much or at all. As I mentioned, I have my code inspector. There’s some cool sheet keyboard shortcuts that let me dock windows left and right, which I put on the slides which you can get a copy of just so you can play around with these, mouse pointer location. There’s a really cool feature. I don’t know if you knew about it.
If I don’t know where my mouse pointer is, sometimes I lose it on whatever document I’m on. If I hit the control key, I get concentric circles around where my mouse would be. Of course, the mouse disappears on PowerPoint. I’m back over on the webpage. For whatever reason, I couldn’t see my mouse because it’s a vertical beam on the letter W between between. If I can’t see that, if I look away and then look back, I can’t tell, but if I hit had control, now I get these concentric circles around my mouse. That’s really cool feature. I don’t know how you would do it on a Mac, but on a PC, and this is the last thing, and then we’ll stop.
If I bring up mouse settings and go to additional mouse options under pointer options and you can’t see that, if I go bring up magnifier, another Windows tool, magnifier hopefully you can see that. I went to the pointer options and down at the very bottom of the dialog is show location of pointer when I press the control key. It’s probably something hardly anybody knows about, but it’s a super awesome feature to turn on. In case you lose your mouse, for mouse [inaudible] mouse users. Again, where’s my mouse? I don’t. Oh, there it’s, concentric circles. All right, sorry. I get carried away and talk a lot and don’t pause for questions. I know we’re out of time now, but I am willing to hang around and answer any questions.
>> We do have our captioner for 15 extra minutes. I book them for 15 extra minutes just in case so we have buffer. There was a question that was put in early by Miguel, that I wanted to circle back to. Miguel was asking how piggy are you with keyboard patterns e.g. using the arrow keys additionally to the tab keys for components like tab groups, accordions, sub-menus, and navigation. Do you expect that to work? So when you go in a drop-down, would you want to see that you can use the up-down arrow keys to navigate in addition to tab? If it doesn’t work, would you call that a problem?
>> Excellent question. It’s more of a usability. It’d be fantastic if you look at- let me just bring this up, there’s what’s called the authoring practice, which is basically a design pattern library. You mentioned the tab. I think you mentioned accordions as well, but let’s go to the tab pattern which has a little icon of tabs like tabs on a file folder. It has a list of keyboard interactions that you should implement, which is best for the user because now when they go to your page which has tabs and they go to somebody else’s page which has tabs and some other commercial site which has tabs, that they’re used to the pattern of how to navigate with the keyboard. It’s always best to follow these instructions.
Tab key does a certain thing. Left arrow does a certain key, right arrow, space or enter to home or end key. There’s all these different recommendations, strong recommendations on what to do for keyboard support. If you want to get technical and look at the actual guideline, so 2.1.1 is keyboard support. All this says is that all functionality is operable through the keyboard period. It doesn’t say you have to use the right keys. It doesn’t say that you really should use the arrow keys to navigate through the different tabs on a tab navigator.
If you don’t, does it fail WCAG? Technically no, because maybe somebody implemented the tab. That’s poor name. The tab key on my keyboard to navigate between the different tabs of the tab navigator. Okay, I can get to it through the keyboard. That’s all that’s required or maybe even worse, maybe they implemented it with maybe the number keys. Maybe 1, 2, 3, 4 goes to the different tabs. That is a keyboard functionality. It works with a keyboard. It passes WCAG. It’s just from a usability or consistency perspective.
I would not fail that, but when I do accessibility testings, I have severity for issues. I only use high and medium for my severities that are true WCAG failures, and I’ll mark an issue as a low priority if it’s more of a usability issue. They should fix it. Legally you might not have to cause it’s not a technical WCAG failure, but it is something that you should do. That’s a great, great question. Thank you.
>> I think we do the same thing. I like to flag best practices, but it was interesting if you listened to Nick’s talk last time. He’s like accessibility testers should not, at least in how he’s training the screen reader testers. He’s like we flag on WCAG. We don’t flag on other things. I think that’s interesting.
>> It’s very subjective. I might work for one client that says, “Yes, tell me everything. I want to know usability stuff.” Other people are very strict and say, “No, absolutely. We don’t care about–” Well, I won’t say we don’t care. “We don’t want usability issues reported in our accessibility testing.” That’s unfortunate because usability and accessibility are not separate things. They’re not exactly the same either. There’s a ton of overlap, and you really should not ignore usability because you’re focused so much on which criterion do I fail or pass?
>> I think I’ve seen, actually, there’s examples of websites that were intentionally made unusable or “inaccessible”, but don’t actually have WCAG failures. I can’t remember what that was. It’s like there’s one that’s like the least accessible website with a 100% Lighthouse score for accessibility.
>> That’s what it is. I was going to–
>> Deneb had a question. This is going back to when you add the focus. Do you ever use colon not, parentheses focus dash visible trick, or do you find that people don’t mind seeing that outline on click, so when you’re actually building the website?
>> Again, that’s more of a design. That’s a design thing. Personally, I don’t mind seeing outlines around stuff, even when I click on them. It’s a reinforcing thing that I clicked on the right thing. I don’t mind it. There are some designers that really despise any kind of outline or ring around stuff. It’s a very subjective question answer. For me, it doesn’t bother me. I don’t use the not.
>> In our practice, the default is that we just do on focus, not like on– What is it? I don’t know. It’s there even on click, but we do sometimes remove it when we get a lot of pushback from clients. It’s only there when it’s focused on or interacted with a keyboard focus versus a click. I don’t like doing it. I tried to talk clients out of it, but sometimes you just decide to pick your battles.
>> Right. Sure.
>> That was the last question that I think we had in the Q&A. I appreciate so much everything that you have shared with us today and taking the extra time to be really detailed. It’s been great, Glen, as always. If anyone wanted to follow up with you, what’s the best way for them to get ahold of you?
>> That’s my first slide. If you want to get in touch with me, if you had questions, my email address is Glen.Walker@gmail.com. Glen is spelled with one N. If you spell it with two Ns, I don’t know who will get it. Somebody will get it probably, but not me, G-L-E-N.walker, W-A-L-K-E-R @gmail.com. If you have questions or any follow-ups to hear, or you can post on the meetup comment page as well.
If you want to indulge me for a second, there was actually one really cool thing I wanted to show, that this was on the SEO press page just based on language, because this is a really cool feature of screen readers, if anybody’s hanging around. They have this drop-down on this page here. Let me bump it up a little bit. It says English, and it has a drop-down. If I select it, it says Spanish and French, which first of all, from a design UX perspective, I think those words should be in their native language. I think it should say Español and Français. I don’t have the accents to pronounce this properly.
Instead of having the language written in English, it says Spanish and French, have it in the native language. Secondly, if you do use the native language, make sure you use the language attribute in HTML, because that can change the voice or that can change your screen reader voice to a different dialect and a different accent, and it’s really, really cool. Let me just show you real quick. Sorry. I know we’re out of time, but I need to get– Let’s see.
>> We have about four minutes with our captioner, and then we’ll probably need to be done.
>> Got you. I do this just because I want to get the actual ñ, Español. Instead of Spanish, do Español. Instead of French, do Français. Just easier to get that code. Instead of French, Français. Now, if I only do that, that doesn’t help me with the screen reader.
>> NVDA speech viewer. Meeting control CO press- English button expanded.
>> Right now if I tab.
>> English list with two items, Español link. Français link.
>> It’s reading those as if they were English words, which is not great. But if I use the language attribute–
>> English button expanded.
>> Take a second.
>> Speech mode off.
>> If I go over to Español and say Lang equals Spanish, yes. If I go to French language equals FR or French. Now, if I go back to my page.
>> Speech mode. See if English button collapsed, expanded.
>> Now, if I tab to it?
>> English list with two items Español link. Français link.
>> Now we’re getting a different dialect and accent because I use the language property in HTML. It is affecting the screen reader. I think it’s just such a cool option. That’s why I really wanted to show this. We’re getting a different accent. It’s really cool.
>> The other thing that it’ll do too, if you use something with Asian characters, so we built a website where they had some content in Korean, is it actually impacts the styles of those characters. They look for like brushstroke when you give them a lang attribute of whatever it was for Korean.
>> Interesting.
>> It is very interesting. I think this is a good point too, on usability versus accessibility. Because that’s not an accessibility failure to have them in that language, but it would certainly be easier for someone who maybe needs to switch to that language to see the language title in that language.
>> Yes and no. Originally, when it had that language written in French, when it said Spanish or French, so it’s written in English, that is not an accessibility issue. However, if they said Español or Français, and they did not specify the lang attribute, it would be an accessibility issue. You are correct. Originally, it is not.
>> Well, thank you so much again. We really appreciate it. Thank you everyone for coming and sticking around.
