Jay McKay:
There we go. Hi, everyone. Welcome. It is another time for our Be a Digital Ally. Today, we are talking about WCAG 2.2. I love our title, What's new in WCAG 2.2. Excuse me. We do have slides for you, I'm going to put those back in the chat. If you have any issues accessing that format, please let us know and we'll make sure that we get you a more accessible format, but that one should be good to go. All right, let's do some introductions. So I am Jay McKay. I'm the director of Community Programs. I am a white female in her early 40s. I have my fun little polka dot festive top today, and I have my big old headset on, and I will take it over to Melissa.
Melissa Green:
Hi, good evening. My name is Melissa Green. I'm a digital accessibility specialist, a member of Knowbility's Accessibility Services team. Joining you this evening from Tuscaloosa, Alabama. I'm a middle-aged white female with red hair and freckles. I have on a large headset as well. And while she's not able to join us this evening, I did want to acknowledge and celebrate my boss, Julie Romanowski, who also contributed to the development of this presentation and will be leading some of our deeper dives into WCAG 2.2.
Jay:
Excellent. All right. So next, we want to go into our agenda. For those of you who are familiar with our BADA series, you already know what's coming next. But for those that are new, we always like to give everybody a heads-up and know what to expect. So our agenda this evening, we will do just a quick overview of what Be a Digital Ally is. That's going to include, of course our welcome, we already did that part, hooray, welcome, some introductions and then just talk a little bit about what we mean by the term accessibility. And then we will dive into our topic for this month, which is WCAG 2.2, so what is that, maybe you've heard that term, you're not sure exactly what that means, what does 2.2 mean, and then start to identify some of those changes and what that's going to do and the impact developers and designers.
So next, we're going to talk about housekeeping. So first, thank you. Thank you for letting us be a part of your journey. We are always honored and humbled to have so many of you join us. We always appreciate the emails and the feedback. We know that diving into this world of accessibility can be scary, especially if it's something you're not familiar with, and so we do appreciate for letting us be a part of that. If you do have questions and we know you do and we appreciate them, it's one of our favorite things about doing this is all the chatter and questions and discussion. We do ask that you go ahead and type questions in the chat, feel free to do that. As the presentation is going on, I will be in the chat, Julieanne will be in the chat so we can address things as we go.But of course at the end, we will take some time for you to jump on the mic too if you have additional questions.
Just a heads-up about accessibility features, we will always have auto captions enabled. However, if you require some additional accessibility services such as American Sign Language, things like that, when you register for the next session in Humanitec, we ask you to indicate that, but we also need you to indicate that, give us in about three or four days advanced just to make sure that we can get those services in place for you. And lastly, of course, please feel free to ask for help throughout the session. We are here to make this enjoyable. We want to remove as many barriers as possible.
All right. So just a quick introduction, if you don't know Knowbility, we are a nonprofit organization that was founded in 1999. We're based out of Austin, but really we do operate globally. Melissa and I are both actually located in Alabama, actually in two different cities in Alabama. Julieanne, of course, is joining us from Austin, and then we have staff coast to coast. So we're really all over the place. It's great. And our mission is to create an inclusive digital world for people with disabilities. And we really do that through our services and our community programs, which we're going to talk about next. So our community programs include several things such as AIR, which is our Accessibility Internet Rally. This is a annual web competition designed to help developers and designers practice accessible design in a real-world environment by creating or redesigning a website for a nonprofit organization and getting to work with experts and really go through that process.
Then we have AccessU, which is our annual tech conference that is coming up. We'll have more info later on that. And then our K12 Digital Accessibility programs, that's including our Toolkit Tuesday, our ATSTAR, which is our more in-depth AT Consideration Process, procedure, modules. And then lastly, Be a Digital Ally, which is what you're here today for. So with that, I do encourage you if you have an opportunity to please go to knowbility.org/donate. All of these programs are really funded through you, through our sponsors, our supporters. So every little bit helps. If you're one of those people that likes to do $5 a month, we love that. If you're like me and you're that end of the year spender, we love that too. So if you have the opportunity, we do encourage you to do that.
And next, we'll talk about what we're here about today, so this definition of accessibility. And we want to be mindful when we talk about this term, sometimes when people use the word accessible, they're just thinking about, oh, it's open, it's available, I can see it, or it's available to the public, it must be accessible. And we really want to be mindful about that, especially when we're talking about digital design and web accessibility. So today, when we're talking and discussing WCAG and going through this journey for something to be accessible, that means that people with disabilities must be able to access and utilize it as fully and as independently as someone who does not have a disability. And what we mean by that is can they hear, can they see the content? Is it only audio? Is it only visual? Are there other options for them to get that content?
Do they know where to go? What to do when they get to that webpage, or what to expect when they hit a button? Can they independently navigate using preferred tools? So if you're somebody who cannot use a standard mouse, can you just use your keyboard? Can you use your voice? Can you use voice commands, instead? Can you independently complete tasks and explore all the areas? Sometimes people will design something and the majority of it is "accessible", but maybe not all of it is. So we really want to make sure that's happening because ultimately you want everyone to be able to fully participate in an authentic manner. So if I'm somebody that's on your website and I want to register for an event, or I want to sign up to volunteer, or I want to give feedback on a project or a program, I want to make sure that I'm able to do that to the fullest extent possible and that not feeling short-changed in that process.
All right. And why is it important for us to make sure that things are accessible in this idea of inclusive design? Well, 15% of the world's population lives with some form of a disability, and this number is coming to us from the World Health Organization. And something to remember about that number is that's the number that the World Health Organization has given. And they say this many people are colorblind, this many people have hearing impairments, etc. But there are many people out in the world who may not consider themselves disabled, even though they may be colorblind, they may have a hearing impairment or something else that the World Health Organization is labeling that as a disability. So that means that those people may not necessarily voice opinions or concerns or let their needs be known as vocally as someone else. But then also, why it's important to think about inclusive design and accessibility is really so many other people without disabilities are also benefiting from accessibility and accessible design.
Think about curb cuts, think about close captions. I know every time I stream anything on my Netflix or my Hulu or whatever, I'm looking for close captions and I'm looking for audio descriptions, and that's just because I find it's easier for me to consume that content even though I don't necessarily have a disability that would require the use of those.
All right. Also, when we talk about accessibility, when we talk about accessible design, we need to talk about assistive technology. And so this, again, is a definition from the World Health Organization, and I'm really just going to read this very, very last sentence. And it says, "The primary purpose of assistive products is to maintain or improve an individual's functioning and independence, thereby promoting their well-being." So that is the purpose of assistive technology. So that way people can interact, again, in that full authentic self.
So when we're talking about assistive technology, what is that? What are some examples? And so, assistive technology, you may hear the term AT is any product, equipment, software or system used by people with disabilities to increase, maintain, or improve their functional capabilities. And again, when we say anything, it could be just off-the-shelf at your local Target if you like a certain type of mouse or a certain type of keyboard, or it could be something that is very custom made like a wheelchair. So it spans the range. So these are just a few examples that we, in web design, really are always top of mind. So screen readers, so if somebody is visually impaired, this is a way for them to navigate a computer screen. It will let them know what's on the screen, where they are on that screen.
Refreshable braille display, again, if somebody is a braille user, it will take that text that's on the screen and put it into a device that is essentially raising those dots and then changing as the text changes. Alternative navigation methods, things like keyboard only access, switch use, voice commands. So it's funny, whenever I would tell people, "Well, can you use a mouse and keyboard?" And they say, "No." Or I'd say, "If somebody can't use a mouse and keyboard, will they still be able to access?" And they said, "Oh, well, yeah, they can use a touchscreen." Well, that might not be an option for somebody either, so you need to have all those different methods considered. Closed captions, we already mentioned transcripts, magnification, to be able to enlarge text as needed, dark mode/high contrast, I know several people that having that ability to turn dark mode on or have that in the design makes doing their work much easier.
And now we've also provided just a link to WebAIM, which has some great examples, some pictures, some videos, a little bit more in-depth about how each of those technologies work, so we encourage you to check those out later.
All right, my favorite part, it's time to start our journey. We always, always like this quote because it just reminds us that accessibility is a moving target. You start where you start and then you move forward and you take the next step. So this quote comes from Maya Angelou and it says, "Do the best you can until you know better. Then when you know better, you do better." So this is just a reminder to us all. We're all learning, it's something's new to somebody, so don't feel like you're so far behind the eight ball, it's not worth it. So welcome, welcome and let's begin.
So we're going to talk about WCAG or the WCAG. We'll go on to the next slide here. So, what exactly are the Web Content Accessibility Guidelines? What do we mean by this term? So this is an international standard and it's really a series of documents that help explain how to make web content more accessible to people with disabilities. They include four principle areas that include perceivable, operable, understandable, and robust. So you may have heard something called POUR or designing with POUR, P.O.U.R. And also I want you to think back to our introduction of accessibility at the beginning of this session. So when you look at that, our definition is really built from those principles. So is it perceivable? Can you hear and see all the content operable? Can I navigate? Can I use my tools? Understandable, do I know where to go? Do I know what to expect? Robust, can I use all of my tools?So that's just very brief cursory explanation of that, but that's really what we're talking about in that accessibility definition.
They also provide testable success criteria where conformance testing are necessary. So it's detailing to know when an item meets that standard. So when they have all these standards, they're also providing that information to know when it meets that standard, as well as sufficient and advisory techniques that go beyond what is required and allowing those authors to better address the guidelines and usability. So it's really just very robust in providing them as much information to provide the most accessible web content possible.
So this next quote, I really like. I found this from the Bureau of Internet Accessibility, and I think it really does summarize nicely what the WCAG does. And it says, "The WCAG offers an actionable framework for creating and remediating websites and apps to be accessible. It is not abstract, but specific and technical. It is supported by documentation that identifies the methods and the techniques that would be considered to pass or fail the minimum accessibility expectations of each checkpoint." So, like I said, it's not just here's your checkpoints, it's really all of that additional information to make sure that the designer, the developer, understands how to meet those expectations. So if you're like me, I do recommend checking out that website. It had just a really nice brief, cursory, concise timeline of the creation of the WCAG, and those are one of those little things that I like to look up. So check that out.
So now that we have at least a good overview, very high level understanding of what these guidelines are, now let's talk about how they're used. Okay. They are an industry standard. This is something that companies and organizations can require of their developers and vendors to meet. So they can say, we want a particular website and it needs to meet 2.1 AA or AAA. So we have A, AA or AAA standards. For us at Knowbility, whenever we first encounter a new vendor or potential vendor and we're looking at their products, we always ask for that accessibility conformance report. So we get a snapshot of how accessible their product is, and so that way, they can tell us where they fall in terms of those standards. It is referenced in international laws, we mentioned it earlier that this is an international standard. And for example, in the US under Section 508, the requirements for 508 currently reference WCAG 2.0 AA levels. That's Section 508.
However, you are seeing more and more companies and organizations that are using the most recent guidelines. So they're using 2.1 or some of them are actually now looking at 2.2 as well. And then also, something to note, so even though 2.0 AA, Section 508, something to be aware of is the new proposed legislation, which is Websites and Software Applications Accessibility Act. And we did link that to you, so if you want a little bit more in there. It is going to be introducing some new requirements of WCAG 2.2, even though it may not say that word or that phrase, but you will see those new items from 2.2 being included in that proposed legislation. So if that goes through, we're going to see a lot of the stuff from 2.2 in there as well.
And then ultimately, when you are meeting those expectations for 2.2, you really are following usage trends and allowing even more users to access your site. So it's really that idea of looking at those different levels, the more A's got on there, the higher your numbers, the more people that are going to be able to utilize your site.
Okay. So, I've been talking about different versions of WCAG, so let's talk about how WCAG was developed and just very briefly go into its process. I don't have enough time to really dive into the development and who's all a part of it, but I want to give you at least some highlights. So these guidelines are developed by the World Wide Web Consortium, you may have heard them as W3C and it's member organizations. And so, what they do is when they're developing these guidelines, they have what is called the W3C process, and that's on the screen here. So the first step of that process is what they call a working draft, and this is where there are several working drafts out for the community to provide input on. The second phase is the wide review working draft. So that means the working group from the W3C has addressed all the comments and all of the different drafts, and instead of having several drafts out there, they have combined condensed and made one draft that is now available for wide community review.
So the next phase is the candidate recommendation, and this is actually where 2.2 currently is. So I put a little arrow right across next to it, so this is where 2.2 is, and I like to think of it as the testing phase. So that means that a world that wide review document went out, working group made adjustments again off the feedback. And so now they have this document for developers to use that technical report for their projects. So for the most part, that candidate recommendation document is pretty stable. They're not expecting huge changes out of it, but you may see some changes based off of the experiences that developers are currently having using that current version. After the candidate recommendation phases over, that means that the W3C will announce that it will make a proposed recommendation, so that means any adjustments that they've had to make based off of that developer feedback, this will be the phase where it is submitted to the members for endorsement.
So that means if we think we finished it, take a peek at it, let us know if you like it. And then the members will then say whether or not they support it, it's ready to go out into the world. And once that has been determined, it then becomes W3C recommendation or a web standard.
So again, just a very cursory top down overview of it, but what I wanted to really highlight is there are a lot of people, a lot of moving parts, it's just a significant amount of community input and testing and iterations that go into these guidelines, so they are just very, very thorough.
Melissa:
All right. I think that's my turn right, Jay? All right, thank you so much, Jay. And I'll say that I will probably interchange the use of WCAG, WCAG-EM and WCAG several times. The standards are referred to interchangeably in those ways, so I will probably refer to them several different ways. But while WCAG 2.2 is not yet an official recommendation, the latest published version and the W3C web accessibility initiatives, what's new in WCAG 2.2 draft, give us an idea of what to expect. So as Jay mentioned, each WCAG guideline has success criteria or testable statements that are not technology specific. The success criteria determine conformance to WCAG. In other words, to meet the 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 broadest possible audience.
We anticipate nine new success criteria in WCAG 2.2. The proposed new success criteria are focused on making web content more operable and understandable, and these changes will be particularly beneficial for users with visual, mobility and cognitive disabilities. We'll look at them in more detail in a moment. Additionally, the 2.4.7 Focus Visible criterion, which was at the AA level and WCAG 2.1 has been promoted to a level A criteria in WCAG 2.2. We'll also discuss that change in more detail momentarily. WCAG 2.2 includes all success criteria from WCAG 2.0 and WCAG 2.1 with no changes to the existing criteria with the exception of that 2.4.7 Focus Visible level change. WCAG 2.2 builds on 2.1 and they're backward compatible. So webpages that conform to 2.2 also conform to 2.1 and should also conform to 2.0. The W3C tells us, in other words, that we can update our content to 2.2 now without breaking conformance with those previous versions.
Three of the proposed criteria along with the criterion with a reassigned priority level are intended to address navigability. Navigable websites provide ways to help users navigate, find content, determine where they are, specifically these particular criteria address focus, which is an important aspect of navigability. Keyboard users typically navigate their way through websites by pressing the tab key. This allows them to jump from one interactive element on the page to another. Just like mouse users, keyboard users need to be able to know where they are on a page as they tab their way through it, otherwise they won't be able to identify the elements they're interacting with, and that's what focus indicators are for. Focus indicators are pixels that are changed to visually indicate when a user interface component is in a focused state. So this slide includes some examples of focus indicators from the W3C way or WAI, Web Accessibility Initiative, documentation and Knowbility's own website.
In the first example, a solid focus rectangle and closes the second of two buttons. In the second example, a solidly bound focus rectangle enclose the third of five stars. And the third example, a focus indicator is shown around a tablet. The last two examples are from the Knowbility website, and one, a solid focus rectangle surrounds an image linking to the Knowbility website. And then the other, a solid focus rectangle indicates that a link with the text accessibility testing and auditing is in focus. So these success criteria related to focus, again, are most beneficial to keyboard users. And keyboard users may be cited people with mobility impairments who use a keyboard or device that emulates or copies the functionality of a keyboard interface like a switch or voice input. Visible focus also benefits users with low vision who use the keyboard as well as people with cognitive disabilities, especially attention and memory limitations or limitations in executive processes.These are users that all benefit from being able to clearly identify and discover where the focus is located.
So these success criteria provide us with some guidance in accomplishing this. 2.4.7 Focus Visible level AA and WCAG 2.1 has been promoted to a level A criterion and WCAG 2.2. This means that to achieve the minimum level of conformance, any keyboard operable, user interfaced must have a mode of operation where the keyboard focus indicator is visible. So, in other words, where humans and computers interact using a keyboard, there has to be a visual indicator showing when a component is in a focus state or visually indicating the component on which the keyboard operations will interact. So those who currently use the Web Content Accessibility Guidelines are already familiar with this criterion and the techniques for achieving it, most likely. Really the big difference here is the conformance level, and I'm seeing the comment in the chat, I can't believe this wasn't A to begin yet with.
Yeah, this is the big change in this update. Previously, this was only a requirement for those seeking to conform at the AA level. Now, this criterion must be met to achieve the minimum level of conformance. The first new success criterion 2.4.11 also addresses focus and navigability and is a AA level criterion. So a keyboard focus indicator can take different forms. This success criteria list two primary ways to achieve a sufficient focus appearance. The first involves three primary considerations for the entire focus indicator. The entire focus indicator should enclose the user interface component or sub-component that is focused, have a contrast ratio of at least three to one between the same pixels in the focused and unfocused states, and have a contrast ratio of at least three to one against adjacent non-focused indicator colors. So breaking this down a little bit, a user interface component is part of the content that the users will perceive as a control for a function.
So examples of user interface components are things like input controls, check boxes, radio buttons, dropdowns, lists, list boxes, buttons, toggles, text fields, date fields, as well as form elements and leaks. So something that the user is intended to interact with. The example on this slide demonstrates sufficient focus appearance. So the same component labeled example appears twice, first, in unfocused, then in a focused state. The focus indicator enclose the entire component that is focused has a 3:1 contrast ratio between pixels in focused and unfocused states, and has a contrast ratio of at least 3:1 against adjacent colors. And when I say contrast ratio, I'm referring to color contrast, the contrast of the colors used for the foreground and the background.
So the first wave provides guidance for the appearance of the entire focus indicator. A second way of achieving sufficient focus appearance is by meeting similar considerations for one area of the focus indicator. That area must be at least as large as the area of a one CSS pixel thick perimeter of the unfocused component or sub-component, or at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component. Also, have a contrast ratio of at least 3:1 between the same pixels in unfocused and focused states and have a contrast ratio of at least 3:1 against adjacent non-focused indicator colors, or is no thinner than 2 CSS pixels.
So this slide depicts examples of focus indicators that meet these requirements. So in the first, focus is indicated by an inner outline that is slightly smaller than the outer edge of the component. In the second, focused is indicated by a yellow underline almost as long as the longest edge. So a few notes about this one before we move on to the other criteria. One, there are some exceptions noted in the documentation. Two, this criterion is currently labeled as at risk in the WCAG 2.2 draft. The editors note that it is at risk due to concerns around implementation and testing. I'll read their note, it states, "There is a need for greater information about this, which is expected to be collected during implementation testing in the candidate resolution review period. If testing does not document sufficient implementation of a given feature, it could be removed from the final specification." What I would encourage you to do now is just keep in mind at a high level that WCAG 2.2 may introduce a new success criteria that aims to ensure keyboard focus indicators are clearly visible and discernible.
The next proposed AA success criterion is also intended to address navigability and focus. 2.4.12 Focus Not Obscured (Minimum). Reads, "When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content." The first cited people who use a keyboard or a keyboard like device, like a switch or voice input, knowing the current point of focus is very important. However, when progressing through a page, other content could potentially hide this focused element, and this success criterion ensures that the item receiving focus, the one that the keyboard or the keyboard emulator is going to act on, is not hidden by other content created by the author.
This slide includes an example of a webpage that is part of a step by step navigation titled Learn to drive a car: step by step. It appears on the GOV.UK family of websites. This page has a navigation header positioned right at the top of the page so that users can see it immediately and understand that the page is part of a wider process. It also provides a link back to the main step by step navigation page. And in this particular example, a technique known as a sticky header has been used to provide this navigation header. When the Focus Not Obscured success criterion is met, the sticky header won't cover up focused items and their focus indicators. So keyboard users can visually determine that component on which they will act. In this example, the content seems okay when access on a desktop, that's what's demonstrated in a screenshot on the left side of the slide.
In testing, it would be important to determine whether any focused items are covered up when, say, scrolling on a mobile device, which is what is depicted in the screenshot on the right side of the slide. As a visual user, I am able to determine that there is a link that probably should be in focus that is being cut off by that sticky nav. So, again, in order to successfully achieve this conformance with the success criteria, it's important to use techniques that ensure content is not covered up when navigating the page.
The next new success criterion 2.4.13 Focus Not Obscured (Enhanced) is very closely related. Previously, I spoke of conformance at the AA level. While conformance at the AA level requires that a component not be entirely hidden by web content, conformance at the AAA level requires that no part of the indicator be hidden. So at the AA level, users need to be able to see some of the focus indicator and tell what's in focus. At the AAA level, in order to ensure access to the widest possible audience, it's important that none of that focus indicator is hidden. So two closely related success criteria, but at different conformance levels.
So we've looked at three new and one revised criteria addressing navigation and focus. This proposed criterion addresses input modalities, or making it easier for users to operate web content through various inputs beyond the keyboard. In order for a website to be accessible, all its functionality should be accessible via pointer input devices, a mouse pointer, a finger interacting with a touchscreen, an electronic pencil or stylus, a laser pointer, and so on. This success criterion aims to ensure functionality that uses a dragging movement is compatible with this single pointer mode of operation. So a dragging movement is an operation where the pointer, so if you're mouse user, the mouse, if you are one of the other technology users, a pencil, a stylus, a finger, and so on. A dragging movement is an operation where that pointer engages with an element on the down event, and the element follows the pointer until an up event.
So examples of interfaces or functions that use dragging are sliders and drag and drop interfaces. Some people can't perform dragging movements in a precise manner. Others use a specialized or adapted input device like a head pointer, eye gaze system, speech control, all these things can make dragging cumbersome, challenging, error prone or even impossible. So for this reason, accessible sites must provide a way to operate with one point of contact with the screen, including single taps and clicks, double taps and clicks, long presses and gestures that are based on paths.
So let's get into some examples which may explicate this a little further or explain this a little more clearly. Think about dragging a file stored on your computer's desktop to an online Dropbox folder, for example, or using a slider to adjust start and end times for calendar event. When an interface implements functionality that users dragging movements like these, users typically perform four discrete actions, you tap or click to establish a starting point, press and hold that contact while positioning the pointer. Again, if you're mouse user, moving the mouse, then releasing the pointer at the input. Not all users can accurately press and hold that contact while also repositioning the pointer, so W3C WAI provides some examples of what it looks like when this success criterion is met and sites are accessible to these users.
For example, a map that allows users to drag the view of the map or the ground, also has up, down, left, right buttons to move the view as well, a sortable list of elements that after tapping or clicking on a list element provides controls adjacent to the list for moving that element up and down. A radial control widget, for example, a color wheel where the value can be set by dragging the marker for the currently selected color to another color or allowing users to pick another color value by tapping or clicking on another place on the color wheel.
The 2.5.8 Target Size (Minimum) proposed criterion, also addresses input modalities, making it easier for users to operate through various inputs beyond keyboard. Specifically, it addresses target size. A common requirement for pointer interaction, whether it be via the mouse, a finger, so on, is the ability of the users to position that pointer over the target. With touch and point, the pointer or the finger is larger and less precise than a mouse cursor. For people with motor impairments, a larger target makes it easier to successfully position the pointer, your finger or other technologies, and activate that target.
Having targets with sufficient size and spacing also helps users who may have difficulty in confidently targeting or operating small controls such as people who use a mobile device and a touchscreen as the primary mode of interaction. People using mouse, stylus or touch input to have mobility impairments such as hand tremors, people using a device in environments where they are exposed to shaking like in the car, mouse users who have difficulty with fine motor movements, people who access a device with one hand, people who have large fingers or are operating the device using only a portion of their finger like a knuckle or their thumb. So lots of different scenarios in which larger target sizes are beneficial. The figure on this slide shows four rows of targets illustrating three ways of meeting the proposed success criterion and one way of failing it.
So the proposed criterion reads, "The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where: Spacing: The target offset is at least 24 CSS pixels to every adjacent target. Equivalent: The function can be achieved through a different control on the same page that meets this criterion. Inline: The target is in a sentence or block of text. User agent control: The size of the target and target offset is determined by the user agent and is not modified by the author. Or essential: A particular presentation of the target is essential or is legally required for the information being conveyed.
So obviously these are some pretty technical details. We talked about how WCAG is designed for a technical audience. These details have generated a lot of discussion amongst the accessibility community, particularly around what the ideal minimum target size should be. 24 pixel square, 44 pixel square, 48 pixel square. One way to follow those discussions is by subscribing to relevant W3C email lists. There are a couple where WCAG 2.2 are being discussed. There is the Listserv that public discussion around the activities of the working group and another Listserv that is public discussion, the guidelines in general. So if you're interested in following the nitty-gritty details, I encourage you to seek out those lists and then we are happy to help you track those down.
The next proposed criterion addresses predictability. Making webpages appear and operate in predictable and consistent ways. It is a level A criterion. 3.2.6 Consistent Help insurers users can find help for completing tasks on a website when that help is available. So page authors aren't necessarily required to offer help, but when doing so, these considerations need to be followed. So ensuring users can connect with help is beneficial for a number of reasons. It allows them to complete tasks they wouldn't be able to otherwise. Users may have difficulty locating help that is not part of the page that they're using. Locating that help mechanism in a consistent location allows them to reserve their energy for what they're actually trying to do instead of using that cognitive energy to find support.
The criterion reads, if a webpage contains any of the following help mechanisms, and those mechanisms are repeated on multiple webpages within a set of webpages, they occur in the same relative order to other page content, unless a change is initiated by the user: human contact details, human contact mechanism, self-help option, fully automated contact mechanism. So if your site includes those things, then these guidelines are applicable or this criteria is applicable.
Some examples of web content that meet this criteria, an on-line job application. Some of the application questions may be hard for new job seekers to understand even after reading the contextual help. For example, the form might request their identification number, but they might have several and not know which one to enter. Easily findable contact information will enable them to use phone or email or other accessible communication methods so they can get an answer to their question. Another example is a medical appointment scheduling for. Let's say that the service a patient is trying to book is not easily findable within the interface, they might need human help. A built-in messaging option like a chat client could enable them to quickly interact with the staff person that can help without requiring them to manage a second interface.
All that being said, we need to ensure that that chat client is in fact accessible, a whole other topic. Another scenario, finding a specific policy or procedure. An employee who needs to complete a work task may have difficulty locating that specific policy or procedure document on their employer's website, a How Do I page or FAQ page may include information that enables them to independently complete this task.
The next two proposed criteria address input assistance, which aims to help users avoid mistakes and correct mistakes. Specifically, they aim to ensure there is an accessible, easy to use and secure method to login, access content and undertake tasks. Most websites rely on usernames and passwords for logging in. Remembering a site-specific password is what is known as a cognitive function test. A task that requires the user to remember, manipulate or transcribe information. And such tests or activities can be problematic for many people, including users with cognitive disabilities, whether it's remembering a random string of characters, a pattern gesture to perform on a touch screen, or identifying which images include a particular object, in the case of CAPTCHA type authentication. Cognitive function tests will exclude people.
The 3.3.7 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's more than one step in the authentication process such as multi-factor authentication, all steps should comply with the success criterion. There should be a path to authentication that does not require cognitive function tests, and this is a AA level criterion.
The 3.3.8 Accessible Authentication (No Exception) criteria is the same as 3.3.7 Accessible Authentication, but without the exceptions for objects and user provided content, it does not have these exceptions because it is at a higher conformance level ensuring access to a wider audience. There are many different techniques you can use to meet the success criteria around Accessible Authentication. For example, a website that uses a properly marked up username or email password fields as the login authentication. When the website is implementing these fields in the proper way, the user's browser or a third-party password manager extension, like last pass, key pass, others, can identify the purpose of the inputs and fill in the username and password. Another example is a website that does not block paste functionality. The user is able to then use a third-party password manager to store their credentials, username and password so they can copy them and paste them directly into a login form.
A website that offers the ability to login with a third-party provider using the OAuth method. For example, selecting the option to login with Google or Facebook or SSO provides another alternative or path. Finally, a website that requires two-factor authentication and allows for multiple options for the second factor meets the success criteria. For example, for the second factor, a button on a USB type device or a QR code that can be scanned by an app on a user's device to confirm their identity or a push notification to the user's device prompting them to use their device's authentication method to confirm identity like a PIN or fingerprint or facial recognition. So many techniques which are described in the WCAG documentation.
Now, we've come to our final newly proposed criterion, which also addresses input, assistance or helping users avoid and correct mistakes. The 3.3.9 Redundant Entry level A success criteria intents to ensure that users can successfully navigate multi-step processes. So it reduces cognitive effort when information is asked for more than once during steps in a process. It also reduces the need to recall information provided in a previous step. The criterion reads, information previously entered or provided to the user that is required to be entered again in the same process is either auto-populated or available for the user to select. Except when, reentering the information is essential, the information is required to ensure the security of the content, or previously entered information is no longer valid. So this criterion benefits users with cognitive disabilities who experience short-term working memory difficulty not having to repeatedly remember particular information, reduces stress and the likelihood of mistakes. It also benefits users who experience difficulty forming new memories, recalling information, other functions related to cognition. These users can complete processes without having to unnecessarily rely on their memory.
And finally, it benefits users with mobility impairments, for example, those that use switch control or voice input by reducing the need for text entry. Some examples that meet this criteria, a form that request the user's corporate identification number in the first step of a process. Let me start again. A form that requests the user's corporate identification number (ID) in the first step of a process to purchase a new computer. Let's say in the third step, the user is asked to confirm that the computer will belong to them rather than a colleague and it shows their ID again, it allows the user to change the ID, but it defaults to the one they previously entered, reducing working memory and cognitive load.
Another example is a form on an e-commerce website that allows the user to confirm that the billing and delivery addresses are the same address. You've already entered it once for billing, lets you confirm, use the same address for shipping avoiding redundant entry. Another example is a search results page that pre-fills the search input with the previously entered search term in the same process. So again, as with the other criterion, many different techniques or approaches can be used to achieve conformance.
So briefly, what's next for WCAG and 2.2 and beyond? So as Jay shared, the Web Content Accessibility Guidelines are developed through a process incorporating community input and consensus development. In that W3C process, working groups create specifications and guidelines that undergo multiple rounds of review revision before W3C publishes them as a recommendation. Because the standards are stable and referenceable, they don't change after publication. WCAG 2.0 was published in 2008, followed by WCAG 2.1 in 2018. The accessibility guidelines working group is finalizing the latest version, WCAG 2.2. WCAG 2.2 is at the candidate recommendation stage of the process and we expect it to be finalized in early 2023. Another version of WCAG is also in the works information about and an early draft of the W3C accessibility guidelines. WCAG 3.0 is available on the W3C WAI site. That was previously referred to a Silver, now WCAG 3.0, which I see at least one person in the chat is pretty excited about.
The best source for keeping up with WCAG2.2 developments and for resources to help you understand and apply the new guidelines is the W3C Web Accessibility Initiative. On the W3C website, you can find the WCAG 2.2 draft, a resource titled, What's New in WCAG 2.2 Draft, that explains the proposed success criteria with examples. I drew on that resource heavily for this presentation, so if there's something here that you want to find documentation related to, that's a good place to start. You can also find WCAG 2.2 supporting documents, these are things like quick references, guides, and techniques for understanding and meeting WCAG 2.2. From looking at their current status, these appear to be a mix of 2.1 and 2.2. In other words, W3C WAI is in the process of updating these documents. And finally, linked to a place to find other technical and educational resources.
As I mentioned earlier, you might also want to check out the W3C's mailing list. There's many related to accessibility with much discussion around the guidelines and the work of that working group.
All right, so that's what I have to say about that. I'm going to stop talking at you now and check in with my colleagues in the chat for any questions.
Jay:
All right. We did have a question. Well, question from somebody about, are we going past 4:00? Well, we are at our questions section, so if you have last minute questions that you want to ask, if you need to, of course, go on to other things, we'll see you next time, but this will be recorded. We'll upload it into our YouTube channel as quick as possible so that way you can always reference back. I know a lot of people need to come back to it later. So we are at the end of the presentation phase, so please feel free to jump on the mic, put something in the chat. And then we had a question about looking at these guidelines and things and having those developers.
So, Melissa, I think this is a good kind of a question just overall. So when somebody is having somebody work on a website, having a developer create something for them and utilizing something like the guidelines as something to check, having that third-party come in to look at it, like that's a tool essentially they would be using for those guidelines. And then that's a way too, when you're hiring that developer to say, these are my expectations, and then I'm also going to make sure that these are getting verified by another party to make sure that they're being met.
Melissa:
I agree with that and with Julieanne's comments along the same lines, that the most important thing to point the designer, developer to are the guidelines because they might be able to use various techniques to achieve conformance with the guidelines. However, I think I would want to know if I were doing work, if my client planned to contract with a third-party to review my work, I would want to know. I think that would be a matter of professional courtesy and it would open up an opportunity maybe for you to have a conversation with your developer as well as the company doing the auditing or testing, which I would hope would be Knowbility.
Jay:
We would love too, yes.
Melissa:
We do do that and we work with clients and if they have contracted with another party to do the work, we're happy to meet with all parties involved.
Jay:
And then somebody just wanted some clarification if we have an updated date, if we're hearing anything about when 2.2 will likely be at that recommended phase.
Melissa:
All I've seen in official documentation is early 2023. I know in informal conversation prepping for this webinar, a colleague who's been a little more involved with the process said that she does not expect it in very early 2023. So I wish I could give more guidance than that, but I haven't even seen a month associated with it at this point.
Jay:
Yeah. And I think somebody in chat mentioned it, it might be closer to summer, so it might be the first half of 2023, but it's probably not going to be January.
Melissa:
General consensus of folks involved in the process is that that's optimistic.
Jay:
Excellent.
Melissa:
Great question.
Jay:
All right. Well, while we wait for some additional questions, let me go ahead and put our survey in the chat for everyone. And please, please, just because we're at this part of the section, please don't feel like you need to run away. We are still taking questions, please go ahead and do that. If you want to go ahead and share the slides some more for me, Melissa.
Melissa:
I've brought up an old version that did not have the URL [inaudible 01:02:11]
Jay:
Oh, got you. Not a problem. So that's just our quick little short survey. We always appreciate it. It helps us design our next coming sessions. And speaking of our next coming session, we are going to continue this exploration of 2.2 in our next BADA in January. So that will be January 19th and, we're calling it the Further Exploration. What's really going to be fun with this one, Melissa and I were having a great time planning this one out. We wanted to really dive into some more specifics on some of these success criteria. And as part of your registration, you will notice there is a question or two that we want your input because we have our favorite ones we want to dig into, but we want this to be useful for you. So while we've got something in our back pocket ready to present, if you really want to go over 3.4 instead of 2.7, let us know. We want to make sure that we provide what's most needed for our audience.
So a little audience interaction engagement for you built into your registration form. So please check out, that takes you to our website. There is a registration button there for the January session. Oh, we're getting an error. Okay, let me check that. In just a second, we'll make sure that gets up there correctly.
And then lastly of course is AccessU presale tickets are on sale now. They do not get any cheaper, so we do recommend that you check those out. So this is our annual web accessibility conference, it will happen in May. If you're in Austin, if you want to come and hang out with us in Austin, we will be at St. Edwards University. If you are unable to travel, you can join us virtually as well. But those presale tickets are on sale now until January 23rd. And our call for proposals, I know that there's so much knowledge in this group, the back and forth and the discourse that we've had with our different sessions, we would love for you to propose session for AccessU and be one of our instructors. So please check that out on those pages. And I'm going to stop shilling for a second because we have a good question here. It says, what are your favorite tools for performing accessibility assessments? And it looks like Melissa has already put one of our blogs in there.
Melissa:
I was just going to throw out, that's a recent blog that we published in advance of a BADA session on the topic. One of the links included in it, it's to a W3C resource that lists dozens and dozens of tools. But I'm the author of that posted, those happen to be Melissa's face.
Jay:
All right. Okay, good. We got the digital ally one fixed there too. Great.
Julieanne King:
Melissa, did you include Andy?
Melissa:
We did, yes.
Julieanne:
Okay, good. I love that one. That's one of my favorites.
Melissa:
Yeah, do you want to tell them about it?
Julieanne:
It was developed by the Social Security Administration. It's our really neat little tool. It's like a bookmark what that you drop in. I'm sorry, I'm really raging headache right now. It has some different things where you can go through and check different stuff. It will show you the language that's used for the alternative text, which I like because a lot of the other ones don't necessarily show you what that text is. I do like that. But you can check for the language of the page. So if you have a page that has multiple languages on it, it will tell you what the language is for that page, or if you're doing a dual language website. Then if you're looking at the French page, it should say French. And if it's English, it's say English and things like that.
But it lets you check a whole bunch of different things in a really nice little way. And I think there's even a way where it's like, where's the focus indicator, where are the links, and it'll show you a pink line going down the page and as you scroll, they'll have a sticky piece across the top and as you scroll down, that pink line will keep going and keep going. Or it's pink on mine, let's put it that way. I don't know what it is on there. My cursor is pink so that's why it's probably pink. But until you get to that next item that is of focus or actionable. So I just found it really, really handy when I was introduced to it to judge AIR competitions for the Accessibility Internet Rally. So I helped judge a couple of the sites and that was one tool that was presented to me several years ago that I found really, really useful and really helpful.
Jay:
We have an interesting question here. How important is download speed of a website to a user who has poor web connections? Is download speed even a considered an accessibility? And how does one rate such a thing? Do we have any input on that?
Melissa:
Let's start Julieanne talk.
Julieanne:
So I competed in AIR back in 2019 and we built a website for a client in the Democratic Republic of Congo who had low connectivity. And basically we could only do calls or even texting back and forth at 7:00 in the morning and 7:00 at night because that's when they had connectivity. So having the ability for your site to be downloaded quickly and easily is really important with low connectivity. Also discovered that when we had the Texas deep freeze, I had no cell tower near me that was functional and I would try and load the city site that had a lot of videos on it or a TV station that had a lot of videos on it, and it's so busy trying to load the videos. I literally watched my battery drain before my eyes and never got the page open.
So keeping your file sizes as small as is appropriate and being able to have those go off or be able to have people dismiss those is really, really important if they have low connectivity because they can't get to your main content if it's busy trying to load everything. And then also people will abandon your site if it takes too long, they'll like, fine, I'll go to something else. We have no patience these days.
Jay:
Melissa did drop in a resource from W3C about accessibility and I think it also does talk about that download speed. But one thing that's interesting to note is, I think we talked about it one of our early, early BADAs, if people want to turn off images when they load your site, that is a way for them to be able to access your site faster. But that's something for you to think about. And again, and that's why we talk about if you put an image on there and it has information, if they can't see the image visually, how else are they getting that information, and that's where it's important for that alt text to be there because if the image gets turned off, that alt text will still be available to them. So just something to think about, but good question on download speed. Absolutely.
All right. Well, let's go ahead and go to our very, very last slide and that way if there's any other questions, we can take those as well. But we want to say thank you as always. It's a joy for us to do this. We hope you have a good time, too. And please, we encourage you to help us out with our end of year fundraiser, we're getting really, really close to meeting our goals, so every little bit helps. So if you can go to knowbility.org/donate. We do wish you wonderful holidays. We will see you, of course, in the New Year. So thank you.