Implementing WCAG 2.2 into Your Digital Strategy [TRANSCRIPT]
SOFIA LEIVA ENAMORADO: Hi, everyone. We are so excited to have you here today for the presentation, Implementing WCAG 2.2 into Your Digital Strategy. I’m Sofia from 3Play Media, and I’ll be moderating today. And today, I’m joined by Michele Landis and Aaron Cannon from Accessible360. And with that, I’ll hand it off to Michele and Aaron, who have a wonderful presentation prepared for you all.
MICHELE LANDIS: Thank you very much. And thank you, 3Play, for having A360 at yet another webinar. We’re super excited to talk to the audience today. My feeling is I think this is going to be probably a little bit more of a participatory, lots of questions throughout. I’ve invited Aaron Cannon to walk us through the technical changes that are planned in the draft edition of the Web Content Accessibility Guidelines version 2.2. And for those of you who don’t know this, it was scheduled to come out quite some time ago originally– or allegedly, right, Aaron? And it was delayed.
So we’re all in the same boat. We’re waiting for these to come about. There’s been some edits. So from the last time Aaron and I presented this together, there’s been some updates as well. So we’re keeping a close eye on any of the edits or changes, and Aaron is going to go through those.
The majority of this presentation will be led by Aaron Cannon. Aaron has been blind since birth. He became a full stack web developer and has– I think we joke sometimes, Aaron, that you might have forgotten more coding languages than most Millennials will ever learn, one of our ice-breaking jokes in the beginning. But I’m super excited to have Aaron here to lead us through this.
The best approach is to ask questions while we’re discussing the changes to the specific guideline. We’ll certainly take Q&A at the end, and we’re happy to stay on as long as needed to answer any questions. But we feel that each one is a topic in and of itself. And so put your questions in the chat, raise your hand, jump in, please let us know how we can help answer any specific questions.
Again, Aaron’s important designations are there. You can see why I have him here to lead the technical part of this, and we’ll have some contact information, just wrap up quick at the end of this talk about A360. So Aaron, with that, I’m going to turn it over to you to walk us through the first introductory slide about WCAG 2.2. Again, the first bullet point is this is still not yet published. But as you look towards 2022 and how you’re working with your internal digital products and/or any of those of your client, it’s really good to be aware of these. So thanks, Aaron.
AARON CANNON: Yeah. Absolutely. Thanks, Michele. Appreciate it. That’s what everybody wants to know. When are we getting 2.2? When is WCAG 2.2 going to be released?
And I really feel for the committee that’s working on this, because it’s a very interactive process. There are a lot of little points that need to be worked out, and so I’m not surprised that it was delayed. But I’ve pretty much given up guessing on when we’re going to see it, because I don’t think anybody truly knows.
So the important thing to know about 2.2 is that, just like 2.1, it doesn’t replace the previous guidelines. All of the guidelines that were in 2.1 and 2.0 are being moved forward into 2.2. It’s also backwards compatible still. So if you conform with 2.2, you’re also going to conform with 2.1 and 2.0, except for one minor exception to that, and most people that won’t impact. One of the guidelines was upgraded from double A to single A. But most people don’t really distinguish between single A and double A, so that is unlikely to be a major problem for most people.
So there’s 10 new criteria. There’s one that was updated. And again that was just that level change. There are three level A criteria. So for folks who are unaware, the single A criteria are the most important, most vital, followed by double A, and then followed by triple A.
Pretty much, the industry standard is single A and double A. That’s what you need to do in order to be considered accessible under the law or under most definitions of web accessibility. So there’s five double A’s. And there’s two triple A’s, which we won’t talk about today. So let’s move to slide four.
SOFIA LEIVA ENAMORADO: Sure.
AARON CANNON: So why are we getting a new version? Well, basically, it’s continuing the work that was started in 2.1. And so we really see some new guidance for three specific areas.
Users with cognitive and learning disabilities, they were always left out. They’re a hard group to accommodate because they’re so diverse, more so than other types of disabilities, I think. So they add a few guidelines that will help that group.
Users with low vision– and I want to be clear, when I say low vision, I mean people who can see a little bit but they don’t have great vision. But they have some. And so users with low vision, and then also people with physical disabilities who are using mobile devices.
So 2.1 started talking about mobile devices, because the folks responsible for the WCAG realized, hey, people are actually using these guidelines for things other than just the web. So we’re using them for mobile applications. We’re using them for desktop applications and electronic documents, not just websites anymore. And so they started to add content that was applicable to mobile websites but also mobile applications as well.
So let’s dive in and talk about these guidelines. And, again, I encourage you to ask questions. I will try to take them as we go. Obviously, there’s always the chance that you could ask a question that’s a bit larger than we can handle in this discussion, in which case I’d be happy to answer that through email or whatnot. But we’ll do our best.
So 2.4.7 Focus Visible, this is just the one that is getting upgraded from a double A to a single A. And it makes sense, because this is really important. For people who are keyboard-only users, if they start tabbing through the interface, they really need to be able to see where they’re at. So that’s why that one was upgraded.
2.4.11– we’ll move on to the next slide– so this one is also about focus appearance. So the appearance of the focus indicator, when you start tabbing around the website with your keyboard, the idea here is that the original criteria for keyboard focus basically just said, there needs to be a visible focus indicator, which was a good start. But this one tries to refine that definition a little bit and say, OK, what constitutes a reasonably accessible, visible indicator?
And there’s actually quite a few requirements, so many that they didn’t quite fit on one slide. So we have a second slide of requirements. But basically, it gives requirements for color contrast of the indicator, for how thick the line needs to be, and basically just some things to make sure that, when you do have an indicator, that it’s going to be highly visible and not something that’s really, really faint or really hard to see. So that’s the idea behind that.
MICHELE LANDIS: Yeah. This one had a lot of sub-bullet points. So as Aaron said, we placed them on two separate slides. So again, if there’s any questions specifically on each one of these guidelines as we go through, please just let 3Play know. And we’re happy to be interrupted at any time to answer any question.
I’m often asked questions about how many WCAG guidelines have to do with design? How much help do we need if we’re building something new? And at A360, we’ve been doing design reviews and support on new builds on desktop websites for years, right from the start. But years ago, we also started doing design reviews for mobile apps and enterprise systems and portals and kiosks or internet of things. So we’ve worked on some really interesting things.
And to Aaron’s earlier point, applying the Web Content Accessibility Guidelines to everything digital, I think people are often shocked when we share that the WCAG guidelines came out over 22 years ago. So time flies when you’re having fun, I guess. Aaron, I’ll bring us to the next one, unless there’s any questions on 2.4.11.
AARON CANNON: Yeah. It’s interesting. Again, yeah, these Web Content Accessibility Guidelines really are versatile and are being used on multiple platforms. It’s interesting. Section 508, when they adopted– which is the requirement that government agencies have to fulfill essentially. That’s an overly simplistic answer, I know.
But Section 508 is basically– they require the WCAG, except for a few guidelines, be used for assessing mobile applications. So it’s not just what some people are doing. It’s actually enshrined into law. So it makes it pretty interesting.
This next one is interesting, 2.4.13. This is all about electronic publications, so things like books that you’ve turned into an electronic resource. So a lot of times, when you do that, the page numbers are really important. So you keep the indication of what page the user’s on. You’re able to see, OK, this is page 17.
And this guideline just requires that if you do have those page indicators visually that you also make them programmed in such a way that users can jump to a particular page. And this just makes it more fair for disabled users, so they can also jump to a particular page. Because the reality is that, even though it’s very much an electronic world nowadays, we still use things like page numbers and things like that to refer to different parts of documents.
MICHELE LANDIS: It occurs to me, Aaron, too– and I apologize for the oversight to anybody in the audience– but the title of 2.4.13 is Page Break Navigation. I’m happy to walk through, or we can read the bullet points in here. I’m not sure the transcriber is transcribing what’s actually on the screen. So I want to make sure that we pay attention to that.
So again, this is a level A requirement. And it says, “For web content with page break locators, a mechanism is available to navigate to each locator.” This one has a lot on it, this next one then. We’ve moved to 2.5.7 here.
AARON CANNON: Yeah. It does. And drag and drop, this can definitely be the bane of your existence as a person responsible for web accessibility.
MICHELE LANDIS: Way to sell it, Aaron.
AARON CANNON: It’s a big problem for screen-reader users who don’t use a mouse at all. Screen-reader users use the keyboard exclusively. Screen-reader manufacturers have tried to build solutions for these. But so far, it hasn’t really gotten much traction.
And other people have difficulty with fine motor control. So dragging something with a mouse and precisely dropping it where you want it can be quite a challenge for folks. Folks may even struggle to hold down the mouse button continuously.
Or if you’re using something like eye-tracking technology, I’m not sure how you would perform a drag and drop. Maybe somebody’s figured it out, and I’d love to know about it. But regardless, requiring drag and drop on a website can be a big problem. And so this success criteria essentially requires that you provide alternative means to accomplish it, if at all possible.
There are a few scenarios in which you really can’t make this work, and drag and drop really is the only way. But that tends to be fairly rare. For most applications, they’ll provide something like a list of items. If you need to reorder the list, you’ll be able to drag and drop the items. But you can also use little buttons off to the side that allow you to move items up and down in the list, and so there’s usually ways to accommodate this.
MICHELE LANDIS: Yeah. The one I remember, Aaron, early on was the construction of, say, an oral argument within a study guide. Moving pieces or paragraphs around on a document was where I first learned about this. So again, this level A requirement in 2.2 says that all functionality that uses a dragging movement for operation can be operated by a single pointer without dragging, unless dragging is essential.
And as I stop and I listen to that, it’s like, OK, it’s required, unless it’s not possible. So again, to your point of your opening remarks, Aaron, thank you for all the contributors and editors to this, as we try and capture equitable access guidelines and standards for all of the amazing and creative possible things that designers and developers now create. They’re trying to keep up. A couple notes.
AARON CANNON: Absolutely.
MICHELE LANDIS: I do notice that there’s a question in the Q&A. Does the moderator want to read that?
SOFIA LEIVA ENAMORADO: Yes. The question is example for Acrobat, where can we directly type the page number and go to that page?
AARON CANNON: Great question. And I’m not sure if they’re asking from an authoring perspective or a user perspective. I know from a user perspective I believe you can enter a specific page under the View menu, and there’s an option there to go to page.
For authors, there is also a way to set that metadata. I’m not an expert on remediation of PDF documents, but I know something about it. And I believe there is a way where you can indicate your print page number one starts on this page, and it goes up from there.
And then I think they also– Oh, OK, sorry. Great. So yeah, and then– sorry, I was reading the chat, got distracted, but yeah. So it is possible in the authoring portion of that as well.
MICHELE LANDIS: Yeah. So the interesting thing about this one– real quick, I was just attending Accessing Higher Ground, which is a specific accessibility conference for higher ed. It’s always in Denver every year. A360 is part of a larger collaboration of companies. Obviously, we’re all under one roof now, and that is T-Base Communications that specializes in reflow print and braille– they’re located in Canada– and also CommonLook.
CommonLook is the global leader in document remediation, and this specific topic came up during a learning session that I was in. And there was a lot of discussion about Adobe’s products and how to do that pagination. And sometimes, if you’re the reviewer or the viewer, if you’re trying to remediate a document or if you’re trying to read one, that page numbers may go away. They’re not always present. So it’s a wonderful follow-up.
I believe that 3Play Media and I and my new partners at CommonLook have a specific webinar coming up in January, I believe, on PDF document remediation. So bring the questions and the participants there to that one, and we’ll get the people that spend 100% of their time doing that better than anybody to answer those. So the slide I moved to, Aaron, is 3.2.6, which is called Consistent Help. And I know this was a change in the title actually of this guideline when we were editing.
AARON CANNON: I think you skipped one actually.
MICHELE LANDIS: Oh, did I? Sorry.
AARON CANNON: I think I’m on 2.5.8.
MICHELE LANDIS: Yep, Pointer Target Spacing. Sorry. This is level double A.
AARON CANNON: No worries. Yeah. So I definitely will not be speaking at that PDF remediation conference, because I don’t know a great deal about that. But those folks do, so that should be great.
So Pointer Target Spacing, I think we’ve all– or probably all of us, most of us– have had the experience of using a poorly designed mobile app where the touch targets are so crammed together that it’s really hard to hit the right one. This is not just a usability issue, but it’s also an accessibility issue.
Again, particularly if you’re a person with a physical disability– you have shaky hands or hand tremors. So you need to make those targets large enough and have them spaced out enough so that the user can successfully hit with the mouse or with their finger the target that they’re interested in.
And so this one was interesting. Because when I first did this presentation, we did this internally to a group at A360. They had said 44 pixels, and that was actually directly copying from– or I surmise that it was directly copying from the Human Interface Guidelines published by Apple. But now, they’ve revised it. So now, it’s only 24 pixels. Which, to give you a sense of– for those of you who may not work every day in this area– on a desktop screen, 96 pixels is an inch.
So 24 pixels is pretty much exactly 1/4 inch. Now, the pixel density can vary somewhat, but that’s just to give you an idea of how large we’re talking about. So 1/4 inch by 1/4 inch is what they’re aiming at.
MICHELE LANDIS: It’s not a lot, right, Aaron?
AARON CANNON: Yeah.
MICHELE LANDIS: So I can tell you, even from my personal experience being a visual user and having full use of my hands, being on a mobile site– I can’t remember what I was doing. More than likely shopping or ordering something, because I really don’t go to the stores too much anymore, like a lot of people. But I had a really hard time getting just be able to check the correct box. Things weren’t scaling correctly on mobile.
So again, more of a mobile or responsive website design, user experience issue, but this is an important one. The spacing target offset now needs to be at least 24 pixels to every adjacent target. So it’s an interesting one.
I don’t know how much that impacts the designers and developers here on the call today with us, but there is additional notes that were added to this change. And they actually change the title of the notes, and they call one of them necessary. “A particular presentation of the target is essential or is legally required for the information being conveyed.” And then there’s another bullet point, very important, called legal. “A particular presentation of the target is legally required.” So I can think of health care forms, HIPAA compliance, different scenarios where this will come into play.
AARON CANNON: Yeah. So what they’re anticipating here is situations where you have a government mandated form where it’s required that your electronic version is essentially a pixel-for-pixel rendering of the paper version. And so in those cases, if you have targets on there, checkboxes or whatever, that are too small you either have to make a choice between not complying with the WCAG or not complying with the legal requirements. And so they give you an out here.
But I think this is more interesting, because it exposes a broader point. And it’s not uncommon for outside requirements and the WCAG requirements to clash. And so you’re basically left with these binary choices. OK, I either conform with this, or I conform with that.
And we’ll talk about the WCAG 3 a little bit later on, which is the next major revision of the WCAG that they’re working on. But that is anticipated by this new version of the WCAG 3, which makes accessibility less of a binary question and more of a continuum. So that’s been interesting.
MICHELE LANDIS: It will. And it will allow for a lot more critical thinking and collaboration, I think, which is great. I’ll move on to the next one, Aaron. 3.2.6 is titled Consistent Help.
This is a level A issue, and it just simply states– I’ll read the first bullet point here for everyone. “For each web page within a set of web pages–” I would call that a website, but apparently that doesn’t cover everything– “that provides one or more of the following ways of finding help, access to at least one form of help is included in the same relative order on each page.” So this has to do with human contact details, right, Aaron? [INAUDIBLE]
AARON CANNON: Yeah, and it’s interesting, because I don’t believe that this requires that you add help options to your website. The way I’m reading this, it doesn’t require that you add help options to your website if they don’t already exist. What it does require is that if you have help options or ways to contact the company that you provide those in a consistently ordered manner.
So if your help options are in the footer of your website on one page, they should pretty much remain there. If you have Chat, then Contact Us, and then maybe a link to your knowledge base, those links should stay in the same relative order. So it’s just about being consistent. Consistency is a big help for a lot of disabled users, particularly the folks with cognitive difficulties or challenges. And so that’s what they’re going for.
MICHELE LANDIS: Yeah, and that’s interesting to me, Aaron, because on the note part of this one it says that, “Access to help mechanisms may be provided directly on the page or may be provided via a direct link to a different page containing information.” We’ve had a lot of discussion over the years with clients and other people. With cognitive-related disabilities, it’s always best to keep them within one page.
Opening up a new tab then, it introduces attention issues. It can introduce some other issues. So again, I applaud the work on the editing. And more talking about it just helps everybody solve this best for their own use. So if there’s no questions on consistent help, we’ll move forward.
AARON CANNON: Or anything else.
MICHELE LANDIS: Yeah, or anything else so far. We good, 3Play?
SOFIA LEIVA ENAMORADO: I have one question here that asks, “I see all of these requirements. Yet, I don’t know the experience of the end user needing accessibility. How may I experience that for end users?”
MICHELE LANDIS: So I think what the question is related to is how can you simulate using JAWS or NVDA or voiceover or TalkBack, Aaron, right? How can the testing be done? I think that’s how I am interpreting that question.
AARON CANNON: And I think what I’m hearing is slightly different than that. I think the question is more about, help me understand what it’s like for a disabled user. And yeah, I think we’re kind of saying the same thing, actually, now that I think about a little more. How can I put myself in that position so that I can gauge how my website is doing and so forth? And it’s a great question.
I think one thing that I recommend that people do just first off is the very first look. First thing you should do is put your mouse away and just try to tab through your website and see, how do I experience this? What happens when I start tabbing? Can I reach everything? Can I manipulate everything on the site?
And oftentimes, that will be pretty instructive. And then going beyond that, you can download a screen reader and try that out. I don’t know if I’m getting at the question that you were asking.
MICHELE LANDIS: Yeah. The only other thing that I’d add is, again, this is another example of where automated testing is just not going to give you the answers that you need. So the shortest, most concise answer I can give is live-user testing and live-user testing with people with disability so that empathy and understanding can be realized by the designers and developers that are working on this. So if there’s a follow-up question, we’re happy to take it at the end.
AARON CANNON: Yeah, and I think we have another question that just popped up on 3.2.6.
SOFIA LEIVA ENAMORADO: Yes. Someone said, this isn’t a question. It was more of a comment. You’re correct, Aaron. 3.2.6 does not require help.
AARON CANNON: Great. Good to have. Yeah. It’s been interesting following this and seeing how these documents have been written and evolved throughout the review process. And I appreciate the confirmation and encourage folks, if I’m getting something wrong, please, speak up. I’m humble enough to appreciate that.
Because we’re figuring out, what does this actually mean for us? All of us are, I think, in the industry figuring out what is 2.2 going to mean? So that’s great. I appreciate that. 3.2.7. Should we move on?
MICHELE LANDIS: Yeah. Visible controls, this is a level double A issue. First bullet point reads, “Where receiving pointer hover or keyboard focus triggers user interface components to be visible, information needed to identify that user interface components are available is visible except when–” and then it goes on, Aaron. So I’ll let you jump in there.
AARON CANNON: Yeah, and there’s a lot of–
MICHELE LANDIS: [INAUDIBLE]
AARON CANNON: –requirements for this one or options. So if you spend much time around designers, one of the things that you will often hear them value almost above anything else is a clean, uncluttered design. And of course, that really makes sense. If you have too many controls all over the place, it’s going to cause problems for understandability. And they can be painful to work with in trying to figure out, OK, what controls apply to what pieces of content? And it can really get confusing.
One of the ways that designers have tried to push back against this and overcome this is by hiding controls behind other controls. So you’ve probably all seen this. When you hover over a button, for example, or some other piece of content, some additional controls appear when you move your mouse over that. And that can be a problem for people with disabilities.
So this success criteria is basically trying to address that practice. You can still do it under this guideline. It’s not prohibited. It’s just required that you need to make sure that you are indicating that other controls are available here or making sure that there’s alternative means to reach those, reach those controls, so that it’s not just appearing when you mouse over this thing, that there’s other controls that will do the same things, maybe accessible through menus or things like that.
And to be clear, they’re not discouraging the use of menus or things like that. When you make it super clear that, oh, you click on this, and it pulls down more controls, that’s fine. So the way to think about why this is a problem or to understand why this might be a problem for somebody is, let’s say you are a user who has low vision. And so you’re zoomed way in on a website. And so you’re only seeing maybe on your screen a small piece of the site, and so those controls pop up. Well, if the controls pop up somewhere outside of that little slice of the web page that you’re currently looking at, you’re not going to notice.
And there’s other issues, other types of disabilities that this causes concern for. People with cognitive disabilities maybe won’t remember that, oh yeah, you have to mouse over this, and that appears. Or it can be fatiguing for people searching through your interface if they have trouble using a mouse and they have to go move the mouse over everything just in case there might be a control under there. I don’t want to belabor this too much, but you get the idea where this can really be a problem. And so this is all about making sure that it’s more clear to users and that they can discover those controls and operate them.
MICHELE LANDIS: Great. Aaron, I just have a comment in the chat. So I’m going to pause now and read it, because it came in now. So I think it’s the best thing to do. I did answer one earlier in chat too.
Somebody said, should it be– back again on the last criteria 3.2.6, consistent help, level A. My answer was, I can take a stab at this. I happen to agree with that comment because it comes down to equitable access. So if you can offer something, you need to offer it in an equitable way. That’s the way my brain works. So maybe we should provide that feedback to the WCAG, and maybe they’ll take us up on that.
And then Paul has a comment and a question. He said, “First of all, thank you so much for this great information. We started to see a lot of focus on mobile app accessibility. Do you think there are unique aspects of mobile apps that make them different from the website running in desktop or mobile devices? Should we have specific guidelines for mobile apps?”
I realize that I’m doing the job of the moderator at the moment, so forgive me for overstepping. But Aaron, this is such a fascinating question. Because I don’t think a day goes by where I’m not asked this.
AARON CANNON: Yeah, and I agree. I think there is something lost when we try to adapt these guidelines that were written for the web to a mobile context. We’ve figured out how to do it. We’ve managed to do it pretty well as an industry.
But I think the good news is that the WCAG 3 anticipates this. And so they plan to offer guidelines and recommendations that are different, based on whether it’s a website or a mobile application or a desktop application. So I think that’s really exciting to hear that.
And yes, I definitely hear you that there are different considerations for between mobile apps and web applications. So it can be a bit of an interpretation, sometimes converting these over to a mobile context or a desktop.
We got a question about when WCAG 2.2 will be published, and that’s a great question. We covered that at the beginning. But in short, we don’t know. If I had to guess, I would not be overly surprised if we saw it in the next six months. But just so you know, I have an absolutely terrible track record at predicting these things. So take that for what it’s worth.
Originally, it was supposed to be released– I think middle of this year originally is what they were hoping for. But again, they’re taking the time they need to answer all the questions, the concerns that are being raised by the community. So it’s very much a collaborative process. And they’re doing as good as they can, I think. But yeah, it’s a great question. We would all like to know.
MICHELE LANDIS: Yeah. Anybody with a crystal ball, please, let us know. Again, I feel like maybe we’re just too in tune with the questions and stuff being answered. So please, forgive us, our hostesses today. But there was one earlier too, Aaron, that said, does it apply to the dropdown navigations? I think he’s referring to visible controls. And again, this person, he or she references the mobile hamburger menus.
AARON CANNON: Hamburger menus. Yeah.
MICHELE LANDIS: So I’ll just take a stab. At A360 what we do when we audit a website is we go through everything, and then we offer a QA of that mobile responsive site. And again, one of the things we’re particularly looking at is how that hamburger menu operates, right, Aaron? So we’ll just circle back to that one when we’re all caught up on our questions.
AARON CANNON: Yeah and that was– let’s see. What guideline is that? 3–
MICHELE LANDIS: I think this is in regards to 3.2.7, visible controls.
AARON CANNON: Yeah, so what I would recommend is going to the WCAG guidelines, the draft. I’d look at the editor’s draft. And if you just Google WCAG 2.2 editors draft, you should find it. It’s hosted on GitHub. But basically, they break this down a little bit better than I can here.
The guideline itself can be hard to read. Even technical folks really struggle with this. But the understanding documents that are associated with that I believe call out that specifically menus and things like that don’t necessarily apply under this. It’s more when you have content appearing on hover, and it’s not necessarily obvious that it does that is my read of that. But again, this is one that I haven’t dug as deeply on, and so I would refer you to that understanding document for additional, plain language explanations. Great question.
MICHELE LANDIS: OK, great. Yeah, really good. Let’s move on to 3.3.7, Aaron, and this is Accessible Authentication.
AARON CANNON: Yeah, and so you can thank the rise of captchas I think for this one. Although, it does deal more broadly than that. So this success criteria essentially prohibits the use of cognitive function tests for authentication.
So what is a cognitive function test? Well, according to the WCAG guidelines, it’s essentially requiring the user to, for example, memorize a username and password. And the first time I read that, my mouth dropped open. I’m like, wait, how’s that going to work?
Well, most people nowadays, if you’re doing things properly and using a password, a unique password for every site, you aren’t memorizing your passwords. You are using a password manager. And so in order to comply with this, you don’t need to get rid of your usernames and passwords. You just need to make sure that you’re not blocking paste into your username field or into your password field, so that people can use a password manager. So that somebody with a cognitive disability, they can’t remember their password, but they can copy and paste it. Which is probably all of us at this point, given how complex passwords are supposed to be.
Making users recognize things in an image, so things like click on all the parking meters that you see in this picture. Obviously, that’s going to be a big problem for blind or visually-impaired users. Making the user solve a math problem. If you have dyscalculia– I always mispronounce that, sorry– that’s going to be a big, big stumbling block for you. Or making the user transcribe characters out of an image or even from a text message that you send them.
So again, this doesn’t prohibit most of the authentication methods that we’re currently using, unless you’re blocking pasting or things like that. What it does do is just set some guidelines around them and if you are using one of these methods, where users do have to use a captcha, that you are providing some sort of alternative method.
So maybe you send text messages to your user as two-factor authentication. That’s OK, as long as you can also support hardware tokens, like the YubiKey or touch ID on a mobile device or things like that.
So again, you can still do what you’re doing, for the most part. It just needs to have alternatives provided for certain steps of the process, like the captchas and like the two-factor authentication. Or you can just take the easy way out and let users log in with Google or log in with Facebook or whatever.
So again, I was worried about this requirement when I first saw it. Having spent a little more time with it and thought about it a little more, I’m a little more comfortable with it. I think it’s reasonable, and it’s in line with security best practices, anyway, for the most part.
MICHELE LANDIS: Yeah. I’ll share another quick story from the last conference I was at. There was a speaker talking about artificial intelligence, and he had some really– could be construed as funny, but sometimes kind of horrible outcomes of artificial intelligence being used to identify things in a picture. And he related them to captcha and that type of thing. So I think a lot of times what I see is people really eager to be very creative and very unique or different from other people as how they relate their captcha maybe to their brand’s identity or the mood or the culture of their company. I applaud that, as long as it’s equitable.
So just I think, rule number one, always going back to the basics is, is this going to work for everybody? Can I make it work for everybody? And if you stop and just take a quick breath and think about that often while you’re designing even or developing, it might change the course that you’re going down. So humans use this. So just remember.
We can move to the next one, I think, Aaron. This one is 3.3.9, Redundant Entry. This is a level A.
AARON CANNON: Yeah. So this is the last one that we’re going to talk about, the last new one in WCAG 2.2. And then we’ll jump into 3.0 quickly and just go through that. I think everybody should be happy about this one, honestly.
So this last requirement is basically about if you ask the user for a piece of information once, like their name or their address or their email address, you shouldn’t ask them again. Or if you do, you should allow them to say, OK, yeah, the thing I just entered before on a previous step is still the same. So don’t make me enter that again.
For some people, it can be a real ordeal entering data into a form. It can be slow and annoying and possibly painful, and I mean that non-literally as well as literally. If somebody has arthritis, typing on a keyboard to fill out a government form that you have to complete, you have no choice, can be quite literally painful. And so minimizing the duplication of information that the user has to enter is really important for accessibility, and so this is added as a level A criteria. Anybody who has done their taxes online I think should really appreciate this one.
MICHELE LANDIS: This is my favorite. Honestly, I was looking for the controls to put the hands up for the clapping hands, and I did notice we had a couple of comments and another question. So we’ll circle back on those before we move onto 3.0.
As an able-bodied user at the moment, the requirement to retype something has driven me nuts for years. I’m befuddled by it, as much as I am befuddled about the resurgence of QR codes. So unrelated to what we’re talking about today, there’s just things in the digital world that fascinate me all the time, and I’m glad for this one.
I don’t want to re-enter my email. If I’ve hit it right, great. I’m probably just giving it to you because I want to move forward anyway.
AARON CANNON: Yeah. Now, you can request [INAUDIBLE]–
MICHELE LANDIS: I understand why you’re asking for [INAUDIBLE].
AARON CANNON: Sorry. I think I cut out for a second. Yeah, and I think there is an exception for when it’s required. For example, if you require the user to enter their password twice when they create their account, that’s probably OK. Although, you should also offer them an alternative to see their password and only have to enter it once so they can verify that it’s entered correctly.
Again, it’s just about minimizing the amount of typing somebody has to do. So let’s take those questions and then dive in in the last 10 minutes or so to WCAG 3, and we’ll get a little ways into it. It’s a big one.
SOFIA LEIVA ENAMORADO: Absolutely. So one of the questions we had here is for 3.2.7, visible controls. Is there an equivalent for screen readers?
AARON CANNON: Well, so screen-readers already struggled with this anyway, because how do you give screen-reader users access to controls that are hidden behind something else? So that’s always been a consideration for screen-reader users. Screen-reader users can’t necessarily hover over a piece of content with the screen-reader. They can’t really mouse over something.
Again, the manufacturers of screen-readers have tried to implement that functionality before, but it’s been pretty problematic. And so yeah, that’s a great point. This has already been a concern for screen-reader users in how you give them access to these controls.
So I think that in some ways this isn’t necessarily all that new. It just extends it a little bit out to people who can also see and aren’t using screen-readers. I don’t know if that answers your question, hopefully. Do we have another question?
SOFIA LEIVA ENAMORADO: We had a comment that said Google Authenticator or similar could be a good example for 3.3.7. And then we just had a request, if you could please repeat 3.3.7.
AARON CANNON: Yeah. Can you–
MICHELE LANDIS: So I have that slide up.
AARON CANNON: –go back on the slide? Yeah.
MICHELE LANDIS: I’m there.
AARON CANNON: OK. Go ahead.
MICHELE LANDIS: So 3.3.7 is Accessible Authentication. It’s a level single A, which is new. And then the first bullet point summarizes. It says, “for each step in authentication process that relies on a cognitive function test, at least one other authentication method–” sorry for the typo– “is available that does not rely on the cognitive function test, or a mechanism is available to assist the use of completing the cognitive.” And that’s why our colleague here suggested that the Google Authenticator might be an option, Aaron.
AARON CANNON: Yeah. Yeah, and I think, to be clear, the way Google authenticates you– well, there’s a couple of ways. One is, touch this button if you actually want to log in. That’s probably OK. What’s a little bit questionable– and I need to dig into this a little bit more– but it seems like this would prohibit you having to type in the six-digit code.
So the two ways that Google does it is one is, yes, this is me, and you just tap a button. The other way is that it shows you a code, a six-digit code, and you have to type that in. I believe that would violate the requirement to not have to transcribe. Because a lot of times, you receive those codes on a different device than you’re using. So copy and paste isn’t really an option. So it’s going to be interesting to see how that gets interpreted and implemented when it’s released. All right. So we’re about–
MICHELE LANDIS: Anything else? Yeah. Anything else from 3Play, or are we good? Good?
SOFIA LEIVA ENAMORADO: I think we’re good to move forward.
MICHELE LANDIS: OK, great.
AARON CANNON: Great. So WCAG 3.0. We’re not going to have a chance to get through all the slides. I’ll just talk about what are the major features? What are they trying to do here?
I’m pretty excited, if they can pull this off. I think it’s going to be a multi-year effort. I don’t expect to see it before 2025, and I will be very surprised if we see it even that soon.
Here’s the reality with– we can move on to 16, if you haven’t already. It’s not just a new set of criteria. All the upgrades to WCAG we’ve seen have just been a set of criteria, a set of testable criteria.
This is not that. This is a major rethink of accessibility and how we handle accessibility. They give up on this idea, as I mentioned before, of it just being for the web. And they embrace desktop and mobile and so forth. And again, that’s how we’ve been using it, so that makes sense.
There’s also some question as to how backwards compatible it’s going to be with WCAG 2. I have heard that maybe if you’re WCAG 2 compliant, you’re going to be fine. Up to double A, you’ll be compliant under bronze, under the three guidelines. So that’s also new. So they’re doing away with the single A, double A, and double A, and now they have conformance levels. Or I don’t know if that’s even the right term to use.
MICHELE LANDIS: Categories. Yeah.
AARON CANNON: Yeah, bronze, silver and gold. And so the lowest one is bronze, obviously. And so maybe if you’re WCAG 2 conformant you’ll also be bronze and WCAG 3 conformant. We’ll see. All of this is very, very much early and very much up in the air.
MICHELE LANDIS: It is. Some of the problems, Aaron, with the previous versions– which is illustrated here on this slide– are that there has been a true-false accessibility. And that doesn’t match. Accessibility is a spectrum. We’ve never had a population of humans dependent on technology aging.
So a lot of the conversations I’ve had with other thought leaders in regards to WCAG 3.0 is, what’s the future? Even just bringing AI and stuff into it, how does that happen? So there’s a lot of things moving at a really, really fast pace, and I think I can speak for probably everyone here in that sometimes regulations tend to not keep up with how fast technology can go. So this is a 10-year refresh cycle that fails to keep up, and for sure even a two-year cycle.
And I think, when I look back in 2016 and stuff, Aaron, when I met you, and we started this whole journey that I’m on and you’ve been on for a long time, the Advanced Notice of Proposed Rulemaking was out. And they were going to issue these, and the DOJ was going to make WCAG it or not it. They never did it.
Because from my personal opinion, right up until the moment they hit the button on it, there’s changes and changes and changes. And as soon as you push that button, then that’s that speed bump in time. And it immediately, the minute you push the button, becomes outdated, because technology advances so quickly.
And so I too am very excited about 3.0. Here at A360, this falls in line with really our mission and our vision for accessibility, usability, equitable access from the start of our company. So I’m excited to see it. I’m excited for 2.2, because it means, hopefully, we’ll get closer to 3.0. But who knows? Yeah.
AARON CANNON: It’s not just a set of success criteria now, or it won’t be that you either pass or fail. It basically has a scoring system. So you rate yourself along a continuum– which, again, is very much reflective of the real world and how things like that actually work.
And I think that’s one thing that– why the plaintiff attorneys have done so well for themselves at the expense of website owners is because you can run a scan, and the vast, vast majority of websites are going to fail it. Pretty much any website is going to fail at least one success criteria. And under the current model, that means you fail the WCAG. And they definitely play up that aspect of it.
And so I think this is going to be a much more healthy way to look at accessibility. So yeah, also very excited about it. And we are at time but more than happy to take questions. And Michele maybe had a couple closing words you wanted to say as well while folks type their questions, if any, into the chat.
MICHELE LANDIS: Yeah, and we’ll make sure that updated– minus my typo– will be available for everybody. And as we go through the rest of the 3.0 slides here, again, just examples of what’s coming, how to test for things. One of the things at A360 that we’re known for is really teaching how to test for accessibility, not keeping the secrets of this behind a curtain with our wizards but yanking that curtain open and teaching people how to do this.
So there’s a lot of additional things in here about methods and examples of 3.0. It’s coming in the future. I do have a slide [INAUDIBLE] and just if you have any questions, we’ll make sure [INAUDIBLE] thank them very much for having both of us on today to have this conversation with participants and ask any remaining questions or anything else. Thanks.
SOFIA LEIVA ENAMORADO: Yeah. Absolutely. We had one question, and that was for 3.3.9, Redundant Entry. This sounds like it would also require cookie-tracking consent. Would a user have to consent to cookie tracking in order for this to take effect on a website?
AARON CANNON: Good question. I think, putting my developer hat on, I think they’re– yeah, you’d have to be able to track the user somehow. Maybe that’s a session ID that you put in the URL. But as soon as they leave the website, they’re going to lose that.
So you could possibly get away with not requiring cookie tracking, but it would only be temporary. It would only be for that one session. Otherwise, yeah, you’d probably have to either have the user log in again so you could identify them or–
Yeah. That’s a really, really interesting angle. I did not even consider it from that angle. I think, the reality is you can only track the user as well as you can. And also this guideline is about steps typically in more of a multi-step process as you fill out a longer form.
And so I suspect, in most cases, you’re going to have to identify the user consistently throughout that process anyway. And so going beyond that may not actually require that you track what information the user has previously entered, if you don’t know who the user is anyway. I don’t know if that’s making sense. I’m trying to think on the fly and not doing a very good job of articulating that.
MICHELE LANDIS: That’s a great question. Yeah, really good point.
AARON CANNON: Yeah, it really is, and that requires a whole lot more thinking than I can do here. But that’s a really good question.
MICHELE LANDIS: Right, and I think the privacy laws may take that up, like the California Consumer Privacy Act, which requires that the cookie notifications themselves are 2.1 compliant now. And that was issued last year at this time in anticipation of 2021. So I see, especially in the state of Colorado, where I spend a lot of time, and here in Minnesota, where we’re located, a lot of state governments and some provincial governments up in Canada as well looking at accessibility and the ties to privacy.
So I think it’s a great follow-up one. So thank you, 3Play, very much. I know that we are over time by about three minutes. But again, thank you, Aaron, for joining and being my technical wingman to walk the audience through this. And to everybody who participated, thanks for all the great questions and conversation.
AARON CANNON: Yeah, and we do have a few minutes, if there are any additional questions. Otherwise, I don’t know if we made it through them all.
MICHELE LANDIS: Yeah. Happy.
SOFIA LEIVA ENAMORADO: I think that was all. All I’m seeing come in is just really grateful comments from all the attendees. Thank you so much for taking the time. This is a webinar we’re going to be watching over and over again, because it’s just a lot of really great information. And just a reminder to everyone, we will be sharing the recording and the slide deck tomorrow with you all. And thank you for joining us here today, and thank you, Michele and Aaron.