About the Topic
Thanks to Our Sponsors
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
- WordPress Plugin Accessibility Checker
- Empire Caption Solutions Website
- Empire Caption Solutions on Twitter
- WordPress accessibility in a page builder world
- The Carroll Center
- Understanding Success Criterion 1.3.1: Info and Relationships
- SRUTT Program Website
- Pre-Qualification Screening Assessment for SRUTT Program
- Carousels Tutorial
- How to Use NVDA (Screen Reader): Glen Walker
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
>> AMBER HINDS: We’re at five after the hour. I am going to officially get started. I have a few announcements that I’m going to do and then I will hand it over to our amazing speaker. The announcements today, we do have a Facebook Group that can be used to connect between meetups. If you go on Facebook and you just search WordPress Accessibility, then you’ll be able to find the Facebook Group.
That is a good way to get questions answered, network with other people, find recommendations for plugins, or if you’re having a problem testing something, or having a problem trying to figure out how to fix something that came up in a test, it’s a great place to chat and connect with a lot of really great people who are enthusiastic about accessibility. If you are interested in finding more about upcoming events or viewing past recordings in one place, our website for that is equalizedigital.com/meetup.
That’s a frequently asked question and I think it will probably come up in the chat later today for someone who joins late. This meetup is being recorded, it takes us about a week and a half to two weeks to get a corrected transcript and captioned file. Once we have the full captioned file and transcript, we will post the video on our website. You want to bookmark that website that I’ve shared with you for the meetup page and that’s where you can get the recording. The other way to get notified when recordings are available is to join our email list.
You can join that if you go to equalizedigital.com/focus-state. I think there’s also an email sign-up on the Thank You page after the meetup ends. We send two emails a month and they include notifications about upcoming events, the links to the recordings from the past events, and some links to other news related to website accessibility around the web. Not just our content, it’s a great collection of things that we found that we think are interesting. We are seeking sponsors for this meetup. We rely on sponsors to help cover the cost of our captions and our transcript.
If we’re able to, we would to be able to offer sign language interpretation. Again, it’s something that we did do for a while. If you are interested in sponsoring or you think your company might be interested in sponsoring, please contact us, we would very much like to talk to you and are happy to share the details. You can also get that off the meetup website page. If you have any suggestions about the meetup or anything we can do to make it work better for you, you can contact myself, and my co-organizer, Paula at meetup@equalizedigital.com.
I am Amber Hinds, I’m the organizer, and today, we are also the live caption sponsor for the event. My company is called Equalize Digital. We are a Certified B Corporation, a WordPress VIP Agency Partner, and a corporate member of the International Association of Accessibility Professionals. We really focus on WordPress accessibility. That’s our passion, is making the web work for everyone. We also have a plugin for WordPress websites called Accessibility Checker that scans your WordPress site for problems.
Not all, because not everything can be found by an automated tool which is why we’re going to be talking about accessibility testing manually today, but it can help you to find some of the more obvious problems and speed up error identification for your content creators, so hopefully, they aren’t adding more problems to the website faster than you can fix them. If you want to learn more about us, I’ve already said what our website is, so you can go there and learn more and we’re pretty active on Twitter.
We have a transcript and SRT sponsor today, Empire Caption Solutions. They are who will be taking our video and doing the hard work of ensuring that we have correct captions on the recording after the fact, and they kindly donate their service to us. They have been doing a phenomenal job and we very much appreciate it. We always encourage our attendees to thank our sponsors. If you’re on Twitter or on LinkedIn, and you want to just send them a thank you for sponsoring WordPress Accessibility Meetup, that helps to encourage them to want to continue doing it so they know that they’re getting heard.
We very much appreciate that. In addition to captions and transcription, they also do audio description and sign language interpretation, both for live and pre-recorded media. We definitely recommend checking them out. Their website is empirecaptions.com, and on Twitter, they are @EmpireCaption. We have a couple of upcoming events that I wanted to share. Next week is WordCamp US. I’ll be doing a Website Accessibility Testing Workshop there with Alex Stine, who you may know because he’s previously spoken and done some Screen Reader Testing during meetups for us.
Let me see real quick. Oh, I don’t have it up. I think Paula might share the link in the chat to the schedule for WordCamp US, but if you don’t know– Let’s see, I’m going to grab it from her. I’ve pulled up the schedule right now and it’s Friday, September 9th. Let’s see, not this one. There are multiple sessions related to accessibility and they will all be live streamed with captions. At 10:00 AM Pacific Time, there is one called Embracing Minds of All Kinds, Making Digital Content Usable for People with Cognitive Disabilities.
Then, at 1:00 PM Pacific, will be the Accessibility Testing Workshop that Alex and I are doing. Then, let’s see if there’s another one. Then, on Saturday, September 10th at 10:00 AM Pacific, Sara Cannon will be talking about Designing for Accessibility. Then, at 11:00 AM Pacific, Cami Kaos will be talking about Diversity, Equity, and Belonging. It’s not quite website accessibility but it definitely touches on relevant topics. Then, later in the day on Saturday, Joe Dolson will be talking about Finding and Fixing the Six Most Common WCAG 2 Failures. That is a lightning talk, so he’s going to share all that information in 15 minutes.
If you’re interested, I would definitely recommend tuning in. You don’t have to be there at WordCamp on the day in order to see it. Our next meetup will be Monday, September 19th at 7:00 PM Central Time, and Glen Walker will be sharing his approach to testing websites manually. It should be a great one if you want to learn more on that front. This month is a really great month for learning about doing manual testing and I’m very excited about both our speaker today and that one.
Then, in October in the same time slot at 10:00 AM Central on Thursday, October 6th, Daniel Sommer from Empire Captions will be talking about different transcription types for real-time settings and recorded media because there are different ways that audio can be transcribed. He’ll be talking about that process and what the different options are. I am very excited to introduce everyone to our speaker today. His name is Nicholas Corbett. I’ve just spotlighted his video, hopefully, everyone can see him as well.
Nick has been with The Carroll Center for the Blind since 2017, and he originally joined on the rehabilitation team as a Technology Skills Instructor and Project Specialist. In 2021, he transitioned into the role of Accessibility Training and Research Coordinator. Nicholas is an advanced user and instructor of accessibility software across Microsoft, Google, and Apple products, and he enables others to communicate with language that can be understood by users and developers of digital resources; thereby, promoting employment and opportunities in the digital accessibility space for people with visual impairments. I am very excited to introduce Nick to you all today and have him share information with us about Training Screen Reader Testers. We do have a Q&A box that you can find down below. It is a little more helpful if you put that questions into the Q&A rather than the chat because sometimes they can get buried in the chat. I will be monitoring that and then I’m going to go on mute for now, and I’m going to stop sharing my screen and let Nick take over.
>> NICK CORBETT: Thank you, Amber. Thank you to Equalize Digital and the WordPress Accessibility Meetup for hosting me as well today. The topic of this is Training Screen Reader User Testers. This is a new program that I’m running at The Carroll Center for the Blind. It’s been offered twice. It’s going to be offered for the third time this fall. Originally, it was designed by two people. One person who used to work in finance and then found himself after losing his vision many years working in accessibility, climbing the ladder.
Someone else who worked with him, who, same thing, was teaching assistive technology, found her way to digital accessibility, and now is working for a Fortune 500 company. I started teaching assistive technology, and now, I’m in digital accessibility. I was speaking to one of my close friends the other day who advises the education system for an entire state. That state is now paying for him to go get training in digital accessibility, specifically screen readers. There’s a big demand for this.
I think that training Screen Reader User Tester is really the intermediary point between demand and providing someone who knows those skills. I, myself, am a screen reader user. I have been for quite a while. I’ve taught probably well over 200, 300 people how to use assistive technology. I’ve gotten a sense, over the time, what works best for people, what’s the easiest way to do something and yet the extremely thorough and comprehensive, and what skills do we need to lay the groundwork so we can continue to develop our skills even further. That’s what this course does.
This course brings you deep into the operating system of screen reader and how they interact with digital products. This presentation, I’m not just going to talk at you the whole time. I’m going to do some demonstrations. I’ll do some screen share, but first, I just want to make sure I cover what I need to initially. Let’s talk a little bit about– You got who I am, but let’s talk about The Carroll Center. The Carroll Center for the Blind, it’s a residential rehabilitation center located in Newton, Massachusetts, and I am really an advocate for The Carroll Center.
I see great things going on there. The mission, everyone who works there is devoted to the mission to making change, having an impact. This program and training screener user testers is just one of the latest examples of how we’re trying to stay at the forefront of opportunities for people with blindness and visual impairments. The Carroll Center, check it out at www.carroll.org. It’s a great place and it’s a mission, I think a lot of people can get behind. Now, let’s jump into the meat of the presentation. What is the screen reader user tester training program?
It is a seven-week program presently. We hold it from 9:00 AM to 3:00 PM Eastern Standard Time. We have optional support sessions in the afternoons, three days a week. It’s taught by myself, as well as David Kingsbury, who I’m sure some of you have heard of, who has written multiple books on using screen readers with the Windows operating system. We divide up the content and we jump back and forth, sprinkle about where we’re offering our insights. We go through a number of topics in this course.
I’m actually going to show you a couple of documents that we use in the course and walk through some steps that we might take. I’m going to start my screen share here for you all. I like to say the keyboard commands that I’m doing while I’m doing things, I think it helps people out. I won’t do it always, but I’m just going to do it now. I pressed Ctrl + Shift + Alt to jump over to my active Zoom meeting window to share the screen. I’ll just configure these settings and I’ll share the screen.
>> SCREEN READER: Screen share. Meeting controls, move transcription left when closed captioning right has been enable. Press F6 for more information about who can see the–
>> NICK: We just get talking a little bit there. We’re going to keep it at this speed, which is a medium speed.
>> SCREEN READER: Paula Gonzalez has left meeting. Paula Gonzalez has joined the meeting. Participants can now see your screen.
>> NICK: All right. Let’s see. Hopefully this, [inaudible] goes down a little bit. I’m going to bring you over to a document that is going to be called topic scheduled for presentations. Just going to use Alt + Tab to get there.
>> SCREEN READER: Talking points. Topic Scheduled for Presentations – Excel. Please wait. Topic alert. This document-
>> NICK: Maximize my window.
>> SCREEN READER: Restore all. Leaving menus. Session. First cell.
>> NICK: If we think about any kind of program, if we want to teach someone something, we want to modularize it. We want to make it easy to digest. We can simply get a breakdown of how I’ve modularized this course in the screener to user test training program by our column headers here. A column header is just the first cell in a row going across the top of a spreadsheet or any given table. This first one says session that just corresponds to a specific week of the program. There are seven weeks.
>> SCREEN READER: Date, B1.
>> NICK: Date for any given topic as we go down this column.
>> SCREEN READER: Time, C1.
>> NICK: Time when it’s held.
>> SCREEN READER: Content category, D1.
>> NICK: Every topic that we teach, I’ve broken down into, I think, one of seven different categories. I’ll show you those categories in a moment.
>> SCREEN READER: Topic, E1.
>> NICK: Here’s all the topics.
>> SCREEN READER: Description, F1.
>> NICK: Description of that topic.
>> SCREEN READER: Meetings, G1.
>> NICK: This column is going to disappear.
>> SCREEN READER: Presenter (S), H1.
>> NICK: Our presenters, a couple more things. This spreadsheet, if we hit Ctrl + End.
>> SCREEN READER: Left cell blank, J141
>> NICK: 141, so we see we have quite a few rows in this spreadsheet. Whenever we have a lot of rows in the spreadsheet, we’re going to want to use a filter situation. I’m just going to go to the top of the spreadsheet here, Ctrl + Home.
>> SCREEN READER: First cell, Session, A1.
>> NICK: We just hear the name of that cell announced, which is session. We hear the coordinate A1. We don’t hear anything like filters applied. I’m going to apply filters with Ctrl + Shift + L. It doesn’t say anything, but if I right arrow to the next column.
>> SCREEN READER: Date, B1. No filter applied. Dropdown button.
>> NICK: No filter applied. Let’s go over to our categories column.
>> SCREEN READER: Time, C1. Content category. Topic. Content category, D1. No filter applied. Dropdown–
>> NICK: No. I want to filter all these cells down to just a category that I want to bring our attention to. Let’s expand this dropdown with Alt + Down arrow.
>> SCREEN READER: Menu. S.
>> NICK: If we Shift +Tab three times, we’ll get into a list of checkboxes.
>> SCREEN READER: Cancel. Okay. Manual filter TreeView (Select All). Checked.
>> NICK: Select All is checked. Meaning every category is selected, so every row will be displayed. I’ll uncheck that.
>> SCREEN READER: Not checked.
>> NICK: Now, I can go down arrow and just check just the categories that I want. I’ll go down.
>> SCREEN READER: Level zero assessments, not check. 2 of 10.
>> NICK: Before I choose, let’s talk about each of these categories. Assessments. In the screen reader user tester training program, we have seven assessments. We have weekly quizzes in weeks one through six, and we have a final exam in week seven. Week one through six, these are multiple choice questions. They’re meant to reinforce and confirm that you are gaining the knowledge that we’re trying to teach in weeks one through six. Week seven, the final exam has 50 questions, and it incorporates the topics throughout the entire program, as well as the topics taught in week seven. I’ll go down.
>> SCREEN READER: Coding and Automated Testing, not checked.
>> NICK: Coding and Automated Testing. We do get a little bit into that and we will look a little bit at coding in this presentation today. Not very deeply, but a little bit to get any kinda screen reader user tester started. Automated testing. We don’t look too much at a lot of automated tools, but there is value in automated tools. There’s a lot of them out there. You’re in this WordPress Accessibility Meetup, so I recommend you check out the one that Amber has with her company. See what she’s doing.
If any screen reader user tester can also master an automated testing tool, they just increased their value wherever they go, whether it’s at a company or volunteer situation. Something I like to say is a lot of people who are blind or visually impaired, interested in tech, maybe some of us are looking for work. Something always leads to something. Nothing often leads to nothing. If we do something, whether that be volunteer, part-time, contract, full-time, it will always lead to something else. Just a little thought. Let’s go up and down.
>> SCREEN READER: Assess– Coding and Automated Testing, not–
>> NICK: Coding and Automated Testing. We’ll go down again.
>> SCREEN READER: Course Logistics, not checked.
>> NICK: Course Logistics, just intro to the course. We have some of those in the course. We want people to know how to interact with all the content.
>> SCREEN READER: Guests, not checked.
>> NICK: Guests. We have guest speakers from a bunch of different organizations, all different backgrounds. I think it’s really valuable to see what other people have done and how other companies are handling accessibility just so a screener reader user tester can be aware of what is the environment they’re operating within. Very important. We’ll go down.
>> SCREEN READER: Guidelines, Standards, and Laws, not check.
>> NICK: We wouldn’t have any of this screen reader user testing without guidelines, standards, and laws. I think this is a good time to make a distinction between someone who says, “I love accessibility and I have opinions,” versus someone who says, “I’m committed to accessibility and I adhere to guidelines.” Someone who is passionate about it, but doesn’t have the technical background and doesn’t have the knowledge of what standards are out there, such as the WCAG, they’re just going to make willy-nilly recommendations, and they may not fall directly into something that must be fixed, something that must be remediated. If we tell a developer that they need to fix this but we don’t ask them why, or point them toward anything that says, “Here’s how.” That developer’s likely just going to let it fall to the wayside and that issue won’t get remediated. If we have knowledge of guidelines, standards, and laws, and we can say, “All right, here’s an issue, here’s why it’s an issue. Here’s what it’s violating, here’s how to fix it,” a developer’s going to listen to us a lot more. We’re going to have a lot more value wherever we go. We’ll go down again.
>> SCREEN READER: Prequisites, not checked.
>> NICK: Prequisites. Of course, there’s a lot of stuff we need to know in order to be a screen reader user tester. Not a ton though. It’s manageable. We need to be pretty good with Excel, pretty good with Microsoft Word, good with file and folder management, email communications, navigating website through a web browser, familiar with Chrome, Edge, Firefox, proficient with a screen reader on our mobile device, iOS with VoiceOver. It’s great if you also have some knowledge of TalkBack for Android.
If you can also learn a bit of VoiceOver with Mac, that’s great. You just want to be as diverse as possible. The ones that I see being the most commonly requested is going to be Windows with JAWS, or NVDA, and then VoiceOver with the iPhone. If you start with those, you’re going to be pretty good. Let’s go down.
>> SCREEN READER: Projects, not checked.
>> NICK: People complete projects. When we look at what a student profile– Who’s a typical student? We’ll get a sense of what these projects are.
>> SCREEN READER: Screen Readers, not checked.
>> NICK: Screen Readers. I touched on that in my prior statement.
>> SCREEN READER: User Tester, not checked.
>> NICK: User Tester. This is very important. This is the meat of the program. Let’s go down once more.
>> SCREEN READER: Cancel button, S.
>> NICK: Cancel. There’s no more. Let’s go to user tester.
>> SCREEN READER: Manual filter TreeView user tester, indeterminate. 10 of 10.
>> NICK: Go up and down.
>> SCREEN READER: User Tester, not checked.
>> NICK: We’ll check that.
>> SCREEN READER: Checked.
>> NICK: We’ll hit Okay.
>> SCREEN READER: Okay button. Audio filter is on. First cell, Session.
>> NICK: Now, if we’re going to look for something, let’s look for a certain topic that we’re going to teach. I’m just going to do a Find. We didn’t really have to filter there but it’s useful. Let’s do Ctrl + F.
>> SCREEN READER: Find and Replace.
>> NICK: I’ll type tables.
>> SCREEN READER: Topic, tables has hyperlink. E36.
>> NICK: We see tables and we see has hyperlink. That would bring us somewhere. We’ve got more resources. If I hit our right arrow, we’re going to see a description of what we would learn with tables. I’m just going to slow down a little bit more.
>> AMBER: Nick?
>> NICK: Sure.
>> AMBER: Sorry to interrupt. Would you put that slightly make your columns a little wider? Maybe just the description one. It’s very narrow.
>> SCREEN READER: [crosstalk] followed by Autofit Column Width. Leaving menus, leaving ribbons. Analysis lens.
>> NICK: Is that any better?
>> AMBER: It is, although it’s so wide now that I don’t know if we can see the full description.
>> NICK: Okay.
>> AMBER: I didn’t know if you intended for everyone to be able to read the description.
>> NICK: No, I think that would be great. I don’t think I can fix it quickly right here, but I will slow down the screen just so it will read it. We’ll give that a go.
>> AMBER: Yes, same here.
>> NICK: Sure. Let me just figure out where I’m at.
>> SCREEN READER: List continued. Head tables. Head tables has hyper–
>> NICK: Let me slow down the screen here for this reading of this longer passage.
>> SCREEN READER: Slower, slower, slower.
>> NICK: We’ll go right and we’ll see, what can we learn about tables in the screen reader user tester training?
>> SCREEN READER: Description. Learn to use our test tables and become familiar with data, layout, complex, simple and graphical tables, visual presentation of content for association, and table summaries, captions, and names. F36, adjacent to hidden cells.
>> NICK: It’s kind of the meat. What is a table and what are all the things we need to know about when dealing with tables? I think we’re going to take a look at an actual example of this and this is going to feed us right into the next documents we’re going to look at. I’m just going to bring the speed up a little bit more.
>> SCREEN READER: Faster, faster.
>> NICK: Quick time check.
>> SCREEN READER: 11:30 AM.
>> NICK: Okay. I have a Google Chrome tab open already. I’m going to Alt + Tab over to that.
>> SCREEN READER: Meeting Controls. Talking Points. Use TalkBack gestures presentation. Use TalkBack gestures – Android Accessibility help – Google Chrome. Use TalkBack to– Context menu. Leaving menus used– Use TalkBack gestures – Android Accesibility Help.
>> NICK: It looks like I do have some high contrast here. I hope that’s okay for everybody. I threw a place marker on a certain heading here, so I’m just going to press K.
>> SCREEN READER: Ctlrl + TalkBack level 2.
>> NICK: If I go down, we’ll have a button.
>> SCREEN READER: Version 9.1 and Up button collapse.
>> NICK: Version 9.1 and Up button collapse. That’s talking about probably an Android version, but we’ll expand that button. Actually, before we expand, let’s go down with more.
>> SCREEN READER: Version 8.2. and lower button collapsed.
>> NICK: We have version 9.1 and up or 8.2. and below. If I go to 9.1–
>> SCREEN READER: Version 9.1 Up button collapse.
>> NICK: Expand this–
>> SCREEN READER: New region version 9.1 and Up button expanded.
>> NICK: Now go down.
>> SCREEN READER: Table with 3 columns and 10 rows.
>> NICK: We see a table has been inserted in the web content between those two buttons. This table is what we’re going to look at here. Let me go down once more.
>> SCREEN READER: Action.
>> NICK: We hear action. We now realize that we are within the table. Let’s orient ourselves to this table and let’s figure out, is this table working ideally for a screen reader user or not, and if not, what’s wrong with it. When navigating a table, we have a couple of ways. If we’re using JAWS, we can use our table layer commands. Insert + Space + T and then just use the arrows. I’m just going to use Alt + Ctrl in my arrows to move across the row, or up and down a column. I’ll hold down Alt + Ctrl in my left hand, and I’m going to hit the right arrow.
>> SCREEN READER: Gesture, column 2.
>> NICK: We hear gesture, column 2. If I go up–
>> SCREEN READER: Top of column.
>> NICK: We hear it’s the top of the column. We know that gesture is in row 1. Let’s go left.
>> SCREEN READER: Action, column 1.
>> NICK: Action in column 1. In column 1, we have action. Column 2, we have gesture, and in column 3–
>> SCREEN READER: Multi-finger gesture. Column 3.
>> NICK: We have Multi-finger gesture. These three things are known as our column headers. Let’s just keep that in the back of our mind. Our column headers are Action, Gesture, and Multi-finger gesture. Let’s come back over to column 1. I’ll do Alt + Ctrl – Left a couple of times.
>> SCREEN READER: Gesture, Action, column one.
>> NICK: Now, let’s go down.
>> SCREEN READER: Pause or resume speech, row 2.
>> NICK: Pause or resume speech. Down again.
>> SCREEN READER: Start or stop media, row 3.
>> NICK: Start or stop media. These are our row titles. If we go up to this one–
>> SCREEN READER: Pause or resume speech.
>> NICK: Pause or resumed speech, and we want to know how to do that with the gesture. We would look for the cell that intersects the column title and the row title, or the column header and the row header. We go right.
>> SCREEN READER: Dash dash, column two.
>> NICK: It just says dash dash. I don’t know what that dash dash means. Let me go right again.
>> SCREEN READER: Two-finger tap, column three.
>> NICK: Here, we hear two-finger tap but we didn’t hear the column header. If we go up–
>> SCREEN READER: Multi-finger gesture.
>> NICK: Multi-finger gesture, and now, we go down.
>> SCREEN READER: Two-finger tap.
>> NICK: We see that the Multi-finger gesture for– oh, and now, what was in this row? We need to go back and look.
>> SCREEN READER: Pause or resume speech.
>> NICK: Pause or resume speech. The multi-finger gesture for Pause or resume speech is a– What is it? We need to go back again to the right.
>> SCREEN READER: Two-finger tap. Column–
>> NICK: Two-finger tap. A screen reader user would notice that there’s an issue here. The issue is that column and row headers are not announced as table data is navigated. That makes it difficult for a screen reader user to make associations of table data to its table headers, row or column. We could tell that to a developer and we could say, “This isn’t working quite right,” and a developer probably figure out why that’s not working right, pretty quickly. Then again, a developer made this table, and they made it this way, in a way that is not super accessible.
Here’s something about a screen reader user tester. What would the average person do right now, and what would a screen reader user do right now? I think a standard screen reader user would just accept this and they would try and figure it out and they would move on. A screen reader user tester is going to be curious. If you’re someone who’s curious about why is this not working and how do I fix it, screen reader user testing may be for you. Now, let’s fix this. I want to bring our focus back to the start of this table. I happen to know it’s the only table on the page, so I’m just going to hit T to wrap.
>> SCREEN READER: Wrap interval. Table with 3 columns and 10 rows. Column 1, row 1. Action.
>> NICK: We hear that we’re on column 1, row 1, and we’re on action. Let’s just review what is the issue. We’re just going to go down.
>> SCREEN READER: Pause or resume speech, row 2.
>> NICK: We’ll go right.
>> SCREEN READER: Dash dash, column 2.
>> NICK: Again.
>> SCREEN READER: Two-finger tap, column 3.
>> NICK: Again. See, we’re hearing the gesture one which, is there’s no regular gesture like dash dash. Multi-finger gesture, we see what it is there, but we don’t get those column titles. Let’s change this. Let’s wrap again with T.
>> SCREEN READER: Wrapping to top. Table with 3 columns and 10 rows. Column 1, row 1, Action.
>> NICK: There’s Action. We’re going to open up DevTools, and we’re going to inspect this particular element. We’re going to do our applications or context menu. We’ll do it anyway. Shift + F10 is popular on a Dell computers function, right control. Sometimes you can do a right mouse click, which is, your screen reader key. I just say Insert and 9, but we’ll do the contextual menu here.
>> SCREEN READER: Menu. Use TalkBack gestures–
>> NICK: We’ll Up arrow.
>> SCREEN READER: Inspect. 11 of 11.
>> NICK: We find Inspect. I’m going to press Enter.
>> SCREEN READER: Leaving menus. Use TalkBack gestures – Android Accessibility Help–
>> NICK: Now, if I read my title bar–
>> SCREEN READER: Title is DevTools-support.google.com/
>> NICK: We see it’s DevTools with support.google.com. It’s DevTools for the page we’re working on. If you try and do this on your own, it might not pop up in this window. DevTools, typically by default will open up in the same window as the webpage you’re viewing. There’s a quick setting you just tab around and look for it. You choose to, it’s like detach the DevTools window to its own window or something like that. If you Google just how to make DevTools appear in its own window, you’ll probably find the answer.
Now, what is DevTools? Going to show us here, all we’re going to worry about is that it’s going to look at the DOM. What is the DOM? When we look at a webpage, let’s say we look at a webpage, visually. We’re looking at that page, we’re looking at all its content, and we’re seeing something that’s visually pleasing to us. If we’re navigating webpage with a screen reader, we’re hearing with the screen reader saying, and we’re hearing it in a way that it’s auditorily pleasing to us. A web page is really just an interface for a user.
What’s a screen reader doing though? A screener is actually crawling over the code of a page, and reporting that code to you in a way that’s auditorily comprehensible. Where that code exists is in the DOM, and by opening DevTools, we can actually look at that code, as opposed to looking at the proper and finalized, and clean-looking web interface. That’s the webpage itself. Here, we are in DevTools, I’ll just let anyone know who’s using a screen reader and wants to try this on their own.
I do have my forms mode set to manual, so that I’m not automatically popping in forms mode, forms mode with auto, we would for like a pop as we came in here. Let’s just go up arrow.
>> SCREEN READER: Page DOM.
>> NICK: We hear page DOM. If I go down–
>> SCREEN READER: <strong> action </strong> TreeView item selected. 1 of 2.
>> NICK: We hear this weird thing, it sounds like code, right? </strong> action, I don’t know what that means. I don’t know code. You don’t really have to. You’ll see that as we go through this. You only have to listen for a couple of key things. If I go down again–
>> SCREEN READER: DOM three explore [inaudible] end.
>> NICK: We hear the DOM has ended. This middle area of the DOM.
>> SCREEN READER: <strong> action </strong> TreeView item selected. 1 of 2.
>> NICK: It’s TreeView item. If we hit Enter, we pop into where we can actually maneuver the DOM, I’ll hit Enter. Now, I’ll just go up to get my bearings.
>> SCREEN READER: Level 17. <TD> open. 1 of 4.
>> NICK: We hear <TD> open. Let’s close that with left arrow. It doesn’t tell us it is closed, but it did, so I’ll go up again.
>> SCREEN READER: Level 16. <TR> open. 1 of 11
>> NICK: Now, we hear <TR> open. A TR is a table row. That table we were looking at where we had action gesture, multi-finger gesture, that’s the first row of a table. If I go up one more time–
>> SCREEN READER: Level 15. <body> open.
>> NICK: You see less body, less body just indicates the start of the content of a webpage. It’s obvious that a less body tag would precede less table row tag, right? Because a table row is contained within the body of a webpage. We might be moving kind of fast here, this stuff typically wouldn’t be introduced at all in week one or two in the program that I’m teaching. We have a lot of background information. We’re taking a leap ahead here. Let’s go down to that first table row.
>> SCREEN READER: Level 16. <TR> open. 1 of 11.
>> NICK: We hear that it’s open. We want that open, right? Because if we collapse it with left arrow, and now down arrow.
>> SCREEN READER: <TR> </TR> closed.
>> NICK: We see there’s another table row. Tags often have a <>, and at the end of the tag is that </> with a certain word inserted between the < and >. The / just indicates an end tag, no slash indicates an open tag. Since we close the first table row tag, it jumped to the next table row tag, so we don’t get to see what’s contained in that row. If we go back up–
>> SCREEN READER: <TR> </TR> closed.
>> NICK: Open this right arrow.
>> SCREEN READER: <TR> open–
>> NICK: We can have down arrow.
>> SCREEN READER: Level 17. <TD> </TD> closed. 1 of 4.
>> NICK: We have three <TD> </TD> here. I’ll go down.
>> SCREEN READER: <TD> </TD>–
>> NICK: That’s two.
>> SCREEN READER: <TD> </TD> closed.
>> NICK: That’s three.
>> SCREEN READER: </TR>.
>> NICK: That’s the next table row. These three that allows what we’re seeing on our webpage, we had a table and we have three columns. We had action gesture, multi-finger gesture. As we expand these table data tags, I’m expecting we’re going to see action in one of them, we’ll see gesture, and we’ll see multi-finger gesture in one of them. Let’s go to the first one.
>> SCREEN READER: <TD> </TD> closed.
>> NICK: Let’s extend that right.
>> SCREEN READER: <TD> open <TD> open.
>> NICK: We’ll go down.
>> SCREEN READER: Level 18. <strong> action </strong>. 1 of 2.
>> NICK: Right, so we see action. Now, all we’re going to do is we’re going to change the table data tag to a table header tag. We’ll go up.
>> SCREEN READER: Level 17. <TD> open. 1 of 4.
>> NICK: Right there, so if I just hit F2– If you ever editing a file name and like this PC or any cloud storage desktop app, use F2 to edit the file name, same thing here, we’ll do F2 and it’ll allow us to edit this tag
>> SCREEN READER: DevTools document, elements, panel tag panel, elements DOM tree explored.
>> NICK: Cool, I’ve say control the silence the output, but we can trust that our cursor focus is at the beginning of that tag. I’ll go right.
>> SCREEN READER: TD>.
>> NICK: All right, so TD>, I’m just going to backspace the D.
>> SCREEN READER: D.
>> NICK: Type H.
>> SCREEN READER: Elements, panel type panel, elements.
>> NICK: We don’t actually hit Esc, we hit F2 again to stop editing.
>> SCREEN READER: DevTools – Support.
>> NICK: If I go up–
>> SCREEN READER: <TH> </TH> closed.
>> NICK: Up again.
>> SCREEN READER: Level 16. <TR> open.
>> NICK: Right, so we did it.
>> SCREEN READER: Level 17. <TH> </TH> closed.
>> NICK: It actually collapsed it for us, which is fine, we’ll go down again.
>> SCREEN READER: <TD> </TD> closed.
>> NICK: Let’s do the same thing here. Let’s change this one, which– if I expand it, down arrow.
>> SCREEN READER: Level 18. <strong> gesture </–
>> NICK: To associate with a gesture. I’ll go up.
>> SCREEN READER: Level 17. <TD> open.
>> NICK: I’m going to collapse that. I’ll go up and down. Just make sure it’s closed.
>> SCREEN READER: <TD> </TD> closed.
>> NICK: Now, we don’t need to expand it to edit it. I’ll just hit F2.
>> SCREEN READER: DevTools document, elements panel–
>> NICK: Right arrow to find the D.
>> SCREEN READER: –TD>.
>> NICK: Delete the D.
>> SCREEN READER: D.
>> NICK: Type in H, hit F2, to double check, I’ll go up in the DOM.
>> SCREEN READER: <TH> </TH> closed.
>> NICK: Down.
>> SCREEN READER: <TH> </TH> closed.
>> NICK: Down again.
>> SCREEN READER: <TD> </TD> closed.
>> NICK: This is the final one which would be a multi-finger gesture, again, right arrow to expand, down arrow to confirm the content of the table data. I’m just going to trust and I’m going to hit F2.
>> SCREEN READER: DevTools documents.
>> NICK: Right arrow to find the D.
>> SCREEN READER: –TD>.
>> NICK: Delete the D.
>> SCREEN READER: D.
>> NICK: Type in H, F2.
>> SCREEN READER: [inaudible] panel.
>> NICK: Up.
>> SCREEN READER: <TH>.
>> NICK: Down.
>> SCREEN READER: <TH>.
>> NICK: Down again.
>> SCREEN READER: </TR>.
>> NICK: Now, there’s the next table row. Before we do that, let’s come back to our webpage. Let’s Alt + Tab
>> SCREEN READER: Use TalkBack gestures – Android Accessibility Help – Google Chrome.
>> NICK: Let’s navigate to the table with T.
>> SCREEN READER: Table with 3 columns and 10 rows.
>> NICK: If we come down to the next row, Alt + Ctrl + Down.
>> SCREEN READER: Pause or resume speech, row two.
>> NICK: Pause or resume speech. Now, remember when we went right before, all we heard was dash dash. We had no idea what that dash dash was associated with. Now–
>> SCREEN READER: Gesture, dash dash, column 2.
>> NICK: It announces gesture and then dash dash. If we go right again–
>> SCREEN READER: Multi-finger gesture, two-finger tap, column 3.
>> NICK: Right, it says multi-finger gesture and two-finger tap. It’s a reading the column header for us. Now, it’s not just for this row. If I come back to the left–
>> SCREEN READER: Use TalkBack gesture beginning of row.
>> NICK: Go down like six.
>> SCREEN READER: Start or– Talk– Practice gestures, row 6.
>> NICK: It’s pressed practice gestures, I go to the right.
>> SCREEN READER: Gesture dash dash, column 2.
>> NICK: Right again.
>> SCREEN READER: Multi-finger gesture, four-finger tap, column 3.
>> NICK: It works just fine. What happens if I go up?
>> SCREEN READER: Three-finger tap, row 5.
>> NICK: I hear three finger tap.
>> SCREEN READER: Two-finger double tap, row 3.
>> NICK: Two-finger double tap. I have no idea what these are. That means that the row titles aren’t being announced. Let’s go find one that we want to test out. We’ll go Alt + Ctrl + Left.
>> SCREEN READER: Action. Start or stop–
>> NICK: Let’s go to the top with Alt + Ctrl + Up + Up + Up.
>> SCREEN READER: Pause at top, top column.
>> NICK: Let’s come down.
>> SCREEN READER: Pause or resume speech, row 2.
>> NICK: Pause or resume speech. We’re going to use that one. It’s the first cell, it’s column 1, row 2. Let’s go up.
>> SCREEN READER: Action, row 1.
>> NICK: Let’s go right.
>> SCREEN READER: Gesture, column 2.
>> NICK: Gesture. Let’s go to multi-finger gesture.
>> SCREEN READER: Multi-finger gesture.
>> NICK: If we come down–
>> SCREEN READER: Two-finger tap, row 2.
>> NICK: Right, it just says multi-finger tap. Let’s change it so it reads the row title then it reads that. Let’s Alt + Tab over to our DevTools.
>> SCREEN READER: DevTools – support.google.com/accessibility/
>> NICK: It should still be hearing in the DOM. Let’s go down.
>> SCREEN READER: Level 16. <TR> </TR> closed. 2 of 11.
>> NICK: Here are table row. I don’t know if that’s the table row I want, I’ll go up.
>> SCREEN READER: Level 17. </TR>. 4 of 4.
>> NICK: Less table row.
>> SCREEN READER: <TH> </TH> closed.
>> NICK: That sounds right. We just made that table header there. I’m going to hit left.
>> SCREEN READER: Level 16. <TR> open. 1 of 11.
>> NICK: Left again and up.
>> SCREEN READER: Level 15. <body> open. 1 of 2.
>> NICK: There’s the body.
>> SCREEN READER: Level 16. <TR> </TR> closed.
>> NICK: That’s the table row that we already edited for our column headers. Let’s go down.
>> SCREEN READER: <TR> </TR> closed.
>> NICK: Here’s the next row in the table. It’s a TR table row. We’ll right arrow to expand it.
>> SCREEN READER: <TR> open. 2 of 11.
>> NICK: This one will likely also have three table data cells. In this case, the first one shouldn’t be a row header, which is what is the action that happens? The other two though, those shouldn’t be row headers. Those should stay as table data cells because they are data for the table. They’re the gestures. They don’t indicate associations between themselves and a subordinate table cell. They are the subordinate table cell to the row header or the column header. We’ll go down.
>> SCREEN READER: Level 17. <TD> </TD>. 1 of 4.
>> NICK: <TD> pause or resume speech </TD>. That TD says table data. It tells the screen narrator that that’s a table data cell, it’s not a table header cell. There’s no semantic relationship between that cell and the other cells in the table. Let’s F2.
>> SCREEN READER: DevTools document.
>> NICK: Right arrow.
>> SCREEN READER: TD>.
>> NICK: Delete the D.
>> SCREEN READER: D.
>> NICK: Hyphen H and hit F2.
>> SCREEN READER: [inaudible] panel, DevTools–
>> NICK: I’m doing my best to not talk when the screen reader’s talking. Sometimes it does unexpectedly. I’m going to Alt + Tab back over to the web page.
>> SCREEN READER: Use TalkBack gestures – Android Accessibility Help–
>> NICK: And I’m going to jump to the table.
>> SCREEN READER: Wrap interval, table with three columns and–
>> NICK: I’m going to navigate across this first row until I get to multi-finger gesture.
>> SCREEN READER: Gesture, multi-finger gesture.
>> NICK: Now, I’m going to come down.
>> SCREEN READER: Pause or resume speech, two-finger tap, row 2.
>> NICK: And we fix this one. In this instance, what we’ve done is we’ve fixed it which is neat, and now we know exactly what’s wrong. If we’re dealing with a developer, we might say the table on the– what’s the title? Let’s read the title bar.
>> SCREEN READER: Title is, Use TalkBack gestures – Android Accessibility–
>> NICK: Use TalkBack gestures. The table located on the used TalkBack gestures web page that is displayed when Version 9.1 in that button collapsed is expanded does not have its table headers announced for columns or rows when navigating table data cells. That’s a lot more technical than just saying, this table is difficult to understand. It gives the developer concrete information on how to fix it. Now, DevTools doesn’t change the web page itself. Anything we just did in DevTools didn’t actually change the code of this webpage, it just changed it temporarily for our instance of it right now. If I refresh this page with F5–
>> SCREEN READER: Use TalkBack gestures–
>> NICK: I just did it.
>> SCREEN READER: [inaudible] region use.
>> NICK: I’ll press T.
>> SCREEN READER: Table with three columns and–
>> NICK: I’ll go down-
>> SCREEN READER: Move to the next item on the screen, rotate–
>> NICK: -and then I’ll go right.
>> SCREEN READER: Right, column 3.
>> NICK: Right.
>> SCREEN READER: –Column 3.
>> NICK: It’s not announcing anything, so DevTools has been cleared. Wait, quick time check.
>> SCREEN READER: 11:49 AM.
>> NICK: All right. Let’s, I have one– I want to close DevTools, and then go over and look at another document I have called the Glossary for Desktop User Testing which is something we provide to all of our students. After that, I’ll see if there are any questions, but this will just give us a little bit of reiteration of how this is an issue and also how a beginner screen reader user tester would associate this with cleanly drafted text to give to a developer. I’m going to Alt + Tab over to DevTools.
>> SCREEN READER: DevTools-support.google.–
>> NICK: I’m going to Alt + Tab + 4.
>> SCREEN READER: Use TalkBack gestures–
>> NICK: Now, I’m going to Alt + Tab + 4 to a new document we haven’t looked at which is going to be called Glossary for User Testing something.
>> SCREEN READER: Topic, schedule, meeting, control. Talking point presentation, student one, glossary of findings and explanations for desktop-Excel, alert.
>> NICK: Glossaries of findings and explanations for desktop. We’ve created glossaries for desktop, which just means interacting with a webpage through a desktop browser. Primarily, we’ve created this glossary while using JAWS mainly but also NVDA for some. We also have another glossary for testing mobile devices, websites, and applications, and another glossary for testing PDF documents. Let’s come up here to the very top with Ctrl + Home.
>> SCREEN READER: First cell.
>> NICK: Before we– Well, what’s our objective here? Why did we come to this document, first of all? We came to this document to learn about tables, what can go wrong with tables from a screen reader user tester’s perspective, and how to report that to a developer. What are our column titles in this spreadsheet is always important. I’m just going to do, Insert + Up to read the current cell.
>> SCREEN READER: Categories, findings, explanations.
>> NICK: Oh, it read all the way across, but I’ll still write–
>> SCREEN READER: Categories.
>> NICK: Categories is the first cell.
>> SCREEN READER: Findings, B1.
>> NICK: Findings.
>> SCREEN READER: Explanations.
>> NICK: Explanations.
>> SCREEN READER: Instances.
>> NICK: Instance.
>> SCREEN READER: Impact levels.
>> NICK: Impact.
>> SCREEN READER: Tester notes.
>> NICK: Notes.
>> SCREEN READER: Related WCAG Success Criteria.
>> NICK: WCAG Success Criteria. We’ve created this for, like I said, desktop browsers, mobile devices, PDF documents for popular screen readers, and these are representative samples of pretty much any accessibility issue you might find that you can test for the screen reader. Of course, we probably didn’t get everything but it is definitely enough to get you going. Let’s go to the category section.
>> SCREEN READER: First cell, Categories, A1.
>> NICK: I’m going to apply filters just like we did at the top of the schedule, Ctrl + Shift + L, all-downer to expand the dropdown-
>> SCREEN READER: Menu, S.
>> NICK: -which isn’t really a drop-down, just a filter menu, an all-downer happens to work for it, but I wouldn’t technically call this a dropdown menu. We’ll Shift + Tab three times to get to our, I think they call it a list or table.
>> SCREEN READER: Cancel, Okay button, manual filter TreeView, (Select All).
>> NICK: It’s a TreeView which again, TreeViews typically contain items that can be expanded or collapsed, this does not– so it’s a little funky that they call this a TreeView, but again, we’re going to unselect all backing space.
>> SCREEN READER: Not checked.
>> NICK: We want to look specifically at tables. I could press T to jump right to it, but let’s go down and just see some of the other categories of elements that we teach screen reader users to interact with, and to understand, to assess, to report on. We’ll go down.
>> SCREEN READER: Level 0, carousels.
>> NICK: Carousels, a lot of people don’t like carousels, but they’re fun for a screen reader user tester because they get you to think. Down.
>> SCREEN READER: Sort Z to A. Sort A to–
>> NICK: Something happened, so I just hit Esc.
>> SCREEN READER: First cell.
>> NICK: I’m going to reapply the filter.
>> SCREEN READER: Menu, S, Okay button, manual fil– Not checked.
>> NICK: Go down.
>> SCREEN READER: Carousels, Error Identification, Error Suggestion. Focus outer (IE tab outer), not checked.
>> NICK: These are all issues we can look for.
>> SCREEN READER: Forms or name, row, value, graphics, not checked. Headings, not checked. iFrames, not checked. Keyboard, no checked. Language of page/language of parts, links, not checked. Lists, not checked. Meaningful sequence (IE reading order), not– Media content and players, not checked. Multiple ways, not checked. Other, not checked. Header, not checked. Page title, not checked. Regions, not checked. Site navigation, not checked. Skip links, not checked. Tables, not checked.
>> NICK: Here’s tables. Let’s just hit space to check tables.
>> SCREEN READER: Check.
>> NICK: Tab to okay.
>> SCREEN READER: Okay button, S.
>> NICK: Activate.
>> SCREEN READER: Autofilters on.
>> NICK: Now, if I come over to my next column.
>> SCREEN READER: Findings, B1.
>> NICK: We have findings. We have three different things here I want to point out. We have findings, explanations, instances. Findings are going to be general statements about accessibility issues. Explanations are going to be reasons why a finding is relevant and should be fixed. Instance is going to be language to point a developer directly to the issue that we see on a web page. Now, since web accessibility is an evolving industry, many different companies may have different approaches to how they would like people to test and report accessibility findings.
This is the way that we’ve developed internally at The Carroll Center. From what I’ve seen, the user testing I’ve done, even if this isn’t exactly how a company might like a screen reader user tester to report, it does contain all the knowledge and more than the required knowledge to report and work as a screen readers tester for a company. In this findings column, we’re just going to go down. Everything’s been filtered to the tables, and we’re going to try and find a cell that corresponds to what we just saw using the TalkBack website.
Again, what we saw was that table headers were not announced for columns or rows when navigating the cells of the table. Let’s just go down and let’s listen and see when we find that. Here we go.
>> SCREEN READER: Tables. A significant amount of data included for comparison is displayed in text. B1.
>> NICK: A significant amount of data is displayed in text. That doesn’t sound right. Let me slow this down a little bit.
>> SCREEN READER: Slower, slower, slower.
>> NICK: Next one.
>> SCREEN READER: Tables. Columns and/or rows are left blank.
>> NICK: Columns and rows are left blank, not quite. Some of our cells had dash dash in them, but they weren’t left blank. We’ll go down.
>> SCREEN READER: Tables. The table contains multiple column headers that span multiple rows and are not announced by a screen reader.
>> NICK: Spanning, I’ll just tell you, that gets a little confusing for someone who’s never thought about it before. This is not what we were doing there. Down again.
>> SCREEN READER: Tables. Some single cells in the table contain information that should be located in multiple cells.
>> NICK: All right. Too much information is created in one cell, that’s not what’s going on for us.
>> SCREEN READER: Tables. Table columns and/or headers are not announced by a screen reader.
>> NICK: Okay, cool. This is it. Table row and column headers are not announced by a screen reader. If we go right, we’ll see the explanation for this.
>> SCREEN READER: Explanations. Column and/or row headers should be marked up properly so that screen reader users can understand the relationship between the data and the corresponding column and/or row headers. Improperly marked-up data tables, column headers are announced when screen reader users navigate to the next or previous column and/or row headers are announced when navigating to the next or previous row, C129.
>> NICK: We’re going to read that again much slower. Let me slow the speed down.
>> SCREEN READER: Slower, slower, slower.
>> NICK: I’m going to go left.
>> SCREEN READER: Findings.
>> NICK: Okay. Let’s listen to this again. Again, table column headers and row headers are not announced for screen reader users. Here’s the explanation.
>> SCREEN READER: Explanations. Column and/or row headers should be marked up properly so that screen reader users can understand the relationship between the data and the corresponding column and/or row headers. Improperly marked-up data tables, and column headers are announced when screen reader users navigate to the next or previous column and/or row headers are announced when navigating to the next or previous row, C129.
>> NICK: Cool. There’s the explanation. We don’t have an instance for this. If I jump to the end of this row, we do have a signed WCAG success criteria.
>> SCREEN READER: Related WCAG success criteria, 131 info and relationships (level A) has a hyperlink.
>> NICK: All right, we’ve hyperlinked to that success criteria. What we’re saying here is, we’re saying that where a table does not have its column and row headers announced to a screen reader user, this is violating a WCAG 2.1 success criteria 131 info relationships, what is WCAG success criteria 131 info and relationships? I think looking at one more document here, we’ll wrap up this topic and then we can see about questions. I could hit enter here, I would open a tab in my browser. I already have that open in my browser, some of the alt tab over to it.
>> SCREEN READER: Use talkback gestures dash enter.
>> NICK: I have three tabs open here. I know the third tab is the WCAG success criteria for 131, so we get control three to jump to it.
>> SCREEN READER: Final exam dash.
>> NICK: No problem.
>> SCREEN READER: Understanding.
>> NICK: Let’s speed up this voice just a tad.
>> SCREEN READER: Faster, faster, faster.
>> NICK: Let’s read our title bar.
>> SCREEN READER: Title is understanding success criterion 131, one colon info and relationships-Google Chrome-Nick left-Carol.
>> NICK: Understanding success criteria and 131 info and relationships. That’s cool. All this success criteria have a little label with them and this one’s info and relationships. It’s just like information that is conveyed visually must be programmatically conveyed to screen reader users. Just if something is presented to someone in one modality, that same information must also be presented in modalities for other people who access the information in a different way.
If you just Google like WCAG 2.1 guidelines, you’ll find a big list. There’s headings there, I think your WCAG is broken down into principles, guidelines, success criteria. Your principles are all at I think, level two headings, guidelines level three, success criteria level four. You can jump around that webpage. Beneath each success criteria on the WCAG 2.1 website is an understanding the success criteria link. That is the page that we are on right now, the understanding 131 info on relationships WCAG 2.1 success criteria.
Quick as a little side thought, as we’re looking at this one here, just keep in mind, I’m talking specifically about WCAG 2.1 not 2.2. 2.2 is slated to be released this month. The only difference between 2.1 and 2.2 is that they are adding additional success criteria. I think right now there’s 78 success criteria and WCAG 2.1 and they’re adding nine additional success criteria in 2.2. That’s the only difference, you only have to orient nine more success criteria, which isn’t a daunting task. Once we get WCG 3.0 that’ll be a complete revamp, I believe, but that’s five years down the road.
Let’s jump to the main region on this page for 131 info on relationships. With JAWS Q, Q will get us there. I’ll press that. Lets down arrow and read a little bit.
>> SCREEN READER: Heading level two intent. The intent of this success criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.
>> NICK: We don’t want to try and understand any of that right now, we can hear it and we can understand that it’s telling us a little bit about what’s going on here for 131. This is really where you want to go. This is where you’re going to get the meat of your knowledge as a screen reader user tester. This gives you all your legitimacy and how you can validate what you’re saying.
I want to point you to one section on this page called examples. I’m going to use my headings to get there. I’m going to press H.
>> SCREEN READER: Note heading level three. Benefits heading level two, examples heading level two.
>> NICK: We have a list of examples here. I’m just going to go down and try and find an example that matches what’s going on on the website we just looked at for using talkback on Android with a table column and row headers weren’t announced. I’m going to do CTRL down arrow to move my paragraphs.
>> SCREEN READER: List of five items. Validate form with required fields.
>> NICK: A form, no.
>> SCREEN READER: A form contains several required fields, validate form that uses color and text.
>> NICK: Another form, table is not a form, we don’t care about that.
>> SCREEN READER: A form contains both, validate will schedule table with a headers for each cell can be programmatically determined.
>> NICK: That sounds right, a table, a bus schedule, anything with a table and headers to be programmatically determined, this is in relation to what we were talking about. Let’s go down and see if there’s an explanation.
>> SCREEN READER: A bus schedule consists of a table with the bus stops listed vertically in the first column and the different buses listed horizontally across the first.
>> NICK: What it just said there is your buses are in the first column all the way to the left of your table, if you measure a piece of graph paper, big braille graph paper, column one is on the left side going up and down. Those are all your bus numbers going across the very top of that piece of paper and the little squares or the grids of a table is the bus stops. As we’re moving in the meat of that table, we want to see that the column and row titles are announced. Let’s see if they say anything more about this.
>> SCREEN READER: Each cell contains the time when the bus will be at the bus stop. The bus stop and the bus cells are identified as headers with their corresponding row or column, so that assistive technology can programmatically determine which bus and which bus stop are associated with the time in each cell.
>> NICK: They’re saying the column headers and row headers are announced as table headers. If you recall when we edited our table and dev tools, we were taking TD tags, less TD grader and changing it to less TH grader. So from table data to table header. Let me jump over here really quick.
>> SCREEN READER: Meeting control.
>> NICK: Stop my screen share. I think now might be a good time to see, are there any questions about what we’ve said so far?
>> AMBER: There were a few. Let’s see. A quick and easy one, Mark was wondering is that glossary Excel spreadsheets something that the Carroll Center makes available to the public, or is that just for your students?
>> NICK: Presently, this is only available to our students. It’s constantly being updated and if you think about it, if we have issues that are going on for the web, the web is not a static thing, it’s always changing. This glossary has to be constantly updated. That’s presently updated by instructors of our program. It’s made available to our students. We’re working on continuing education opportunities for graduates of our program since the young program that’s still on the stove being cooked up, but no, the glossary is not publicly shared at this time.
>> AMBER: There’s a question about the table, and I know we saw one of those as you’re going through row items, but Ruton asked, if the webpage developer inserts a blank space in a table cell using a spacebar, the screen readers announce it as blank, and would that be preferable to the –?
>> NICK: I think this is a good time to point out how much coding is actually used for a screen reader user. When you say spacebar there, it sounds like we’re getting a little technical, like going into the minutiae of how should a table be coded. There’s so many different ways to go about coding things, not just a table, but maybe an element, a button. A button can use a native HTML button tag or you can build it as a custom element within a div tag, but all these things, they get into the code and they scare people away. You don’t need to know all this to be a screen reader user.
What you need to know as a screen reader user tester is, are you getting the information that you need to get? If we’re navigating a table, and we land on a cell, and it announces blank, or it announces –, it’s something to know. I think the real key thing there is the associations of the row and column headers, good and sufficient enough to make you know what that cell is supposed to do. We should never, though, be leaving blank cells in a table for formatting purposes.
If you want a blank column in a table, you really shouldn’t code that column into the markup, you should use CSS to adjust the column width of the table to visually the style table of CSS. HTML is the structure of your page, you never use HTML structural elements to achieve a visual design. You want to use the appropriate code in this case, that would be CSS.
>> AMBER: I’m guessing in an instance, like the table you showed us where there isn’t a gesture, would it be best really, for them, the content creator to have written the word non or not applicable or something, rather than just putting dashes?
>> NICK: Maybe, but if a screen reader user tester is reporting something like that, what they’re really doing is they’re making a recommendation from a user experience, not a user tester point of view. If I had someone in my class, who was spending a lot of time making recommendations like that, I would be concerned that they weren’t trying to really get to the meat of what a screen reader user tester does. That’s just language.
>> AMBER: That kind of thing is less a weak-eyed failure than just a better user experience, overall?
>> NICK: Correct. Certainly advisable for screen reader user testers to make user experience recommendations appropriate, but I would always wait if you’re in any kind of subordinate role, you have a manager who’s doing your projects, you’d want to know what does the client really want. Does the client want you to include user experience recommendations or not? If not, then there’s no place for that kind of talk. If they do, it’s great, fantastic.
>> AMBER: I have a follow-up on that, how do you draw the line between accessibility and user experience?
>> NICK: I think the more technical you become, the more you understand the code, the markup, weak hag, the more it’s easy to draw that line. I think when you’re beginning, it’s very difficult to draw that line. I’ll speak with a lot of people who say that they love accessibility, but then a lot of what they talk about is strictly user experience. It’s not accessibility, success or failure. You draw the line as you learn. It is definitely a gray area. It is a judgment call thing, kind of thing, you need some creative aptitude in your thinking processes.
>> AMBER: This may be a follow-up and maybe you don’t have anything else to add on that same, but there’s another course that said when webpage authors hit the inter key to add more white space to webpages, does that add the announcement of blank for screen readers? Is that considered an annoyance or a problem?
>> NICK: I don’t know, particularly. I know I’ve built a webpage, just a notepad using HTML, and then I’ve updated or opened that in a browser and I’ve done that exact thing. I’ve thrown extra enters into the page I built , and it seems that those aren’t detected by the screen reader as blank lines on the webpage, but I have been on web pages where I experienced blank lines. I would say whenever you’re doing any stylistic thing, visual display, again, we want to bring it back to using CSS to accomplish that goal. If you do come across a webpage and you’re hearing a blank line, that might be an ideal opportunity to open up dev tools explore the Dom and figure out what is code associated with that blank line that you’re experiencing?
>> AMBER: There was another question that came in the chat. Peter asked, are there context, specific screen readers, or certain modes or settings, for example, would you be able to turn your screen reader into something where it understands HTML and rather than reading, greater than slash, less than, it would say like, close TD tag?
>> NICK: No, I don’t think so. I think if we were to actually try and answer that, the screen reader does what that person is requesting when it’s on a webpage itself. When we press T and we jump to a table, that’s the screen reader interpreting the HTML in a comprehensible way. There’s no between area, I don’t think. There’s not like a, let the screener interpret it just enough for someone using code, so they don’t have to know code. I don’t think that’s possible.
>> AMBER: If you were using the screen reader in a code editor, it would still just read out the actual characters, like greater than, less than all that read out the HTML language, I guess?
>> NICK: Yes, that’s correct. It would read the markup as opposed to the UI interface that it typically would read.
>> AMBER: Let me look and see. I think that might have been all of the questions right now. Oh, Isla did say, she’s heard that carousels are ‘bad’, but I noticed there’s one in the carousel on your website. Can you speak to what makes that specific carousel work for a screen readers? She’s not a coder, but is very curious,
>> NICK: The carousel center website. I could pull it up now and try and actually run through it, but I think that might take a little bit of investigation on my part. For a screen reader user, it would take me probably about five minutes to orient to a carousel on a webpage, if I knew that that page contained a carousel. The issue with why people think carousels are bad, it’s we don’t always know that they are on a webpage and we hear web content changes, we navigate the page.
My mind when that happens, I’m either thinking that the page is refreshing. My focus is being jumped around and there’s something up with the webpage, when actually I’m just encountering a carousel. The question becomes, how can we make the carousel better for screen reader users?
I think if we say, stop using carousels they’re bad, and this is probably my perspective more than a recommendation by an entity that creates standards, but I would say– I would never recommend to stop using something because it seems confusing. We should rather try and invent creative ways to make popular tools accessible. That just benefits and furthers innovation.
For a carousel, for instance, one way to make this work a lot better is to nest it within a region. If we nest a carousel within a region and we come to a webpage, as we press R, we would jump to a region or all the regions of the page. When we encounter the region containing the carousel, hopefully, we’ve labeled that region in such a way that it informs the screen reader user that it contains a carousel.
I believe we can give a region a name by itself, or we can use aria to assign a label to a region. In that way, we would inform someone that a carousel exists. Other popular issues that appear with the carousel is things like play, pause buttons not being labeled, a next or previous slide button being labeled right arrow or left arrow, where it just doesn’t give you enough information. Those issues there with play, pause, next, previous, those are actually button concerns, but they’re popular button concerns that happen in the context of carousel.
Even right here, you’ve seen me say carousel, regions, buttons, and labels, everything that we’re teaching in the screen reader to user tester training program, is it intersects, and it creates this beautiful ecosystem of knowledge that once you get the associations, you can start to paint these pictures in your mind and articulate those pictures to people of how the web works in accessible way.
>> AMBER: I appreciate that. It sounds like the screen reader user testers need to learn a lot of HTML in order to understand?
>> NICK: Not a lot, really. If we were to try and break it down, I’d say if we can understand maybe 20 tags, pretty intuitive tags, like less header, less body, a list tag, table tag, headers, graphics, links, you can get a sense of those. We don’t need to even need to look at the code. We just look at less word grader. We do about 20 of those, and then we say this one relates to this one and this way, this one is subordinate to this one. This one is a parent to this one, this one, and this one. Then we understand how they relate to one another. Once we do that, we can understand the hierarchy, the semantics of a page.
>> AMBER: I think those are all the questions we have for now. I’ll go back on mute and let you take back over.
>> NICK: All right, cool. I believe my screen shares are still not on, and I’ll leave that off for now. I’m going to jump over to a notes document I have. Let’s see where I’m at. Let’s look at a student profile. What does a typical student look like? A typical student of my program, or let’s say maybe you don’t even want to do the program that I teach, and you’re just interested in a screen reader to user testing, what kind of person are you and would that be a good fit for you?
You’ve been using JAWS for, at least, three years likely. It’s just a generic benchmark that we use, but you’re familiar with it. You can create word documents, you can edit word documents, make sure they have no errors first. You apply headings, you apply lists. The structure of your document makes sense. Say a heading level one is the primary name of your document. Then you have subsections of your document heading level two, subsections to subsections at level three. You’re already implementing semantics in your own work.
You access the web regularly. You browse for fun. You browse as part of work. You use webpages that you don’t use all the time. You have your standard group of webpages that you go to, but you also are very comfortable jumping onto new webpages and orienting yourself to it. Or you’re semi-comfortable, even if you’re not very comfortable in our course, we can get you there. Your prerequisites, you’re going to make sure that you have basic intermediate web browsing skills with multiple tabs, word document, emailing, a calendar. If you can use a calendar that’s preferred. If not, we teach it in our course, Google calendar, and Outlook calendar.
You’re good with online video conferencing and you’re detail-oriented. You enjoy technology. You can sit there all day. What does your work day look like as a screen user tester, you’re sitting at your computer, you’re looking at digital products, you’re analyzing them, you’re thinking about them and you’re writing, reading, writing, and thinking. That’s what a screen reader user tester’s doing, and toward the ultimate goal of communicating and remediating. If that’s you, that’s great.
Let’s take another quick screen share here and come look at a student profile, what you would encounter in my course here. I’m going to go to the Zoom window, control shift ALT, [inaudible], shared screen. Just make sure it’s not going to talk. I have a folder open here called student one. I’m going to alt-tab over to that.
>> SCREEN READER: Talking points, understanding glossary topics, presentation with student one.
>> NICK: Cool. I have a number of files here and in addition to the quizzes that we do in the course and the file exam, these are all of the documents that we’re going to ask you to edit. If I go to the top.
>> SCREEN READER: PowerPoint.
>> NICK: There is.
>> SCREEN READER: About my SRUTT experience.
>> NICK: About my SRUTT experience. SRUTT is Screen Reader User Tester Training. That’s just a journal. We’d like people to keep a journal and let each student in my course, or the course of the Carroll Center see each other’s journal. Create community and learning experience. I think it’s really powerful. If we go down.
>> SCREEN READER: PowerPoint Project Report.
>> NICK: People generate a PowerPoint. This is not great at the PowerPoint. Each person’s assigned either an overview of WCAG or to talk about one of the four WCAG principles, which are perceivable, understandable, operable and robust. Just take one of those and explain what it means. Another project is this one.
>> SCREEN READER: Project 1 report.
>> NICK: Project 1 report. We might go into this document and take a quick look at it. On this one, we go to a webpage, and we analyze that webpage without a task script. We look at the page and we say, all right, what’s wrong with this page? We run through it by element, and we report on that. That’s where we really have to look at that glossary document that we have and say, all right, here’s the glossary. Here’s everything possible that could be wrong with a webpage, and here’s this particular webpage. Now do things on this webpage, violate or align with the violations reported in the glossary of findings?
As you get to know these things, you don’t need the glossary over time, and you can analyze a homepage freestyle. That’s really the end goal, I think. Another report that people do is Project 2.
>> SCREEN READER: Project 2 report.
>> NICK: This one follows a task script, and we do this one with NBDA. A task script follows a flow, so a flow would be anything like signing up for a newsletter, booking a train ticket. Where the steps in the flow are interdependent, you must create an account before you purchase a ticket, that kind of thing. It would be task one, step one, so it’d be 1.1. Task one, step two, would be 1.2. Then once you finish task one, you go on task two. It’d be 2.1, 2.2. That just gives you a much more of a clear roadmap in a screen reader user testing, as opposed to a freestyle webpage manual audit, which we do in project 1. If we go to project 3.
>> SCREEN READER: Project 3 report.
>> NICK: This one is just analyzing. We analyze a mobile application, on an iOS device with voiceover. Finally, our project 4 reports.
>> SCREEN READER: Project 4 report.
>> NICK: Looks at PowerPoint. Let’s quickly look at one of these project reports. Let me check the time.
>> SCREEN READER: 12:19 PM.
>> NICK: We’ll come on up.
>> SCREEN READER: Project 2 report, project 1 report.
>> NICK: If we hit enter here.
>> SCREEN READER: Alert, this document is safe to edit, please wait.
>> NICK: Let’s just read our title bar.
>> SCREEN READER: Title is project 1 report.
>> NICK: We have a couple sheets. We use a lot of Excel in this program. This first sheet is called specifications. I’m going to fill it out with you. If I go right.
>> SCREEN READER: User input.
>> NICK: User input. We’ll go down.
>> SCREEN READER: Tester name: blank B2.
>> NICK: We’ll just type test. I’ll hit enter.
>> SCREEN READER: Does this report follow a task script?
>> NICK: We use a lot of dropdown menus here. This one we’ll say no, it does not. I’ll hit Alt down arrow to get a dropdown menu in the cell.
>> SCREEN READER: Yes, no.
>> NICK: I’ll hit enter.
>> SCREEN READER: No, B3.
>> NICK: We’ll go down.
>> SCREEN READER: Operating system:
>> NICK: Another dropdown. We’re going to select Windows.
>> SCREEN READER: Chrome, Mac or Windows.
>> NICK: Enter.
>> SCREEN READER: Windows.
>> NICK: Down.
>> SCREEN READER: OS version:
>> NICK: We’ll just put 11, enter.
>> SCREEN READER: Browser/app:
>> NICK: Browser. Let’s do alt down.
>> SCREEN READER: Desktop app.
>> NICK: Let’s choose Google Chrome. I’ll go down through the list of choices.
>> SCREEN READER: Google Chrome.
>> NICK: I’ll hit enter.
>> SCREEN READER: Google Chrome, B6.
>> NICK: Down again.
>> SCREEN READER: Browser/app version: blank–
>> NICK: We’ll just put X.
>> SCREEN READER: Leaving table–
>> NICK: Not sure what it is. We’ll hit enter.
>> SCREEN READER: Screen reader: blank.
>> NICK: Here we’ll select JAWS.
>> SCREEN READER: Chromebook, JAWS.
>> NICK: Enter.
>> SCREEN READER: JAWS B8.
>> NICK: Down again.
>> SCREEN READER: Screen reader version:
>> NICK: 2022, enter.
>> SCREEN READER: 2022, B9.
>> NICK: That’s it on this sheet. Now if we come to our next sheet control page down.
>> SCREEN READER: Report at first cell.
>> NICK: This looks just like the glossary that we looked at earlier, where we had all the table finding and the table explanation. If we look on the left here, we have a date.
>> SCREEN READER: What date? A1.
>> NICK: That would be the date for any issue we find. Go to the right.
>> SCREEN READER: Website URL, B1. Contains formula.
>> NICK: That formula, dependent upon our inputs on the specification sheet, this cell will say something different. If we said yes, it followed a task script, this cell would say task number. We go to the right.
>> SCREEN READER: Category C1.
>> NICK: We have category. If we come down.
>> SCREEN READER: Blank, C2 contains data validation drop.
>> NICK: This has a dropdown menu too. So if we’re reporting something about headings, we would hit Alt down here.
>> SCREEN READER: Page title.
>> NICK: We just go down through our choices until we find headings.
>> SCREEN READER: Language, meanings, focus, headings.
>> NICK: Hit enter.
>> SCREEN READER: Headings, C2.
>> NICK: That’s how we kind of fill out reports. Let me close this. I want to see if I can try and show you one more thing and have time for maybe one more question. All the four.
>> SCREEN READER: Microsoft, Excel–
>> NICK: I’m not going to save that. Time.
>> SCREEN READER: 12:22 PM.
>> NICK: PDFs, a lot of people get scared of PDFs. I think PDFs can be daunting mainly because we don’t use them every day, right? We use the web all the time. We don’t use PDFs every day. It’s fairly simple to assess if a PDF is inaccessible and why that might be. Let’s take a quick look at one. Let’s Alt tab. We have a folder open called the presentation materials. We’re going to look for that.
>> SCREEN READER: Student one, meeting, control, talking point, understand topics, presentation materials.
>> NICK: I think it’s called microwave cooking or 03 or maybe it’s 0, and I’ll just go down.
>> SCREEN READER: Glossary of findings and explanations, 03 microwave cooking.
>> NICK: Here we go. I’m going to open this and it’s going to open Adobe. We do all our PDF testing in Adobe, and I want you to watch if a dialogue box is going to pop up. It may pop up right away, it may take a second. We’re going to watch for that dialogue. We’ll hit enter. Read our title bar.
>> SCREEN READER: Title is 03 Microwave cooking.pdf-adobeacrobatreaderdcleft-64-bitrate.
>> NICK: I think it might have popped up. We’ll hit insert B and see if we can read a dialogue box.
>> SCREEN READER: Reading untagged documents with assistive technology dialogue group. An assistive technology like a screen reader may be running on your machine. This untagged 3-page document must be prepared for reading with assistive technology.
>> NICK: We get this dialogue box and we see this a lot with PDF documents. It says reading an untagged document with assistive technology. What does that mean? What is an untagged document? I like to think of it this way. A PDF document is just a local website, essentially. It’s not on the web. It’s a PDF, it’s a protected document, but it works just like a website. You can navigate it with quick keys, headings, tables, there’s links in it, there’s graphics. If it’s not tagged, that means there’s no markup backing up the content of that page.
Let’s say we were on a website and we pressed H and it says, no headings on this page. Visually, there’s got to be some headings. It’s like someone on a webpage took text and they increased the size for a certain line of text, they bolded it. Now that’s visually a heading to everyone, but programmatically, it’s not coded as a heading. Screen reader users don’t know that that heading exists because programmatically, it does not. It’s just visually depicted.
A PDF document that’s untagged is doing much the same thing. It’s been formatted to look good, but there’s no semantics, no code, no tagging built into the markup of the document to make it accessible for screen reader users. I’m going to tab over the to the okay button on this dialogue.
>> SCREEN READER: Read the- do not start button, alt–
>> NICK: Start, I’ll hit space.
>> SCREEN READER: 03 microwave cooking.pd–
>> NICK: Let’s read the title bar.
>> SCREEN READER: Page has no links, zero–
>> NICK: Insert T.
>> SCREEN READER: Title is, 03 microwave–
>> NICK: Cool. That dialogue’s gone. Now, it said untagged, so if I hit H.
>> SCREEN READER: There are no headings on this page.
>> NICK: No headings, G.
>> SCREEN READER: Two graphic.
>> NICK: They got an unlabeled graphic. That’s not great. A table.
>> SCREEN READER: There are no tables on this page.
>> NICK: No tables. There’s another way to determine if this document is tagged or not, but it’s not intuitive. We have to be creative. If we open up our properties dialogue box within Adobe for a PDF document that we’re analyzing, we can explore some things. I’m going to press control D.
>> SCREEN READER: Document properties, dialogue, the document security method.
>> NICK: I’m going to switch over to the description tab. Just like how on a web browser, if we’re changing tabs, I’m going to use control tab here.
>> SCREEN READER: Fonts tab.
>> NICK: Again.
>> SCREEN READER: Custom tab.
>> NICK: Again.
>> SCREEN READER: Advanced tab.
>> NICK: Again.
>> SCREEN READER: Description tab.
>> NICK: Here’s the description tag or tab. If I hit down arrow, though.
>> SCREEN READER: Description tab, security tabs, fonts tab, custom tab, advanced tab.
>> NICK: It’s just reading the tab bar all the way across. I’ll do it again.
>> SCREEN READER: Description tab, security tab, fonts tab, custom tab, events tab.
>> NICK: I can’t move anywhere, but there’s another way to access the content of this dialogue. We could tab, but tab also doesn’t show us everything. I’m going to route my PC cursor to my JAWS cursor with JAWS key left bracket.
>> SCREEN READER: Route Alt to PC.
>> NICK: Now I’m going to turn on my JAWS cursor with JAWS key P.
>> SCREEN READER: JAWS cursor.
>> NICK: Now when I down arrow.
>> SCREEN READER: Description group. File:03microwave cooking. Title: Microwave cooking for the college bound student.
>> NICK: We can review a bunch of content.
>> SCREEN READER: Author: Sandra Bastien.
>> NICK: Within this properties dialogue box, and at the end of this thing, if I hit control N and up arrow and listen for the word tagged.
>> SCREEN READER: Tagged PDF: No fast web view.
>> NICK: Tagged PDF document: No. It’s telling this is an untagged PDF document. If we were working on an accessibility team and someone said, can you analyze this PDF document, this is one of the first things you would do. You would verify if this document is tagged or untagged, and there’s a couple of other ways we can look at PDF documents to analyze other accessibility barriers. Let me stop my screen share again.
>> SCREEN READER: Meeting controls.
>> NICK: Let’s see, 1227, so we’re like three minutes. Are there any final questions, Amber?
>> AMBER: I think it would be good to talk just a little bit at some nuts-and-bolts questions about the Carroll Center, just for people who aren’t familiar. It’s a nonprofit organization, right?
>> NICK: That’s correct.
>> AMBER: Is the training course in person or is it remote?
>> NICK: This training course remote.
>> AMBER: People can live anywhere in the world?
>> NICK: Yes.
>> AMBER: Cool. How long does it last?
>> NICK: Seven weeks. This next offering is from October 3rd to November 18th, from 9:00 AM to 3:00 PM Eastern time with tech support and job support sessions from 3:30 PM to 4:30 PM in the afternoons on Monday, Wednesday, Friday. It’ll likely be held in the same format in the spring, but I’m actively working toward trying to make this more of a self-paced course. That’s not presently available, but that’s something to watch out for in the future.
>> AMBER: Do you do any, or would it be appropriate for a sighted person to take this course, or do you have a different one if they want to learn how to be a better screen reader tester, or even how to use screen readers, in general? Or do you typically only focus on training people who are blind with visual impairments?
>> NICK: Due to our mission and our goal at the Carroll Center, right now, we’re focusing on providing this to people who are blind and lived screen reader users. We think that people who use screen readers every day have a certain set of skills that really can’t be matched by someone just intellectually learning a screen reader and using it professionally, as opposed to every single day, all the time needing to depend upon it. We’ve had a lot of requests for sighted instruction on this same topic. That’s also something that I’m working on. It’s a priority. I wouldn’t say that it’s an immediate priority.
>> AMBER: That makes sense. I definitely agree with you. I think that bringing users in gives you a whole different picture of a website than having the developer who developed it test it with the screen reader, right?
>> NICK: Sure.
>> AMBER: On that front, I think you all also do do user testing for companies or organizations who need their website tested, is that right?
>> NICK: Not so much anymore. The Carroll Center is beginning a strategic pivot where this program is becoming the focus of our accessibility endeavors. I don’t think I’m at liberty to talk anymore about the activities there.
>> AMBER: We had one other question I think about the program. Does the program cover the importance of properties or metadata on files and web pages or long descriptions for complex or interactive content?
>> NICK: It does. A long description for a complex image is one way to provide accessibility for something that contains too much content. Let’s say, maybe a map that shows the houses within the estate, you can’t really provide short all-text for that, you need a long description, so we do talk about that. Metadata, if you look at a PDF document and you read the title bar and it says .PDF in the end of the title bar, but then you look at the description page and the properties dialogue box for a PDF document, and you see that it does have a title, we’re not really sure why the file name is being announced when the title bar is read when the file in the actual title should be announced. That’s an issue in the metadata.
We don’t talk about remediating that metadata issue, but we definitely get to the point where we can understand when that is a problem.
>> AMBER: I think that may have been all of the questions that came in. If someone wants to contact you for follow up information or they want to learn more about the Carroll Center, what’s the best way for them to do that?
>> NICK: If people want to learn more about– everyone can reach out to me directly. Let’s see, if I open nick.corbett@carroll.org, I just posted that. I think I posted that. If not, it’s nick.corbett@carroll.org, that’s my email. If you also just Google Carroll Center for the blind, you’ll find the main website. We have a contact us link or form right on that page. If you also Google screen reader user tester training, we’ll be at one of the top results in Google. On that page, which also is going to be put in the chat, I think Paula put it in there, there’s a pre-screening assessment, which you can take to see, would I qualify for this course? There’s no commitment to take that pre-screening assessment.
>> AMBER: You’re not doing the training through the Carroll Center anymore, but if someone needs to hire a screen reader user tester, you do job fairs and things like that?
>> NICK: Yes. All of our graduates, we’re trying to work with a lot of companies in Massachusetts and around the country, to create paid opportunities for our program graduates. This last spring, we had four people graduate within two months. Three of them had three-month paid internships making well above minimum wage. I think that was really cool to see. We’re continuing to promote those types of partnerships, so that people who go through our course have the opportunity to make money and also gain more experience to advance in their accessibility careers.
We have a couple of other strategic creative initiatives around employment that we’re going to begin to incorporate into this course too.
>> AMBER: Thank you so much. I really appreciate it, Nick. It’s been really great having you and very informative and a great presentation. I think someone else mentioned in the chat, which you may not have heard earlier, that they really appreciated how you described the keyboard shortcuts that you were using and what you were doing as you were doing it. We got that picture of what we couldn’t see happening behind the scenes. That really was great. Thank you.
>> NICK: Cool, my pleasure. I’d be happy to have a chat whenever needed.
>> AMBER: As our final, I’ll just share my screen real quick and I’ll do a quick reminder, WordCamp U.S. is next week. There’s multiple talks on accessibility that will be live-streamed. Then on Monday, September 19th will be our next meetup, and Glenn Walker, who you may have seen in the chat because he was attending today, will be showing how he approaches manual testing on a website. Thanks so much, everyone, and have a great day.
[] [END OF AUDIO]
