
Thanks to Our Sponsor
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.
Read the Transcript
>> AMBER: Yes, I’m going to really quickly do a few introductions and housekeeping items and then I will hand it over to Raghavendra to give our presentation. If you have not been before, we have a Facebook group that you can join to connect between Meetups.
You can find it if you search WordPress Accessibility on Facebook. Otherwise, the URL is facebook.com/groups/wordpress.accessibility. If you are interested in seeing other upcoming meetups or if you want to get the recording of this meetup, that’s a question that we always get and I can guarantee you it’ll show up in the chat about halfway through this.
“Is this being recorded?” Yes, this is being recorded. It takes us about two weeks to get a corrected transcript and then we’ll release the video with the transcript. So you can find all of the past Meetup recordings and see what future Meetup topics are going to be.
If you go to equalizedigital.com/meetup, that will redirect you to a much longer URL, but that’s the quick way to get there.
We also highly recommend joining our email list. You can go to equalizedigital.com/focus-state or if we’ve done things right, you’ll land on the thank you page when you leave the webinar, where you can join the email list.
We send out a newsletter about twice a month and then we send out other reminders about events right before them or as they get scheduled. So that’s the best way to see what events are coming and also get news and announcements and the links to the recordings are shared via the newsletter that we send out.
We are seeking sponsors for this meetup. The evening meetup right now currently doesn’t have a sponsor and we do rely on sponsors to help us cover the cost of live captions. So if anyone is interested in sponsoring, please let us know. You can reach out to myself and Paula, our co-organizer, who you’re going to see in the chat and who is helping run things and doing all the magic behind the scenes, if you email us at meetup@equalizedigital.com.
So who are we? I’m Amber Hines. I am the CEO of Equalized Digital. We’re a certified B corporation and a WordPress VIP agency partner. We have a plugin for WordPress websites called Accessibility Checker that can help you to find the issues that are able to be found with an automated checker in your WordPress website. There’s a free version on Wordpress.org.
And we are the organizer of the meet-up. We also are the sponsor for the live captions tonight because we don’t have a separate sponsor. You can learn more about us on our website. We’re on Twitter. That’s probably where I’m the most active as far as social media goes – on Twitter and we’re just @equalizedigital on Twitter.
And then we do want to thank Empire Caption Solutions. Empire Caption Solutions has donated their services to us, post-event. They take our recorded video and create that corrected captions file and transcript file and we very much appreciate them for donating that service to the meetup. In addition to video transcription and podcast transcription, they also offer ASL services and audio description services as well. So we highly recommend checking them out. Their website is empirecaptions.com. And you can find them on Twitter if you want to tweet them a thank you for donating their services to the WordPress Accessibility Meetup at @Empirecaption.
There are three upcoming events that I want to share with you all. The first one is later this week. It is not part of the meet-up, I just have to make that clear because it is a paid event, because we are paying this speaker and we didn’t find a sponsor. So we’re trying to cover our costs with live captions as well. But it is a two-hour workshop on how to use Voiceover for accessibility testing. So Voiceover is a screen reader that works specifically for Mac computers. So if you’re a Mac user, you have Voiceover on your computer already.
Nick Corbett from the Carol Center for the Blind will be leading that webinar and he’ll be talking you through all of the recommended settings for Voiceover for doing accessibility testing and then doing some testing and talking about how to test with Voiceover.
That is this Thursday, February 23, from 10:00 am to 12:00 pm US central time. As I mentioned, it is a paid webinar. However, we really want to make it work for everyone, so if the price doesn’t work for you, please reach out to us and we’ll see what we can do to make that work.
And then the next two events are meetups and I will be speaking on Thursday, March 2. I’ll be sharing a talk that a lot of people have asked about, which is how to grow recurring revenue with accessibility monitoring and remediation plans.
So I’ll be sharing how we approach getting people onto auditing and fixing over time so that we have recurring revenue and they don’t have to make a big cash outlay for remediation all at once. And then on Monday, March 20, in this same time slot, Alex Stine will be back with me and we will be doing a live audit of the paid memberships pro plugin and giving feedback to their team. So that’s a great meetup to tune into as well.
I am very excited. I’m going to add a spotlight here so Raghavendra is visible to everyone. Again, I’m very excited to introduce Raghavendra to everyone. Raghavendra is a digital transformation specialist working with small and large enterprises in the areas of digital accessibility and digital marketing. He has an accessibility blog at Digital A11y, but it’s A11y.com and he also founded HelloA11y.com, which is a community of accessibility professionals, developers, and enthusiasts.
I have gotten to know Raghavendra through WordPress Accessibility Day, which he helped to organize last year, and he helped a lot with the auditing there. And then, he has come and consulted for our company and has helped us with some user testing and some accessibility testing for some of our clients.
So I can’t speak highly enough about his skills and I’m very excited that he was willing to come and speak to meet up and share what his process is for finding and documenting accessibility issues.
So, Raghavendra, I’m going to stop sharing my screen and I’m going to let you take over sharing. For everyone that is watching, there is a Q and A box in zoom. If you can try to put questions into the Q and A box, that is the easiest way for me to keep track of them because the chat can get a little bit noisy. We will try and ask questions. Raghavendra, do you kind of want questions as they come in? Is that what you’re thinking makes the most sense, or do you want me to hold them towards the end? Do you have a preference?
>> RAGHAVENDRA: I missed that, Amber, the screen reader was speaking it.
>> AMBER: Do you want me to chime in when questions come in or do you want to hold them more toward the end?
>> RAGHAVENDRA: If it is relevant to whatever topic that we’re going through, you can chime in and stop, or we can take it at the end also.
>> AMBER: OK, awesome. All right, so, everyone, I’m happy to hand it over to Raghavendra and then we can dive in.
[Screen reader]
>> RAGHAVENDRA: Can you see my screen?
>> AMBER: Yes. We can. It might be helpful to minimize the video in zoom. I don’t know if you’re able to do that.
>> RAGHAVENDRA: I don’t know how to do it.
[Screen reader]
I don’t know how to do it.
>> AMBER: OK, not a problem. I’m just going to turn my video off, but I’ll chime in if I…
[Screen reader]
>> RAGHAVENDRA: Hi, everyone. Good morning, good evening, good afternoon, wherever you are in any part of the world. My name is Raghva. I’m the founder of DigitalA11y.com and HelloA11y.com, a community of accessibility professionals. I’m based out of India. I worked with IBM and Deque systems in the past, and I do a lot of consulting work now.
I’ve been using WordPress for more than 14 years and I’m late blind. I became blind about nine years back due to a genetical disorder. Today, I’ll live-test a website and I’ll also share the process of how I’m going to record accessibility bugs in the Google Sheets and how I identify bugs.
And I’ll also be sharing some of the tools that I’ll be showcasing and how I built my own reference documents and how I write my own code to see if there is any problem with either the screen reader or browser, just quickly to test.
[Screen Reader]
So we have Spotlight and…
[Screen Reader]
OK. Quickly, for everyone, is the Nvda speed sufficient enough or do I need to slow it down?
>> AMBER: I think that speed is OK. I just had a thought. I could remote into your computer real quick and minimize a few things. Would you be OK with me doing that?
>> RAGHAVENDRA: Yes.
>> AMBER: OK.
[Screen Reader]
I wonder if I can actually click on the zoom stuff though.
No, it’s in front of it.
[Screen Reader]
>> RAGHAVENDRA: You see that zoom floating bar?
>> AMBER: Yes. So I see the Zoom floating bar. There’s also a banner that a participant has enabled closed captions that I was going to try and close that’s in front of the website you’re sharing.
>> RAGHAVENDRA: Play it now. You should be able to close it now.
>> AMBER: No. I think that it’s not allowing me to interact with zoom.
[Screen Reader]
I stopped the remote control, but are you able to get into the zoom toolbar?
[Screen Reader]
>> RAGHAVENDRA: No.
>> AMBER: Someone posted this in the chat box which might be useful. “Are you able to list all of the buttons that are available in zoom?”
[Screen Reader]
>> RAGHAVENDRA: Yes, I can. So the shortcut keys will not work.
>> AMBER: We can just go with it as it is. I don’t think it’s that big of a deal.
[Screen Reader]
>> RAGHAVENDRA: I think it’s Alt Ctrl Shift H or M or something.
>> AMBER: Someone said Alt + U will hide the participants. Well, but it’s the video.
Let’s see. Glenn suggested, “Will Insert + f7 show all the buttons and zoom?”
[Screen Reader]
>> RAGHAVENDRA: Yes, it’s not working.
[Screen Reader]
>> AMBER: Oh, there you go. Close that button.
[Screen Share]
>> RAGHAVENDRA: OK.
[Screen Reader]
>> AMBER: Close that. Not that one. The tab one.
>> RAGHAVENDRA: This one?
>> AMBER: Yes. Close that.
[Screen Reader]
>> RAGHAVENDRA: Is it closed?
>> AMBER: Yes. So that big banner went away. There’s one more, which is the video, but it’s probably fine.
[Screen Reader]
OK. I think that is better.
>> RAGHAVENDRA: This is good?
>> AMBER: Yes. I mean, you could potentially actually minimize it. I think it might be a Shift Tab.
>> RAGHAVENDRA: I think hide.
>> AMBER: Yes, hide.
>> RAGHAVENDRA: OK, done.
>> AMBER: Awesome. Yes. Looks good. Thank you, Raghavendra.
[Screen Reader]
>> RAGHAVENDRA: It’s Insert F6, for people who want to know. And I found it by chance.
[Screen Reader]
Let me drink some water. So when I reach any page, first I check the page title to see on which page I am.
[Screen Reader]
So I’m on support spotlight. I’m on the support page. That gave me a hint. I use the keystroke Insert + T. And what I do is I don’t generally use Insert F7 to see the list of headings and all. Generally, if I’m running very fast with my screen reader, I do something called discovery. So what I do is I see if there are tables.
[Screen Reader]
OK. If any radio buttons.
[Screen Reader]
So I use T. These are single shortcuts. I’m not using any NVDA shortcut keys like Insert. I’m just pressing T and it says no table.
[Screen Reader]
If I press R, no radio buttons. If I press C…
[Screen Reader]
So there’s a combo box here. When I press C, it went there. So I’m going to go to the top of the page once more.
[Screen Reader]
And I’ll press X to see if there are any checkboxes there.
[Screen Reader]
There’s a checkbox. So let’s see if there are any buttons.
[Screen Reader]
OK, there are buttons, multiple buttons I see. So what I did is I just used the basic shortcut keys of NVDA, like B for buttons, T for tables, X for checkboxes, C for combo box, and R for radio buttons. Once I’m done, I want to know how many links are on the page.
[Screen Reader]
So I did Insert + F7 and it gave me the number of links that are there on the page. So this gives me an overview of how long the page is, like how many tabs we can do within the links and similarly…
[Screen Reader]
You see form fields there: 22. So what I do in my brain is I calculate the number of links form fields, and that gives me the number of tabs I have to use. So if you have to tap through 100 elements, it’s going to take a lot of time. So what I do is when I do power testing – what I call this is power testing or a quick micro audit – I generally browse through the page using the down arrow quickly. For this, I generally use Jos [Phonetic] because I was trained in Jos when I was transitioning from being a low-vision person to a blind person 15 years back. And Jos speed, I can catch up much better than NVDA.
What I’ll do is I’ll quickly see how many heading…
[Screen Reader]
I’m just pressing H to see how many heading structures are there.
[Screen Reader]
They have only a few headings. By looking at the heading structure, I understood what each of the headings will contain – the content of that heading. So when I reach that particular heading and evaluate the content, it becomes easy for me.
I also want to see if there are any list items.
[Screen Reader]
The navigation has a list of six.
[Screen Reader]
A couple of list items. So once I have run through all these checklists then I’ll run Axe.
[Screen Reader]
So what I did is I pressed F12 and I have Axe DevTools extension installed on my Chrome.
[Screen Reader]
I went to DevTools. So if you go to these elements… normally for me, Axe DevTools is the last step.
[Screen Reader]
I just press from elements, left arrow. So that is the last step. So it opens Axe dev Tools for me. So you have to install and enable the extension so you can see this in your Axe Dev Tools.
[Screen Reader]
So if you see, I’m just jumping from button to button here. Scan all of my pages. So as an accessibility specialist, what happens is all this becomes muscle memory for me. Even though I’m not doing accessibility, let’s just assume that I’m browsing a web page.
So once I’m familiar with some tool or a web page, it becomes so easy to navigate or go to that website or tool. And without pressing Tab, I can just jump to the target element that I want to activate.
[Screen Reader]
We have 33 issues. So many elements below this. What I’m doing is that I’m just jumping to the issues that I want to see.
>> AMBER: Raghavendra.
>> RAGHAVENDRA: Yes.
>> AMBER: Would you be able to change the way your DevTools is docked so that it’s on the side rather than the bottom? Are you familiar with how to do that? Only because right now we can’t actually see what’s in the DevTools panel.
>> RAGHAVENDRA: OK, if you can guide me, I can do it. I think there’s a shortcut to make it…
>> AMBER: Probably there’s a keyboard… I’m not 100% sure if I know how to do that. But there’s a setting.
[Screen Reader]
Sorry, it’s not actually the settings. I’m trying to see if I can figure out what this button is called. It’s the tab sub after the settings button.
[Screen Reader]
>> RAGHAVENDRA: Should I undock into a separate window altogether?
>> AMBER: If you want to go back and forth. Otherwise, if you were to just put it on either the left or the right.
[Screen Reader]
>> RAGHAVENDRA: OK.
[Screen Reader]
Is this good?
>> AMBER: Yes.
[Screen Reader]
>> RAGHAVENDRA: So we see the total issues are 33. So what I’m going to do is once you get familiar with Axe devTools, if you just tab, there are a lot of elements here.
[Screen Reader]
So what I do is just press X
[Screen Reader]
But there’s a best practice checkbox. I don’t scan for best practices. I only look for failures. WCAG Failures. A lot of my clients want only WCAG failures. That’s one of the reasons I avoid best practices. So what I do is I press B here.
[Screen Reader]
This is something that I do not understand. Again, I’m pressing H here to move to the heading issue region.
[Screen Reader]
So I’m just pressing down arrow to see. If you see, element location is not very helpful for me. But element source. Where is the source?
[Screen Reader]
This is the source that I generally work with developers. So by looking at this, I also understood the WordPress site is built with Elementor which is a page builder.
[Screen Reader]
So it did not say exactly what to fix here. But we understood there are some nested Aria issues over there that need fixing. I understood the Aria issues, there are no form field-related issues, there are no empty lines, and there are no buttons that are not labeled.
So if you see, the major issues are related to nesting, color contrast, and…
[Screen Reader]
OK, there are elements that do not have children.
[Screen Reader]
So the role tables do not seem to have role tab children. So we need to inspect this. So whatever Axe gives me, gives me an overview of the issue, but it’s not giving me exactly what is the problem here.
So I need to manually see if this is a valid issue. Again, for most of the Axe issues, there are no false positives. There’s definitely some problem with the code here. So we’ll inspect the code when we see it manually.
And I’m going to press F12 to undock this and close.
[Screen Reader]
Any questions? Amber, any questions?
>> AMBER: One person was asking, “Are you using the paid version of Axe DevTools or the free version?”
>> RAGHAVENDRA: I’m using the free version.
>> AMBER: OK. Someone else asked, “When you’re using the letter shortcut to see all of the different items that you had, like headings, buttons, form fields, those things, would it help if those lists had accessible names?”
>> RAGHAVENDRA: Yes, they all should have. Like when we have a heading, it should be…
[Screen Reader]
So it says support heading level one. So that is the name. So there are two things: when what we see is the label, what the screen reader outputs is the accessible name.
So generally, like if you see…
[Screen Reader]
If the original review can be an icon, the Aria label that is provided can be the original review. So there’s a difference between the accessible label and the accessible name.
According to W3C, what you see is the label, but what assisted technologies output is the accessible name.
>> AMBER: Thanks. Those are the only questions so far.
>> RAGHAVENDRA: OK. So once I finish all this and see if there are any accessibility issues… I already ran a couple of tools and all that. So what I generally do is refresh the page.
[Screen Reader]
So I want to test if the skip to content link is broken or not.
[Screen Reader]
OK, it went and it read the entire paragraph, so it identified the main region.
[Screen Reader]
What I did is when I pressed skip to main content, it went to the skip region, wherever the heading is provided, and it started reading and I stopped it from reading the entire paragraph. But when I do Insert Tab… This is a keystroke everyone should remember when you’re using NVDA. Press Insert + Tab.
[Screen Reader]
If you see, it says, “Document Focus Read Only.” So in Focus jump, what happens is it goes to that particular div region and it is over there. So you know that to check the current focus, if you’re on any link, or any form control, when you press Insert Tab, it will read the current element. I’ll demonstrate it for you again.
[Screen Reader]
I tapped this element now, but I’m pressing Insert Tab now.
[Screen Reader]
So it reads the current focus. So this comes in very handy when you have forms, when you have focus updates. So let’s just say there’s a model dialogue that opens on the page, or there’s an auto pop-up email sign-up form that opens and you get disoriented, as a screen reader user, you press Insert Tab to see where your current focus is. And that can give you an idea of what happened. So I’m going to see the navigation because there seems to be a submenu.
[Screen Reader]
So it says features collapsed.
[Screen Reader]
So if you observe here, it says features link collapse submenu. And when I encounter a link in my mind’s eye, what happens is it’s a link. For me, generally, a link will open a page. If it would have said features button collapsed, which is a common design pattern where expand collapse. If you give a button, it makes more sense than a link.
[Screen Reader]
So it says grouping for some reason, but it should say how many list items are there inside this. So that’s one failure that I see.
[Screen Reader]
Because I’ve entered features submenu and I’m pressing down arrow.
[Screen Reader]
It did not say, for me, a list of X items, how many items are there. So the screen reader generally identifies if there are lists are nested lists and that’s a failure.
[Screen Reader]
If you see, I did inspect the code to see if Aria has pop-up, Aria controls, and Aria expanded are provided the appropriate way. So I’m going to showcase another small Chrome extension here to see if these kinds of Aria attributes are appended properly or not.
I’m closing the DevTools. So I built this plugin to improve my technical knowledge. And there’s a huge problem for me. So there are a lot of accessibility bookmarklets. Accessibility bookmarklets are nothing but small JavaScript snippets that identify a particular accessibility problem in your web page. You can run Accessibility Bookmarklet to identify forms, identify headings, and to identify links that do not have an accessible name or href attribute. So what I did is I took a bunch of Accessibility Bookmarklets and put them inside a Chrome extension.
It’s called Digital Eleven by Tubleds [T-U-B-L-E-D-S].
[Screen Reader]
It’s on the Chrome Store. Everyone can download it. I’ll share the link at the end of the webinar.
[Screen Reader]
We have Aria.
[Screen Reader]
We have multiple. You can identify images. You can identify headings and tables.
[Screen Reader]
It will show how many, and what landmarks are there. So this is especially helpful for sighted testers. It is not very helpful for someone who is using a screen reader day in, and day out, but sighted people who want to see quickly if landmarks are provided, if headings are provided, tables are there.
Let’s just say you see a specific content that appears like a table. You have the data, but you don’t know if the table tag is there or not. And you can run the bookmarklet and see the table. It will highlight the table for you.
So here I want to highlight one.
[Screen Reader]
I want to enable this one also.
[Screen Reader]
So you see on the page, only this gets annotated.
[Screen Reader]
So they used Aria current for the current.
[Screen Reader]
I want to expand this.
[Screen Reader]
So I’m going to reset the tablets. I want to see the form. There’s a form.
[Screen Reader]
So I’m going to reset the page by refreshing it so I can remove the bookmarklets.
[Screen Reader]
So again, support does not have a nested list. So this is a failure. So how do I record all these failures? In my experience – I’ve been doing testing for about eleven years – testing takes limited time but recording accessibility failures properly so that developers can fix them takes a lot more time.
Amber, do you agree with that?
>> AMBER: Yes, 100%.
>> RAGHAVENDRA: So how do I record it? So what I’ve done is built a small tool to automate a large portion of the process. So let’s just say I want to see if the features listing is not there. So I want to record a tool.
[Screen Reader]
So I built a small tool here.
[Screen Reader]
I just put the page URL as test.
[Screen Reader]
So if I want, I can edit.
[Screen Reader]
For me, I know which checkpoint a particular guideline fails. So the list headings, list tables fail on 1.3.1 because if I type 1.3…
[Screen Reader]
So I’m going to tab again.
[Screen Reader]
What I did is I listed out all the failure scenarios. So if you go to W3C and your understanding documents, you will see something called failure techniques and if you look at the failure you get all of this. Most of these are listed out there.
[Screen Reader]
So I’ll just pick this description here.
[Screen Reader]
I can just put the features or I can take the…
[Screen Reader]
These are all prefilled. You select the description, everything else is prefilled and the report is populated. I just need to write the details. I will write the code snippet here.
[Screen Reader]
Why am I not able to move into that?
[Screen Reader]
I’ll just copy this.
[Screen Reader]
So if you see the recommended field action is also filled.
[Screen Reader]
So I will just need to put a screenshot URL. Generally, we put it in dropbox or Google Drive and I’ll just give it test here.
[Screen Reader]
So you might be wondering where all this data is collected. So what I did is I used Google sheets API. So the data is collected in Google Sheets.
[Screen Reader]
So if you see, I’m Inside the Google Sheets. I’m just checking the page title.
[Screen Reader]
This is the code snippet.
[Screen Reader]
These are the headings. Whatever the labels that we identified in the form are what we see here.
[Screen Reader]
I’ll hold here. Any questions?
>> AMBER: I’m actually curious, Raghavendra. So you built that form which uses the Google API to post your issues into the spreadsheet for you. Where is the form? Does that live on a website?
>> RAGHAVENDRA: No, it’s on my local right now.
>> AMBER: OK. So it’s like an HTML form that is hosted locally on your computer?
>> RAGHAVENDRA: Yes. So what I did is I built a massive repository of all the various scenarios. Let’s just say if there is a carousel, the carousel region is not identified. The previous and next buttons in the carousel are not keyboard operable. The current state of the slide is not exposed to the screen reader in the carousel. So you identify a widget like, let’s say date picker.
And I wrote issue descriptions for all these scenarios. And then what I did is I converted it to the JSON and then put it with the HTML. So it auto populates. So I used all the off-shelf and took everything from GitHub.
There’s a script called Auto-Populate from GitHub. I’m not a developer. So what I did is I did an extensive study on how to do this. This is just what I do or tinkering. So if you ask me what I do at [Unintelligible 45:20], these are the things that I build.
I take up some hobby projects and try to learn something and see if something comes out of that. So the Chrome extension is also a part of that project. This reduces the effort while you document accessible issues. Let’s just say I’ll give the list of all the accessibility issues to someone, but if they have to copy the description, and recommendation properly to another Sheet and add their issues, it’s tedious.
And there are a lot of mistakes that can happen. So we reduce a lot of friction and a lot of effort here.
>> AMBER: Yes. Because you’ve pretty much prewritten all the possible issues and how to fix them, and then you only have to connect them to specific elements on web pages.
>> RAGHAVENDRA: Yes.
>> AMBER: That’s pretty cool. Maybe other people will understand, but I still don’t totally understand how that form runs on your computer.
>> RAGHAVENDRA: It’s just JavaScript and HTML. I can show you.
[Screen Reader]
>> AMBER: I would be really interested in that. I don’t know if you intended to show that.
>> RAGHAVENDRA: It’s nothing. I can tell you what I used. I used a website called…
[Screen Reader]
I used this API. This is free. It’s called Sheetmonkey.
[Screen Reader]
Oh, Sheetmonkey is out. OK.
[Screen Reader]
I think it’s Sheetmonkey.io
[Screen Reader]
I used this one to run the auto, like when you see this one. These are all form fields. So you just label the form field. You put the API in the form action, like your get ID.
[Screen Reader]
The only thing I used is this one where I did an autocomplete for this one and I got the script from GitHub where if you see, I think it is…
[Screen Reader]
It is from gov.uk.
[Screen Reader]
Yes. This one. alphagov. This one. So I use this one by gov.uk to autocomplete so that the autocomplete feature is accessible. And then what I did is… It’s just a logic that you select the checkpoint and it will give you a list of descriptions for that particular checkpoint. So that JavaScript I wrote and I got it validated from my brother who is also a developer.
>> AMBER: That’s awesome. This is really cool. Other people are saying the same thing.
>> RAGHAVENDRA: Yes.
[Screen Reader]
This is just less than 1mb of web folder, that’s all. There’s nothing much. I think just for styles, I asked some developer to help me with it, and he kind of used a lot of bootstrap and all that stuff. But we don’t need all of that, if you want, just to keep this in-house.
>> AMBER: Do you have a GitHub account?
>> RAGHAVENDRA: Do I have the?
>> AMBER: Yes. Do you have this on a GitHub account?
>> RAGHAVENDRA: No, not yet.
>> AMBER: If other people wanted to look at it?
>> RAGHAVENDRA: No, but I’ll just put the logic. I haven’t learned how to put my code snippets on GitHub yet. That is one goal in the next few months – to open-source some of the work that I’ve been working on.
>> AMBER: So someone has asked, “Can you explain the difference between automated and manual accessibility testing and how both are different from user testing? And which are you demonstrating here?”
He said, “I’m asking because the webinar mentioned manual testing. But what we’re demonstrating seems quite automated.”
>> RAGHAVENDRA: OK, so what I did is I’m testing…
[Screen Reader]
What we did is we ran Axe, which is automated testing. But when I looked at the list-
[Screen Reader]
here-
[Screen Reader]
this feature submenu not having list, this is like you do it in manual. Let’s see if there is a form here.
[Screen Reader]
I’m just going to submit it.
[Screen Reader]
So if you see this, “This is a required field” is not very helpful. But which field is required?
[Screen Reader]
These are all the things that we identify in manual testing. So the only way I document my accessibility issues is when I find any manual accessibility bug, the tool helps me automate, instead of writing each description, recommendation, code snippet, and other things. It helps me automate that stuff. And I need to add the failure code snippet and the screenshot. That’s the only thing.
And Amber, you said there’s an Instagram here somewhere.
[Screen Reader]
I’ll go to the Demo page.
[Screen Reader]
This is a demo page.
[Screen Reader]
Is there a way to invoke that demo?
>> AMBER: I think the demos are just down below. I might add something to the question that was asked, though, about the automated first manual. Because I think, when you’re using Axe, that’s automated testing. But what you’re doing goes beyond that because you’re not just looking at Axe and hitting the export button, because Axe has an export if you have Pro and it would just export to CSV, all the issues Axe found. That would be automated testing.
So what you’re doing is you take it to kind of point you in the direction to get started, and then you’re doing manual testing, and then you’ve automated some of your reporting to help you speed it up, but it’s still not automated testing because you’re manually testing it with a screen reader.
>> RAGHAVENDRA: Yes.
>> AMBER: And we’re viewing all the items on the page with the screen reader, not just what Axe found, right?
>> RAGHAVENDRA: Yes. So I have a visual assistant who helps me, but she uses the bookmarklets because I do the screen reader testing while with her and she uses bookmarklets to see if there are any bugs that the screen reader is not able to catch and she guides me towards that. Because she’s not a screen reader user.
>> AMBER: Your assistant, who normally helps you with the testing?
>> RAGHAVENDRA: She is more of a guidance, testing only to an extent. So they are not from an accessibility background. They are from the technology space. They’re learning still. Less than a year.
[Screen Reader]
So if I choose grid, I think it will show a grid view of the Instagram post, correct?
>> AMBER: I think so, yes.
>> RAGHAVENDRA: Did anything change?
>> AMBER: It scrolled you down the page. So that, in and of itself, is an accessibility failure.
>> RAGHAVENDRA: Yes. That is a focus order failure.
[Screen Reader]
So my focus is still on the grid link. I think grid is supposed to take me somewhere.
[Screen Reader]
Press custom. Did it scroll me again?
>> AMBER: Yes, it visually changed the page, but it didn’t shift your focus. So what would you put that under?
>> RAGHAVENDRA: I’ll put it in focus order. So either this goes into focus order… Let’s see all the tools here.
[Screen Reader]
Do you see this one?
>> AMBER: Yes.
>> RAGHAVENDRA: So this is the description.
[Screen Reader]
So we’ll test this particular screen.
[Screen Reader]
Where is the Instagram feed, then?
[Screen Reader]
>> AMBER: Sorry, give me a second. I’m counting.
[Screen Reader]
So there are probably eight tab stops after you would get to the list. Otherwise, there’s also a heading. Automated Instagram feeds.
[Screen Reader]
[Crosstalk 57:05]
>> RAGHAVENDRA: Yes, but for all the views, I think.
[Screen Reader]
So I’m not sure what the purpose of this one is.
[Screen Reader]
I’m going to press Enter.
[Screen Reader]
Focus more into the modal dialogue.
[Screen Reader]
So if you see, the model dialogue opened in the footer region of the page. Do you see this? So what I did is while I’m tabbing-
[Screen Reader]
my focus is trapped within the dialogue. But when I press the arrow up-
[Screen Reader]
that’s the footer region.
>> AMBER: And you shouldn’t be able to arrow out of this.
>> RAGHAVENDRA: No, you should not be able to arrow out. So there’s a failure for that also.
[Screen Reader]
You see this here? These are the failures.
[Screen Reader]
So this is the failure description on that one.
>> AMBER: Yes, because they have a focus lock for tab, but they did not have a focus lock when you’re in browse mode.
>> RAGHAVENDRA: Yes.
>> AMBER: The other thing that I noticed on that was that all of those buttons which… I give them kudos. Because first of all, they were actually coded as buttons to open the images in the modal. A lot of times in other plugins I see they’re like links, so I think they did a good job making those buttons.
>> RAGHAVENDRA: Yes.
>> AMBER: But they all had the exact same name.
>> RAGHAVENDRA: That is the confusing thing because I did not understand which Instagram post I’m opening. So I think it needs to fetch whichever Instagram post and give you a small hint.
>> AMBER: So that’s the weird thing on Instagram because it’s captions, right? There may not be alt text on the image.
>> RAGHAVENDRA: Yes.
>> AMBER: But do you want some amount of the caption to be used to make them unique?
>> RAGHAVENDRA: If we can fetch it, yes.
[Screen Reader]
And if you see this footer social media links-
[Screen Reader]
-they are saying Twitter, YouTube. So they should be much better labeled like “connect with us on Twitter” or “watch our videos on YouTube”. Those should be the labels there for these links.
I’ll still fail them. Because often what happens is when I go to a lot of websites, I see every article has a shared link and they say after the shared link there will be a bio which has again Twitter, Facebook.
You don’t know which Twitter is for sharing or which Twitter is for following someone.
>> AMBER: Yes, that’s a good point. Let’s see. I’m trying to look. So there are a few other comments that might be worth sharing real quick, looking through the chat.
So Glenn had mentioned those links that visually scrolled down but didn’t go. He said they behave kind of like a table of contents.
>> RAGHAVENDRA: Yes.
>> AMBER: So they were talking about shifting the focus down. And also, there was a comment, which I know you wouldn’t notice, but there’s not actually a visual focus indicator on most of this site.
>> RAGHAVENDRA: OK. Yes. So that’s where my sighted assistant comes and helps me out.
>> AMBER: She can get things like color contrast or missing focus.
>> RAGHAVENDRA: Yes, she does color contrast, visual focus indicator, resize, and reflow. So I’ll be there when she’s doing it. And from a subject matter expert’s standpoint, I’ll be guiding her. Like, I’ll zoom into 200% and tell me if there is any overlap of content, loss of content, or all that, and she’ll tell me if that is there.
And depending on that, I’ll record failures under my guidance. She takes screenshots and adds them to the report for me.
>> AMBER: I haven’t seen any other questions. If anyone else has any other questions, feel free to put them in the chat.
I’m sort of curious for you, though, because you’re putting together the report from that big list that you created. How much time did it take you to pre-fill all of those different answers and write all of them?
>> RAGHAVENDRA: Less than a year and I’m not done yet. I started last year in January and it took a couple of [inaudible]. So my goal is to get every quarter one iteration out. It’s pretty straightforward. As I said, I looked at the failure techniques, one. And if we go to code snippets, you have code snippet that is there, it lists out all the rules that it checks against. And if you go to Accessibility Insights, that is one place you get more information. Then you get information from Axe Core rules. So you just need to rewrite the summary.
I think even Chat GPT is not good. So it took me a lot of time because I had to write each issue, each description and recommendation, and put suggested code snippets. I can show you something.
[Screen Reader]
Do you see this massive list here?
>> AMBER: Yes.
>> RAGHAVENDRA: Do you see this? This is [inaudible]. This is gibberish for someone who looks at it. But I find my way inside this. Like any link that I come across, instead of bookmarking, I just copy and put it under a category. So I have different lists on my computer.
And what I do is I constantly see if there’s something that is missing. I find and I reiterate. So I also built my own. I can show you something.
[Screen Reader]
If you go to DigitalA11y… This is not for the public.
[Screen Reader]
So this gets integrated with the report.
[Screen Reader]
So I’m going to add this as part of the references in the reporting again so that it’s more clear and concise.
>> AMBER: Did you say that this part of your website is publicly available or not publicly available?
>> RAGHAVENDRA: No, not there.
>> AMBER: OK. Is it something that you’re thinking once you build out this library, at some point you might make it available to other people?
>> RAGHAVENDRA: Yes. It’s not ready yet because there are a lot of corrections that need to be done. This one, what you are seeing here is not even three months old. So there’s a lot of effort that needs to go in. I see at least another three to six months of work.
>> AMBER: I am hugely impressed – I just have to say that – with all of the effort that you’ve put into building the library and speeding things up. And I know that’s something we’ve internally talked about with trying to make our issues when we find them generic enough that they could be reused on future websites. Because you’re right, it really does. That’s the bulk of the time of testing – actually building the report.
So I really appreciate you sharing this with us because I feel like I’m taking away ideas for how we can make ours better as well.
>> RAGHAVENDRA: Yes. So that is how the idea came. I worked with IBM, they have their own set of tools. I worked with TQ. As you know, it’s one of the best accessibility solution providers. So they have their own set of tools. When I left TQ and came out, the goal was for me to do consulting initially, then explore opportunities. But when you get used to a certain process for about 15 years working for various companies, you need those tools.
So what will you do? And you can’t afford to buy enterprise toolsets. So I thought hard about all this. So last year I learned a bit of Node, React, and other programming languages to see if I can build this on a React app. But the Google APIs have become too complicated to build within React. So I just shifted to HTML, CSS, and JavaScript. It’s pretty easy and straightforward.
>> AMBER: Yes. I don’t think your screen reader is telling you this, but there are tons of applause, and reactions floating up in Zoom and I just wanted to share a few things that people had said in the chat. So Danielle said, “I’d pay for it, especially to support the time it takes to create and maintain all of this. It’s a full and comprehensive system.” I definitely second that. I feel like you might have the beginning of a membership or something here where people can get access to these tools.
Let’s see. Claire said, “Very impressive.” Christian said, “I like the self-made tool for sending the reports to Google Sheets and the auto-filled thing in Google Sheets. I’ve never explored auto-filled. So this was an eye-opener for me.”
Nathaniel talked about Axe and Selenium being a great automated testing combination. But yes, I think this is really cool and it’s giving me a lot of ideas. I really appreciate you coming and sharing it with us.
>> RAGHAVENDRA: Thank you, Amber.
>> AMBER: I don’t know if there are any other questions. Was there anything else that you wanted to cover? If not, it might be useful to share with people how they could follow up with you, and the best place to connect with you. Obviously, you’ve got your website.
>> RAGHAVENDRA: The best place is DigitalA11y. You can message me from the contact form or connect with me on LinkedIn. I’m more active on LinkedIn. I kind of left Twitter forever. Even at the end of 2021, not very active there. But I’m more active on LinkedIn and Facebook.
>> AMBER: Awesome. You’re in our group and you shared a few things in the group that is very helpful.
>> RAGHAVENDRA: Yes.
>> AMBER: Well great. Thank you very much. I don’t see any other questions from anyone, so I think we’re going to wrap a little early and give Ragh…
>> RAGHAVENDRA: So one thing, one resource. I think this is something that everyone might want to look forward to.
[Screen Reader]
We have a YouTube channel for DigitalA11y and it’s just two weeks old. If people can subscribe. I’m going to put everything that I learned in my life in accessibility over there in short videos.
>> AMBER: Awesome.
>> RAGHAVENDRA: This is going to be my project for this year and see if I can learn something while creating videos and other things.
>> AMBER: Can I ask you to also release audio and podcast format? Because I love to listen to stuff.
>> RAGHAVENDRA: Yes, that’s happening. So the first goal is… A friend is helping me create WCAG Understanding documents which can be concise and you can understand within three minutes.
>> AMBER: Oh wow, that would be awesome.
>> RAGHAVENDRA: Let me see if I can do a demo for anyone.
[Screen Reader]
I hope there are two more minutes.
[Screen Reader]
>> AMBER: Yes, we are good.
>> RAGHAVENDRA: How do I play this?
[Screen Reader]
>> AMBER: You were focused on it, but it might not have a label.
Speaker 3: Hello, everyone. Today we’re going to talk about headings and labels.
We’re also going to talk about its requirements, benefitted types, some examples, failure scenarios, and how we can fix them. Headings and labels for the form controls and UI controls must be descriptive.
By descriptive, we mean they must be concise, clear, and easy to understand. But why does it matter? Let’s see who benefits from this. It’s for users who have reading disabilities and other cognitive disabilities, such as short-term memory loss.
It’s for users who use screen readers or other assistive technologies that bring a list of headings for easy navigation and thus can read headings without additional context. And it’s for low-vision users who can see only a limited number of characters at a given point in time.
Now let’s take a look at some examples. A web page containing news articles where the headings contain the first 35 words of the articles and a Read more link. Or a contact us page where the users are asked to fill in both the work phone number and the home phone number.
So the form fill labels read “work phone number” and “home phone number”, respectively. Unfortunately, there are some failure scenarios. Let’s take a look at them. A payment page where the headings are not separated and descriptive for the billing address, address, and shipping address, and a contact us page by the address fields read as address one and address two instead of address line one and address line two.
Now let’s see how we can fix them. Content authors must define the section titles of their articles or web pages clearly and concisely. And when designing forms, the form labels must be precise and descriptive enough that users can understand the purpose of the field without additional context.
This is the end of the video. Thank you for joining.
>> AMBER: That’s cool. Are those the videos that you’re going to be putting out?
>> RAGHAVENDRA: I haven’t decided anything. So I’m chronically sick with a kidney issue. I’ve been a transplant patient. And after I got my transplant, I really wanted to do something. And during my dialysis period was when I started Digital A11y. It’s a story on its own because being an athlete, and one day someone says, your kidneys have failed.
So I’m going to put some of this content, a lot of this content out and see what… I want to contribute back to the community that gave me so much.
>> AMBER: That’s awesome. Well, we will all go subscribe to your YouTube channel. There are hearts floating across the screen, just so you know. Paula put the link in the chat and we really appreciate you talking. And everyone, feel free to follow up with Raghavendra on his website, with his contact form, or on LinkedIn, and we’ll see you back at a meetup in a couple of weeks and maybe a screen reader testing later this week.
Thank you, everyone.
>> RAGHAVENDRA: Thank you, everyone.
Links Mentioned
- DigitalA11Y Tublets Chrome Extension
- Sheet Monkey
- accessible-autocomplete GitHub repository
- ARIA Authoring Practices Guide (APG): Link Pattern
- Digital A11Y Website
- Raghavendra on LinkedIn
- DigitalA11Y Insights Youtube Channel
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.
Summarized Session Information
In this session, Raghavendra Satish Peri, founder of DigitalA11y.com and HelloA11y.com, shared his extensive experience in accessibility testing, particularly for websites. He provided a live demonstration of his methods, combining both manual and automated testing techniques to identify and document accessibility issues.
Key topics included his initial testing process using NVDA shortcuts, detailed audits with Axe DevTools, and the importance of addressing ARIA issues. He also highlighted the development of his Chrome extension, “Digital Eleven by Tubleds,” to assist sighted testers. Raghavendra discussed the challenges of documenting accessibility failures and introduced his custom tool, which integrates with Google Sheets to streamline this process.
Ragha concluded with his future plans to share educational content on accessibility through YouTube and other formats, showcasing his dedication to the field.
Session Outline
- Introduction
- Initial testing process
- Power testing and micro audits
- Detailed accessibility audit with Axe DevTools
- Addressing nested ARIA issues
- Testing “Skip to content” links
- Navigation menu issues
- Digital Eleven by Tubleds Chrome Extension
- Challenge of documenting accessibility failures
- Documentation methods
- Pre-written issue descriptions and recommendations
- Differences between automated, manual, and user testing
- Conclusion
Introduction
Raghavendra Satish Peri, founder of DigitalA11y.com and HelloA11y.com, began his presentation by introducing himself and his background. He explained that he is based in India and has extensive experience in the field of accessibility, having worked with IBM and Deque Systems.
Raghavendra shared his personal journey, noting that he became blind nine years ago due to a genetic disorder and has been using WordPress for over 14 years.
This presentation focused on a live demonstration of how he tests websites for accessibility issues, documents these issues using Google Sheets, and describes the tools he uses for testing.
Initial testing process
Raghavendra proceeded to demonstrate his testing process. He explained that his first step upon reaching any web page is to check the page title to understand where he is. He uses the NVDA keystroke Insert + T for this purpose.
He described his method of using basic NVDA shortcuts to navigate and assess the page structure quickly. For instance, he uses the letter T to check for tables, R for radio buttons, C for combo boxes, and X for checkboxes. This approach helps him gather a quick overview of the page elements. To get an idea of how many links are on the page, he uses Insert + F7, which lists all links and form fields, allowing him to estimate the number of tabs needed to navigate through the elements.
Power testing and micro audits
Raghavendra referred to this quick assessment as “power testing” or a “micro audit.” He typically uses JAWS, a screen reader he is more comfortable with due to his long experience, but he demonstrated using NVDA for this session.
He checked the heading structure by pressing H to see all headings, which helped him understand the content organization. Additionally, he looked for list items and navigation lists to get a sense of the page layout.
Detailed accessibility audit with Axe DevTools
After completing these initial checks, Raghavendra moved on to using the Axe DevTools extension in Chrome for a more detailed accessibility audit. He explained that Axe DevTools is the last step in his testing process. By pressing F12, he opened the DevTools and navigated to the Axe DevTools panel to run a scan of the page. This scan identified 33 accessibility issues, which he began to examine in detail.
Throughout the demonstration, Raghavendra emphasized the importance of familiarity with tools and websites, as it allows for quicker navigation and more efficient testing. His approach blends manual checks with automated tools to ensure comprehensive accessibility audits.
Raghavendra continued his demonstration by explaining how he handles the issues identified by the Axe DevTools. With 33 issues detected, he emphasized the importance of focusing on WCAG (Web Content Accessibility Guidelines) failures, as these are often prioritized by his clients over best practice recommendations.
He used the screen reader to navigate through the detected issues, moving from heading to heading to understand each problem’s context.
Raghavendra noted that while the Axe DevTools provide an overview of the issues, they often require manual inspection to confirm and understand the specifics.
Addressing nested ARIA issues
Raghavendra identified nested ARIA issues that needed attention. He explained that such issues often involve incorrect ARIA roles and attributes usage, affecting how assistive technologies interact with the web content.
Although the tool indicated problems, Raghavendra stressed the importance of manually inspecting the code to verify these issues, as Axe DevTools generally do not produce false positives.
He also discussed the significance of accessible names and labels, explaining the difference between the two: the label is what users see, while the accessible name is what assistive technologies read out. Ensuring both are correctly implemented is crucial for usability.
Testing “skip to content” links
Raghavendra then demonstrated testing the “skip to content” link, which helps users bypass repetitive navigation and go straight to the main content. By using the NVDA screen reader’s Insert + Tab keystroke, he verified that the link functioned correctly, focusing on the appropriate content. He highlighted the utility of this keystroke for checking the current focus, especially useful when dealing with dynamic content like modal dialogs or pop-up forms.
Navigation menu issues
Next, Raghavendra explored the navigation menu, identifying issues with how links and buttons were labeled and how the screen reader conveyed this information. He noted that links opening submenus should be labeled as buttons to make their function clearer to screen reader users. Additionally, he pointed out the importance of proper ARIA attributes to indicate expandable and collapsible elements.
Digital Elevel by Tubleds Chrome Extension
To enhance his technical knowledge and streamline his testing process, Raghavendra developed a Chrome extension called “Digital Eleven by Tubleds,” which incorporates various accessibility bookmarklets.
These bookmarklets are small JavaScript snippets that help identify accessibility issues on a webpage, such as missing headings, improper use of ARIA attributes, and unlabeled links. This tool is particularly useful for sighted testers who need to visualize a page’s structure and landmarks quickly.
Challenge of documenting accessibility failures
Raghavendra highlighted the challenge of documenting accessibility failures, noting that recording these issues in a way that developers can easily understand and address them often takes more time than the testing itself. To address this, he created a tool that automates much of the documentation process. This tool uses the Google Sheets API to collect data, including the page URL, failure descriptions, and code snippets. By prefilling most of the necessary information, the tool allows Raghavendra to quickly generate detailed reports, complete with screenshots and recommended actions.
Documentation methods
Raghavendra’s session continued with an interactive discussion about his innovative methods for documenting accessibility issues during an audit. Amber inquired about the form Raghavendra built to post issues into Google Sheets via the Google API.
Raghavendra explained that the form is hosted locally on his computer and is a simple HTML form connected to a massive repository of issue descriptions and recommendations that he pre-filled based on various accessibility scenarios. He used JSON to auto-populate the form fields and leveraged scripts from GitHub to streamline this process, even though he does not consider himself a developer.
Pre-written issue descriptions and recommendations
Raghavendra highlighted the importance of having pre-written issue descriptions and recommendations, significantly reducing the effort and potential errors in documenting accessibility issues. This approach allows him to quickly generate comprehensive reports by selecting relevant issue descriptions from a list and adding specific details such as code snippets and screenshots. He mentioned using a free service called Sheetmonkey.io to facilitate this process.
Amber expressed her admiration for Raghavendra’s method and noted how it speeds up the reporting process while ensuring consistency and accuracy. She also acknowledged the potential for Raghavendra’s system to benefit others, suggesting that he could consider sharing it publicly or even monetizing it in the future. Raghavendra revealed that he plans to open-source some of his work once he refines it further.
Differences between automated, manual, and user testing
While Axe DevTools provides automated testing, his process involves manual testing using a screen reader to verify and document the issues. Automated tools like Axe can point out potential issues, but manual testing is crucial to understanding the context and severity of these issues. Amber added that Raghavendra’s process is more comprehensive because it combines automated findings with manual verification and enhanced reporting through his custom tool.
Conclusion
Raghavendra shared insights into his collaborative approach. He works with a visual assistant to identify issues that screen readers might miss, such as color contrast and visual focus indicators. This partnership ensures that all accessibility aspects are thoroughly evaluated. He also demonstrated how he uses bookmarklets and Chrome extensions to aid in his testing, highlighting a particular issue with the focus order on a web page’s modal dialog.
Towards the end of the session, Raghavendra discussed his future plans, including a YouTube channel for DigitalA11y, where he aims to share short, educational videos on accessibility topics. Amber also encouraged him to consider releasing the content in audio or podcast format to cater to different preferences. Raghavendra concluded by sharing a demo of a video on headings and labels, illustrating his commitment to creating accessible and informative content for the community.
Throughout the session, Raghavendra’s dedication to accessibility and continuous learning was evident. His innovative solutions for documenting accessibility issues and his willingness to share his knowledge with others underscored his contributions to the field.