Risky Business? Only if You're Not in Compliance

Transcript for Risky Business?

INTRO

Lori

Hey, everybody. Welcome to today's Accessibility.com event, “Risky Business? Only If You're Not in Compliance.” Today we are discussing WCAG and how it's evolving. And WCAG is the Web Content Accessibility Guidelines that help lead us all through this maze of accessibility information that's out there and what we should be doing in order to make all of our digital content more accessible to those who need it so that we have a more inclusive digital world.

My name is Lori Litz. I am the Director of Conferences at Accessibility.com, and I'm so pleased to be here today with my friends Casey and Garry. And they're going to discuss WCAG and its evolution, looking to the future and WCAG 2.2 that's due to come out in the, oh, next couple months or so.

And what's next for WCAG after that? They're going to be doing it more in a in a response to questions. So go ahead and start typing in your questions in the Q&A. They've already got some ahead of time, so they're ready to go right from the get-go when we get onscreen. Today's event is sponsored by the Bureau of Internet Accessibility and AccessibilityWorks.

If you click on the event page off of our website, Accessibility.com, you can see their logos on the page there. And if you click on those, you'll find out all sorts of relevant information about accessibility and how both those wonderful companies can help your business navigate accessibility. Now, believe it or not, these two gentlemen that are here today have taught me more about accessibility than anyone else.

They're very detail-oriented when it comes to explaining what you should be doing and what you should not be doing. There's no two better teachers out there that I can think of. So without further ado, we're going to set it off to Casey and Garry. And before I forget, today's event is being recorded and will be available later today.

I'll email you out this evening all the information and how to access the recording. So if you could only stick around for a little bit, we understand. You can catch the rest of it later at your convenience. Off to Casey and Garry.

WCAG DISCUSSION

Casey Naiduk

Everybody. I'm Casey Naiduk. I am a lead product regulatory strategist for accessibility at Oracle. Happy to be here today to talk about the evolutions in WCAG or the Web Content Accessibility Guidelines. Feels like a little bit of a homecoming. I was also a founding head of content and experience here at Accessibility.com. I’m here with my friend Garry today to talk through some interesting questions and hopefully share some insight.

Hello Garry.

Garry Harstad

Hey Casey. Good to meet you today. I'm Garry Harstad. I'm a VP of Technology at the Bureau of Internet Accessibility. I've had a few decades playing with this industry and we’re here today to talk specifically about the WCAG 2.2 concerns and questions people have about where it is going and what it means to them. I think we've had a lot of questions and concerns surrounding what particulairily it means to them when when it when it's going to turn up.

And in fact, the bigger question when it will turn up, indeed. So if we want, we can go straight to Q&A on this. It looks like we do have a few questions I think doesn't it make sense to go over the high level questions that people have first so we can ask those bigger existential questions to some sort of satisfied satisfaction before we get to any technical details.

With that in mind, let's get the overview questions. We have six of those at the moment. The first one being what does it mean that a new version of Web Content Accessibility Guidelines is coming out? And we're referring to WCAG 2.2 here, which is the impending latest version of the WCAG 2 specification. What do you think, Casey?

Casey Naiduk

Well, I think to answer that question, you know, we may have some in attendance who don't necessarily have a ton of familiarity with the Web Content Accessibility Guidelines. Their history and and what they are and how a new version could even be possibly coming out? And so maybe I’ll... what do you think Garry? I'll touch on that for a second what WCAG is or are and then I can get into that.

Yeah. Okay so so the Web Content Accessibility Guidelines, they are essentially the gold standard in accessibility guidelines, in digital accessibility guidelines. So accessibility professionals globally, government organizations, laws... have adopted them as saying, yup, WCAG or Web Content Accessibility Guidelines gives you a pretty reasonable standard by which to measure accessibility. And it's... there's pretty good consensus amongst some of those that I just mentioned that if you conform with WCAG, particularly the latest version of WCAG, that you are reasonably accessible to your customers or users with disabilities

And so what is it, I think the question... what does it mean that a new version is coming out? Well, the current version right now is WCAG 2.1. WCAG 2.1 came out, I believe the summer of 2018. WCAG 2.1 was a subsequent version of 2.0 which kind of reigned for ten years, I think from 2008 to 2018. And these are minor, minor version updates of one another.

And so WCAG 2.1 when it came out, it had the attention of, you know, a lot had changed in technology between 2008 - 2018, right? We’re working on smartphones, we're working on touch screens, we're working on smaller devices. Browsers and other user agents had evolved. The guidelines, the standards kind of had not. And so there was some catchup work that needed to happen.

And so WCAG 2.1 came out to to fill in some of those gaps with a special focus and special area of attention being filling in some of the gaps related to cognitive accessibility and related to to mobile accessibility. So when we talk about a new version, WCAG 2.2, coming out on the horizon, it's essentially a continuation of of the same.

So it means that, you know, the last major version that we have, which is the 2.X series, will be enhanced one step further to fill in again continuing with the same theme, but fill in some more gaps related to cognitive and mobile and touch screen accessibility. That's how we would describe it at a high level. What would you add there, Garry?

What does it mean that a new version of WCAG is coming out?

Garry Harstad

Well, I think you're exactly right when it comes to the versioning. The good news people can take away from this is that the 2.X series of WCAG versions are all backward compatible with each other so people don't have to overly panic saying, oh my God, this is a complete new set of data. It is not. We'll talk about that later

when we talk about WCAG 3.0, potentially. But the 2 dot series is really an incremental set of the changes and improvements which are focused mostly on trying to... The 2.1 is and the 2.2 are really trying to improve on each other. So we're just trying to make the user experience better for the people who need the accessible technology. So I think there are two things to be a big concern of, is that it is progressive, it is backward compatible, and it's all about improving the accessibility and usability for everybody.

And it doesn't necessarily means greater hardships on developers. It just means greater clarification and more details of how to resolve these issues.

Casey Naiduk

Hey, Garry, can you when you say backwards compatible, what do you mean?

Garry Harstad

Well, for instance, if you were compliant on WCAG 2.0, now you've became compliant in WCAG 2.1. What you really did was, is you added some extra measures to cover the additional criteria added in 2.1. So therefore you're already compliant with 2.0. By adding 2.1, you're compliant with 2.1 and 2.0. And when this WCAG 2.2 version comes out, if you get compliant with that, you're going to automatically be compliant with 2.1 and 2.0.

So they build on top of each other with just differentials or additive information. This, this, this 2.2 version does have a few gotchas in there. That's one removal and one change that we will note. But that's not typically the case. Usually they're just incremental as an additive. So essentially, once you go ahead and make yourself 2.2 compliant, you're already be 2.1 or 2.0 compliant.

And if you're already 2.1 compliant, you're already 2.0 compliant. I think that's that's part of the good news here. So the success criteria numbers, whether it be 4.1, 2.1, 3.1.2... Those numbers are all still in succession and still in general the same organization structure that they were before. So there's nothing alien that's going to be happening to the documentation here.

So the biggest changes are just the changes. There's nothing really changing other than the additions as far as I can see.

Casey Naiduk

Yeah, and, and I think we'll... I'm guessing that we're going to touch on it later. For the first time ever, there is a variation there, right? Where there will be, there's expected to be a removal of a criterion which, which has not happened before. And although no language to my understanding will change in any of the criteria, there is expected to be a change in level of a criterion, right? From Level AA to A for one of for one of those 2.4.7 focus visible. I think we'll get into those details in a little bit.

But it's interesting that we're seeing that for the first time. Up until now, right, the new versions have been solely additive

Garry Harstad

Right.

Casey Naiduk

I mean. Right. And I should step into the new versions, meaning really, you know, 2.1, especially 2.0 was was solely additive and added quite a bit. But aside from what was added, you know, the standards were verbatim.

They had not changed. Nothing was removed. Nothing was altered at the time and that’s a great point.

Garry Harstad

That’s right. And in fact you just blew away all the security I gave everybody saying that nothing changes and everything's progressive because it is, except for those two things you just brought up, which have never happened before. So typically it is actually only additive, except it isn't right now. But the majority of them are additives. So I think we'll find when we get into those two changes, we’ll realize they're not that big a deal and in fact might make life easier for developers.

Casey Naiduk

I think so too. And I think I know jumping jump in the ahead a little bit, but probably long overdue. Both of those would be my opinion.

Garry Harstad

I would agree. Yeah, there's been a lot of confusion over documentation, understanding how to fix them both things. And really it's waiting for technology and that's really why we have a 2.2 coming out anyway, because the technology has changed so much. They have to, you know, keep changing stuff. So it keeps up with the people who are going to do the developing or the remediation.

So WCAG has to go along with the technology. Otherwise they're going to get out of date very quickly. No one wants. That.

Casey Naiduk

Yeah, absolutely. Garry. I think that that might be a really slick segway into what I think I see is the next question, which is, you know, we just discussed what does it mean that a new version is coming out? Right? So we've got a minor minor version update to 2.2. The question is, why is there a new version of WCAG coming out?

Why? Why does what WCAG evolve? Do you want to you want to kick us off there? We touched on it...

Garry Harstad

Yes, totally. I mean, the quick answer is, you know, if you don't, you know, WCAG has to keep up with technology. And that's just the basics of it. So whenever you say, oh, that with a new browser coming out. A new Chrome this or that, they've changed the underlying technology, the the underlying way they examine elements and what developers can actually utilize to remediate problems that they have found. So the WCAG has to keep up with the specification of contemporary modern technology that comes along.

Otherwise the they lose all respect from people in the industry. It's basically contingent on the modern technology and advancements in standards and in browsers and in mobile phones, obviously, because before mobile phones, as you mentioned, there was very little concern about mobile at all. And then now that they're becoming huge forefront of the issue, there's all sorts of new rules and regulations that are coming out regarding size of target areas and what can and can't be collapsible shown. So the quick answer is that they have to keep up with technology to stay relevant.

Casey Naiduk

Yeah, I mean, you're you're so right and you're you're so obviously right. But when I was just listening to you give that explanation, Garry, I was kind of I was kind of thinking how on the other side of that coin, yeah, they have they have to keep up with technology, but they really, you know, they, they also the updates of the of the WCAG versions also kind of, in my opinion, tend to push, you know, web best practices in general and what really ought to be happening.

And I'm thinking back to 2018 and then more realistically 2019, 2020 when organizations really fully bought into WCAG 2.1. It got released, it got recommended as a as the recommendation in 2018. But, you know, there was a bit of an adoption period. And the biggest change that I saw there was, you know, to meet some of those new criteria...

I'm thinking of reflow and I'm thinking of some of the things about, you know, touch target recommendations and things related to kind of like touch screen and stuff. It really was no longer kind of okay or it would have become really difficult, for example, to maintain like a desktop version of your website and tried to push that out onto people's mobile phones.

Right? Like, you know, it kind of it kind of really accelerated, in my opinion, the adoption or in some cases the requirement of responsive design, which is just in general, you know, a good practice, right. And so I guess I guess what I'm saying is, in addition to keeping up, they also kind of they also kind of push on the other end. Like, you know, it would have been really hard and really difficult to to try to maintain old design and development practices and conform with WCAG 2.1 It would have been really... there would have been a compatibility issue there

I'm thinking.

Garry Harstad

Yeah, sure. In in fact, even more specifically relevant is even the notion of cascading style sheets where a lot of the stuff we do now to make responsive design and make it more accessible just wasn't available worldwide. A lot of the browsers when we had the browser wars, they were using their own contemporary and specific proprietary tags and and CSS and all sorts of stuff.

And thankfully, due to specifications like WCAG, everybody's coming together and following that spec. And that's great beauty behind WCAG is that it's there as a light for us all to use which is often why they take so long trying to release these things because they want to get it right. They want to be up to date with the latest browser technology and it just sometimes goes a snail pace because obviously they're one committee and review processes and it just is laborious sometimes.

But absolutely. Yeah, I can't I can't imagine mobile browsing without the updates to CSS and browser technologies that came along at the same time. It's just not not feasible in my opinion.

Casey Naiduk

Yeah, Yeah. And I've got, I've got like a personal like a personal anecdote that I, a website that I'm visiting every day now as part of like a financial application thing. And it's a modern, it's a modern, you know, it's a modern bank that I'm dealing with and they've, they've got accessibility knocked out of the park in like nine out of ten,

you know, they're, you know, properties that I visited. But there is this one site that I constantly have to visit of theirs, to enter in, you know, I'll get a text of here's your here's your two factor authentication code. And I go to the site to put it in and it's like I've either got to try to hit this target that's like a pin hole at the desk-

It's a desktop site, right? Or I've got a zoom and it's it's so funny how in a matter of a couple of years that went from being kind of, you know, half expected, to now it's like, it reflects poorly on them. It's like what all the design and development standards are you following to get that? Perception changes quickly.

You know.

Garry Harstad

And that's one reason why I think some of these 2.2 standards are really welcome and long overdue. I am personally hugely irritated by having to match those tiny close buttons on ads that pop up on my mobile and things like that. I just wish someone would destroy them all. But the reality is it's the target error and so they start defining that and making it a specification, no one’s going to look at that. No one’s going to get sued based upon that. So as you mentioned, it's really a driving force behind technology. You know, when the standards change, people have got to start following them, otherwise they're nonstandard. So it's it's a good thing.

Casey Naiduk

It is a good thing. And I'm hoping that that I'm hoping that comes through. And, you know, in the in the remainder of our conversation that this is... this isn't something to be afraid of. You know, evolutions in these standards is not something to resist. It's it's a good thing. It's a natural part of the process. Technology does not stay stagnant.

And so there's no reason to expect that the standards that guide it would. This is this is good. Yeah.

Garry Harstad

Yeah, totally. All right. So I think we can probably hold off on what WCAG 3 is regarding WCAG 2.2 to later so we can probably jump to the next question. You think?

Casey Naiduk

Yeah, sure. Um, so Gary, next step in our Q&A, what's different in WCAG 2.2 from the currently established WCAG 2.1 version?

Garry Harstad

Well.

Garry Harstad

We'll go into some specific details in a few questions because we do have a question say, you know, what are the exact changes and additions. But in general there are, there are nine new criteria or checkpoint success criterion, and they're known as. Two are at Level A, five are at Level AA, and two are at the aspirational AAA level. Five out of those nine are operable.

That's the 2.X series. And four of those are centric to understandable, which is the 3.X series. And those are two, two and three, a pretty important and very common with a lot of accessibility problems that can arise. Operable, for instance, is the user interface components and navigation must be operable. Pretty self-explanatory. Understandable is information and the operation of the user interface must be understandable.

So both pretty self-explanatory. But the additions mainly are the fact that there are nine new criteria, two are A, five are AA and two more at AAA level. So there's really only seven to be concerned about if you ignore the AAA. And it's really neat. Two of the important ones at the A level, which is why they shouldn't be too scared about this particular version coming out.

And like I said, as we go into these versions a little bit, but one of the pressing questions about all of that is when in fact, will the WCAG 2.2 version be released? Which is our question four, Casey, which I'm going to throw at you.

Casey Naiduk

Well, I don't have a... I don't have a crystal ball.

Garry Harstad

Why not?

Casey Naiduk

And I’m not, I'm not clairvoyant, but I can tell you that right now, the current estimate puts us hopefully getting WCAG 2.2 to be moved to that final recommendation status toward the end of April of this year, April 2023. Now, it's not, it might, you know, that's a relatively straightforward question to ask.

It's it's a much harder question to answer. And maybe actually we ought to take a step back and quickly touch on the current status of 2.2 and where that kind of fits in the in the process of, you know, of all that has to go into actually updating a a WCAG 2.X standard. So so right now it's in the candidate recommendation stage. It has been in the stage before. Last year either in the summer, in the fall, maybe September,

I want to say. And this is a... this is kind of somewhere, somewhere in the middle, but getting closer to that to the final recommendation stage. And so at this point of the process, WCAG 2.2 is put out for another commentary period or more review, for more comments. You know, the working group that that shepherds this through, you know, they're looking for they're looking for a lot of things.

I'm not I'm not privy to all of them. But, you know, they want to get consensus from from those in industry and from those... And, you know, eventually on the advisory committee, when it gets to the next stage. And just in terms of how clear is the language that's been drafted, how feasible is it to to actually consistently and reliably and always meet and what hiccups or unforeseen complications could get in the way of that?

So, you know, they're looking for feedback in terms of does the criterion itself make sense? Does the criterion language need to be adjusted? So it's not confusing. So it's not too vague, so it's not too prescriptive. And it's really important that that you know, we we expected 2.2 sometime sometime last year. It might have initially been you know, it might have initially been scoped out for 2021, if I if I’m remembering correctly.

So people get impatient saying, you know, where is it? When's it coming out? I'm not one of those people. I would much rather that, you know, the people who are shepherding this through, who are caring for this and essentially are caring for kind of the next chapter of digital accessibility, essentially globally. I'm okay with that. Them taking their time and and getting this right because it would be a real disservice to to everybody. And most of all, users with disabilities to actually to move forth.

And you to move forth guidelines that that can't be reliably met or for which there is just too much ambiguity in terms of meeting them. And so it's a long way of saying that right now. So right now, you know as of as of last month, as of January, 2.2 was moved to the candidate recommendation phase.

That means it has two subway stops away from its final recommendation, at which point it becomes, you know, the new thing. It becomes the new W3C recommended version of WCAG. So we're hopeful that'll come out in April. I know I've heard some estimates that say we're realistically we're looking at summertime and and if that's the case, so be it.

I think I think there's no rush here. I think it's important that they get it right.

Garry Harstad

What do you think is the hold up, Casey? Is it is it the trying to understand how developers can remediate these things? Or that they're not clear on how to identify these things? Which you think is going on?

Casey Naiduk

So I don't know entirely. I know that there was there was one criterion in particular. 2.4.11, focus appearance, which is now considered at risk in this candidate recommendation version, which was which was not the case in the past. And what that means is it may or may not make it into the final. It may or may not get published.

And my understanding is they kind of make that determination and, you know, based on a couple criteria. They want to make sure that, you know, that what set forth in these guidelines is testable, is repeatable, and and frankly, that it's that it's possible. Right? It would become a really it would really be a disservice to all those involved if there were one or two that were just really tough to meet or you couldn't meet it or you couldn't consistently meet it, and now all of a sudden you can't claim WCAG 2.2 conformance,

for example. That would stink. So, you know, I don't know any more of the specifics other than that. But actually, now that I'm now that I'm noting that focus appearance criterion in particular at this point in the in the draft process or in the yeah. In the guideline process. Now that it's in the candidate recommendation, once it moves to the next step, if the advisory committee, if the advisory group chooses, you know what that criterion is not going to make it and they cut it. That's considered okay at that point is my understanding.

It doesn't need to necessarily go back to the candidate recommended recommendation phase. The fact that it's formally flagged as at risk right now, I believe gives them the the leniency or the leeway to to scrap it at that point and move forward. Even so with moving it to final recommendation.

Garry Harstad

Right. And I actually looked at that criterion. And interestingly, it doesn't seem that tough to me. So they must be getting caught up in the details of the documentation and all of that stuff. How to remediate and detect? There's one I saw also related. I think it was or is it the new 33.9 accessible authentication enhanced AAA has zero understanding document at this time. But I don't know they're going to you know use that as an excuse not to release 2.2 or not.

And that's where it becomes enigmatic is we just don't know what specific reasoning they're going to come up with to say we're going to delay this again, which is why people have been talking about 2.2 for a few years.

Casey Naiduk

Yeah, well, hey, at least at least people are talking now. I don't know. I'm not I'm not in the camp of saying, let's go, let's go, let's get it out there. I'd you know, and maybe, maybe part of it is, you know, you know, in my in my roles as an accessibility professional, I have to understand the criteria.

I have to be able to explain them. I have to be able to test for them and I have to be able to defend decisions that I make around complying or not conforming or not conforming with them. And so get it right from my mind.

Garry Harstad

Yup.

So I think in the short answer, when will WCAG 2.2 be released? I think the answer is, wouldn't you like to know?

Casey Naiduk

So yeah, yeah, I.

Garry Harstad

Guess, you know, the timeframe appears to be April onward, right?

Casey Naiduk

We can say that it won't be before April, right. Because it was moved to the candidate recommendation phase in in January. I think that has a minimum of a 28 day review period, as does the next phase. I believe it has a 28 day review period, assuming that that moves along within the next weeks or so. So it won't be before April, we could say that.

Garry Harstad

Interesting. And I think W3 does have a page for the code and implementation report which does kind of tell you when and what is coming up and its searchable. So I think that's all we can do in question four, when will WCAG 2.2 be released? So the next question is number five. Will existing digital assets that conform to WCAG 2.1 be nonconforming or inaccessible when WCAG 2.2 is released?

Do you want to take a stab at that?

Casey Naiduk

Yeah, it's a yeah, I'll take a crack at it. And it's an interesting question there because the way it's phrased is I think there were two adjectives. One was non-conforming and one was inaccessible and they're not exactly synonymous or interchangeable words. And I did notice that the word compliant was not used, was not used in that question, which, which I think would have made me have a different answer as well.

But so will existing digital assets that conform to 2.1 automatically become nonconforming when 2.2 is released? Well, they wouldn't be conforming to 2.2, you know. But but no, there's nothing. And like you described earlier with 2.2 being backwards compatible to 2.1 and being and being additive for the most part in nature to 2.1. There's nothing magical that happens the day that 2.2 becomes a the final recommendation that would somehow nullify or or make out of compliance, a property out of conformance, a property that currently does conform with WCAG 2.1.

Right? That's my understanding.

Garry Harstad

Yeah.

I mean, that's good news, right? I mean to conform or not to conform, that's the question. So the good news is if you already conform to 2.1, you've done a great job and when 2.2 comes out, you'll still be in 2.1 conformance. And if you go ahead and add the extra stuff to be 2.2, you can up a double pat on the back because you're now 2.2, 2.1 and 2.0 conforming.

You're a genius. So really, and it's even better that they made a previous spec from AA to A, because if you already conform to AA, it's going to obviously be easier at Level A. In theory.

Casey Naiduk

Yeah. That's, that's a great distinction. Yeah. And, and I almost don't want to open up this can of worms because I'm, I'm imagining had the question asked about compliance it would have been a more complicated answer. Well, it depends. But for if we're specifically referring to WCAG conformance, yeah nothing nothing critically devastating happens on that day.

Garry Harstad

Isn’t that all we can do, Casey? We can't really be compliant necessarily, right? I know that's -

Casey Naiduk

Not with WCAG. Yeah, well, so that's a good maybe that's a maybe that's something that we should spell out. So typically we would say that we can be conformance with WCAG and that's what the W3C would say. Is well you could be conformant with WCAG. It's a standard, it is a voluntary standard. Usually. There are there are laws and regulations which which have codified WCAG basically into law.

Right? So one of those is Section 508, which requires, you know, the digital properties of the federal government or their contractors to be accessible. You know, in that case, the law's pretty clear. You've got to follow WCAG, in that case, 2.0.. You know, we've got other other laws and regulations, some nationally, some internationally, like EN 301549, which applies to the European Union.

That one's pretty clear. You've got to be WCAG 2.1 compliant. And the reason we use the word compliant there, I'm sorry, you've got to be WCAG 2.1 conformant in order to be compliant with EN 301549. And so you comply with laws or regulations, you conform with with a standard like WCAG, right? So you comply with things you have to do.

You conform with things that maybe you want to do. I don't know if that's a good way to put it.

Garry Harstad

I thought it was actually pretty excellent. And actually brings up a point where people are going to ask us, you know, what's the difference? If I'm going to get sued, I'm going to get sued. So compliant, conformant, who really cares? But the technical language is conformant because it's technically voluntary.

Casey Naiduk

That's right? Yeah. Yeah. I wouldn't add anything to that. That's well said. Yeah.

Garry Harstad

All right

Casey Naiduk

So, yeah, go ahead.

Garry Harstad

Oh yeah. So I think that's all we can when you talk about that. I think you're right. I think that's all we can say about the conformancy of 2.1 to 2.2. I think. I think the general advice is don't panic. You're still 2.1 conformant if you are if you have been in the past.

Casey Naiduk

Yeah. And you know, to you know, I'm going to leave well enough alone. That's that's distinct and that's clear. And I'm just going to muck it up.

Garry Harstad

That gets into a gray area for sure.

Casey Naiduk

Yeah. Yeah, yeah. Um, hey, what if I throw this next one to you?

Garry Harstad

Okay.

Casey Naiduk

Next question in there in our queue. Uh, so how do I prepare for WCAG 2.2? Um, and then subsequently, when should I start spending time and resources on it? So it looks like there are two questions there. How do I prepare and when should I start allocating what's needed to prepare to prepare for?

Garry Harstad

Oh.

Well, that's a great question, as you know, because we don't know exactly when it's going to come out. There's no clear cut answer. But I would argue that it's definitely imminent at this point. We're talking the next 3 to 6 months. We're kind of 85% sure, fingers crossed. So I would say the time is to get in front of this is now. I mean, start at least trying to understand the new specifications, understand at least what's written in the understand documents and the, you know, any remediation advice or techniques they might suggest and just start doing that now, it's not going to hurt you and it's going to be very little changed theoretically between now and when

it is when they even if there are further changes. There's just so few things that can go wildly wrong with the next version. I think start now. You know, understanding that now there's no downside that I can see. Worst case is you might use a terminology slightly different than they end up wording it. So I think I would start now.

And as for spending money and resources on it, I think if you're comfortable with the new criteria, you won't really worry about that because you realize there's not that much to do. There's not that much like major things that are going to overturn what you've done previously in this new specification. It’s mostly minor additives, so I would focus on it now.

Just do do what you can as soon as possible. You can certainly hold off on your big changes. You know that are company-wide until it actually releases in case there's something there, but the majority of it I would definitely recommend subject matter experts and accessibility people such as yourself get on top of it right now. I mean, when did you start looking into this?

You know.

Casey Naiduk

Probably like. Like this. Like this morning. Yeah.

Garry Harstad

But yeah, I would start doing it sooner than later.

Casey Naiduk

So you're so you're confidence in the in what's in the draft right now is pretty high?

Garry Harstad

Pretty high.

Like the 85% rate.

Casey Naiduk

Okay.

Garry Harstad

Whatever, however useful that is.

Casey Naiduk

Yeah. But it's-

Garry Harstad

I really don’t think the A levels are going to change. At least let's think about that. You know, the AAA, I wouldn't concern ourselves with.

Casey Naiduk

Yeah, fair enough. But it sounds like you would stop short of, of maybe visiting or revisiting like company policies or things like that at this point? You would... Who, I guess, who or what kind of roles or for whom do you think it might be a good idea to start kind of considering what-

Garry Harstad

I would advocate for the two A level criterions to be done companywide now. Those two A ones are consistent help and redundant entry. Consistent help is just about if you have a contact us link or help resource or a chat thing or... and it appears on more than one page, the criteria just says make sure they appear in the same place as in the previous pages because somebody with low vision, no vision or some cognitive issue is going to mentally create a model of what they think your site is laid out like where those links are.

So if you change them page to page, they have to read on every page. So I don't see that one changing. Redundant entry is mostly about autofill capabilities, not making people type things in twice. That's just generally a good practice, period. So I would definitely companywide work on those to A levels before anything else.

Casey Naiduk

And the way you're to in the way you're describing them, it sounds like it's relatively low risk because even if they got scrapped from WCAG, it sounds like you're saying they're still pretty good practices.

Garry Harstad

Totally.

I mean, if they got scrapped, I'd be amazed because they just so... it makes so much sense outside of accessibility, let alone inside of the lens of accessibility. So I don't see them moving. But if they do, as you said, it's still good business practice to do those things.

Casey Naiduk

Garry, this might be going a bit off script, not that we have a script, but based on our based on our Q&A. But I'm realizing that that both of us have talked a number of times now in this conversation about A, AA, AAA criteria. I don't know if we've identified what that means. Would you would you share that with viewers?

Garry Harstad

Sure. I mean, the they’re known as conformance levels, but we refer to them as levels. Level A, AA and AAA. A being what we imagine as being the most important and easiest to solve as problems. Level AA being potentially more difficult to solve, but still important. And Level AAA being things that we'd like to fix, but we understand that they're possibly very hard or impossible to do in certain contexts.

So the AAA level is more aspirational, at least in my mind. It's like, wouldn't it be great? And it's not that there aren't AAAs you can't put in place. You can, but it depends on the technology, the context and what you're trying to achieve. Because the AAA's in any of the WCAG specifications don't make you non-conforming. So businesses tend to chase the A and AA and we call that the industry standards.

More altruists will say, hey, you should make it AAA. But that can also actually lead to techniques which make other things harder. So the AAA ensure aspirational, AA medium technical difficulty, and the single A you absolutely should be doing this without question. You know, just get this done. I don't have a great a technical explanation of the A and AAA, there might be an actual official explanation.

Casey Naiduk

You know, and I don't know if there might there might be I don't know if we need a technical explanation, but, you know, the way I think about it is there are yeah, there are three tiers and you can you can satisfy all of just let's say the base A level and then at that point, if you do that, you can claim that you conform with WCAG 2.X A. The problem with doing that is you've still got you've still got some gaps that make your website fairly unusable for for some people.

And like you said, meeting those A and AA criteria really put you in a good sweet spot of all those techniques. All those rules are they're testable, they're repeatable, they're the burden is is kind of determined to be, you know, nonoppressive. Right? For people who have to build and maintain those things. But, but they do, yeah. They do kind of put you in a good spot to make sure that you know, that in general people will be able to use your your content functionality.

Yeah.

Garry Harstad

You brought up an interesting point. If you only thought the single-A directive, you could technically say your WCAG 2.1 A conformant, but you've got to say your WCAG 2.1 conformant, period. Then isn't it right that you have to cover at least A and AA.

Casey Naiduk

Well, I guess I have to give a disclaimer which is I'm not 100% sure, but my understanding is that you would never say that you're WCAG 2.1 conformant. I, I believe the expectation and there is a W3C web page out there. I don't I don't recall what it's titled, but people can go check it out if, if if conformance levels and how to claim them is of interest to you.

Casey Naiduk

But my understanding is that you would always specify the level at which you're claiming conformance, and W3C lays out a couple couple of rules of the road. I think there are like five things that you have to meet in order to to claim that. One is there can be no exceptions, right? So let's say I, let's say I want to claim I conform with WCAG 2.1 or 2.2 levels A and AA. I can't have I can't have a single exception there.

Right? So it can't be I conform with all of them except one. Right? It can't be, you know, I mean everything except my site has no, no all text. I don't, I can no longer claim that conformance. It has to be without exception. And there are a number of other other criteria in there that I won't pretend that I've memorized because I don't at the moment.

And so.

Garry Harstad

Yeah, it's interesting. So essentially when you declare conformance, you would normally specifically specify the A and AA or at least just AA, which implies single as well. You would always specify the conformance level.

Casey Naiduk

Yeah, that's right.

Garry Harstad

Well that was the high level overview stuff. I think the next level is to get into specific changes and the additions in WCAG 2.2. Though some of this can be a little bit technical. But I think if we go over at least the criteria name and number and what it generally means, that may be enough for people.

Casey Naiduk

Sure.

Garry Harstad

You want to take a stab at number seven changes that apply to WCAG 2.2 regarding 4.1.1 parsing? I understand that one is interesting.

Casey Naiduk

That that what is interesting and I'm going to surprise you with why it's interesting. First, it's interesting because it's the first ever WCAG criterion that assuming, you know, the final version keeps form with the draft that it's in now, the first time that a criterion will actually be removed from from the previous from the previous guidelines. And so that means that when WCAG 2.2 comes out, if it is as it stands now, WCAG 2.1 would include a criterion 4.1.1 parsing.

WCAG 2.2 would not. It's also my understanding that it's kind of TBD. It's kind of to be determined as to whether in the future they might actually go back and retroactively remove 4.1.1 from WCAG 2.0 and WCAG 2.1. I have no idea if they'll do that or not. So to me, it's kind of the impact to me there's no impact there.

If they do or don't, I don't think it changes how developers develop or how testers test. But a positive there of removing it is, you know, it's a criterion that is that is confusing to a lot of people, including a lot of accessibility professionals. And I know I've seen, you know, dozens of times where accessibility findings are potential violations are tied to 4.1.1.

And more often than not, I mean, maybe I've seen a couple of valid ones and I might not even know. But more often than not, I scratch my head at them and I say, you know, that looks like a stretch. Looks like maybe you're trying to tie it to something that's not quite fitting. But the reason I said I'm going to surprise you with my answer is because you're the engineer.

I am not. So I'm wondering, can you explain? I know you could explain it better than I can. So would you be willing to explain what parsing even is and why it's kind of okay that we get rid of it?

Garry Harstad

Yeah, well...

You know, and again, some of these is speculation, but I believe the original intent for this is because there was a catch all of what we can't run our rules if it didn't discover the things to run the rules against in the first place. And they call that parsing. And what that really means is things like AT technology, assistive technology, really what it has to do, a screen reader, for instance, it has to look at the website and all of the elements, all the application and then basically parse it, which basically means dissect it and put things in there, various labels and categories.

And then any, you know, an e-reader can actually then go through those elements, examine them and say that something announced things like an alt text for an image or a label for a certain... name for a label or something. But but the technical piece behind it is with 2.1 came a lot of user agent or browser changes, a lot of technology enhancements

as you mentioned. The CSS mobile development. And with that the browsers started to conform, They stopped doing the browser war and they started conforming essential specifications. So a lot of modern browsers these days will come out and they'll still act the same way as another browser because they're following a centralized specification. And the reason that's great is it all the modern browsers now also create what we call an accessibility object model, which is different than the document object model, which development is access by accessing the elements of the document, the web page.

But this AOM or accessibility object model has been around for quite a while. And, you know, e-readers like Jaws and NVDA, they actually inspect that model instead of trying to parse the entire set of elements on the page, the browser is done it fast, efficiently, and accurately before they even get to there. So it's a huge leap and bound in technology.

And I'm actually hopeful that within the next few years that accessibility object model will actually be exposed to developers. Currently, it isn't available to JavaScript developers and people that want to fix things with JavaScript, but the e-readers have been using it for a while. So mostly just to ensure 4.1.1 parsing was originally intended for certain criteria which no longer apply.

And not only that, it actually used to be trying to cover things which are already being covered in other criteria now. So you've got 2.11 for keyboard operability, operability 4.2 for name rollover value and 1.3.1 for information relationships. So those parsing problems are now being delegated out to lower criteria. So they... this whole passing section that really doesn't need to exist anymore.

And I think that's why they made the decision to mark it for removal. And I think it's a good thing. As you said, things were spotty at best when trying to look at that.

Casey Naiduk

Yeah, I know. I'm excited. I no longer have to pretend I understand what it means. So...

Garry Harstad

You know, a long time ago I was writing rules for that and I was racking my brain like, how are we to figure that out? You know, because they were kind of meddlesome things. So frustrating. So I'm, I, for one, am happy this is going. Actually one of the interesting side effects of this is one of the only valid or vaguely legitimate areas on the 4.1.1 parsing was duplicate IDs.

I mean, when you put an ID in a page, it's meant to be unique on the whole page. You don't want a link, which is the ID one and another link with ID two, ID one as well because they're duplicated. But interestingly, 4.11 parsing removal means that technically won't be a WCAG failure anymore unless it fails subcriteria which require similiar things.

And that's where it gets gray.

Casey Naiduk

Yeah, yeah, yeah.

Garry Harstad

That's passing. I guess.

Casey Naiduk

Yeah, sure.

Garry Harstad

The next one is 2.47. Is that right?

Casey Naiduk

2.4.7. Focused, visible. I'm going to I'm going to jump in on this one because I, this is one I actually if it's possible to have a strong opinion about WCAG criteria and then then this, this one is that for me. And so this is an interesting one which like 4.1.1 parsing is kind of an outlier in that for the first time we have an existing criterion that in 2.2 is expected to change.

Like you talk about conformance levels, So focus physical is expected to move from AA criterion to a single A criterion, which in a nutshell means we talked about claiming conformance too. In a nutshell, it means that there can be no no claims of accessibility conformance, no claim specifically WCAG conformance if you don't have focus, visible focus indicators. And this one for me is like, you know, hallelujah.

I don't know. I don't know how we got into 2023 where this hadn't been a single A requirement before. For anybody unfamiliar with what focus visible means it basically says that as you navigate interactive or keyboard reachable elements components with your keyboard, that there is an indicator that shows you where you are. It shows you where your focus is.

And I've always scratched my head at that how something so fundamental to accessibility. We think of what a large number of sighted keyboard users there are and I'm thrilled. So there's there's no there's no change to the content or the the, the language of the criterion itself. It's it's getting bumped up from that from that middle level AA to that to that A level. Right?

Garry Harstad

It was promoted to be more important.

Casey Naiduk

It is. It's at that it's now at that same level of right some of the other AA criteria are some of the most foundational fundamental aspects of accessibility, right? That 1.1.1 nontext content, right? You have to have a text alternative for stuff that's not text. You can't have accessibility without it. Right? Or 2.1.1 keyboard accessibility. You can't claim accessibility with that.

This bumps it up to that level, which I'm thrilled to see. Yeah.

Garry Harstad

So interestingly, if you if you followed this back 2.2, it could be the only gotcha where if you used to claim AA and now you don't do that you now don't you can't claim AA because or it... I guess it doesn't matter.

Casey Naiduk

Well if it were the other way around maybe..

Garry Harstad

But backwards.

Casey Naiduk

I think.

Garry Harstad

Yeah. It doesn't matter anyway because this is 2.2 compliance. This isn't a fact. You know, you can't complain claim 2.1 compliance hasn't changed even though the success criteria has changed.

Casey Naiduk

Yeah, let's go with that look. Yep.

Garry Harstad

And now this is not the same as 2.4.11, which is focused appearance.

Casey Naiduk

Yeah.

Garry Harstad

This one is focus visible.

Casey Naiduk

So what does focus appearance 2.4.11?

Garry Harstad

Well, the specifics of it are about how much it gets focused and how much you can see the boundary and the borders. I haven't gone into much detail on my notes, but that one that is at risk removal because they're still trying to figure out the details of how the appearance keyboard focus elements should be required to be versus that it needs to be at all.

Casey Naiduk

And this one's weird for me. I got to be honest. The fact that it's maybe it's at risk because they have to clean up, you know, exactly where the guardrails are for this. But it's weird to me that this is at risk. And I'm going to, you know, I'll admit something on a on the airwaves right now that sorry to anybody who I've done an accessibility audit for in the past, but I already have applied this, like for years.

And here's the reason. 2.4.7 focus visible is required. Okay. If you can't see it, it's no good. Okay. So to, so, you know, how can how can you say you've got a visible focus indicator if the contrast of it is so low that that you don't know it's there? And there's another and maybe I should say that that one of the one of the kind of requirements of 2.4.11 focused appearance if it if it remains in the in the final draft is that it'll specify at the focus indicator so that that bounding box or that thing that shows you where your focus is that it has to meet a minimum 3 to 1 contrast

ratio in a couple of different ways. Against adjacent colors, but then against its default unfocused state. Now there is there is already a criterion that came out in 2.1 1.4..11. Nobody look that us because I don’t know if that's right. But that is color contrast for UI components, right? So we've got 1.4.3, which is related text, we've got one 1.4.11 related to UI components.

Now that tells you that you've got to meet a minimum 3 to 1 contrast ratio, for... to to provide a visual indicator of important UI elements and hamburger menus or something like that. But then also if there's a visual indication of the state of an element and by my book, whether or not an element is receiving focus, you could call it a change of state.

So, you know, to me this one's kind of already to me, this one's kind of already in there. Now I know, and this may this may be part of the reason that this one is at risk. I know there are additional considerations in terms of, you know, this would prescribe exactly how how big in pixels the indicator needs to be, I think.

Right? Is that this one? And stuff like that and maybe or am I getting ahead?

Garry Harstad

Yeah. No, I think one of the additions is that it's a bit like 2.4.7 focus visible, but it's kind of trying to enforce a border. So the bordering either would have to be around all four edges or on the shortest edge and be thicker. So I think they've been working through those specifics and they're not really sure yet who's happy.

Casey Naiduk

Yeah.

Garry Harstad

I guess if you imagine bordering a five star rating, you border around the star edges? Do you border around the entire thing? You know, I think there's some questions about that, although as you said, there's already understanding documentation for it and people have mostly been doing this anyway. So I'm surprised that it's at risk as well.

Casey Naiduk

Yeah, but and who knows exactly exactly what you brought up. You brought up some good reasons that it might be at risk. But I would say this to anybody, anybody looking at this and saying, you know, does it matter how visible our vision, our visible focus indicators are? The answer is yes. The reason that the reason that criterion exists is people have to know where their keyboard focuses.

If you're a sighted keyboard user or other keyboard alternative user, that visible focus indication is only good if you can see it. And we already have pretty well-defined standards that tell us how to measure whether or not something is is going to be visible for most people. Right? So there's not really a minimum contrast that we can say everybody will be able to see based on your you know, based on your color perception, based on your level of vision.

But we know, you know, that when you get UI type of elements, meet at least a 3 to 1, 3 to 1 contrast ratio that they're they're generally considered visible for for most people. So whether or not this one makes it in and, you know, make those focus indicators visible. Right.

Garry Harstad

Yeah, it's interesting because 2.4.11 and 2.4.12 are kind of they're not the same but that the focus they're concerned with the focusing and the visibility of the focus. You know, whether people can actually see it. I mean, even sighted people, sometimes if you tap through a page, it's hard to know where you're at or what you're looking at, depending on how they do it.

So, yeah, I'm also surprised 2.4.11 is at risk, but that rolls into 2.4.12 and I think we can possibly talk about 2.4.12 and 2.4.13 together in the fact that 2.4.12 is ensuring that a focused element is not obscured by a pop over element. And the enhanced version 2.4.13. It says that none of it can be obscured where the regular version says that you can obscure a bit of it, just not all of the button. So imagine you hover over a button.

Any part of part of it is obscured by an overlay. That's okay in 2.4.12, but it's not okay in 2.4.13. But they are AA and AAA accordingly.

Casey Naiduk

Do you know? I don't and I probably should, but I promise that one this becomes a recommendation I'll find out. When we that some of some of an element can be obscured. Is it defined as as to what some of it means? Is there... can have-

Garry Harstad

No. In fact, that that's the only clarification is that 2.4.13 says that none of it should be obscured and that 2.4.12 says that it just shouldn't be obscured.

So, I mean...

I think the question is, I think what it seems to be the difference is, is that 2.4.12, focus, focus, not obscured minimum says try not to hide everything they're focusing on. But if you can't help some of it oh well. And then the next one says no oh well. You will make sure zero are being covered by the focused element.

And almost the second one makes more sense, doesn't it? Because if I can hard focus over button, I'm now trying to reread and it's not there, it seems very difficult to me, but that's the way that they got it set up.

Casey Naiduk

Yeah, well, yeah. And maybe some of maybe a more useful because I'm with you. I'm a little I'm a little wishy washy on the specifics of, of that one. But I think one of the, one of the helpful ways for me to think about it is, you know, it's, it's super important that, you know, a lot of times there's where the focus is and it's where it looks like and then there's where you think the focus is or something's behaving as though the focus is elsewhere.

And I think for me, the takeaway here and some of this, you could argue, kind of falls into is it 2.4.3 focused order? Like it's I know they're different ones in terms of visibility, ones in terms of where the focus is. But I mean, I would argue that they're almost they're almost related where if you've got a situation where where the focus is in terms of yeah.

And where it looks like the focus might be, and that would include if there's if there's an element that's obscuring, you know, something in the background, that could impact your your meaning and your your, your ability to understand the content functionality and your ability to navigate it. And so we should not have scenarios where, you know, the element that your focus focused on is obscured.

Just like we should not have scenarios where, you know, you've got a big you've got a big window or something in the front and your keyboard navagability is actually happening in the background. Right? And you know, for for me, the take home here is, you know, let's have a 1 to 1 between where it looks like focus ought to be and where it is.

And if I think if you boil it down to there, these kind of scenarios, I don't know. I think that mindset kind of helps these become non-issues to begin with. I don't know if that's right, but that's why I think if anything.

Garry Harstad

I mean, I can imagine cases where a developer create an app with a lot of functionality and a lot of small buttons together are arguing, I can't do this. So I kind of get a little bit why they're pushing back on it. But on the other hand, they create a AAA version that says screw that. And in a virtual sense and, you know, basically try it because, you know, until it's enforced, it's really not going to be something people go out of the way to fix much.

But to be clear, both of those, 2.4.12, these are focused not obscured at the minimum and enhanced versions, these are always and only concerned with user created and position content. So if a browser tips automatically over something that's not your fault, you don't have to worry about it. So it's just something to be aware of because some people freak out when they say, you know, if something obscured am I breaking it? But if you didn't create it, you didn't break it.

Casey Naiduk

Hmm. That’s a good.. that's a really simple but probably accurate way of putting it.

Garry Harstad

So that was 2.412 and 2.4.13, if that was significant enough to move on?

Casey Naiduk

I think so.

Garry Harstad

Now we've got dragging movements 2.5.7, and that's another new one.

Casey Naiduk

It Is.

Garry Harstad

AA.

Casey Naiduk

Yeah, and I mean, I can tell you my understanding of this in a, in a sentence or two and then I'd love to hear your interpretation, and your advice to people wondering how to how to interpret it, but more importantly then how to apply it. So 2.5.7 new criterion dragging movements and it basically says that if there's functionality that is available through dragging movements or like a drag and drop, you know, meaning pull down your mouse pointer as an example, move it somewhere else, that there has to be a way to achieve that task that does not rely on that dragging on that dragging movement. There are a number of reasons

for that. Physically, that can be a very difficult or painful thing for somebody to do. And then also, if we do think about, you know, perhaps perhaps a nonsighted screen reader user, for example, a lot of times dragging movements kind of by their nature inherently require an understanding of physical placement of elements on an interface. And so what this criterion is getting at is that for dragging movements, there's there's an alternative way that does not rely on that dragging movement to to achieve it.

And I'll give one example and then I'd love to hear your interpretation of your guidance for people. So, you know, for example, let's say you've got, you know, you've got a an interactive list of elements that you can rearrange or something. A lot of times you'll see like that drag and drop. I want to move item three to item one, an alternative way to achieve that

that doesn't rely on the drag and drop would be maybe I click a button and now I've got arrows where I can physically push that and something jumps up a couple of spots. Or maybe I've got maybe I've got a text input mechanism that says, hey, move this to spot one with this to spot two. Things like that

based on my understanding that the documentation that's been released so far would be acceptable ways to achieve that criterion. Is that is that kind of in sync with your understanding?

Garry Harstad

Totally. And exactly. And in fact, they define you alternative must be a single point of action which they define as a single tap or click, a double tap or click, long presses or path based gestures. So I know that sounds similar, but dragging is not that. Dropping is not. That that requires a lot of dexterity, a lot of spatial awareness, and potentially a lot of visual acuity.

So I use a single click such as you mentioned, narrow instead of drag. You know, you've got to ask yourself if you're going to hold such functionality, why not have that be the functionality, be accessible by default? When I, I'm always an advocate for trying to make the functionality or the feature you're creating accessible by design and not like let's make it accessible after the fact.

And I think all of us can evangelize a little bit about how developers sometimes go for the sure easy thing to do. But things like this make you really think that functionality, because if they do have drag and drop interfaces, it's now a whole nightmare to try and replace that functionality or create a duplicate functionality. But that's exactly right.

I couldn't really explain it better than you did. A single point.

Casey Naiduk

I bet you could. Why don't I throw this next one to you, Garry? We've got I think next on the list is 2.5.8 target size minimum. And that is a a new and expected new AA criterion.

Garry Harstad

I think this is related to the one that gets me most irritated, but I can't match the close button because there are these tiny little Xs on these things. That just infuriates me. And I think some, there's some confusion about what size they should be. I noticed a year or two ago I was dealing with something on Android.

It had to be 48 pixels and then something else had to be something else. I think it's important to be clear about what we're talking about here is CSS pixels, which are the pixels that are defined. Absolutely. Whether or not your display is hugely dense and doubles our pixel size is kind of irrelevant. We're really talking about the pixel size

you would specify it in a style sheet or in CSS sheets. And what it what this says is 2.5.8, target size minimum, which is AA. And it basically says the size of the target pointer is at least 24 by 24 CSS pixels. That basically means you can have at least a 24 pixels square or larger. It's important to note that that this applies to independent components.

If you have a link in line with some other text, it doesn't apply to that. So whatever that text is you stay at that size, for instance. But if you have independent like a hamburger menu or, you know, a close bond, it should absolutely be 24 by 24 pixels. And please, for the love of God, everybody do this because it's it's just one of the probably the second most inaccessible thing I come across daily.

It's like not being out of find the right button and being bait clicked into clicking adverts because you can't click the button because its so small. Maybe my fingers are too fat? Who knows? But I have trouble with it. So in my experience its infuriating.

Casey Naiduk

Yeah. You hate the close buttons. I hate the advertisements themselves.

Garry Harstad

Yeah.

Casey Naiduk

So 24 by 24 CSS pixels. Is that big? Is that small? Is that terribly burdensome for designers and developers? What's your take?

Garry Harstad

You know, I tried playing with this a few... I had a few scenarios for this last year, and 48 was too big from a design standpoint. It was troublesome. 24 not a problem at all. Most font size is around 18-20 pixels anyway, so you know, it's really not going to be that out of line. And when you look at the text versus in relation to the buttons you click, it really should be similar to the regular buttons, but not this tiny little text without a board or there an unclear target area.

So I think 24 pixels is totally doable. It's more than reasonable in my opinion.

Casey Naiduk

Yeah. Yeah. And maybe I'm certainly not going to try to restate anything. You just said it super clearly. I might just add, you know, part of the reason it's important and there are two there different but related, you know impacts of this that this has. The first is we don't want people to not be able to to reach a control they want to reach right?

I talked about that that website that I've been using on my phone recently for... Yeah. For that that one banking website... and some of those buttons I mean I can't even I can't get them. I've got to I've got to pinch it you know and fortunately I'm able to pinch it and that's an option for me. Right?

So there's there's the physical ability to select them. But then also we want to make sure that we're not introducing scenarios people are unnecessarily or have a higher, higher chance of selecting something in error, right? So if you've got elements that are that are in proximity to one another, you know, you don't want to you don't want to click submit when you meant cancel.

And now all of a sudden, you know, you filed your taxes and you didn't mean to. You know, you want to you want to make sure that you can increase to the extent that you're able to user confidence and user control. And it's a good practice.

Garry Harstad

That’s an excellent point. It's really about the ease and usability. But sighted people have trouble. You're in a wrong they entirely already. I think this is a long time coming, this 24 pixel thing. I'm not sure that needs much more information. I think that was it.

Casey Naiduk

Yeah. Let’s move on. That was good.

Garry Harstad

3.2.6 consistent help. We touched on this briefly earlier. This is talking about if a page provides help to users. And again this is not for single page sites or for things where things are transformed off, you need landing pages. If you provide help on more than one page, the places and positions of those, or the discoverability positions of those helpful

links and buttons should be consistent on each page. And I don't think that's hard to do. It sounds a little difficult, but I think normally these things aren't being put as or in many areas, so that which are pretty persistent. Is that right?

Casey Naiduk

Yeah, I think so. I think it's one of those... this one, I'll be honest. This to me was this to me was the surprise in WCAG 2.2. I know that a lot of people are of the opinion that this is long overdue. And I'm not I'm not I'm not saying I don't share that opinion, but this it's this one took me by surprise for some reason, because I can I can foresee some people, you know, kind of kind of interpreting this or are forseeing some people maybe on the other side of a web accessibility audit or something saying, well, how can you tell me where I have to put my

my help, my help information? But if you think about the intention here, you know, it's not to be limiting in in and what you can do and where you can place help information like like, you know, like frequently asked questions or or contact links or chats or things like that. It's it's really quite the opposite. And and if you embrace this, you know, if users can reliably consistently know where those... Where help information can be accessed and help channels can be accessed, that can only be a positive, that can only reduce frustration and increase kind of satisfaction.

You know, in my understanding of this too, is that this could apply to specific help channels, but it could also could apply to if you have a generic link out to like, you know, got to a help resource or something, it could apply in both of those scenarios. I also find it interesting this one kinda sorta a little bit, you know, could already be in scope or you know, under 2.0 and 2.1.

Right? So we do want to always strive for consistent navigation and depending on where you know, a lot of times and you brought up, you know, you brought up like hamburger menus and footers and like that, a lot of times those would fall under the realm of what we might define as navigation. And so to some extent, there's already there's already an expectation that when repeated navigational elements appear on many pages or across a whole website or digital property, that they already kind of are in a consistent and predictable place.

So in some ways, you know, for whatever reason, this one through me as a loop. I was like, huh? I'm surprised to see that. But in some ways it's in my mind, it's it's not even entirely new, right? And it is a good practice.

Garry Harstad

And it's actually quite logical. And I'll admit it surprised me, too, because I can think it's so many reasons why people could say, I can't do that. This section of the website is for these guys and they have a different menu. Now, where am I going to fit this? But what it really does is say figure out your consistent navigation.

I mean, just figure it out once. And once you've done it, as you said, it's pretty much been there for a while now. We're just calling it out now as well. So it's not that difficult. What's actually difficult is trying to have automation tools detect this. That's hard. So there's a lot of vendors out there with scanning tools trying to figure it out. For them

it's very hard. But I think from an implementation standpoint, it's actually extraordinarily simple and again, probably a good best practice, right?

Casey Naiduk

Yeah, Yeah, that's right. Fewer fewer decisions for users, fewer fewer points of confusion often translates to higher satisfaction, higher usability.

Garry Harstad

Right.

So we got redundant entry, 3.3.7, which is Level A.

Casey Naiduk

We do.

Garry Harstad

This really says that information previously entered or that has been provided by the user previously. If it's required to be entered again, then it's either auto populated, they don't have to fill it out again, or there's some mechanism where they can kind of say, copy my previous answer or copy the billing address in a shipping and billing case scenario.

I don't think any of that's confusing except for the way WCAG has put on their website. There seems to be some confusion.

Casey Naiduk

Yeah. Yeah.

Garry Harstad

Not to go into too much detail, but they're all listed as 3.3.7 is accessible authentication. 3.3.8 is the no exception accessible authentication, and then 3.3.9 is the redundant entry. Then if you go into the later documents and you click on the 3.3.9 redundant entry, it's actually accessible authentication.

So there's a couple of number confusions. It's easy to see and explain. But I think what we come down to is that the latest criterion for this three three is 3.3.7 redundant entry. But it may also have previously been referred to as 3.3.9. But again, WCAG 2.2 is new. They are not finished it yet, they just want to get it right.

So these things mistakes happen occasionally. But redundant entry, pretty easy to do. I think for me it’s about enabling mostly autofill, password managers, making sure they work. And if you do have that billing shipping case, you give them the option to copy the shipping address or copy the billing address. I don't think any of that is outside of best practices either.

What do you think?

Casey Naiduk

I don't. And this is one of those this is one of those interesting ones to me where I think a lot of people would read this this criterion and say, well, you know, it seems to be a boost for for ease. But but why is this why is this necessarily or specifically an accessibility requirement? And I think if anybody has that question, I think it's an interesting question, and I think it's a fair question.

Some of the, to add some color commentary there, some of the reasons might be, you, you know, related to cognition. So the simple act of remembering what was it that I put on step one, I want to make sure I put the same thing on step two. Some of it is, you know, so there's there's mental and cognitive load, but then there's also just the physical exertion of of inputting data.

And for some people it's very easy. They could type 100 words a minute. I'm not one of those people. For some people inserting inserting characters is laborious or painful or error prone or difficult for any number of reasons. And if we have an opportunity to proactively limit that and, you know, we we really ought to. Now there may be security and other reasons that would that would kind of introduce some exceptions as to, you know, exactly when or how or why you might not want to want to conform with this criterion.

But in general, like you said, it's a good practice. Yeah, right. Yeah.

Garry Harstad

And I don't think any of this is you know, you mentioned it's really close to a usability problem than an accessibility problem and, you know, having the even is a non accessible problem. It's simply frustrating to retype stuff you already think they have the information for. So you know.

Casey Naiduk

It is. Yeah. Why are you making me put the same thing on step two and step three and step four when I already already gave you that? Yeah.

Garry Harstad

So it's really just pushing. Don't let that happen. And that's really all that's about.

Casey Naiduk

Yeah. And imagine, imagine if we were having that conversation. Okay. What's your name? My name's Garry. Okay. What's your name? Well, my name's Garry. I should know that. Yeah.

Garry Harstad

Actually going to be McDonald's ordering four times because you got [inaudible]. It doesn't make sense.

Okay. The next two are the last two. We've kind of talked a little bit, but they're both about accessible authentication. 3.3.8 is the AA and 3.3.9 is the AAA, the enhanced version. But 3.3.8 authentication. You want to take a quick stab at the overview of that?

Casey Naiduk

Yes. So 3.3.8, accessible authentication, there's a AA and AAA, like you said. My understanding is it's trying to to limit, ideally eliminate, but at least limit the, the extent to which cognition impacts your ability to authenticate into your own stuff. So if we actually let's see, do we have this? When I was hoping to... bear with me, I'd like to actually read the... I’d like to actually read the criterion language

itself because I don't want to botch it and it's one that I often confused.

Garry Harstad

With, I actually viewed it, just to... I kind of summarized what I thought they were trying to say. I came up with basically they're trying to reduce the cognitive test requirements, as you said, that have been common for authentication in apps and pages, and they really want you to just provide a non cognitive alternative such as email me a magic link or something, something which is already natively easy for them to do.

And if you're trying to solve puzzles, or ask them to identify things, it should be things they can and are familiar with. So they should be either objects or it needs to be things they've already provided, which is a little trickier. But imagine things like secret answers that you're been asked to set up previously. Now you have to identify them that that is less cognitively load bearing burdensome than just an email link or trying to put everything in the right place.

Some of these authentication puzzles are annoying, really annoting. Think reCAPTCHAs, for instance.

Casey Naiduk

Yeah, drives you, drives you bonkers. Accessibility aside. Right? Those things are not accessible for anybody. They're just they're such a pain. Now, let me ask you this. Does this does this example fall in line with your understanding of what would be, you know, a successful way to meet the new AA accessible authentication? So, you know, one example that's popping in mind is let's say I have you know, I have an access code or something that's that's been texted to me, right?

You know something I know that my phone does I think a lot of smartphones do. Won’t say the brand. If I'm on a website or if I'm authenticating and my phone gets texted a code, something really neat that I do is if I tap into the input field where where would be entering that that authentication code that was texted to me, my phone says, Hey, do you want to use this one that just appeared in your messages?

And I just bop it. And I know for me that that's easy because one, I, I'm going to forget the six or eight digit passcode because I just always do. And so that helps me to from having to go from, you know, from having to have my memory fail or try to go back and forth and do one character at a time is is is that along these lines?

Garry Harstad

I think it is along those lines. I think it avoids it does it does not try to say it's not really a two factor authentication replacement. So it's really saying that in a to if I you still have to put a password in for instance or still potentially saw reCAPTCHA or, something like that. What they're saying is there should be an entirely alternative version.

So if you could have yourself texted a magical link that you could then use on your phone and in the website new it that may be used on a desktop. That's great. That's amazing and that really, but if you could do that reliably, securely and and it did fully authenticate you without needing to do these other cognitive barrier things, then yeah, that's totally 100% applicable to an auction.

You know, I think the simplest form of an alternative to authentication is that I don't know how to do this thing. You're talking to me, send me a link, knows how to use their email. So if they do have to do that huge thing and instead they could do this very simple thing, I think that's the kind of alternative solutions they're after.

Not in the enhanced The enhanced offer a bit more and it's not actually understanding documentation for the enhanced version. And if anything, I would have thought that one would be the one that should be at risk. I can just barely come up with that.

Casey Naiduk

I thought that. Yeah.

Garry Harstad

So that's what that one out for the Super 11 or whatever.

Casey Naiduk

Yeah. Okay. So okay.

Garry Harstad

Oh, I just want to say because it basically says a cognitive function test such as remembering a password or so on the bottom should not be required for any step in your authentication process unless that step provides at least one of the following in his work. It's a little interesting. I do an alternative mechanism. We just kind of talked about that, or a mechanism available to a system so we could talk possibly password managers that could kind of get there... Object recognition.

So that's interesting to me because I get objects are easy to identify, but still, if your low vision it doesn’t matter what you're looking at, that tough. And then finally, personal content, which is content you provided a website, and although I didn't mention it here, I really it like they're trying to have that personal content can be things like uploaded images and video which is interesting to me because if you're going to be able to objectify or see anything that's both of you, it might be the sound of something in a video.

It might be.

Casey Naiduk

The.

Garry Harstad

Movement of something that might open up some interesting questions in my head.

Casey Naiduk

Yeah, I'll be interested to see how this plays out. And I'll be interested to see when people smarter than me have started to put together more examples of how to satisfy this so that I can steal them and apply them. Right?

Garry Harstad

That's why three, three, nine with no understanding documentation, I'm not sure what they expect from us. So also authentication is often multi steps. So it's like how do you encapsulate the entire process? And one criterion I'll be interested to see how that evolves myself.

Casey Naiduk

Yeah.

Garry Harstad

That's the last specific criteria. I think we went over the few, the one that removed one that got promoted, and the one that’s at risk. We went through the rest that were additive. But there are only two AAAs, there are only seven technically majorly actionable items on that and probably trying to come up to the conclusion here. And what's the future of WCAG after WCAG

2.2 is published is the big question.

Casey Naiduk

It is a good question. Well again, disclaimer. No crystal ball. I try to predict the future. I'm not good at it. I can't tell you what I'm doing tomorrow, but I can tell you this. We know that after 2.2, at some point there will be WCAG 3.0 which is also called Silver. That's going to be... so 2.2 right from 2.1 is up is a minor version update. 3.0 when that comes out which at this point we think is in a few years.

Although we heard that maybe a few years ago. It's kind of a reconceptualization of how to test and then and and then classify what what exactly is an accessibility failure or or pass. And so the scoring system will look quite different. It's not something that I would even, you know, if you have interest, right? if you have an interest in the area go ahead and, and look out about what's out there.

There are some good articles information out there including W3C stuff that you could that you could gather. I wouldn't worry about trying to understand 3.0. This is my opinion. But but trying to understand 3.0 quite yet for any purposes of how would I apply this to my organization or my. It's just too undefined at this point.

And it's it's way too up in the air. One neat thing... so it'll still my understanding is we'll keep with the WCAG naming conventions so WCAG 3.0. But unlike the Web Content Accessibility Guidelines name, which I think confuses a lot of people as to, you know, does it apply to things outside of web content? And we know the answer is yes.

We know it's more broad to digital, to your properties, more broadly. I think in order to combat that that misunderstanding. But we'll keep with the WCAG naming convention, but then I'll actually stand for W3C Accessibility Guidelines. So a shift from that web content to W3C Accessibility Guidelines. So it'll look familiar. But technically behind the scenes we'll have a different meaning in that title.

Yeah, yeah, yeah.

Garry Harstad

Even with W3C, just so people know, is the World Wide Web Consortium.

Casey Naiduk

Right.

Garry Harstad

Is what the W3C stands for. So unless you know that explicitly, even the change in name is confusing.

Casey Naiduk

That's true. Yeah, that's a good point. But I guess what, I guess that was a long way of saying that my understanding and you know, and my my belief is that following 2.2, whenever that gets released as the final version, hopefully in April, maybe the summer, who knows? You know, I think that will be the last in the 2.X series until we get that you know that that totally new brand spanking new WCAG 3.0 which whenever that comes out it's my understanding, too, that would essentially be we would have kind of parallel current valid recommendations from W3C.

So it would not be the case that 2.2 all of a sudden becomes deprecated or invalid, at least as it's been explained to me. And from what I've read thus far, which what's available with what's available about 3.0. They would both be valid but different web accessibility standards that that exists concurrently which which is a shift, but it'll be cool to see how that shakes out.

But that's what I think. What do you think?

Garry Harstad

So... you're saying it's not really it's not. It's going to be totally different, but it's not really different in the change from 2.0 to 2.1, 2.1 or 2.2, it's it's you're either conforming in a 2.X or you're conforming in a 3.X scenario.

Casey Naiduk

Yeah, maybe. And who knows, maybe it could be in both? I don't know. But. But it would be, you know, it wouldn't. It's not necessarily the case. So right now, people, if you're if you're still listening to this webinar, you're probably you're probably trying to make the decision of okay, 2.2. I've heard it's coming out. When do I need to worry about that?

Do I need to adjust my policy? Do I need to start testing for that? Because you want to replace 2.0 or 2.1 in your in your policy or in your testing strategy because you know that those will be outdated as the W3C recommendations and 2.2 will be the current recommendation. When 3.0 comes out, you'll have two current recommendations: 2.2 and 3.0.

That's at least how I understand it now.

Garry Harstad

Right? I don't think one is going to supplant the other. I think they'll be years apart.

Casey Naiduk

Yeah, I think so. I can't even speculate at this point.

Garry Harstad

I actually believe they might be at 2.3 where we have a-

Casey Naiduk

A 2.3?

Garry Harstad

Yeah. Only because there's been so many delays and 3.0 is such a gargantuan undertaking. It's it's a very ambitious project. They're trying to do. It's going to create a revolution in my mind in how accessibility is determined, and conformant, and who knows, maybe even compliant by that point. But because of the enormity of it and because of the general traditional delay between getting the specs out, I'm guesstimating that there probably be another version 2.X in here, maybe even two, but it will be contingent on how fast the technology and the user agents and the industry standards are moved while they're working in parallel on 3.0 because the 3.0 takes three years.

You can imagine with a lot of browser changes over three years, there's a lot of technology, a lot of phone mobile changes. So to keep up, they may have to do exactly what they're doing now, which is, oh dear, let's stop this gap. 2.2, 2.3. It's been two years already. We need to add these two extra criteria. We're going to call it WCAG 2.3.

But as you said, this thing is entirely speculative. No one knows. You know, and and I think what you can do is just make your best guesses about okay, 2.2 is actually coming out in the next six months. Now I can work on it 3.0. It's still theoretical. It might change wildly. So as you said, I wouldn't go chasing that waterfall yet.

Just worry about 2.2 and probably staying in a two series for what I would predict will be a few years from now. But who knows?

Casey Naiduk

Yeah, well well that that I think we that I think we agree on. That and you know even if 3.0 came out tomorrow which which it's not but even if it did you know it's not like you know so experienced or seasoned accessibility professionals now okay... 2.2 comes out. What are those new criteria? Okay got them. Start to apply them and understanding them. 3.0 is going to be a relearning for for everybody and it's going to take it's going to take a lot of time. I know it's going to take me a lot of time to wrap my head around it.

It's going to take even longer before I have my you know, I've got a grasp on it enough to to be comfortable and confident, making a recommendation to somebody else about about what they should do with, you know, with content and properties that they own. So it's it's going to be a learning curve for sure. And that's that's going to take time.

Garry Harstad

I think what you can be certain about is that 3.0 is a major change. It's not a two series. It's not the one series, it's the three series. And when major versions change, it means they are not backward compatible typically. So what we're really talking about is an overhaul, a revolution. Everybody has to relearn things. Reunderstand it. Create tools.

It’s going to be this whole evolution about it and it's going to be noisy in my prediction. It’s going to be a bit of a noisy argument about what is and what isn't required. But just be aware that, you know, just like with WCAG 1.0, we’re on 2.0, now 2.2 coming out.

There's a reason why those major versions are there. It's to let you feel comfortable that in the two series you're still good. You're not going to be changing. But when three comes along, expect major changes, expect great turmoil and a lot of lwork.

Casey Naiduk

Are you predicting riots?

Garry Harstad

Possibly in the streets. I'm not sure, certainly between developers though.

Casey Naiduk

The Yeah, yeah the the geek version of riots. Yeah we're going to play we're going to be arguing about Yeah. Yeah right.

Garry Harstad

I think that’s really it. We don't really know at this point, what we can speculate and the speculation is now 3.0 in a year or two, 2.0 for next year or two. 2.2 for the next year or two.

Casey Naiduk

Yeah. Yeah. That's, that's Yeah. So what can you do now. You can I mean Right. You could continue to, to follow the track of 2.2 right. To the extent that it makes sense to understand the criteria themselves, do it. Within a few months, hopefully that becomes the recommendation, then you're more seriously consider looking at how to, how to update your your testing strategy and maybe your corporate policies.

Right. And then we'll see. Maybe maybe laws will adopt adopted. We'll see how quickly that happens. Right. Sometimes we see, you know, if you're like an accessibility, if you're if you're an accessibility company yourself, you know, you might be ready to go with to that to the next day. If you're a large corporate entity, I take you six months.

It might take you a year if a government entity, it might take a couple of years. We've we don't know. But I think nothing magical happens that day, right, when 2.2 drops where your website does not blow up, you know, you're not all of a sudden inaccessible just because that happened, right, Garry? I mean, it's it's it's a good thing.

Embrace it. Learn about it, you know, and and the beautiful thing is all of these criteria that are that are getting introduced into that, too, they're really customer and user, right? I don't think there's one in there that you could argue makes the experienced worse or more burdensome or tiresome for a user. They all, they make the experiences easier, less stressful.

They reduce physical and potentially cognitive load and dare I say, more enjoyable. So I'm looking forward to it. And it's, you know, it's exciting when you're in industry. It's it's not too many. You know, we're we're on 2.1, right. Which is, you know, we felt like four versions before. This doesn't happen every day. So it'd be cool to see cool to see people's interpretations and guidance and best practices as this evolves over the weeks and months yeah.

Garry Harstad

2.2 for the way and don't worry about three point.

Casey Naiduk

Oh that's right and riots in the streets area I predicted riots in the streets and hey listen I think we're yeah I think we're at the end of our ever question as far as I could see. Gary is good talking to you and good to see you. Thanks. Thanks, everybody, for joining us. Well.

Garry Harstad

Take Care.

CLOSING

LORI

Wow. So that was a riveting conversation about WCAG, the Web Content Accessibility Guidelines between Garry and Casey.

It went a little bit longer than we intended. So understand if some of you haven't stuck around, but it has been recorded today, so it will be available ondemand shortly. I will send out an email when it's ready to go. Thank you to Casey and Garry for sharing their insight and knowledge on the Web Content Accessibility Guidelines with all of us today.

We really appreciate your time and your knowledge. Today's event, again, has been sponsored by the Bureau of Internet Accessibility and AccessibilityWorks. You can find information about both those companies off of today’s event page. Up next for us at Accessibility.com is a three-part series, the DDD series we're calling it here. Design, Develop and Deploy for Accessibility. That's going to kick off in March with Design, and then Develop in April, and at the beginning of June will be Deploy.

So hopefully you've all registered for those and those will be recorded as well and available for you ondemand after the fact if you can't catch them live. Hope you all have an amazing rest of your day and we'll see you next month.