Welcome to Screen Reader Testing and Website Support for Beginners. Some of the things that you see in this session, you're also going to experience during the advanced screen reader session later on. And that's going to include the inaccessible site that we found. Just so you guys know, when we go to that site, University of Washington intentionally created it as inaccessible so that people can demo it and use all of the features to teach folks all the things that if you do them, what they're going to cause for an experience for someone.
So first I'd like to introduce us, the presenters. So to my right is Matt McCubbin. He's from the University of Massachusetts Boston. And he is going to be doing the demo portion of the presentation when we switch over to that. And then I am Kristina England. You've received a lot of emails from me over the last month. And I am the co-chair for the retreat and I am going to be doing the PowerPoint slides of this presentation.
So feel free to stop us at any time. The only problem for the online folks is that I'm going to be running the presentation and doing the monitoring of zoom at the same time. So I apologize if I don't get to your questions like right away. I'm going to try to. So what are we going to be going over today? So today, we're going to be going over why WCAG 2.0? We're going to be going over the core principles of accessibility, semi-automated accessibility testers. And we'll talk about why they're only semi-automated. Why manual testing matters, and that's when we're going to get into the demo portion.
And then we're going to turn it over to you guys. You're going to turn on those screen readers you installed and you're going to experience what it is like if accessibility is not applied to a site. You're going to also test your-- so you're going to go to your own site to see if you can find accessibility issues. Because that's one of the goals of today, to experience what it's like to actually navigate a site that you're familiar with with the screen reader.
I did have you guys also install semi-automated testers. We won't do that portion. But you guys can actually pull that up just so you can see the violations. But you'll get more into that during the advanced class. And that's why I've had you guys install those. OK. So why WCAG? Perfectly there. So section 508, that was actually published over 17 years ago. They just came up with a refresh that goes into effect in January 2018. It was published in January 2017, but they extended the time frame in which it goes into effect.
So if you can picture the original section 508 guidelines that vendors go by, those were published before the iPhone. So we're talking about a long time ago and I always say before the iPhone. And so a lot has changed with websites in that time. And one of the big things about them, no success criteria to actually test the accessibility guidelines against. The nice thing about WCAG 2.0 is it was created by web developers and accessibility testers. They created success criteria to go along with the violation, so that you could take a look at, what is it that I need to do to my site to fix it so that it passes.
So you actually have to go through those success criteria, which is huge. It was rolled out in-- 2.0 was rolled out in 2008. And just, guys, anyone on the phone, if you guys can make sure you're on mute. I can switch over and lock you guys all out, too. But I know someone's not on mute. The good news is WCAG 2.1 is going to be released in 2018-- and I'm going to mute someone. Yes, web accessibility--
Web Content Accessibility Guidelines.
Mute all. Sorry, guys. No, don't allow them to unmute. Now I have to unmute you all. That's much more quiet. And the big thing to remember is that when you're thinking about WCAG 2.0 guidelines, ensure that you're thinking about them from the beginning of the process of developing your website. Don't wait until the end when your website, you know, you have a month to launch and then you run all the tests. Because if you do and you're not keeping all those guidelines in mind, chances are, your site is not going to be accessible.
Iris knows nothing about that. So, what are the four principles of accessibility? They are perceivable, operable, understandable, and robust. It's called POUR, as in pouring water, not poor as in, you know. A lot of people joke about that all the time. But as if you were pouring water. So perceivable is information and user interface components must be presentable to users in ways that can be perceived. Users must be able to perceive the information being presented. It can't be invisible to all of their senses.
Operable, user interface components, navigation must be operable. You'll run into a lot of forms that you can't actually operate with a keyboard. And we don't know anything about that, Iris, right? Users must be able to operate the interface. Yes, and they're actually available on the retreat site as well, yeah. So I'll send those out after the fact, too, where you guys can download them. And the good news is we did accessibility testing on all of them, so they're also screen reader accessible.
Understandable. Information and the operation of user interface must be understandable. Users must be able to understand the information, as well as the operation of the user interface. And I know these are kind of dense, but when you get into the actual detailed guidelines, they make a lot of sense. But all of the guidelines are based off of these four principles. And then robust. Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
So how many people do both-- so first of all, how many people have an accessibility testing tool in-house already? So, something like Site Improve or Ainspector. Yeah. OK, and I know I have it all ready on the slides, but why would you consider it to be semi-automated? So it's only going to catch about 60% of the violations. Because for over 40-- I think it's about over 40% of them require manual checking. There's no way a semi-automated testing tool is going to be able to find those issues. Looks like no one's asking questions on the chat.
So things you have to keep in mind, when doing testing. So you run that testing tool, which it will catch a lot of them. And then you can-- as you're developing, you can fix those violations. But then you want to go in and you also want to use a color contrast simulator, to be able to see, hey, are these colors different enough or are people going to be able to tell the difference between these two colors? Like if I flip them and I have like a blue background but I have a light blue text, and I flip them, can people see that?
And then you want to be able to keyboard. One of the ones that often missed is zoom in, how you zoom and how the site performs when you zoom in on text. And for low vision folks, that's extremely important, to be able to zoom in on text and what is the experience when you do that. And there are several other ways in which you can test a site. And one of the ones that we're not getting into today is even how to mobile test on iPads and stuff. And Matt actually runs a testing session for that as well.
So those are things to keep in mind. Don't just use that automated tester. It's so easy to think that's going to catch it all. It's not. And anyone that tells you it will, don't listen to them. Yes?
WebAIM... Wave has a color contrast tester.
It does. Yeah, you can use--
Yeah, so the semi-automated testers won't recognize everything. And the color contrast, that's one of the ones where it actually has a separate tool where you can test it and simulate. But if you can simulate, like what I do I actually go on my iPhone and I convert to the-- the iPhone has great selections of the four common colorblindness. So I convert it and I just look at all my sites via that. Because it's better to me than running the test that says, yeah, this passed. What does that pass mean?
You want to make sure that you don't have content that can only be distinguished by color. That's another big thing that we see, is content that--
The red text or the blue text.
Yeah, everything in red is required.
Yeah, so we want to make sure that you-- that's a very common issue on forms, is that the red items are mistakes. And so you want to make sure if you're coding a form, that you have other ways of indicating that there are errors.
[Inaudible note by participant].
Yeah, it is good but it always helpful to use that iPhone or something else to switch over.
That would be great to have as a presentation.
Yeah, yeah. I think Tracy is going to be doing more code, how to fix the code in that. So manual testing, why it matters. So I put my example up there of what folks would would experience if we don't do the manual testing. A non-sighted user navigates to the log in page for an application. The non-sighted user accidentally mis-types their password. They attempt to log in and do not realize they failed as the invalid password error message is not picked up by the screen reader. There's no focus on it.
And then they get locked out.
Yeah, then they get locked out because they have no idea. And that is a very common one that you'll actually experience. I would test any login that you have and test do an invalid password. And you'll probably notice that it fails. The colorblind user navigates to a web page where it mentions projects with a red status bar have a status of at risk. And projects with a green status bar have a status of on time. But they can't see the green or the red.
So they can't tell the difference between the two. What are in which you could actually distinguish the two? So it's not bad to use color, but you have to use another way to convey that meaning. So instead of using two status bars, could you use two different shapes as well? Yeah. And then also for the screen reader behind the scenes, you want to ensure that they're tagged red or green as well. So you don't want to convey through an image. Does that makes sense? OK.
So like a red x would be at risk.
Yeah, and then the green check mark. Yeah. Yeah. My problem is--
But you would also want some label that said at risk or pass, or something, to distinguish that it would be a pass or not.
A hearing impaired user is asked to-- I have a typo there-- is asked to watch a video for class. When the user receives the link, the user can't watch a video as it has no captions or transcripts. So that's another one. And often, so I know closed caption is a big discussion right now at the university of ensuring things are closed captioned and that there's a transcript to associate with it as well. So a user with attention deficit disorder lands on a web page with a video playing in the background. And imagine a very fast video.
The user can't focus on the content on the page as the video keeps distracting the user. There is no pause button and the video can't be paused by the command on the keyboard. That's a common one. There's actually a lot of sites that you can go to right now where they have on their home page a very fancy video but there's no way to pause it. And that's actually suppose to be a requirement of WCAG.
And it can also be a problem for a screen reader user, because if you're launching a page and there's a video playing, the audio will cover up your screen reader's audio. So actually, browser manufacturers now, like in Firefox, there's actually a key you can press to mute all audio on your current tab. And I think Chrome has that as well.
--video, you can upload it to YouTube and get your automated caption. But captions and transcripts, is it really either or?
So there's a question in the room from Joanne, just making sure to repeat for the folks on the phone, if there's a hard and fast rule on either or for captions and transcripts. And--
If you can have both or just one.
I think you have to ensure there's a way in which the person can obtain that information. It's recommended that you do both, just also for-- if it's a student, you're dealing with different learning levels, as well. And someone might find it better to read the transcript because that is an easier way in which to learn from the video. But I don't know, Matt, do you know if there's a hard and fast rule on that one?
I don't know if there's a hard and fast rule for both.
You just have to have something.
For captions, certainly, you want to have captions. Definitely want to have--
But the transcript's always--
Transcripts, I think, if it's a lot of very technical content, transcripts can be very helpful for other students as well. Like for me, I prefer reading a podcast transcript, for instance, because it's oftentimes a lot quicker to read a transcript of something than to watch a video.
OK. And a user with low vision navigates to a website on a mobile device using the magnifier. The user cannot navigate left or right on the site using the magnifier and half the content is cut off. iPhones have a great magnifier tool to use. I found a lot of issues that way. So if you ever enable that and you can't even move the magnifier around, something's up with the code and it's preventing you from using that functionality.
What was the tool you just mentioned?
It's in the iPhone, under the accessibility...
It's called Zoom.
Yeah. So there's a ton of different tools you can use right on the iPhone, or the iPad, or the Mac.
How about Android?
Androids are not our friends.
The short answer is there are accessibility features on the Android, but they're not as cohesive as on the iPhone and they're not as consistent as on the iPhone.
That is a great answer.
Android has made many strides in recent years to be accessible. I know there are some very happy Android users who use the accessibility features. But from a consistency standpoint, because there are so many different versions of Android and manufacturers that design Android product, Apple offers a much more consistent experience, especially for testing.
So if you were somebody putting together a plan, and you had an iPad, an iPhone, a Mac, a Windows computer, a Android tablet, and an Android phone, would you bypass that Android phone and Android tablet?
If you have the Android device, you might as well. There are lots of-- lot's of our students do use Android devices. So if you have the testing capabilities on Android, you should definitely test it. Do we have a sense of percentage-wise, though, like if there is somebody that's visually impaired or impaired in general, do we have a perception of percentage--
Yeah, so Iris asked if there was like a percentage of folks that-- do we have a way of looking at statistics and seeing how many people really use Android versus iPhone versus desktop. And WebAIM, actually, Web Accessibility in Mind, it's a web site you'll become very familiar with and has great articles as well. They actually run a screen reader survey every year. And it probably provides the best sense of what's used. Obviously, the iPhone from a mobile standpoint, trumps everything else. But you'll see a lot of mixed results in there.
So as Matt said, it's helpful, especially if you have the time-- majorly if you have the time. The huge thing is to make sure to get the iPhone, the Apple, and the Windows down. But if you only have like one tester on staff, they're not going to have time for the Android too or they're only going to have cursory time, you have to actually prioritize which ones you're going to test.
Is there a particular screen reader app on the Android that stands out as being better, that should be recommended?
The one that's built on Android is called TalkBack. TalkBack, that's the built in Google solution.
About the best one to test on.
I also notice that in voice activation, people... [inaudible note from participant].
Not during this session.
So before we move into the demo, first, I wanted to talk about screen readers. There are a lot of screen readers out there. Again, WebAIM does a great job of highlighting them all and what's currently being used from a desktop standpoint. So right now, at the president's office, just because we don't have the budget for screen readers at the moment, we're using NVDA for Windows. And that's open source. And it's one of the more commonly used ones. But you'll see quite a few out there. And then voice over is built into Macs, so it's just so easy to just enable that and use it.
So that's what we use in-house for our testing. And Matt, I think in Boston you guys also use JAWS because you guys have a JAWS license.
Yep, we have a campus-wide JAWS license. So it includes both JAWS and Zoom text. That's what's the new kind of infusion product from Freedom Scientific. And we also are starting to do a little bit with Windows 10 on narrator, with the built-in Windows solutions, as well.
And we did bring free licenses for everyone.
Yeah, so actually Matt and Bill back there, they're from Freedom Scientific and they are the JAWS folks. So they brought 90 days?
90 days, so Roger that.
Yeah, so 90 day test. And I know that Matt had actually sent over, we're starting to look at if we could get like a university-wide license. And if someone hasn't reached out to Freedom Scientific, they will be soon. I'm just waiting to hear back from them. Because JAWS is the most popular screen reader out there, so it would be helpful to have it in-house for testing. So I did have everyone install NVDA or voice over. And I know for the session we probably won't have time to go over how to install it and stuff. So if you didn't install it yet, you can kind of watch over someone else's shoulder during testing.
Or if you're online, you could install it while we're doing the testing experience, just so that you guys have it on your computer. So you can either do NBDA, or for the people that are Mac, you could just flip a switch.
Or Command F5. So before we switch over to the actual demo, Matt and I are going to have to enable a couple things, is I did want to check with everyone online on if you guys have questions and if you want to drop those into the chat feature, as I try to pull it up. OK.
So anyone online have a question? If you just want to drop it into the chat, I'll give you a minute or two. And then we're going to actually-- I'm going to make Matt the presenter. OK, let me just--
Do you want me to click on share?
Yeah, well, I got to make you co-host. And for some reason this is just being a pain today.
I mean, what we could also do is just show it on yours and then see if the audio is--
No, we can do this. We can do this. OK, so you should have the ability to take over presenter right now.
Is it the case that voice over only works in Safari?
Voice over, Safari is the recommended testing version. But I do know Amherst, you guys do test on Chrome as well. So for us in-house, because Safari is the recommended version, at president's office right now we only do Safari just because we don't want false positives on the experience. But I know that Chrome has come a long way with that stuff, too.
Yeah, and Firefox as well. Even Firefox on the Mac has come a long way as well. But if you can only test one on the Mac platform, stick with Safari. Share screen. This button here?
Where is it? Yeah, that's the one. Zoom is one of the most accessible ones but we ran into an issue already this morning. So I don't know...
Share computer sound? Oh, do you think this will work? Share computer sound?
Uh, don't share-- oh, actually, share computer sound.
Well, let's try it out. Optimize for full screen video.
And share screen with--
There we go.
Share screen with computer audio.
All right, every online hearing that fine? I just want to make sure we're not getting any reverberation.
Oh, can we turn that down a little?
Yeah. There's no like mute button.
Can you guys hear fine on the phone? OK, I see yes, yes, yes. Perfect.
Can we turn it on...
I don't think I had it--
Accessible university demo side access--
That is extremely laggy. It's very non-responsive at all.
There's an OK here.
Share screen with computer audio window. Avoid hearing duplicated audio. Your computer speaker's on when you are sharing screen with computer audio. OK Button. accessible university demo site.
I can't turn the volume-- that's just really black.
Try it again.
Accessible university demo site--
Yeah, and I can't turn it down here.
Try it again.
Accessible university demo site--
[Inaudible comment. Laughter].
Sorry, guys, we're just trying to get the sound... There it goes. Now try it.
Accessible university demo site, inaccessible version Mozilla Firefox.
Oh, wait, you found it.
Accessible university demo site inaccessible version Mozilla Firefox. Accessible university--
So for folks that need like access the site...
--no next heading.
And need it as an alternative format, in the presentation slide, there is a link to it so that also you can test it after the fact as well. So I'll switch it over to Matt.
All right. So, can everyone see that slide on the screen? OK, so this website--
This website was handily created by the University of Washington. And Kristina and I were very excited when we first saw this. She sent it to me and--
A few times-- that kind of thing.
The only time I was excited to see something that was not accessible. But this is a demonstration site that was created to show the experience for someone who is using a screen reader, like myself. And this site is not accessible. So can anyone right now tell me a few things that are not accessible with the site, just off the bat.
The color contrast with the tabs.
Yep. What else?
Required fields are in blue.
Yeah, so just so you guys online hear what the folks are saying, so the tabs are not accessible from a color constrast standpoint. Required fields are in blue. That's a no no.
Out of list clickable arrow left graphic clickable.
These graphics aren't labeled here.
Clickable graphic clickable arrow right. List with three items clickable, clickable, clickable. Out of list welcome. Accessible university. Is a fictional university and this is its fictional home page. This--
It's a fictional university.
Page is designed to demonstrate a variety of common web design problems that result in visitors with disabilities being unable to access the content or features of a web page. Although the heading at the top of this section of the page... inaccessible design of this page sends the opposite message. Bienvenido. Accessible Universidad.
So another thing is the language did not properly switch over. The language did not properly switch over on me. There is-- now there is an accessible version of the site, which we can certainly go to. That will show a better experience. But this page does not have headings. Graphics aren't labeled on this page. Let's see, what were some of the other things that were wrong with this page?
Contrast. No audio alternative.
And it has auto-complete, name, and email-- edit has edit has desired computer sites.
Do you guys know why the headings are so important?
Checkbox not checked. Engineering.
Content editors. So--
No next heading.
No next heading.
Or if they're not labeled correctly on the back end of things without an h1 heading, etc. It helps delineate the space that you're trying to get to. Versus if you just have a bolded space above, then that really doesn't that this is a place you need to be.
It also removes shortcuts. So behind the scenes screen readers can actually use the headings to navigate the page.
Yeah, for instance, with NVDA and other screen readers, you'll have quick views or quick navigation commands that you can use. And so with my screen reader, I can press the letter H right now. And if there are headings on the page, it will navigate to the next one. But because there are not headings on this page--
No next heading.
And if I press shift H to go back--
No previous heading.
So there are no headings on this page. So this page is already not as easy for me to navigate as a screen reader user.
Imagine that-- if you guys are going to attend the Word class-- imagine that the a word document. So no headings. And also just keep in mind, so tables and stuff like that, that are labeled correctly, they also have shortcut keys.
Columns row one column one. Column to 2007 and 08.
So this isn't actually him trying to navigate a table.
Enter table. Row two column one. Column 2cs.
This table does not have any table headers.
So all it does is read the value, but it doesn't say what the header row it is tied to. If it was labeled correctly, it would actually say that-- it would say the header row that it's tied to. And you'd be always able to [screen reader speaks over presenter]. Also, if the table is labeled behind the scenes correctly, as a table, there is also a table command key where you can use it to go to a table.
And you just hit t for NVDA.
Out of table Creative Commons license graphic link. Accessible university by Lincoln university of Washington is licensed under a--
So that table is pretty-- so there's also a couple of other things with this table. Does anyone know what the other issues are with the table?
Well, one thing is not using tables for anything that's not data. Don't use tables for layout purposes.
I've seen many forms that are-- yeah. Don't use tables for layout purposes. Always use your style sheets.
Because people have the ability to do that.
And they put pictures in it. Yeah, like a picture in the left. They'll hide the table border... And they'll put the content to the right. And they're like, oh, I want to style it this way.
[Inaudible comment by participant].
Can you go back to the table?
Table with five rows.
Column two two.
Also with the table, there's two header rows. Even though they're not identified...
That's a no no.
Row two, column one.
There's also blank cells.
Column three. Column four. Column seven.
Either put not applicable in there or blank.
That's included in there.
Column 10 echo.
Anything else we missed on that one?
Can I make a comment?
If you have to use layout, if you have to use a table for layout, there is a role called role=presentation that you could use in your HTML tags to hide the tables... So it's a great feature to use if you have no choice.
Did everyone hear that on the phone? Matt just said there is a way to use tables for presentation, you will just assign a certain role to it in the code. So obviously you couldn't let your content editors do it because they're not going to have that ability, unless you create it as a template behind the scenes. And that's a template that they always use. I always discourage content editors from using tables, but developers can go in and do it and create the table. But usually the content editors aren't going to have the access to do that stuff.
[Inaudible comment from a participant].
Vanita is saying that sometimes you're using a vendor and I know the exact vendor, Oracle, and they use tables to convey everything and to deliver everything. And so it does create a mess behind the scenes. And hopefully their fluid deployment will be much better. But yeah, and there's no way to fix it because you don't have access to the vendor's code, right? So yeah, that's a huge separate discussion. Are you joining the legal discussion later?
So yeah, what do you do with vendors? Oh, I do have a couple of questions on chat, so I just want to make sure-- or at least note. OK, there was a note that it's hard to hear us with the screen reading going at the same time. Sorry, guys. So that was just a quick note there. So we'll make sure to mute it while we're talking as well. And then Matt, do you want to answer this one? How do table headers differ from captions?
So are we talking table captions, I assume?
Table headers are really what it sounds like. The code at the top of the table, which says what each column specifically is. And captions are at the bottom, so it might be like a summary of the table, or something, like a short description of what the table is. Usually captions up here, for me, oftentimes they appear at the bottom of the table when I'm reading a table.
I think that the caption or the summary as the title for the table. So that allows the user to know what the table is being used for when they land on the table. Sometimes you may, you know, a lot of data in that table, and if you're not giving a name to it, it doesn't make sense. So that's the purpose of using a caption or a summary in the table script.
OK, you going to move on to the form next?
The form, OK. What form?
There should be a form next.
No previous out of table edit has auto-complete.
This one? Right here?
Edit has auto complete. Blank.
So I'm tabbing through this form. And I'll do that once I stop talking. But listen to how this form is read with my screen reader.
Edit has auto complete. Blank. Edit has auto complete. Blank. Edit has auto complete. Blank.
People on the phone, what is wrong with this form right now? You guys can throw it in the chat. Because all the faces in the room are horrified at the moment.
Check box not checked.
Edit has auto complete. Blank.
So someone online just replied, they don't know what to put in the form. Yes, yes. The form fields are not labeled. So this is going to be impossible to complete.
Yep, I have no idea-- right now, tabbing through this form, I have no idea what each form field is. There might be labels around. I could certainly navigate to labels. But it really does make this form very slow and tedious to fill out. Do we want to go to the more accessible version now?
Yes. Let's go to the more accessible version.
How about the security thing?
Oh, you want to experience the security?
[Inaudible note from participant].
Can you tab down to the-- the next thing is going to be the security.
Check box not checked. Check box. Check box. Check box. Check box. Edit has auto complete. Blank.
Those check boxes have no--
Submit button. Edit has auto complete. Please enter the two words you see below, separated by a space. [LAUGHING] Doesn't University of Washington do a great job? I think they covered all the bases except for video.
Yeah, I mean, it generally captchas our problem. There have been some very creative people trying to fix it. Anything from audio captchas, which are OK, but audio captions are not the best option, because if you cannot hear the audio, then that's a problem. And what a lot of vendors now are starting to move towards are the automated systems that you just check a box. Are you a robot? You know, I'm not a robot. You check the box and it solves it, basically.
Some of them use little math puzzles or logic puzzles, so like type in the fruit in this list of items or something. And the list will be like apple, green, and blue. So I mean, there are some creative ways of getting around a captcha. And now I would not recommend using an audio caption because they're not fully accessible to everyone. So there are better solutions than just the audio versions. And plus, the audio is not always easy to hear. If you ever listen to an audio version of these captions, sometimes they're very garbled versions of audio or they're not very easy to listen to.
So let's go to the--
I have a question about the menu. Because it seems like they actually got the menu right and missed an opportunity to make the menu horrible.
They could have made the menu much-- yeah, they could have made it a brutal experience. Right.
The menu is a list, which is good. But I'm wondering if they got enough there. Should have been more...
I agree with you, but there should have been an issue with focus on the list, and being able to close the list and stuff like that. Because that is usually something that's missed a lot of the time. Also, for video, I would have loved to see a pop-video here, because pop-up videos, I've seen so many places where they don't do it right. And you literally get stuck in the pop up and you can't even get to the video controls. And you can't even hit escape to get out.
So then you're just stuck there. And then you have to hit the back button and get out of that. And you can't watch any videos on the site.
Yeah, would have been nice if there were some keyboard traps on this page or something.
But I think this page does a really good job of kind of covering some of the low hanging, the big issues that screen reader users and just assistive technology users in general encounter when they navigate the web. All right, let's find this. Do you know the link--
I know it's actually on the page.
Elements List dialog.
--bu they didn't underline it or indicate it with a hyperlink.
Click here, 6 of 11--
Sorry if you're online. I apologize.
Can you spot the barriers? There are at least 18 accessibility issues on this page. To see a list of all known issues, click here to see a more [INTERPOSING VOICES]. Accessible university demo site accessible version.
It doesn't tell you anything.
It doesn't tell you anything. So if you're using the screen reader, how do you navigate the site often?
You are going to move through the links or tab.
Yeah, you're going to tab through the links or move through all of the links and the headings and stuff. You're not going to read all the content around it. Now you're forcing someone to go to the content around it, read the whole paragraph to know where to go. No click heres, no read mores. Avoid those.
Accessible university demo site, accessible version Mozilla Firefox.
This version should be more accessible. And what I'm going to do, just right off the bat, this is one of the first things I do is check to see if the page has headings, navigation headings. And sure enough.
Main landmark featured story slideshow heading level 2.
Here we go. We have a slide show here.
Graphic robot with a friendly face, assembled with various scraps of hardware and mounted on an old--
Oh, I didn't even know this thing was there, did you?
Graphic deck talk speech synthesizer.
Oh, that's an old synthesizer.
A student wins engineering award for a talking robot sign language interpreter. Read more about the-- link students engineering award dot.
So already off the bat, this graphic is labeled. This link has a better label as well. And if I press the letter H, I can go to the next item on the page.
Welcome, heading level 2. And I can press H again.
Accessible university, bienvenido. Heading level 2. Accessible universidad, UE, Universidad.
Well, if my screen reader was working correctly, the language would have switched. When I tested this page with JAWS last week, the language did switch properly to Spanish. I don't think there's a Spanish version of this voice right now. But let's go to the table here and the table will be--
Table with five rows and 13 columns. This table shows enrollment over a two year period by subject and gender. The academic years. 2007-08 and 2008-09 are arranged in columns, with six subjects arranged as columns nested within. The year columns, total enrollment, and male and female enrollment percentages are arranged in rows. Row one, column one.
Column two, 2007-08. column eight, 2008-09.
So already, this table is easier to navigate. It's navigating, for some reason, with the screen sharing, the responsiveness with my screen reader is not great. I think it's just because we are doing screen sharing. But I can use table navigation commands to navigate this table. And it is a fairly complex table because there's a nested table inside this one. But there is a good caption, a good summary for this table. And it seems to have proper headers.
Let's go down to this captcha, this form here.
Out of table, apply now. Form landmark name required. Edit required has auto complete invalid entry. Email required. Edit invalid entry required has auto complete. Blank. City, edit has auto complete. State slash province, edit has auto complete. Zip slash postal code, edit has auto complete.
So all these labels are now properly applied to this version of the page.
Edit has auto complete.
And I'm going to go to the--
Desired major, ask grouping. List. List with six items computer science check box not checked.
There are so many nice things about this page. There are lists. There are property marked up lists. The checkboxes are properly marked up. These items are grouped together properly. So let's go down to this captcha here.
Out of list submit button. Sunday, Bird, Friday. Which of these is not a day? Edit invalid entry required has auto complete.
Which of these is not a day? Sunday, bird, and Friday. Well, I'd probably say bird. So any questions about this version of the page?
And just so you guys know, I mentioned in the beginning, just in case we had folks join us online a little bit later, in the advanced screen reader testing, Tracy's going to use the same page and she's also going to show you how she adjusted the code on the back end. But the thing is, is that you really have to also train your content editors because there was a lot here that content editors, if they don't do it right, it doesn't matter how accessible your code is. If they put click here as a link or if they put an image without alt text or no closed captions or anything like that, then your code can be as accessible as you want but the site isn't accessible because the content is key.
One question I had is that with the form, there are forms that you have that you don't have to hit search to get results.
So there are ways to-- Tracy will be able to answer that better than me because I'm a web app specialist, she's a developer. But there are ways to code it where it will basically notify you with a message that it has refreshed. But if you're not doing that, if you're not thinking about that, it can pose an issue because the person doesn't know it's already submitted the search. We actually just avoid it entirely and let people do the search.
[Inaudible note from participant}.
Yeah, Google used to do that and I turned off that feature in Google because it didn't work very well. But Google doesn't actually do that anymore.
And always a problem anyway that a lot of people when they're typing, they might be typing fast. And they have a typo. And then it's like, no results. Wait a second, back up. So it just gets annoying sometimes when it's doing an auto-refresh.
I went to the menu in the good one. They gave it aria roles, so it has menu and menu items.
Oh yeah, we can go up here and check it out.
Is that helpful from a screen reader perspective?
Banner landmark heading. Main menu navigation landmark button show menu keyboard shortcuts. Menu bar menu item sub menu about. Collapse sub-menu link academics. Menu item sub menu admissions.
So one of the things that is noticeable here is it's very verbose. The screener output is very chatty. And actually, there are ways to adjust this, especially in one of the newer versions of JAWS. You can actually change how some of this verbiage is announced. And for screen reader users who are fairly advanced they'll go on and tinker every time they can to make their screen readers as efficient as they can be.
I do want to address one question that we got from Lisa online. So the security question is a better version of the puzzle-based captcha. I click on any images that are not a street sign, etc, which is visually based. And yes, I don't know how accessible that is from a screen reader perspective--
But from even a-- so if you're a person that doesn't do good with visuals, like me, I get that wrong twice before I get it right because I miss a sign every single time. And I've talked to a lot of people. There's always someone in the room that misses the sign several times and then they're continually having to refresh it to be able to pick out one that they can visually make out all of the signs. So yes, it's bad in many ways.
I think any time that you can go past the testing portion, if you can just click a box that says, oh, I'm not robot and that's it, trying to eliminate the users having to basically solve a problem or solve the challenge. Because I think you're going to have-- even with this particular challenge-- it's not perfect for everyone.
And on the WebAIM site, there's actually a great page that goes over all of the disabilities to consider because we don't want to just consider low visibility, blindness, hearing impaired. We also want to make sure we're covering different learning ones and other disabilities. Because you could be focused on those but at the end of the day, if you have things like a challenge where someone that struggles with challenges is going to sit there and get it wrong several times, that's also inaccessible. So you have to be thinking of a lot of different personas.
Instead of using captcha to focus on the user to prove they're not a robot we use something like honey pot that fools the robot--
--revealing that it is a robot.
Some of the issues with honey pots, though, is sometimes if you don't hide the form fields properly, they will show up for a screen reader.
Oh, a screen reader.
Yeah, a screen reader. So actually, Boston actually has one. At the bottom of every form at Boston, there's a honey pot at the bottom. And it's not visible on the screen, but all the screen readers do detect that. So I have to make sure that I don't actually edit the field or type in something there.
[Inaudible note from participant].
And if it's not hidden in the code, I can probably see it.
So there was a question online about the example of Sunday, bird, Friday being acceptable to security teams. This is purely example, guys. We're not planning to implement this form. The Google captcha is really where people are headed. And it's what we have on our site because it is accessible. But we're not recommending to use the Sunday, bird, Friday security question at all.
So how would you go about-- what's the preferred method to--
Right now, I think it's Google captcha.
I would use Google, their new recaptcha, where all you have to do is check box and that's it. I'm not a robot.
And then there's the honey pot for Matthew here. If you guys are using honey pot, Tracy has it so that it's hiding the field, so we could always send you that code as well, from an accessibility standpoint. Because it is a great feature. It has cut down on a lot of spam for us. But we also still had some spam coming through. And so we did implement, on some of our more highly used forms, we implemented Google captcha.
From what I was getting, we should consider, visual, auditory, and cognitive. So what about the neural? What about the flashing lights, etc.?
Yeah, they don't do a good job-- so she asked about the neuro as well. And they don't do a good job here of doing that because the flashing-- people always joke, let's put something in that's flashing so people notice it. And it's usually a joke because everyone hates that. But yeah, we want to also be looking at something that could cause seizures, migraines, et cetera. So having stuff flashing right on the home page of your site, or anywhere on your site, is really not a good thing to use because you have to question what is the goal of it flashing. And can I do it in another way?
Why am I doing this or is it just to create some fancy fun, pretty much. And does it provide any value to folks. Because chances are, it's not, and it's actually giving everyone a migraine. So good question. Any other questions? Otherwise, we're going to switch over-- oh, yeah.
Sorry to go back, but it was interesting, Matt, what you said about chattiness. And I wonder in web pages that we strive to make accessible, that we, as developers, need to think about the amount of verbosity that we put into our pages. Or do we rely on the users to tune their screen readers?
I think there has to be a little bit of both. I think as developers, it's good to certainly use a screen reader in daily testing to get in the habit of testing often. You test throughout the development cycle. You don't just test at the very end. But your testing is going to be different than my testing. And my testing set up is going to be different than, perhaps, how I use my screen reader on a daily basis. And because there are so many different variations in websites and things, you know, I think, though, as a developer, it is important to think about how my form is labeled and how links are labeled, and how verbose is my site for me navigating.
But you can't cover all things. And some people might like the chattiness, right? Some people might want it to say every role and every element and everything. But for more advanced users, it's often not necessary to hear all of that verbiage. No, it's a good point. So the good news is we actually took up the whole hour. The bad news is you guys didn't get to--
Row one column. Downloads. Row one. Accessible-- [Screen reader audio].
Because then we do have a part, only 45 minutes. If you want to come back here with your lunch, enable your screen readers, then you can do that. The people online, I'm also happy to do something like next week where we can just all jump on a call and do that as well. We went over a lot today. So for folks that are in person, go have your lunch. Get into the long line. And don't forget to bring it back up because we have only like a short time between.
And for the people online, thank you guys very much.
And we apologize for any audio difficulty. But also, just feel free to drop me emails as well if there's anything you missed or whatnot. Thank you, guys, very much.