Transcript for “WCAG 2 2 Guidelines for Mobile, Web, and Beyond” Webinar
Transcript with Audio Description
[00:00:00.23] Hi, everybody. Thank you very much. It’s a pleasure to talk with you today. My name is Aaron Page. I am director of accessibility here at Allyant. It’s
[00:00:07.76] very much a pleasure to talk with you today about the newest version of the Web Content Accessibility Guidelines, WCAG 2.2.
[00:00:14.63] Just a little quick background on myself. I am director of accessibility. I started out here at Allyant as a native screen reader auditor. I myself am blind. I was born with congenital glaucoma, lost my remaining functional vision about 15 or so years ago now. Been working in the digital accessibility space for 10 years, the last five of which have been here at Allyant.
[00:00:33.59] And as I said, started off as one of our native screen reader auditors. As you might expect, we conduct our audits in teams of 2 with a live screen reader user along with a sighted auditor to really get that full assessment of a website’s accessibility.
[00:00:46.79] So today, we’re going to talk about the Web Content Accessibility Guidelines version 2.2. And we’re going to give a little bit of background for those of you who are new to WCAG, just on what WCAG is, a light little understanding of the history of it, how it’s organized before we dive in to the specific new updates that were rolled out in WCAG 2.2 here.
[00:01:10.81] So what are the Web Content Accessibility Guidelines?
[00:01:14.85] So WCAG, the Web Content Accessibility Guidelines, they were developed by the Web Accessibility Initiative. The WAI is a project of the W3C. And the W3C is an international organization that really is responsible for the standards that we think of that build the modern web, so think of the HTML specification and CSS specifications. These are actually developed by the W3C. The WAI is a project of the W3C specifically focused on digital web mobile document accessibility.
[00:01:49.39] And so the Web Content Accessibility Guidelines, you can see the goal that they were developed with there, providing a single shared standard for content accessibility that meets the needs of individuals, organizations, and governments. So really, an international standard that everybody can be able to refer to to evaluate and determine whether or not web content initially, but really it’s broadened out to mobile and document accessibility, which you’ll hear me talk about again and again throughout this presentation. But a single standard to ensure and evaluate the accessibility of those types of content.
[00:02:24.75] Slide, Who is W.C.A.G. for?
[00:02:26.82] Who is WCAG for? So this is a list that’s straight out of the Web Content Accessibility Guidelines, and they say web content developers, site designers, authoring tool developers, evaluators. And you can really take any of these users and put mobile in front of it, mobile application developers, mobile authoring tool developers, document authoring tools, document reader developers. Really, it’s a standard that is applied well beyond just the simple context for web that WCAG kind of seems to indicate in their list that they provide here. But it’s much, much broader than that.
[00:03:06.12] Slide. Image.
[00:03:06.96] What types of content does WCAG apply to? As you’ve heard me say already, websites, web applications, mobile applications, documents, electronic documents, of all different kinds of formats, Word, PowerPoints, PDFs, Google Docs, Google Slides, Visio documents, spreadsheets. You name it. WCAG is applied in a great many electronic contexts. Desktop applications, as well, is one I didn’t mention that I should have. So it goes well beyond just website web application accessibility to encompass a great many types of digital content digital formats.
[00:03:44.31] Slide, What content does W.C.A.G. apply to?
[00:03:46.52] How is WCAG organized? I feel this is a very useful thing to understand. And this applies really to all three versions of WCAG 2.x, so 2.0, 2.1, 2.2. WCAG 1.0, we’ll talk a tiny bit more about that in the next slide, but it was organized rather differently. So what we’re describing here really applies to the 2.0 series of versions of WCAG. But the way in which it’s structured is in the form of principles, guidelines, and success criteria. And so an easy example of this is 4.1.2, name, role, value, is a specific success criteria in WCAG.
[00:04:30.05] So 4, 1, 2, that number four in there represents the principle, and the principles are perceivable, operable, understandable, and robust. If you ever hear the acronym POUR referred to in the context of digital accessibility, this is what it’s talking about. And the way that I like to think about this is perceivable, can I see it? Operable, can I use it? Yeah, can I use it? Understandable, can I understand how I’m supposed to use it? And then robust, can I actually use it consistently across different devices, different platforms, different situations? I think is an easy way to think about it.
[00:05:09.31] But the first digit in WCAG success criteria, so in this example, the number four, that represents the principle. So 4,1,2 falls under the robust principle of WCAG. Then the number one, that goes to the guideline. So guideline 4.1 is what is being violated here with success criteria 4.1. 2. And then the number 2 represents the specific success criteria. So under guideline 4.1, there are two, now three, specific success criteria there. And so this one, name, role, value, is the second testable success criteria under guideline 4.1. So that really is the hierarchy of how WCAG is organized into principles, guidelines, and then success criteria.
[00:05:59.52] It also has levels, so level A, level AA, level AAA. And up until WCAG 2.2, they were pretty well organized in that they went from the lower number success criteria being level A, the higher number ones being level AA, the highest numbers being level AAA. That pattern is a little bit broken now with WCAG 2.2, so you do have to pay a little bit more attention to which specific level a success criteria is at.
[00:06:29.25] But it’s pretty clear which level that is if you go and look it up in WCAG. But there’s still level A, level AA, and level AAA. Industry best practice, and we’ll talk again about this later on, is that you conform to level AA. So your focus really will be on level A and level AA success criteria and guidelines. You don’t need to necessarily worry about things that are level AAA.
[00:06:53.96] Slide, W.C.A.G. Version History.
[00:06:55.11] So WCAG version history, just a little quick background on this. So the first version of WCAG version 1.0 came out in 1999. The first version of it was pretty restrictive. It was structured very differently in the form of checkpoints. And so one of the biggest kind of concerns, as I understand it, around WCAG 1.1 is how prescriptive it felt.
[00:07:21.93] Whereas WCAG 2.0 is built into these guidelines and success criteria which really outline their intent. WCAG 1.0 is almost more like a checklist, and it was just, you must check this box. You must do this thing. If you can’t do this, then you can’t conform. There it is.
[00:07:38.88] WCAG 2.0 with its new structure is a lot more flexible in that regard. And so WCAG 2.0 came out in 2008. And it rolled out with 12 guidelines and 61 success criteria. And so as new versions of WCAG 2.0, 2.1, 2.2 came out, they built upon one another. So again, with 2.0, you see that it had 12 guidelines, 61 success criteria. 2.1 came out in 2018. It added an additional guideline and more success criteria. So now it had 78 success criteria. And now with WCAG 2.2, it has added nine additional success criteria. And it has 13 guidelines, 86 success criteria.
[00:08:29.02] And so those of you who are doing the math might wonder, well, wait a minute, if you have 78 and you add 9, why is it that you have 86? And the reason why is because for the first time ever, WCAG actually deprecated a success criteria in WCAG 2.2. So you actually have a requirement that was present in 2.0, 2.1, that is no longer present in 2.2. And we will talk a bit more about that shortly.
[00:08:58.55] So what are the new WCAG 2.2 success criteria? Getting to the heart of the matter here when it comes to this presentation. So here’s the list of all nine of the new WCAG 2.2 success criteria. And you know, reiterating the point that I made earlier, industry best practices to focus on level AA conformance. And so really, while there are 9 here, your particular focus is likely going to be on the six that are at the A and AA level here. You’re not going to necessarily seek to conform to all nine of these.
[00:09:39.65] I’m not going to go through and read them all off because what we’re going to go ahead and do now is go through each one of these six new success criteria and really just at a kind of high level here. And give you a high level explanation of what that new success criteria is, so you can start thinking about what is that going to entail for you when it comes to conforming to that requirement.
[00:10:04.10] So the first one here– and again, these are all level A and level AA WCAG requirements.
[00:10:13.22] This first one here is focused not obscured. You can see the text of the actual WCAG success criteria there. I’m not going to read that out. The moral of the story when it comes to the success criteria is that you don’t want to have an element that can receive focus, an actionable element, that is completely obscured by another piece of content.
[00:10:37.42] The easiest example to think about is a sticky Header or a sticky Footer, something that kind of moves with you as you scroll up and down through the page. Well if you can tab onto, let’s say, a Submit button, that Submit button has to at least be partially visible. It can’t be completely covered over by the sticky Header or sticky Footer, whatever it may happen to be.
[00:11:00.69] And so this one is kind of an interesting one because I think most live user– I’m sorry– live user testing outfits, such as Allyant, really could consider this an issue already under 2.1.1 for keyboard only operation. I certainly would identify this as an issue during a type of an audit just because it prevents keyboard only users from being able to access the control if they can’t actually see it.
[00:11:25.29] And so here, it’s nice to see that this is actually codified in WCAG 2.2, but I suspect a lot of other folks in the accessibility space are doing what Allyant has really been doing already and would have kind of would have identified this as an issue already should an element have been completely obscured.
[00:11:44.99] The difference here between the requirement at the level A and AA level versus the AAA requirement, because there is a AAA version of this, is that at the AA level here you can have it be partially obscured. So part of that submit button could be covered over and that would be considered acceptable here, sufficient to meet the level A, level AA requirements of WCAG because part of that control is in fact visible.
[00:12:16.58] On the other hand, if the control was completely covered over, that would be a violation of it at the level A, level AA level here, so. At the AAA level, the entire control must be visible. That whole Submit button has to be visible in order to be AAA conformant. But again, AAA is not really the standard that you should be seeking to achieve. It’s always best to target that level A, level AA conformance. That really is the industry best practice there.
[00:12:45.50] And this is designed for users who rely on keyboard focus, as you might expect, or keyboard interfaces, so sip puff switches, joysticks, different types of things like that. But these users need to be able to see where their focus is in order to be able to interact with the control. And if whatever they land their focus on is completely obscured, they aren’t going to be able to see it. They aren’t going to be able to use it. That would be a violation of this WCAG requirement.
[00:13:14.73] The next one is around dragging movements. And so again, you can see the actual text of the WCAG success criteria here. I won’t read that out.
[00:13:26.91] But the moral of the story is that actions that require you to drag, they have to have an alternative that allows the user to complete that using the mouse pointer and without holding down the button.
[00:13:39.81] So if you think about a typical drag, you click on an object, or you tap on an object, and you move it over. You continue to hold down the mouse pointer. You drag it over, and then you release the mouse pointer at the desired location. This is intended for users who are using the mouse pointer, but aren’t able to hold down the button. So that part of the typical drag flow is what’s being kind of targeted here.
[00:14:07.08] And so in WCAG 2.0 and 2.1, the real focus when encountering a drag and drop style control has been is there a keyboard only alternative? Is there a way to do this using the keyboard? That alone isn’t sufficient in WCAG 2.2. What WCAG 2.2 is essentially asking for here is you’ve got to have a way of completing that function, that drag and drop functionality, using the mouse pointer, but without having to hold the button down. So essentially, to be able to click on it, move to the other location, and click again, not have to hold that mouse button down.
[00:14:44.46] So that’s the intent behind this and what they’re kind of looking for in terms of the actual interaction and behavior here. Obviously, this is designed for users with motor dexterity disabilities who aren’t able to hold down the mouse button. And again, the big thing here to think about is that simply having a keyboard only alternative is not sufficient for this, unlike WCAG 2.0, WCAG 2.1.
[00:15:10.74] This is really going above and beyond just having that keyboard only alternative, and it says you have to have a way of doing it with the mouse pointer, but without holding down the button. So whether you allow the user to click once and then click again, or maybe you click and a series of controls appear that allow you to select from an option to perform that same task. However you seek to approach it, but you shouldn’t have to click and hold down the mouse button in order to perform the operation.
[00:15:40.54] Slide. Image.
[00:15:41.76] So the next requirement in WCAG 2.2 here at the level A, level AA level is around target size, and so the minimum target size for an element. And so this one is actually a relatively short and straightforward one in a sense, but could also become a very large, large issue as it does directly impact the visual look and feel of a website, or a web application, or a mobile application.
[00:16:09.05] And any time that gets called into question, that obviously leads to a lot more discussions with UX designers, UX concerns, branding, different types of things like that. So always a bit of a touchy spot when you have to make modifications that will impact the visual look and feel of the app.
[00:16:26.01] But what this requirement in WCAG 2.2 says is that actionable elements, elements that perform a function, have to be at least 24 by 24 pixels in size, or they have to be 24 by 24 pixels in size when you account for that surrounding whitespace.
[00:16:43.81] And so what they are trying to do here is ensure that controls are large enough that users with motor dexterity disabilities who might not have the most precise or accurate navigation when they want to tap on an object or click on an object are able to reach it, that controls aren’t so small and so bunched together that users who can’t perform a precise click end up inadvertently clicking on the wrong thing.
[00:17:08.71] So that is the requirement here for target size, that it’s got to be a minimum of 24 by 24 pixels in size. If it’s bigger than that, then you’re just kind of automatically good to go. If the control is smaller than that, then you do have to take into account the surrounding whitespace. So it’s OK if the control is smaller than 24 by 24, but there’s got to be enough whitespace, dead space, no other controls, actionable elements surrounding it that the user can tap on that or be able to click on that without issue there.
[00:17:40.53] And there are a few exceptions on here. Some of the exceptions that they outline are if a control is inline. So for example, if there is a link that is embedded within a paragraph of text, that is an inline element. It’s an inline control. And so you don’t necessarily have to make the link bigger if the surrounding text is smaller than that size. So there is an exception if it’s considered inline in that regard.
[00:18:08.61] Equivalent, what they mean by that is if there’s another control elsewhere on the page that allows you to perform that same function, then if that control does meet the size requirement, it’s OK to have a control that doesn’t. So if you have two buttons on a product page that allow you to view the ratings and one of them is a very small control adjacent to the Buy Now button.
[00:18:31.26] That control doesn’t meet the size requirements. But further down the page in the product details, you have a very large prominent button that can be toggled to view those reviews. Because you have a second control on the page that is equivalent, it provides the same function and it meets the size requirement, it’s OK that that one that’s adjacent to the Buy Now button does not meet the size requirement. So that’s what they mean by equivalent.
[00:18:54.78] User agent is talking about if the control is generated by the browser. So think of if you’re using an input type of date, then the way in which that appears will actually vary a bit depending on whether you’re using Chrome, Firefox, Edge, whatever browser it might be, has their own slightly different twist on how those interfaces appear. Those are being generated by the user agent, and so those are out of the scope of this requirement, as well.
[00:19:20.98] And then essential, and essential is actually a pretty common exception that you see in many WCAG success criteria. And it’s a source of great frustration and great arguments for many people. But essentially, what it tries to say if meaning this would alter the core functionality of it, it would invalidate the experience, then it’s considered essential.
[00:19:42.00] An easy example not using this success criteria, but is around timing. And so WCAG says that you can’t place arbitrary limits on time for users to complete a task. You have to give them the ability to extend it. Well if it’s an auction, giving the user an option to extend it would invalidate it.
[00:20:01.99] And so that is an example where it would be considered essential because to meet the requirement would invalidate the activity. And so essential is definitely a tough one that a lot of people kind of debate around, and there’s a lot of confusion and argument over it. Not something you want to try to hang your hat on, certainly, in my opinion anyway.
[00:20:24.49] So that is the target size requirement, 24 by 24 pixels in size or that large when you account for the surrounding whitespace. Really targeted at those users who have motor dexterity disabilities, might struggle with interacting with controls that are very small, very tightly clustered together, that type of thing.
[00:20:42.42] Hey, AP.
[00:20:44.98] Two questions on this one, specifically. And then we have some other questions, but I’m saving them until the end. But specifically on 2.5.8, I have two if you want to answer them in real time.
[00:20:56.29] Perfect. So the first one is for 2.5.8 target size, what if the element is smaller than 24 by 24, but when using an ADA tool, it makes it bigger? And I’m guessing we’re going to have to make some assumptions in an ADA tool is something like a toolbar or an overlay, but I’ll defer to you.
[00:21:14.32] Yeah, in general, the idea behind WCAG is that it’s not taking into account changes to the Settings that the user might have made or assistive technologies that they have installed. This is talking about just out of the box, if I go to your site, I’m looking at your site, does this meet this requirement? Not necessarily, does it meet this requirement if I have an extension installed or a particular piece of assistive technology, that type of thing. It’s designed to make it compatible with those assistive technologies. But your conformance isn’t measured based on whether one is being used.
[00:21:51.35] An easy to think of example is color contrast. Most operating systems and devices have high color contrast functionality built into it. But when you go to measure a site’s color contrast against WCAG, you’re not turning on high contrast on the computer to do it. You’re measuring it based on how it just appears on the site.
[00:22:12.44] Perfect. And then the second one– and I’ve made note of this, as well, if we need to follow up– But what is 24 at 24 pixels work out to for PDF accessibility?
[00:22:24.93] This is an excellent question. And I will be straight and say that my specialty lies more in the digital web mobile app accessibility side of the house. We can certainly take that to our PDF gurus and get an answer for you. As most of you are aware, Allyant, we have three different divisions here. We provide alternate format solutions. We also incorporate CommonLook, which is a very popular accessibility suite. And we can certainly send this question over to CommonLook, and get a more defined answer to you.
[00:22:56.85] Yep, and I made note of that, John. So I will be sure we follow up. And then the final one, AP, on 2.5.8, and then we can roll on is what is the best way to test for 2.5.8? Interesting one.
[00:23:09.21] Yes. It is an excellent question, and it is one that our audit team has been definitely trying to hash out. Because if you go to the understanding page of the WCAG provides for 2.5.8 and look at the specific success technique, they don’t outline necessarily testing parameters or testing steps for this. And so an easy way to go about it is, to start with anyway, is to check just the size of the elements.
[00:24:03.02] Now you have to start thinking about, OK, well what about the surrounding whitespace that’s around it. And so that’s where the testing of it can certainly become a little bit more difficult. Our audit team is relying a bit on some browser extensions that will provide a defined outline around that element to help you visualize this. And to some extent, it will require just some intuition. Looking at it and assessing, OK, how tightly packed are the controls?
[00:24:31.62] If it’s a tiny control that is smaller than 24 by 24, and it’s immediately adjacent to other controls, it likely violates the success criteria. And so this is one that will require a bit of human judgment, I think, as well. From a programmatic perspective, it’s a bit hard to– it’s easy to calculate what the size of the actual element is, but getting a clear programmatic way of seeing the size of that surrounding whitespace, plus the size of the element, that’s where it becomes a bit more difficult.
[00:25:00.24] Slide, 3.2.6. Consistent Help, A. Image, A smiling young man.
[00:25:06.12] And we have some more rolling in, AP. But why don’t we keep going, and I’ll just keep note of all of these.
[00:25:11.70] Perfect. Yeah. And we’ll have time, I do believe, at the end for Q&A. I think we’re moving through the slides pretty quick here.
[00:25:19.57] All right, so let’s keep talking about some more of the WCAG 2.2 requirements here. So 3.2.6, consistent help, so essentially what this is saying, that if you have help mechanisms and contact information on your site, that help mechanism, that contact information, needs to be presented in a consistent manner in a consistent location.
[00:25:43.90] And so if you have contact information, let’s say, located in your site Footer throughout most of the site, and then you get to a flow where that contact information is gone. You can’t find it anymore. It’s no longer at the Footer. That could be considered a violation of this.
[00:26:00.93] Or if on some pages you’re providing tooltips that are adjacent to the controls and on other pages you’re providing help text that is located at the top of it, these are inconsistent ways of providing access to the help information, the help and the contact information.
[00:26:17.90] This is truly, from my point of view, not something I expect to be seeing a lot of issue being pulled out on. Most sites most applications tend to utilize components to do this. They have a tooltip component. They have an FAQ page. They have contact information that is located in the Header and the Footer. And so, generally speaking, from my experience, helping contact information is usually fairly consistent.
[00:26:42.79] But that is what this success criteria is talking about, those self help, tooltips, contact information, things like that, those need to be in a consistent location so that users can find them. And if you think about it, this one does impact a lot of different types of users with disabilities. And so obviously, somebody like myself who is blind, if you’re moving your help information around, I can’t see where it’s at. So now I have to go looking for it.
[00:27:07.84] If I know it was on your Footer to begin with, but now it’s not, now as a screen reader user, I kind of have to go reread through your page until I manage to find it. Whereas the sighted user can kind of visually skim through the page and be able to locate it that way.
[00:27:20.71] Keyboard only user, now they have to figure out how to navigate to wherever your contact or your help information has been located, so they’re having to figure that out. Users with cognitive disabilities simply get disoriented by the fact that it’s not consistent in the way that it is located and presented throughout the site.
[00:27:39.79] So a big caveat to this is thinking about sets of pages. What it talks about is that the help information should be provided consistently across sets of pages. And so what constitutes a set of pages is potentially a source of debate when it comes to the success criteria. I mean, does the set of pages mean on an e-commerce site the home page, the PDP, the PLP, the cart, the checkout, the checkout flow, or does it just mean the checkout flow is a set of pages?
[00:28:09.49] That’s probably an area that you could certainly debate about. But the overall takeaway is provide your contact information, your help mechanisms, consistently across your site, across your applications, as much as you possibly can, and then set might be something to debate.
[00:28:27.37] Obviously if you have a particular reason why you need to present your health information in a certain way during the checkout flow, you could very reasonably argue that the checkout flow is a unique set of pages unto itself. It is consistent within the context of that set. So a lot to think about when it comes to that particular WCAG 2.2 success criteria.
[00:28:49.02] Slide, Redundant Entry.
[00:28:50.78] The next one is 3.3.7, Redundant Entry. And I’m going to apologize in advance if we have any government employees on the line who might be significantly impacted by this because what it specifically says is that you shouldn’t make the user enter the same information twice without providing a mechanism to auto populate or to pull that information over. And so if you have a workflow and you tend to ask the user to repeat themselves a lot, to repeat that same information, that can be considered a violation of the success criteria if you don’t have some way for the user to pull over their prior response.
[00:29:26.51] An easy to think of example of this is pretty common on most e-commerce websites when you go and you fill out the checkout, you enter in your shipping information. And so you put in your address, your zip code, your name, your phone number, all of that information, and then you get to the billing step and you enter in your credit card information, that option is provided that says my shipping is the same as my billing, or my billing is the same as my shipping. By checking that box, it pulls over the information that you already entered into that kind of duplicative field if it’s the same information there.
[00:30:01.00] And so that’s a kind of easy to think of example of giving the user the ability to pull that information over that they have already entered. There are some exemptions for this one, as well. We get to– sorry, I lost my focus in my notes here– essential, again, there’s that essential one that we talked about.
[00:30:25.41] Security, so if the information is needing to be entered in again for security verification, type of purposes, then obviously, that would be considered exempt from this, and when previous information is no longer valid. So if for some reason that information has changed or would have been expected to change, it’s no longer valid, then obviously, giving the user the ability to pull it over is not going to be helpful because it’s not valid anymore. And so that would be exempt from this requirement, as well.
[00:30:56.92] This one here is designed obviously for users with cognitive disabilities for whom having to re-enter the same information again and again could cause mental fatigue. And also the WCAG doesn’t point to this specifically if you go to their understanding page for this success criteria, I would strongly say that users with motor dexterity disabilities are significantly impacted by this, as well, because they have to go through the process of re-entering that duplicative information.
[00:31:25.63] So that is the Redundant Entry requirement in WCAG 2.2. And then we get to 3.3.8, Accessible Authentication. And so this is our last one here at the level A, level AA level. And it is a rather interesting one. And I know that a lot of debate went in behind the scenes when it came to Accessible Authentication.
[00:31:50.67] Certainly, you can find a lot of debate and argument about it if you go reading about this one online. And in the end, the final version that WCAG released for this at the AA level to me is pretty mild and is not something that most companies, most organizations, are going to struggle with conforming to.
[00:32:13.11] Essentially, the way to conform with this is to ensure that users, if you’re relying on a username and password, which most obviously log ons are, followed by a two factor, the username and password is perfectly fine as long as the user is able to copy and paste in a password as long as a password manager is being supported.
[00:32:34.03] And I will say, I can only think of one time in my five years of auditing work here at Allyant where I saw a site deliberately turn off the ability for the user to paste in a password into the log on form. So I don’t think this is something that happens quite a bit.
[00:32:52.96] Then when you get to your two factor, you have a few options here, really, at the level AA level. And so you can go with object recognition. I’ve encountered at least one example of this that I can think of where I was asked to create a log on, set up my username and password.
[00:33:11.32] And then they asked me to set up a second step where they gave me a series of images, and I had to pick an image that I liked, and that was going to be my security image. So whenever I logged in again, I just had to select that image. It would show a handful of different images, and I had to pick the right one, the one that I had set as my security image. And so that is an example of something that would be sufficient to meet this requirement.
[00:33:34.33] Alternately, if you allow the user to upload their own image, that also would be considered sufficient. And you could also use video and other types of multimedia. WCAG does allow for that. But I think by far, the most common use of this we’re going to see would be images for this type of object identification there.
[00:33:55.87] And then if you are relying on what I think the vast majority of users are, which is a validation code, a push notification, or an SMS text that sends the user a code that needs to be entered in. That is considered sufficient, again, as long as the user is able to copy and paste in the code. And WCAG does account for the fact that this might be on a separate device.
[00:34:20.72] So if I’m trying to log into your site on my Windows PC. I enter in my username. I paste in my password from my password manager. I now am being prompted for a two factor authentication code that’s been sent to my phone. WCAG does allow that the user would share that code from their phone. They might email it to themselves. They might have a shared clipboard that they use across the two devices.
[00:34:43.78] Whatever mechanism might be, WCAG essentially assumes that the user has the ability to get the code from device A to device B. What you have to be concerned about is once the user gets the code onto their Windows device, can they paste it into your two factor field? Wherever you type the code in, can you paste the code? As long as you can paste the code, that is considered sufficient.
[00:35:07.72] So really, the biggest way to think about this is can the user copy and paste in their username and password? Can the user copy and paste in the two factor authentication code? Or do you use an object or a personal identifying image type of system approach for that two factor authentication where the user might upload their own security image, or they might pick a security image identifying an object?
[00:35:34.07] Any of those approaches are considered sufficient, but from my experience, the vast majority of folks are really going to fly through this one because I’ve only once that I can think of off the top of my head seen a log on where they deliberately shut off the ability to paste a password in. It’s just so common now that everybody uses password managers. It’s considered the best practice, so nerfing the ability for the user to use one would be a huge usability break. And so I don’t think many folks do that.
[00:36:01.09] The bigger question that comes to your two factor, how does your two factor work? Can you copy and paste in the two factor code? From my experience, most of the time, the answer to that is going to be yes. If your two factor code entry breaks it up into separate fields, for example, I see this on iPhone where they actually instead of having one code where you enter five digits, they have five fields where you enter one digit.
[00:36:25.40] As long as you can copy and paste still into that first field and have it drop it automatically into the rest, which the Apple one does, that’s considered sufficient. But if by using five separate fields you break the ability to copy and paste the code, that would be considered a violation of this requirement.
[00:36:41.70] So in the end, it’s not a big one if you ask me. However, it is one that is going to make for an interesting discussion about automated accessibility solutions. And so we’re going to talk a bit more about that here in just a few more minutes.
[00:36:56.75] Hey, AP. We have two good questions that I think would be best to just cover in real time. So Stephanie asked a great question. And this is one of my favorites because I struggle with this one, and I never guess the right images. But Stephanie said, what about the authentication when they ask you to click on images with, say, a car? And I think it’s normally nine things, and you got to pick the nine images that have a car. She said, I imagine this greatly impacts blind or visually impaired users. Any thoughts on that?
[00:37:22.83] Yeah. Yes, it does. And I mean, usually though, that would be covered already by existing WCAG 2.0 requirements. Because the concern that comes up there is, well, if the security question says, click the image of a car, you obviously can’t give all attributes that say car, right?
[00:37:42.00] And so usually, the push back to making that type of a security approach accessible is, well, I can’t put it in the alt attribute because then a bot would be able to just simply compare the question text to the alt text and break my security tool. And so where that violation for that type of approach usually comes in is around 1.1.1 non-text content because usually the images aren’t labeled.
[00:38:06.36] Like I’ll hear as a screen reader user, it’d say, click the image of a car, and then I’ll hear five unlabeled images because obviously, they don’t want to label one that says car, right? So that is really a kind of scenario already covered by WCAG I would say.
[00:38:21.70] And then the second one I think we can answer in real time is if we provide the user a set of images from which the user chooses one to be their password in the future, is that acceptable?
[00:38:31.56] Yep. That’s exactly what they’re talking about here for this requirement at the AA level. So if you set up a username and password and then for your two factor approach, you ask the user, pick an image, and the user picks an image of an apple.
[00:38:47.13] And then when they go to login again next time, they put in their username and password and they see five images. And one image is an apple, and they just are asked, pick your security image. And they pick the apple. That’s an example of an approach that would be conformant with this requirement.
[00:39:04.39] It’s not something that I’ve seen a lot, but I have seen it. So it does work. I will also say there is AAA success criteria around authentication. And the big difference between the AA and the AAA one is the AAA one does not allow for that object based identification.
[00:39:22.12] So this example we just talked about of using an apple as your security image and just being asked to pick your security image every time you log in, that would not be valid under AAA because it’s an object based approach. And that’s the difference. They don’t allow for that object based approach.
[00:39:39.30] The argument being that users with more severe cognitive disabilities may particularly struggle remembering what objects they picked and being able to recognize it as their security image. But at the AA level, using objects or images like that is valid.
[00:39:55.59] And then final one, AP, is, I assume it’s important that the two factor authentication code does not include formatting spaces or other styling which prevents copying the code as a cohesive string. I’ve seen this in some auto generated 2FA systems. That would be considered a violation, correct?
[00:40:14.52] It’s an excellent question. I’ve not seen anything that clearly states it would be. But I would be inclined at the very least, if I were auditing an application or a site to 2.2 and I saw that, that, OK, it sent me the security code, but the way it sent me the security code, I have to go and remove the dashes, or remove the spaces, or tweak it before I can copy and paste it.
[00:40:37.41] I would at the very least advise against that as a kind of warning level. I don’t know if you could go so far as to say it’s an outright violation because it doesn’t say the user has to have the ability to copy and paste without modification. If it said without modification, then it would clearly be a problem. So I think it’s probably on the line type of scenario there. It’s something I would warn against, but probably wouldn’t go so far as to say you’re violating it.
[00:41:05.46] Ultimately though, the user’s got to have that ability to be able to copy and paste it. So if they can’t copy and paste it after they remove the spaces, that’s clearly a violation. If they copy and paste it, all they have to do is just remove the spaces, that’s probably on the cusp of being a violation, if that makes sense. Not everything is clearly defined in WCAG in that way. There is some interpretation and gray zones.
[00:41:30.06] Slide, 4.1.1. Parsing Deprecated.
[00:41:33.86] Great question.
[00:41:35.11] Image, A man places fingertips on a book.
[00:41:37.84] Well, if there are no more, we can keep moving on through our slides here. The next one that we have, so we’ve gone through the six new level A, level AA success criteria in WCAG 2.2. One thing that I mentioned earlier on is that for the first time ever in WCAG 2.x, they actually have deprecated a success criteria. So something that was a success criteria in 2.0 and 2.1 is no longer a success criteria requirement in 2.2.
[00:42:12.45] And so this is WCAG 2.0 success criteria 4.1.1, parsing. And what it called for was, essentially, for you to use valid HTML, for you to have complete start and end tags, for you to reference the IDs that properly exist, for you to use valid attributes, things like that, essentially, HTML validation.
[00:42:38.37] And WCAG– the idea– the reason for this was because it used to be that many assistive technologies were directly themselves parsing the HTML of the page. They were actually grabbing the HTML. Creating almost their own experience, their own browser page, for the user that they are interacting with.
[00:42:58.17] That’s not the case really anymore. Assistive technologies, pretty much all across the board now, what they are interacting with is the accessibility tree that is being generated by the browser itself, by the user agent. And so they aren’t parsing the HTML themselves. So if you have just simple HTML validation issues, it’s not necessarily going to be a problem.
[00:43:21.07] And so the kind of follow up to that is if you do have an HTML validation issue that would create a problem, that problem would violate another WCAG success criteria. And so easy example to think of is let’s say you have an aria labeledby attribute, and that attribute is referencing an ID that does not exist. So technically, that is a violation of 4.1.1 because you are referencing a non-existent ID. That is no longer a violation because 4.1.1 doesn’t exist anymore in 2.2.
[00:43:55.66] However, the result of the having that broken ID reference is that a conform control is now unlabeled. That control doesn’t have a label that is properly associated. So it violates 3.3.2, labels and instructions. And so even though 4.1.1 doesn’t exist anymore, if you have an actual 4.1.1 violation that creates a real accessibility issue for a user, that is going to be covered by another existing WCAG success criteria. If you are trying to use a role attribute that does not exist, it’s not valid, then you’re going to violate 4. 1. 2, different examples like that.
[00:44:34.28] And so that was a big part of the logic in why this particular success criteria was removed. I will also say, from my experience, this one was cannon fodder for automated scanners. Oftentimes, when you see litigation, you see automated scan reports included along with it.
[00:44:50.39] And so often, this is the type of thing that an automated scanner love to flag because it’s obviously very easy to find. If you’re not referencing a valid ID, or your HTML is missing the closing tag, whatever it might happen to be along these parsing lines, it was very easy to detect using automation. And so now, really, just simply having a validation issue isn’t a problem unless it actually creates a accessibility issue for the user in WCAG 2.2.
[00:45:21.37] So that I think is a fantastic update. One thing to keep in mind, though, is that many organizations are still going to have to deal with 4.1.1 because they might be subject to other versions of WCAG due to other laws. So section 508, obviously, is an easy to think of example of this. It specifically is citing, I believe it’s 2.0, and so it is not automatically updating based on the fact that 2.2 was released.
[00:45:49.16] So if you are an organization that falls under Section 508, then you will still have to conform to this parsing requirement, even though, technically, in WCAG 2.2, it no longer exists. You are being held to an older standard by law. And that law, if it’s not automatic– if it’s not written in a way to automatically reference the latest and greatest versions of WCAG, which most aren’t– outside of California is a big example where it is– then you will still need to deal with conformance to 4.1.1.
[00:46:20.02] So that is the background on 4.1.1, why they chose to deprecate it. To me, I think it’s a great change. It really will just mean HTML validation issues that create a real problem for the user that violate another success criteria, those are the things you have to worry about if WCAG 2.2 is your target there.
[00:46:41.11] So the next slide here is talking briefly about WCAG 2.2 and automated accessibility scanning tools. So as you probably noticed, many of these don’t seem like something that would be very practical to detect by automation, and that is certainly true.
[00:46:57.99] Most accessibility experts– unless they’re really trying to sell an automated scanning tool, an overlay tool– most people in the accessibility space will acknowledge that automation usually finds somewhere between 25 and 35– a quarter to a third– they’ll say something like that– actual accessibility issues. And along the way, it’s going to create a lot of white noise for you in terms of false positives, redundant entries, different types of things like that.
[00:47:25.18] This pattern continues to hold true with WCAG 2.2. As it stands right now, we are obviously in the process of updating our HUB tool kit to be able to scan for and identify as many of these WCAG 2.2 violations as we possibly can. But our current roadmap only looks like we’re going to be able to make two or three of these automatically scannable via automation. And they will still likely require some manual human testing on top of what the automation is able to detect.
[00:47:53.48] So this pattern of 25%, 35% of requirements can actually be found by automation, from our perspective, seems to hold true even when you talk about WCAG 2.2 here. An easy to think of example around this is the authentication one. Do you expect an automated scanning tool is going to be able to actually go to that two factor step of your authentication process, and be able to scan it and determine whether or not the user is able to perform that copy and paste operation?
[00:48:22.81] That is likely not something that a typical automated accessibility scanning solution can do. Usually as soon as a password entry gets put in there, that blocks accessibility scanners from being able to test it. Unless you are using something like a browser based extension where you can do the login manually, but now you’re talking about manual testing using an extension.
[00:48:45.10] So no longer really talking about fully automated scanning. So really, fully automated scanning just not going to be able to identify all of your WCAG 2.2 violations, just like it can’t find all your WCAG 2.0 and WCAG 2.1 violations. You will still have to rely on that live user testing. So don’t believe the hype if you are being told that an automated scanning solution is going to be able to help you conform to WCAG, or will ensure that you conform to WCAG.
[00:49:13.48] Certainly, it can help, but there is no way that it is going to actually be able to scan for and identify all of the potential WCAG 2.2 violations. And again, keep in mind, while there are nine success criteria released in WCAG, only six of them are at the level A and level AA levels. So that really is your focus.
[00:49:33.64] So you hear an automated scanning solution saying, we can help you conform to WCAG 2.2. Immediate question to ask, how many of the WCAG 2.2 success criteria at the A and AA level– there are six of them– how many of it is it actually capable of being able to scan? Likely the answer to that is going to be 1, 2, maybe 3.
[00:49:54.85] So that’s just a bit of background on automated accessibility scanning. Kind of the same message you’ve likely heard from us and other accessibility experts when it comes to automated accessibility scanning solutions for 2.0 and 2.1. They can be a great tool. Don’t expect that they are going to be able to find all issues. They are going to create noise along the way.
[00:50:14.68] And really, the best place for an automated scanning solution is as a supplement to live user testing by actual users with disabilities and accessibility subject matter experts who can really break down those automated scanning solution issues, remove the false positives, and help you focus on issues that actually impact users with disabilities.
[00:50:36.44] Hey, AP.
[00:50:37.27] So, yes.
[00:50:38.49] Yeah, one thing on this one, and I think it’s highly applicable. So one question, similarly, what about widgets and overlays as you just talked about automation?
[00:50:48.95] Oh, golly. I could do an entire hour long presentation about widgets, widgets and overlay tools, you know. The long story short is is that don’t count on a widget or an overlay tool to ensure that your site is accessible. They tend to fall into one of two baskets.
[00:51:07.85] They either say, I’m going to magically by inserting some code, I’m going to make your site perfectly accessible. I’m going to automatically fix all of the issues for you. Well, we just talked about how of the six A and AA requirements in 2.2, maybe two or three might be something that could potentially be detected by automation. So there’s no way some magic chunk of code you insert into your site is going to identify all 2.2 violations, if only two or three of them are something that can be detected by automation to begin with.
[00:51:37.73] The other basket that these tools tend to fall into is insert my widget, and I will give users a suite of tools that they can use. I will add a screen reader to your site. I will add a screen magnifier to your site. I will add high color contrast to your site. And these tools are functionally useless because if a user requires these, they’re going to have them already.
[00:51:57.30] I am blind. I need a screen reader to turn my computer on, and to log in, and to open up Chrome, and to get to a website in the first place. You putting a screen reader on your website does me no good. I needed a screen reader just to get to your website, so now the screen reader that you have stuck on your site is now getting in my way.
[00:52:15.00] You can apply that same concept, that same mindset, to basically all these other tools that, quote unquote, “widgets offer.” So if you offer by installing a widget you put a screen magnifier on, well, if a user requires screen magnification, they’re going to likely be using Windows magnifier, ZoomText, Ultra, some tool like that. So putting it on your site isn’t helpful.
[00:52:36.01] It’s– again, it just gets in the way– high color contrast– same thing– so widgets and overlays are just– avoid them. At best, they’re just not going to fix the issues. And at worst, they’re going to introduce features and functionality to your site. They’re going to actually make it harder for users to use the site.
[00:52:52.89] Slide, Roadmap for W.C.A.G. 2.2.
[00:52:55.80] So we got just a couple minutes left. Power through this one last slide here just about roadmap for WCAG 2.2 conformance. Really important thing to keep in mind is WCAG 2.2– or I’m sorry– 2.0 and 2.1– are still valid WCAG, W3C, recommendations. It is likely going to be a while before we actually begin to see litigation, which is often the biggest driver in the accessibility space, lawsuits, demand letter, settlement agreements, begin to cite WCAG 2.2.
[00:53:28.41] Probably will be a quicker transition than we saw with 2.1, as the accessibility industry has grown. But there’s going to be a while. It’s going to be even longer before the laws begin to actually catch up. Even the recent Department of Justice and Health and Human Services notices proposed rule making. They specify WCAG 2.1, and they do not have any disclaimer calling for use of subsequent versions. So these rules that are in progress right now, even though 2.2 is already out, they are citing 2.1. And that’s not likely to change.
[00:54:00.59] So for a very long time many organizations and entities are still, even though 2.2 is out, are still for one reason or another going to have to seek to conform to 2.0 or to 2.1. So it’s still perfectly valid to target conformance to these, and they build upon each other with the exception of that 4.1.1.
[00:54:20.02] It’s a great idea to start with 2.0, get to 2.0 level conformance. That’s going to tackle so many of the biggest issues. Most of the success criteria that are in 2.2 are in 2.0 already. And so you are more than 2/3 of the way there to 2.2 just by achieving 2.0 conformance, and that’s a great milestone in the event you need assistance in litigation. You need to document and memorialize your accessibility efforts.
[00:54:46.84] Once you hit 2.0, you can work on getting up to that 2.1, and then eventually on to 2.2. But take your time. Use it as steps. That’s really how, in a way, it has been built out. And so you can start by your 2.0 conformance, 2.1. And if you’ve already met these, say you already conformed to 2.1, you only have six more success criteria to deal with to get to 2.2.
[00:55:11.35] And so the haul shouldn’t be too great to be able to upgrade from your existing 2.1 to 2.2. And again, there are only six. So somebody is telling you there are nine new requirements that you have to meet, there are nine new requirements, but only six of them do you actually need to meet at the A and AA level.
[00:55:30.23] And so I’m going to go ahead and hand it back now to Ryan, so he can just talk a bit about how Allyant is going to be able to help you get to 2.2. And then he’s going to emcee our Q&A portion here.
[00:55:40.95] Yeah. Thank you, AP. So as the slide says, and I’ll talk through, we’d really appreciate it if everyone would follow us on LinkedIn. So obviously, you can just find us at Allyant. That helps stay up to date with everything that we’re publishing, both webinars, new articles, eBooks, topics on WCAG 2.2, and, really, everything else in the accessibility space.
[00:56:02.50] Additionally, if we didn’t answer anything that you were looking to get answered today– and I jotted down a ton of notes– specifically on PDFs, and we’ll have team members from our expert division follow up on that front. But if you have any other questions, if you’re curious about how WCAG 2.2 or an audit to 2.2 could affect your site, affect your customers, you can reach out to our team at any time via our website, allyant.com, or of course, email@example.com, as well.
[00:56:27.57] If you’re an existing Allyant customer, which I know we have many on the call, as well, obviously, you have a specifically assigned customer success manager, so you can certainly reach out to them. We can have a conversation around your next QA session or usability testing session to update that to 2.2.
[00:56:46.86] With that, AP, I will jump into questions. We have a lot of them. So I think we’ll get through as many as we possibly can. And then we’ll also get a recap of everything in response to this, and be able to follow up more directly, as well. So I’ll just start at the top, AP, and I’ll kind of rapid fire to you because, again, I noted we have a lot of questions.
[00:57:09.54] The first one, is there a definition for partial and partially obscured? How much little of the button must show when keyboard focus is there?
[00:57:18.66] It’s a great question, and it is certainly one that came to my mind, as well, when building out, obviously, this presentation, and as our audit team has been building out our own internal testing parameters for this. And the short answer is not.
[00:57:33.21] WCAG actually does not define partial. What they do say is they recommend the more, the better, right? So if you can make 2/3 of the control visible, rather than 1/3, do that. But they don’t define a kind of minimum standard for just how much of that control do you need to be able to see, so no.
[00:57:55.06] It’s kind of up to you to decide in a way how much you think is best. The way that we at Allyant are really approaching this is that there’s got to be enough of it there that you can see that focus indicator because obviously, WCAG, and since 2.0, has required the user to have a focus indicator.
[00:58:11.77] So enough of that controls got to be visible that that focus indicator is capable of being displayed, at least some of it. If it is, then that’s not something we’re going to call out as an issue. It’s pretty flexible by not defining what partial means in this context.
[00:58:28.47] Perfect. The next one in– and this might be one we can follow up on, as well– so the contact said they work for the city of Torrance, can Allyant recommend a content management system for WCAG compliance?
[00:58:41.96] Oh, an actual content management system– not really– some content management systems are better than others. Really, it comes down to all of them are going to have issues. So many of the issues that end up resulting come from the users who are creating the content, so training for those users who are using the content management system is very important.
[00:59:04.39] But WordPress, Drupal, different types of content management systems that are out there are all valid and can be made accessible with varying degrees of effort. But do we have specific ones that we would recommend you go and use, I wouldn’t say so.
[00:59:24.44] Perfect. The next one is– so Robert asks– and no, Robert, I don’t think this is a dumb question, so he prefaced it, AP– but does this mean we should avoid em, rem sizes for interactive elements? And I believe this related to 2.5.8.
[00:59:44.88] I don’t know, to be honest, off the top of my head. That is one we would need to dig into. I think in the end, it comes down to however that size ends up translating when it’s being displayed. Not so much how you’re programmatically defining it, but how it actually ends up rendering for the user. But that’s a question we would have to look into and get back to you.
[01:00:09.45] Perfect. And then the next one from Elizabeth is, what is the best web tool to assist in checking the 24 by 24 pixel element sizing? Anything that Allyant would recommend?
[01:00:20.69] We do have a few extensions that our audit team has identified, and are going to be using for testing that particular requirement. I don’t know the names of them off the top of my head, so we can certainly make note to grab those and follow up with you.
[01:00:34.33] Perfect. I will do that. The next one– and I believe this one was related to 2.5.8– so how about mobile applications? How to test the size in mobile apps? I think this was–
[01:00:46.55] Yeah. Yeah. That is an excellent question. And honestly, I don’t think I have an answer for you at this particular point in time. When you’re doing end user testing on a mobile application, you don’t necessarily have access to the code to be able to do that. And you can’t run extensions and different tools like that to be able to check this.
[01:01:10.78] So testing the conformance to this success criteria in the context of a native mobile app is, I think, quite difficult. And really, it will largely come down to a user, an accessibility expert, looking at it and making a bit of a judgment call based on just how small do these appear to be and how tightly clustered are they. I think they’re– in terms of native mobile applications, we don’t currently know of any good tools that would be usable without being on the back end where you actually have access to the app’s underlying code.
[01:01:48.97] Perfect. This one relates to 3.2.6 as you hear in the question. So obviously, it came in when you were talking about that, AP. But so an example of 3.2.6 would be like CSUSB’s website for a specific department that has a fixed sidebar when the user scrolls, and it’s consistent for all departments. They were kind of asking like, would that suffice for 3.2.6?
[01:02:14.24] Yeah. For talking about consistent help, it very well could. There’s this bit where it talks about a set of pages, right? And so I think that gives you some wiggle room based on what constitutes the set of pages. If I was thinking about higher education, I think you could very reasonably say a department, a program, or a school would constitute a set of pages.
[01:02:38.12] So if the School of Fine Arts has a sidebar across all of its program pages, but then you go to the School of Business, and they don’t use that sidebar. They instead use a Footer. I think that could be considered valid because the School of Fine Arts itself constitutes a unique set of web pages. And so that’s where I think the biggest flexibility to this requirement comes in is when you think of what constitutes the set. And if that sidebar approach is being used consistently across like a school or a program site, I think you could very reasonably argue that constitutes a unique set.
[01:03:13.94] Perfect. And right on topic with 3.2.6, Ben asked, do you have a recommended best practice or pattern for applying 3.2.6 for native mobile applications?
[01:03:26.22] Oh, for native mobile applications, I don’t off the top of my head. You know, obviously, this is a really new space. And a trick with WCAG is that it is so largely written and focused on web. If you go and you look at the actual success techniques and failures and the examples they provide, they’re always based on web. And may be responsive content, but it’s all web content built in HTML.
[01:03:55.19] And so the trick when you start having to apply WCAG to other contexts like native mobile or document accessibility is that sometimes you have to figure out ways to translate it. How do you test this in the context of mobile when WCAG themselves is only providing examples of how you test this on web?
[01:04:14.93] And so I think many of the same rules, obviously, apply. Thinking about what’s going to constitute a set? How are you presenting your contact information? I think many, many mobile apps have something akin to a hamburger menu. From within that, you can get to a contact page. Like if that’s something you’ve consistently applied, you are providing consistent access to that contact information.
[01:04:40.58] Then you start thinking about your other types of help mechanisms on your site, tooltips, that type of thing– or I’m sorry– on your application. How do you go about implementing those? Most likely you’re using consistent components and approaches for it already. This is not one I expect to see a lot of issues being called out in 2.2 audits, but could be wrong. It’s early days.
[01:05:04.74] Perfect. And then on 2.5.8, is the whitespace something that can be checked or ensured by building in margin?
[01:05:17.17] I don’t know to be honest with you. Can– excuse me– can be checked or insured by building in margin. I honestly don’t know the answer to that question. Something we can certainly take to our development team, I think, in particular, our tool kit development team who are working on building out the 2.2 specific rules around this, might be able to answer that. I think, though, in general, the trick with the target size requirement is that it’s very easy to get a calculation of what the size of the element is.
[01:05:52.18] So if the element itself is bigger than 24 by 24, you’re automatically good to go. Where it becomes a lot more murky is when it’s not bigger than 24 by 24. Now you have to start thinking about that surrounding whitespace. Is there enough surrounding whitespace? Finding a reliable way of calculating that surrounding whitespace automatically, it appears to be a bit of a struggle.
[01:06:16.92] And so, certainly, like our tool, our kind of first pass for a rule on this requirement, is to flag any actionable elements that are smaller than 24 by 24 as needing investigation. So at least you know to go look at it and see, is there whitespace around this? How tightly packed is it? Because I think, for now, until WCAG and more specific testing tools and parameters are outlined for this, I think it’s going to be a bit of intuition of just looking at these elements that you know are too small to see if they have enough surrounding space.
[01:06:54.21] Perfect. The next one, is there any WCAG success criteria regarding desktop hover states on buttons or links?
[01:07:05.34] Desktop hover states on buttons or links, so yes. Like for example, 2.1.1 for keyboard only users, it essentially says that content that you can– active– content that is present has to be accessible with the keyboard. You have to be able to get to it with the keyboard. So if you are a keyboard only user and there’s content that only appears when you hover over an element, that user, that keyboard only user, is not going to have access to that content.
[01:07:34.23] A screen reader only user would have a very similar problem with content that is displayed on hover. So it’s not that you can’t use hover– it’s something that I always want to be careful about when hover comes up, especially when it gets asked about in things like nav menus because on a desktop website, people want that hover mechanic on their nav menu. You hover over the menu, it expands.
[01:07:55.74] You can have the hover effect. The trick is that you’ve got to have some other way, though, of triggering it besides just the hover. And you can’t just rely on focus, as well. So like having a help– or having, let’s say, a men’s nav menu that you hover over it, and you see the men’s content expand. Well, tapping onto the men’s menu and then automatically expanding it is not an ideal solution because now you’ve forcibly expanded it for keyboard only users, and screen reader users don’t tap in that way outside of forms.
[01:08:31.36] And so relying on focus as kind of an accessible alternative to hover just doesn’t work. And in the end, what it usually means is you’ve got to have some other way of actuating that hover. So if you have a men’s menu link that you hover over it and the men’s menu expands, you should also have a button adjacent to that menu that a keyboard user or a screen reader user can toggle that button to actuate the menu. So you can use hover, you just have to be careful to make sure that hover isn’t the only way to access that information.
[01:09:04.34] Perfect. OK, so the next one is what about screen reader on the site that cannot be turned off? Every time I select text, it begins to being read. Does it violate SC of WCAG? Which one? Need me to reread that, AP?
[01:09:30.81] Yeah, if you don’t mind.
[01:09:32.73] Yeah, sorry.
[01:09:33.48] It’s all good.
[01:09:33.75] So what about a screen reader on the site that cannot be turned off? Every time I select text, it begins to read. Does that violate a specific success criteria of WCAG? And if so, which one? I’m going to assume–
[01:09:51.10] Of course, we’re always– assuming’s never good, but I’m going to assume this has something to do with an overlay, but I’ll–
[01:09:55.98] It kind of sounds like it to me, yeah. So I’m latching on to the part where we say screen reader on the site. And I’ll reiterate the point that I made earlier that I am blind. I need a screen reader to log in to Windows. I need a screen reader to open up Outlook, to open up Chrome, to type into the address bar. So I need a screen reader just to operate my computer.
[01:10:16.95] You putting a screen reader on your website, specifically, doesn’t help me because I’m already using a screen reader just to get to your website. What you putting a screen reader on your site does is get in my way because now I have to either figure out how to turn off your screen reader, or I can’t use mine.
[01:10:34.12] And I will tell you, screen reading software is complex. It takes years for people to learn. And so forcing them to stop using their screen reader of choice that they know how to use and are accustomed to using, and instead having to use a browser or site based screen reader that is being provided by a widget, is downright painful.
[01:10:54.76] I have had to experience this before, and it’s just it’s unpleasant. Users, essentially, are back to grade school in terms of learning how to use the screen reader. So the moral of the story, I guess, to answer your question, is don’t have a screen reader on your site. There is no point in having a screen reader on your site. If somebody needs a screen reader, they need it to get to your site. They’re going to have one installed already. So putting a screen reader, a screen magnifier, color contrast options, any of these things on your site is redundant, and it just gets in the way.
[01:11:28.06] Perfect. Yeah, I think that’s what that was referencing. So this one is from Linda. Do you recommend or are there any requirements about an accessibility page at our website? What information should be on there? So obviously, I can touch on this one quickly, AP, and then defer to you.
[01:11:45.75] So we do have for all of our Allyant clients, we do have a recommended accessibility statement template that we provide at project kickoff. So certainly, Linda, we have a in case investing in use example of a strong accessibility statement. But, AP, anything to add from your perspective around accessibility statements?
[01:12:03.98] No, the big thing I would say is WCAG does have– the W3C and the [? WA– ?] they do have a page where they talk about recommendations around accessibility statements. But to be clear, there is no requirement in WCAG that you have an accessibility statement, let alone, specify where the accessibility statement may be located.
[01:12:24.09] It’s just good to do. It’s something that you almost always see requested and required out of accessibility related settlement agreements. It’s proactive. It notifies users that accessibility is on your radar. Hopefully, it gives you a little bit of defense against those nuisance lawsuits because, hey, why come after this site that has an accessibility statement, when there’s 10 other sites that don’t? It’s just a good practice to have. In terms of what information to put in there, that is kind of up to you.
[01:12:50.10] W3C and Allyant, we certainly have our examples of accessibility statements we can provide. The biggest thing, though, is providing some form of contact information and making sure that that contact method is itself accessible. And so, usually, the easiest way to do this is to provide an email address because email is kind of a universally accepted accessible option for communication.
[01:13:14.22] You can offer a telephone, but then you might need to start thinking about how deaf users might be wanting to communicate, limited hours in which users might be able to communicate. And so email just tends to make it all a little bit easier or an online contact form. But of course, if you use an online form or an online chat, you need to make sure that the online form and the online chat that you’re using are also WCAG conformant because if the form that you use to submit accessibility feedback is not accessible, then it defeats the purpose.
[01:13:45.79] Perfect, and a few more, AP. So this one’s a great one. So if you have a tool on the site to aid compliance, and it says you are compliant, and you get a report showing that you’re compliant, does that not suffice? Is the only true way to show proof in compliance, I’ll say, is having a human audit, and they give a report, which I believe is strongly yes. But I’ll let you answer.
[01:14:07.51] Yeah. Yeah. I’m trying to remember which US Department it was. It might have been the Department of Justice or the Department of Education at one point put out a very specific statement where they said automated accessibility solutions are not capable of determining whether or not a site conforms to disability laws and regulations and requirements.
[01:14:27.43] Some automated scanning tools like WAVE– hats off to WAVE from WebAIM– because if you go to their terms of service, they are very clear about this in their terms of service. They say something to the effect of, WAVE cannot determine whether or not a site discriminates against a user with disabilities. It should not be used to determine that. It shouldn’t be used in the context of a lawsuit or a demand letter to say a site is or is not conformant or is not usable. They’re very clear about this.
[01:14:54.38] Not all automated accessibility solutions are, but the simple answer to your question is yes. If just having a report from an automated scanning solution or some kind of overlay tool or whatever it might be that says you are conformant, no, that is not sufficient to actually determine whether or not you are conformant.
[01:15:12.59] And in the end, it’s not likely going to protect you either in the event you get targeted in a lawsuit or a demand letter because what it really comes down to in those situations is how usable is the site. And you have no idea how usable the site is because all it’s done is automation. The only way to know how usable is to do real testing.
[01:15:32.11] Perfect, and two more, AP. This one– we might have to follow up with on this one, Eric, to get some more insight from you. And we certainly can do that. But Eric’s question is, what is the best tool for devs, DevSecOps, and data lakes? I’m not tracking, AP, but you know. I’ll defer to you, maybe you’re tracking.
[01:15:54.81] I’m not sure either. I’m sorry.
[01:15:57.66] No problem. Eric, I’ll be sure that we shoot you a follow up note, so that we can get that answered for sure. And then Nora asked, we use an automated tool which often reports violations based on code our website management vendor has written, and we don’t have access to in WordPress. This is a great question and a common problem. I often mark these as cannot fix or open support tickets with the vendor, but I’m curious what a best practice would be in the event of an audit?
[01:16:26.14] Yeah, no, it’s a great question. And it is a problem that so many clients run into. And the answer varies, obviously, depending on what the situation is. In some cases, you have to bring in an outside consultant who might be able to implement the necessary remediation for you.
[01:16:48.88] It really just it depends on what the situation is. And is it just that the vendor is unwilling to, that they don’t feel that it’s in the contract, in which case, it might become more of a contract negotiation. It may require you to walk away from your vendor and go to somebody else who is willing to actually address accessibility issues. It might require renegotiation of the contract to ensure that they state the site is accessible. And that if accessibility issues are found, they’ll remediate it within a given time frame.
[01:17:20.80] What you end up having to do in that situation varies. But the unfortunate truth of it is is that their obstinance is your liability. If they’re not willing to fix it, it’s your site. If you get targeted, you’re liable for it. It’s not going to fall on that vendor. And so it really behooves you to pressure that vendor, threaten to switch whatever needs to be done in order to get them to play ball with accessibility issues, rather than just saying we can’t fix this one. That, in the end, doesn’t help you. Don’t know if that answers the question or not.
[01:17:58.24] Yeah, I think it does, but that’s a great answer, AP. And that’s it. So AP, I think we’ve done it. Obviously, fantastic work by you getting through this, and I think we’ve answered all the questions. So I’ll defer to you for sort of final statements.
[01:18:12.06] Awesome, well, thank you all very much. I hope you found this presentation useful. Again, just keep in mind that WCAG 2.2, it’s building on 2.0 and 2.1. So your accessibility efforts that you’ve already undertaken to get to 2.0 and 2.1 have not been in vain. You’re already a large way there. There are nine new requirements in 2.2, only six of them, though, are at the A and AA level. So don’t be fooled if somebody tells you there are nine requirements you have to deal with. There are only six.
[01:18:40.89] Keep in mind that automated scanning tools, they’re only going to be able to identify one or two, maybe three of these WCAG 2.2 violations. And reach out to Allyant, if you’re not already a client. If you are a client, reach out and get arrangements put in place to be able to upgrade to WCAG 2.2 today. Thank you all so much.
[01:19:03.49] Thank you all.
[01:19:04.42] Presentation ends.