Jay McKay: All right, I think we're ready to go ahead and get started. Good evening everyone. Hello. Welcome to another Be a Digital Ally. You are here for the further exploration of WCAG 2.2, looking at accessible authentication. We do have some slides for you. I'm going to put those up in the chat momentarily, but it is a Bitly link. It is B-I-T dot L-Y slash and then all capital letters J-A-N-B-A-D-A. So JANBADA. So welcome, welcome. All right. Just some quick introductions. I am Jay McKay. I'm the director of community programs here at Knowbility, and my partner in crime here today will introduce herself.
Melissa Green: Hi, good evening. I'm Melissa Green. I am a digital accessibility specialist member of Knowbility's Accessibility Services Team.
Jay McKay: All right. So for those of you, you may be new to be a digital ally, maybe we are part of your New Year's resolution to learn more about accessibility. If so, welcome, welcome. If you are familiar with us. This is the point where if you know what's going on, you might want to go grab your snack, grab your coffee as we do our intros and housewarming. But our agenda for today is we always do a little bit of prep work, maybe for people who are new, welcome them to BADA, give just a very brief overview of what we mean when we talk about accessibility. And then today we're going to talk more specifically about WCAG 2.2 and talking about some of those changes that are coming to WCAG and learning those techniques for those criteria.
So, all right, just some housekeeping. First off, thank you for letting us be a part of your journey, Melissa and I always say this is one of those things we always look forward to every single month. It's just a great time for us to interact, engage, explore all these different areas of accessibility, and that has really kind of created for wherever you are on that journey. So maybe you are new to accessibility, maybe you just, you're doing some content creation for social media, maybe you're trying to update a webpage, maybe you're not really into heavy coding, that's okay. You're always going to get something out of these trainings, but maybe you are that I do all hand coding, I know everything about HTML and frameworks and all of those different things. We're going to have something for you as well. So we usually try to give a very broad overview as well as some other places for you to explore further and do some deeper dives.
So thank you for being a part of this journey. If you have any questions, please go ahead and type them in chat. I will be here, I think Juliana will be joining us as well, one of our community engagement specialists. We'll be here in the chat. We might be able to answer it there, but there will also be an opportunity to jump on the mic at the end if there's a question we didn't cover. Usually as we go through the questions you have, we'll cover them going forward in the session. So hopefully we get to everything. Just some quick overviews on some accessibility features available.
We do make sure that we have the auto captions enabled. If you are having issues accessing those, please let us know. We can help you with that. If you are somebody who requests some additional services, such as sign language interpretation, those are things that you would need to request in advance, just so that way we have time to make sure that those interpreters are scheduled and available. So usually if you know you're coming to BADA, we need at least we would say 72 hours in advance to make sure we have those people in place for you.
And of course, just ask for help. One of our favorite things about doing these BADAs is just the community and the engagement and having people share. So there's no question too small. We're all here for each other.
All right, if you are not familiar with Knowbility, if this is your first time meeting us, hello. We were founded in 1999. We are based out of Austin. We are nonprofit out of there, but really we operate globally. We have people across country, around the world that we work with and our staff and our volunteers, as well as the different clients and community partners that we engage with. And our mission is to create an inclusive digital world for people with disabilities. And we do that through so many of our different programs and we're going to take you to our donate page to go over those.
But at Knowbility, we have several different community programs. We have AIR, which is our accessibility internet rally. We just finished that. It's a great web design competition where we pair non-profits that are in need of maybe a brand new website or a redesign on a current website. And they get paired with development teams that are interested in learning about how to create really effective, impactful websites, but that are also designed with accessibility from the beginning. So really with that intent to make that website as accessible as possible. So we just concluded our 2022.
We have AccessU coming up actually this spring in May. That is our annual web accessibility accessible design conference. So we will be in Austin, Texas. We would love to see you there, but if you're not able to travel or maybe you're somebody that just you're really liking these virtual learning opportunities, we do have virtual participation as well. You will still get all the access that onsite attendees do. So please come and join us for that.
We have our AccessWorks, which is our usability testing program, our K-12 Digital Accessibility. That includes our monthly webinars for Toolkit Tuesday, where we look at different aspects and upcoming policies, changes, procedures, things that people can do to provide more effective implementation of assistive technology and inclusive practices in the classroom. And then of course, Be a Digital Ally. And really, we cannot do any of these programs without your support, without our sponsors. And so we always like to just remind you, we have this wonderful Knowbility.org/donate page if you wish to contribute.
So we want to talk about accessibility before we dive into our topic because accessibility can mean different things to different people. Sometimes when we say something is accessible, it just means it's available or it's open, open versus closed, on the shelf versus tucked away in a corner. But we want to be very precise in what we talk about when we say accessible. So when we talk about something being accessible, it means that people with disabilities must be able to access and utilize it as fully and as independently as someone without a disability.
So some questions to think about is can everyone be able to see and hear the content? Do they know where to go or what to expect as they're navigating a digital space? Can they independently navigate using their preferred tools? So maybe I'm someone who can't use a touch screen on my tablet or my phone and I have to use a voice command or switch operations. Can I independently complete tasks and explore all the areas? So again, am I able to do everything on my own or am I needing assistance or something being blocked because of maybe my preferred tools or because the way the content's displayed, and really ultimately it means can they fully participate in an authentic manner? Do I as the person engaging with your content or with your site or with your digital space, feel like I'm really able to share what I want to share, ask the questions I want to ask and engage with the content the way that I want to the fullest extent.
So next we want to talk about inclusive design because that's really what we talk about and how to design for accessibility is that idea of inclusive design. So this number comes to us from the World Health Organization, their disability report in 2011, 15% of the world's population lives with some form of disability. And when we talk about that percentage, that is the way that the World Health Organization identifies a disability. And we mentioned that because there's many people who do not consider themselves disabled as defined by the World Health Organization. Think about, I always think about some of my family members as they get older and maybe need to wear hearing aids. Now, the World Health Organization may label them as a person with a disability, but my aunt or my uncle may not necessarily consider that as a disability because they just have a set of hearing aids or whatever it is.
So we want to keep that in mind because somebody may not label themselves or come out and say, I have a disability. So you may not know that they have that disability interacting with your website. So really when you're designing for accessibility, not only are you giving access to that 15% of the world's population, but you're also benefiting people who don't necessarily have disabilities. There's so many things that are in place now that everyone benefits from. So you think of close captioning or audio descriptions in streaming platforms. Those are things that I use and I do not necessarily have a hearing disability where I feel that I need those, but I do benefit from having access to those.
So the next thing we want to talk about is assistive technology because when we're designing our websites, our digital spaces to be accessible, and I talked about those preferred tools, we're also talking about assistive technology. So assistive technology enables and promotes inclusion and participation, especially for persons with disability, aging populations, people with non-communicable diseases. The primary purpose of those products is to maintain or improve an individual's functioning and independence, thereby promoting their wellbeing.
So it's in this definition from the World Health Organization, it's talking about what its purpose is. It's going to be something that can maintain or improve their function. So giving that person access, if I need a specialized keyboard, if I need to use Eyegaze. And here we have a list of examples of different types of assistive technology. And what's really kind of fun with assistive technology is it could be any product. It doesn't necessarily have to be labeled as AT, right? So this could be any product that is purchased off the shelf. It could be custom made, it could be a software. It could even just be a system that's put in place for somebody.
So all of these things can be considered assistive technology, and we just have a few examples here. A screen reader, something like JAWS or NVDA is used by people with visual impairments, that is how they navigate computer screens. So it will read everything on the screen for them. So when they click through using their mouse, or their keyboard, excuse me, it'll say this screen, it'll read the title, it'll read the text on there. So it's not so much of just speech to text, it's actually telling them every single file that's in the folder and when they scroll over to the next page, what's on that page as well? Refreshable braille display. This is a device that you would again, hook up to your computer or something that's receiving that digital input and it would turn it into a braille display that changes as it goes through the different text. So somebody would put their hands on it like they would to read braille, but the text or the little dots or bumps that you're familiar to seeing would change as the text does.
Then we have alternative navigation methods. Some people do not use a mouse, some people do not use touchscreens, they have to use just the keyboard. Some people have to use their voice to give commands to their computer or to use a switch, which is a device that they would place either by their head or by their arm, wherever they have access to. Essentially hit that button to make a selection. Close captions, we already talked about a little bit. Transcripts, so even just having a document that has the transcript from a podcast that you just listened to, that's assistive technology. Magnification, dark mode, high contrast. And then also we have a link down at the bottom here from our friends over at Web AIM. And this link takes you to some really nice examples of assistive technology and gives you some, not only pictures, but I think there's some videos as well depending on which ones you're looking at and really kind of dives in a little deeper into what they are and how they can be utilized.
All right, so the best part, it's time to start our journey, and we always, always want to remember that accessibility is a journey. Technology changes, people change, everything evolves. So it's always best to just remember, I love this quote from Maya Angelou. It says, "Do the best you can until you know better. Then when you know better, you do better." And we really like to start here because sometimes if you're new to the journey of accessibility, it can feel very overwhelming, especially when you look at something like the WCAG guidelines and you're like, oh my gosh, I didn't know all of these things existed. There's too much for me to learn all at once. That's okay. You take those steps where you can take them, and when you've got one step down, then you go to the next step. So welcome and let's go ahead and get started.
All right, so we are going to talk about WCAG a little bit. For those of you that joined us last month, this'll again just be a very brief review of what the web content accessibility guidelines are and what they mean. So this is an international standard with documents that explain how to make web content more accessible to people with disabilities. There are four areas of principles, and that includes perceivable, operable, understandable, and robust. So if you think back to our introduction of what accessibility means at the beginning of the session, those questions, that definition that we gave you is really built off of those principles. So that way if you're like, I don't know what perceivable means, I don't know what operable means, go back to those questions and that'll give you an idea.
The guidelines also provide testable success criteria where conformance testing is necessary, detailing how to know when that item meets the standard. So it's not so much of just it needs to have X, Y, Z, it tells you how to look for it, how to test it, how to know when you have achieved that success criteria. And then also they have sufficient and advisory techniques that go beyond what is required, allowing authors to better address the guidelines and usability. So really it's not just these are it, and that's all you need to do, but it also gives you that way to expand and increase your impact. So I really like this quote. This came from the Bureau of Internet Accessibility, and it says, "WCAG offers an actionable framework for creating or mediating websites and apps to be accessible is not abstract, but specific and technical and is supported by documentation that identifies methods and techniques that would be considered to pass or fail the minimum accessibility expectations of each checkpoint."
So for me, this was this really nice summary of what all this means. So thank you Bureau of Internet Accessibility for that definition. So now that we kind of have a better understanding of what these guidelines are, we're just going to talk very quickly about how they are used. So these are an industry standard. As an industry standard by several different companies and organizations. They will require vendors to meet that A, AA, or AAA standards when developing their websites. So as an organization, for Knowbility, we always ask a vendor if they approach us or if we're interested in working with them, we always ask for that accessibility conformance report because we want that snapshot of how accessible their product is. And that report is showing us where they fall on those guidelines. It is referenced in international law. So for example, in the US section 508, the requirements currently reference WCAG 2.0 AA levels.
However, we are seeing more and more companies and organizations use the most recent guidelines. And then also you're seeing the proposed websites and software applications accessibility act that it's kind of moving up its ranks through Congress to introduce those new WCAG 2.2 requirements, even though it's not specifically calling it WCAG 2.2. So really by following these, you are ensuring that you are following usage trends and allows for even more users to access your site.
All right, one last slide and then Elizabeth gets to take over the show. So we just want to remind you about what we mean by I referenced 2.0 earlier and maybe you've heard of 2.1. So we want to just briefly talk about what we mean by 2.2. Does this mean it's in place, is it active? Is this what I should be following now? So it isn't a process, it is not technically approved, and I don't want to go into all of the working parts of it, but we do like to mention that it is something that is developed with several different people with the worldwide web consortium, it's member organizations.
They do take several steps in this process that we have linked on this slide. And so there are five steps in terms of getting something as an approved guideline. So the first step is really getting that community input with several working drafts, and then the second phase is where they really start doing a wide review of those drafts. So that means the working group has addressed all the comments and provides a complete document for the community to say, okay, this is kind of the central working draft now. Then the third phase is candidate recommendation, and this is the current phase for 2.2. I like to think of it as the testing phase. So it's been through review, they have this working draft, but now it's being recommended. So developers are encouraged to really use this technical report for their projects. So we're not expecting large changes at this phase, but we may see some adjustments occur based on experiences from developers.
So if they're looking at it saying, Hey, this language isn't clear, this part doesn't make sense, we don't know what's what's supposed to happen here, or we don't feel this is an effective guideline. And then the fourth stage is when the W3C announces it as a proposed recommendation and it is submitted to the members for endorsement. And then finally the last stage is when that technical report has sufficient support from the members and the community, and it is then officially published as a recommendation. So it still has a few more steps, but we know that it's getting closer and closer to those steps. We wanted to make sure people were prepared to start knowing what 2.2 is going to look like when it is officially published as recommended. So I'm going to step back and now you are all officially briefed. And Melissa, take it away.
Melissa Green: Great, thank you so much, Jay. Just one moment. I'm going to switch some things around on my screens.
Jay McKay: And while you're switching around, Melissa, there was a question about the W3C was going to upgrade 2.2 to a proposed recommendation this past fall, but if they have announced anything about the delay, have we heard anything about the delay?
Melissa Green: I have not.
Jay McKay: Okay.
Melissa Green: That was a short answer.
Jay McKay: Yeah, I know Julie Romanowski I think follows a little closer on where they are. Unfortunately, she was unable to join us today. She would be the perfect person to answer that one for us because I know she has a little bit more insight.
Melissa Green: I Know the last time Julie and I chatted about the status, it was pretty much the same that the official word was early 2023, but folks involved a little closer to the process did not feel as if early 2023 was particularly realistic. So I'm still not holding my breath for anything.
Jay McKay: Fair. Fair.
Melissa Green: All right. Well thank you so much Jay. And while WCAG 2.2 is not yet an official recommendation, the latest published version and the W3C, WAIs, what's new in WCAG 2.2 draft, do give us an idea of what to expect. In our previous BADA session? Introducing WCAG 2.2, we took a high level overview of the proposed success criteria. Today we are taking a closer look at success criteria proposed to address accessible authentication, something several of you expressed interest in when you registered for this evening session.
I like that we're starting our deeper dive with this one because I think the techniques and examples are so interesting. Now, as Jay mentioned, each WCAG guideline has success criteria or testable statements that are not technology specific. The success criteria determine conformance to WCAG. So in other words, to meet the WCAG guidelines, the content needs to meet the success criteria. The success criteria are at three levels, A, AA, and AAA with level A as the minimum level of conformance and AAA conformance ensuring access to the widest possible audience. We anticipate nine new success criteria in WCAG 2.2. The proposed new success criteria are focused on making web content more usable, operable, and understandable, and these changes will be particularly beneficial for users with visual, mobility, and cognitive disabilities.
Additionally, the 2.4.7 focused visible criterion, which was at the AA level and WCAG 2.1 has been promoted to a level A criterion in WCAG 2.2. WCAG 2.2 includes all success criteria from WCAG 2.0 and 2.1 with no changes to existing criteria with the exception of that 2.4.7 focus visible level change. WCAG 2.2 also builds on 2.1 and they're backward compatible, meaning webpages that conform to 2.2 also conform to 2.1, which should also conform to 2.0. If you're required to conform with 2.0 or 2.1, the W3C tells us you can go ahead and update your content to 2.2 without worrying about breaking conformance with previous versions.
So the proposed success criteria we're taking a closer look at today fall under the area of WCAG guideline 3.3, input assistance. WCAG guideline 3.3. Input assistance is pretty short and sweet. It reads, help users avoid and correct mistakes. So everyone makes mistakes. However, some people with disabilities may have more difficulty creating error free input or entering data without errors. It may also be harder for disabled users to detect that they've made an error because common ways of indicating errors may not be accessible because of a limited field of vision, limited color perception or use of assistive technology. If methods don't take those things into account, they may not be accessible.
So what do we mean by input? People use different approaches to enter text and activate command. For instance, some people don't use a mouse, a keyboard, or both, while others use specific configurations for keyboard and mouse or use alternative hardware and software altogether. The examples of input include using keyboard only, by people with cognitive, physical or visual disabilities, touchscreen only by people with cognitive and physical disabilities, mouse and keyboard with software that compensates for a hand tremor, for example, and voice recognition or speech input and other hands free interaction.
Some people use software and customized settings to enhance the efficiency of typing, writing and clicking. Jay described some of the assistive technologies and adaptive strategies related to input. The success criteria that fall under WCAG guideline 3.3, input assistance seek to help users avoid and correct mistakes by providing help with input. The WCAG 2.2 draft proposes three new success criteria under this guideline, 3.3.7 redundant entry and two criteria addressing accessible authentication, 3.3.8 accessible authentication at the AA level and 3.3.9 accessible authentication, no exception at the AAA level. As with other no exception criteria, this is basically a AA and then a AAA success criteria or what you need to do if you're going for AA and a little bit more or AAA.
Before I read the text of the proposed criteria, I'd like to talk terminology. The process of verifying the identity of a user or process or device, often as a prerequisite to allowing access to resources in a system is commonly known as authentication. We're about to look at several examples, but for now, think about entering a username and a password to log into an email account or using your thumb to unlock your iPad or responding to a push notification on your phone asking if it's really you logging into a new device. These are authentication methods.
The purpose of the accessible authentication success criterion is to, or success criteria, both of them, is to ensure that there is an accessible, easy to use and secure method to log in, access content and undertake tasks that doesn't rely on something called a cognitive function test. The cognitive function test as defined by the WCAG glossary is a task that requires the user to remember, manipulate or transcribe information. So remembering refers to remembering a site-specific username, password, set of characters, images, or patterns. This may be difficult or impossible for all users, but especially users with cognitive issues related to memory. For purposes of this definition, recalling something personal to you that persists across sites like your name, email address, or phone number is not considered a cognitive function test because those things are personal to you and consistent across websites. It's not as much of a test of cognitive function to recall them.
Transcription refers to entering data such as typing in characters. An example of an authentication process that requires transcription is receiving a two factor authentication code or other value that you have to type in to a site. A captcha could also be considered a cognitive function test if the user must transcribe the text if that they are presented within the captcha. Transcribing can be problematic for many users, but particularly folks with cognitive issues related to memory reading, users with dyslexia, for example, numbers such as users with dyscalculia or perception processing limitations.
Manipulating information in this context refers to things like spelling correctly, performing calculations and solving puzzles. These may be good useful tools for distinguishing humans from robots, but they can make it difficult or impossible for some people with disabilities to access and use a site, whether it's remembering a random string of characters, a pattern gesture to perform on a touchscreen, or identifying which images contain a particular object, cognitive function tests will exclude some people. Such tests are known to be problematic for many with cognitive disabilities.
So in order to conform with these success criteria related to accessible authentication, you're working to make it possible to authenticate without remembering, transcribing, or manipulating any information. You could also think of these success criteria as make it possible to authenticate without remembering, transcribing or manipulating any information. That's a plain language description from accessibility professional, Allison Ravenhall. Another plain language definition I like comes from Sarah Pulos at Utopia who says, don't make people use their memory, transcribe information that can't be copied or pasted or solve a puzzle to authenticate themselves. Provide an accessible, easy to use, and secure method.
So those are the general principles. I wanted to kind of break it down in that way before we looked at the actual text of the criteria, which can be a little overwhelming when taken as a whole. Let's take a look at the details now though and some examples. So the proposed criterion reads a cognitive function test such as remembering a password or solving a puzzle is not required for any step in an authentication process unless that step provides at least one of the following: alternative, another authentication method that does not rely on a cognitive function test. Mechanism, a mechanism is available to assist the user in completing the cognitive function test. Object recognition, the cognitive function test is to recognize objects. Personal content, the cognitive function test is to identify non-text content the user provided to the website.
There's a couple notes that are included with this success criteria or these success criteria. Note objects to recognize and user provided content may be represented by images, video or audio. And note examples of mechanisms that satisfy this criterion include support for password entry by password managers to reduce memory need and copy and paste to reduce the cognitive burden of every typing. I think the irony is for me sort of parsing this is a cognitive function test, so that's the text.
In other words, the 3.3.8 accessible authentication criterion states that when a cognitive function test is used, at least one other authentication method must be available. That is not a cognitive function test. If there is more than one step in the authentication process, such as with multifactor authentication, all steps need to comply with this success criterion. There should be a path to authentication that does not rely on cognitive function tests, and this is a AA level criterion. Let's break that down a little more.
So the proposed criterion states that we should not require cognitive function tests unless we also offer an alternative, another authentication method that does not rely on the test or a mechanism to assist the user in completing the test. At the AA level, we also have the option of requiring users to recognize objects or identifying non-text content the user provided to the website.
Those are the general principles. So let's look at the details and some examples. The proposed criterion states that when a cognitive function test is used, at least one other authentication method, an alternative authentication method must be available that is not a cognitive function test. So if we can't authenticate by memory and we can't authenticate by transcribing and we can't authenticate by puzzles, how can we authenticate instead?
Well, biometrics are one way. Biometrics are unique physical characteristics such as fingerprints or your iris that can be used for automated recognition. Most mobile phones now have some sort of biometric authentication built in like face ID, touch ID or voice recognition. USB tokens, or another good alternative authentication approach. A USB token is a secure hardware device. It often resembles a flash drive that a user can connect to a computing device to verify their identity. So in that case, we're providing software or hardware as a mechanism to authenticate. Authentication links provide a way for users to authenticate without a password. These are sometimes referred to as magic links because a user gives an application an email address and then clicks the magic link that is sent to their email and voilà they're logged in. So this slide includes a screenshot from Slack's Magic Link workflow. A user has entered their email address and this message directs them to check their inbox for a link that will sign them into the Slack workspace that they are interested in and trying to access.
OAuth could also be used to provide an accessible path. OAuth is an open protocol to allow secure authorization in a method that is simple and standard from web, mobile and desktop applications. It's a system that essentially allows for authentication to be relegated to another party. This means you can use login credentials from one provider to log into systems of another provider. For example, you can use Google or Apple login information to identify yourself and again, on your smartphone. Say you want to visit a site like eBay. Because this website allows financial transactions, the owners want you to create an account. You can make an account on their system, but this forces you to provide your billing information, remember yet another password and other such annoyances. Instead, you can log on using your Google account. And when prompted to authenticate, you input your credentials in a popup from a server owned by Google, not eBay.
Google sends you an OAuth token, a cookie that contains an encrypted message, essentially saying that Google is sure you are who you say you are. The popup then closes and the eBay website collects the token, checks it and provides access. At the same time through a separate channel, Google provides access to your billing information provided that you opted into that. This slide includes a screenshot of the eBay sign in page. There are options for logging in with Facebook, Google, and Apple and I have been seeing instances of this all over the web, only increasing. I think just today I was prompted to log into the New York Times website with either Facebook or email or Google or several other options. So this is becoming very common.
One of the best approaches is providing multiple ways for people to authenticate. Duo, which is a service used for multifactor authentication or providing multiple layers of account security. Duo allows users to verify their identity in a number of different ways, SMS or text, a voice call, a one-time passcode, the Duo mobile smartphone app or a hardware token. This slide includes a screenshot of the Duo interface. It shows that there are multiple authentication methods from which a user can choose. Send me a push, call me and enter a passcode. To conform with this success criteria. If we require a cognitive task, we must provide support for or not block the use of mechanisms that can assist the user in completing the task. So examples of mechanisms that satisfy this criteria include support for password entry by password managers to reduce memory need and support for copy and paste. To reduce the cognitive burden of retyping.
Websites can employ username or email and password inputs as an authentication method if they allow browsers and third party password managers to fill in those fields automatically. I'll say that again, you can still use per the draft, you can still use username and password as an authentication method. Provided you do not block a password manager or browser's ability to fill in the fields automatically. Copy and paste can also be relied on to avoid transcriptions, users can copy and paste their login credentials from a local source like a standalone third party password manager or a document, although that's not quite so secure. Users can copy those credentials and paste them into the username and password fields on a website.
If they're able to do that. It's not a cognitive function test, but if they can't copy and paste or if you ask them to use a different format between the copied text and what is entered, for example, enter the third, fourth, fifth, and sixth number of your phone number that would force the user to transcribe information and therefore fail this criterion unless another method is available. There's another path to navigation we can use if we require a cognitive test. At the AA level, we can require an authentication task, which is based on recognizing generic objects. So if you think this sounds like a captcha, you are not alone. And there has been a lot of discussion around this in accessibility circles. Captcha stands for completely automated public touring tests to tell computers and humans apart. So it's an approach to distinguish humans from robots. Human users of websites from robots.
And the traditional capture approach asks users to identify obscured texts in an image. But other approaches have developed over the years like audio capture, logic puzzles, visual comparison based on identification of images. The example on this slide is Google's second generation recaption recaptcha, which verifies if an interaction is legitimate with the I am not a robot checkbox and invisible recaptcha badge challenges. Here the user is prompted to select all images with traffic lights. So at this time the draft criteria read as if they support the use of captcha, but the understanding and techniques documents the ones that explain the intent of each criteria or at least the understandings document at this point reads a little different. I'm reading from it now.
If a capture is used as part of an authentication process, there must be a method that is not used a cognitive function test unless it meets the exception. If the test is based on something the website has set, such as remembering or transcribing a word or recognizing a picture the website provided, that would be a cognitive function test. Recognizing objects or a picture the user has provided is a cognitive function test. However, it is exerted at the AA level. Some forms of object recognition may require an understanding of a particular culture. For example, taxis can appear differently in different locales. This is an issue for many people, including people with disabilities, but is not considered an accessibility specific issue. So while this may continue to evolve as WCAG 2.2 is finalized, what we know for sure is that captcha is inaccessible to many people and we should strive to avoid it.
At the AA level, it is also acceptable to provide a test where you ask the user to identify an image, an audio file, or a video file that they themselves have provided in the past. This one's kind of interesting. You could, for example, pop up five profile pictures and ask them to pick their own picture to verify that it is in fact them that's trying to log in. That one doesn't seem super secure. Other people would know what I look like and be able to select that picture. But what if they popped up five pictures of pets, five pictures of dogs and cats, and you're asked to identify the picture of your dog or cat that you have uploaded. This is considered an acceptable way of using personal content.
Note that the content must not be text. So having to type an answer to security questions like what's your pet's name? What street did you grow up on? What's your mother's maiden name? Those would be considered a cognitive function test and would still need some alternative.
So that's 3.3.8 accessible authentication, which in plain language may be summarized as don't make people use their memory, transcribe or solve puzzles to identify themselves. If you do, be sure to provide another way to authenticate that doesn't require these tasks. And don't block copy and paste functionality or password managers. At the AA level, you may also ask users to authenticate by recognizing objects for identifying their own personal content.
The 3.3.9 accessible authentication, no exception criteria is the same as 3.3.8 accessible authentication, but without the exceptions for objects and user provided content. In other words, to achieve conformance at the AAA level, you must provide a path to authentication that is not a cognitive function test. And that path cannot rely on recognizing objects or pictures or identifying content that the user has provided to the website.
Who does this benefit or what's the point? The primary benefit of the proposed accessible authentication criteria is that people won't have to rely on their cognitive abilities to authenticate themselves. And this benefits everyone. Have you ever forgotten your password? Then this benefits you. This benefits everyone, but especially people with cognitive issues relating to memory,, reading like dyslexia, numbers, like dyscalculia, or perception processing limitations and introducing the 3.3 guideline. I mentioned that there are those who need more help or more time typing, writing and clicking, or that are more likely to make mistakes typing, writing or clicking. Having multiple accessible paths to authentication benefits these users too. The primary benefit of the proposed accessible authentication criteria is that again, people will not have to rely on their own cognitive abilities in order to identify themselves. Having multiple accessible paths to authentication benefits all users, however.
Indeed, like we often say about digital accessibility, accessibility is vital for some and good for all. And accessible authentication is a excellent example of how when guidelines are followed to ensure accessibility, we end up ensuring the web is more open and usable for everyone.
So before I turn things back over to Jay for questions or wrap up, I'd like to direct you towards some resources. The best source for keeping up with WCAG 2.2 developments and for resources to help you understand and apply the new guidelines is the W3C web accessibility initiative. On the W3C WAI website, you can find the WCAG 2.2 draft, our resource titled What's New and WCAG 2.2 draft that explains the proposed success criteria with examples that drew on it heavily last month and in today's presentation, you can also find WCAG 2.2 supporting documents like quick references, guides and techniques for understanding and meeting WCAG 2.2 in other technical and educational resources. There was a question about what's the hold up or an update on the timing of when the draft will move to the next phase. The a way to stay apprised of that would be by just subscribing to the W3C mailing list. There's a mailing list that is for reports, the work of this working group charged with writing the recommendations or the guidelines as well as several others related to digital accessibility. So up to the minute updates, that's what I would recommend.
Jay McKay: Okay, we do have a couple questions here. We had some good chat, getting some nice links to where people can find the updates for, just to confirm, WCAG 2.2 is in the candidate recommendation phase. Where was the, there we go. So here's a weedy question for you. I like that it specified it was weedy. Would blocking a user from using a password manager include design issues where, say for example, a show password icon often inside the right side of the input field is displayed in the same place as the password manager's icon to trigger field completion, visually two icons sitting on top of each other equals their inability to select either. So how do we feel about password managers-
Melissa Green: I have this problem as a last user actually, where those icons end up overlapping and I have difficulty selecting the appropriate one. I don't know at this point that that would be considered a failure of these particular success criteria. I think that they would probably fail more for the proposed target size or focus criteria, which we'll get into in more detail. Those things have to do with sort of how big something has to be for someone to be able to tap it with their finger and click it with their mouse and how much padding is available.
So to me, I think that it would probably be more likely to fall under those, although I suppose that if it prevented someone from authenticating altogether and there was no other alternate method than it would be a failure for this criterion as well. There is in the understanding document some thoughts from the working group about what to show in fields where usernames and passwords are entered. For example, typing indicators and asterisks and things like that. So I'll point you toward the understanding document and the what's new in WCAG 2.2 to hear all you want to know about the working group's thoughts on that particular issue. Great question.
Jay McKay: Let's see. We had a really nice comment that was talking about when we're looking at those recognizing objects for an image, how can be difficult for sighted users and people for cognitive disabilities. And that's why really having the text or sound alternatives are really important. So that was a good point brought up by Jonathan. We had another one, Bruce had said, could you please clarify 3.3.8? It sounds like you would need it with just a username password if you don't prevent them from copy pasting their credentials or using a password manager. So we just need a little bit of clarification on that one.
Melissa Green: Okay, so this is another thing where there's been some discussion of interpretation of the proposed guideline and the understanding document, but my take is that you can use a username and password provided you provide support for those other mechanisms, copy, paste, or password manager or browser bill.
Jay McKay: Okay. Any other questions everyone? Okay, well let's go ahead and go on to our next slides. If you still have questions, please, please feel free to jump those in while I-
Melissa Green: Sorry,
Jay McKay: No, that's okay. Oh, we didn't upload the new, you didn't have my new slides in there, so I will put those in the chat here. So we have one second. There we go. Let me just put this in the chat here. Oh, we do have it. Okay, perfect. So as we are going through these last couple slides, if you still have questions, please feel free to just type in the chat, raise your hand and we'll jump to you. Absolutely. So we do of course, love your feedback. It really does help us plan, know what's of value to you, how to really make these more beneficial for you. Because as much as we love doing them, really we do them with the intent of making this more helpful for you.
So the feedback survey is just a bitly link. It is bit.ly/JanSurveyBADA. So it'll be at capital J, capital S for survey. And then of course BADA is all capitalized B-A-D-A. All right. And then we're going to go on to our next session, which is our February, oh my gosh, it's already coming up to February. And we will be doing a further deeper exploration into WCAG 2.2. And this time we will be talking about the infamous 2.2 11. I know that's one of those where a lot of people have questions about it. We don't know if it's at risk, so we're not exactly sure what it all looks like, but we will definitely dig into it a little bit more. Hopefully we'll have some more updates and information on that as well. So please join us in February to get the registration link, you just need to go to Knowbility.org/DigitalAlly with the capital D, capital A.
Actually, I think it'll work if you don't capitalize those with our website as well. You will find the registration button as well as the video for tonight's session. We will have that link there under the previous sessions. So definitely, definitely go and visit that page. And then of course, we want to remind you that AccessU is happening. We're really excited. Please go ahead and check it out. It is Knowbility.org/AccessU. Our pre-sale tickets, these are the cheapest of the year. They do not go any lower, I promise. They will stop being as cheap as they are on Monday, January 23rd. So please, please get your tickets now. This is our four day. If you go to the pre-conference, it will be from May 9th through the 12th. This is such a great way for you to do some deep diving, hands-on learning, collaborating with your peers, networking.
We will be onsite in Austin at St. Edwards, but we will also be providing our virtual attendees as much of an experience and access to the sessions as our onsite attendees. So we do not say only certain sessions for virtual attendees, we open those up as much as possible. So please, please do not delay. Get your tickets now. Prices will go up significantly after January 23rd. But also, I know we've had some great contributions in the chat and I hope to see call for proposals from you or proposal submissions. So you'll find more information on that in that website as well. So please join us. Have an ice cream with me in Austin, I'll be down there. So it'll be good time. All right, so let's wrap it up. Let's call it a night if we don't have any other questions. So please join us again for February. Thank you very much. And don't forget, of course, you can always help us out at Knowbility.org/donate. Thanks everyone.