Jay McKay: Hello everyone. Welcome to Be A Digital Ally. It is that time again where we get to talk, go deep into accessibility best practices regardless of your experience, whatever type of content you're creating, one of our favorite, favorite programs here at Knowbility.
Today our topic is a continued exploration of WCAG 2.2, and that is Focus Appearance and Focus Not Obscured. So before we get started, let me go ahead and give you the slides link. It is going to be a Bitly again. So bit.ly/BADA216. So that'll be BADA216. All right, we'll go on to the next slide.
So, hello, just some quick introductions. I am Jay McKay. I'm Director of Community Programs. So BADA AccessU Accessibility Internet Rally. Basically all of our public-facing education service projects, that's me. So onto my co-host here, Melissa.
Melissa Green: Hi, good afternoon. I'm Melissa Green. I'm a certified professional in accessibility core competencies and a member of Knowbility's accessibility services team. I'm looking forward to learning with you this evening.
Jay: Okay. So just a quick overview of our agenda. So just a quick little poll we want to take today, because we know most of you are returning BADA participants. But if you could put in the chat or use the raise hand and let us know if you are completely new, if this is your first time coming to BADA. Are we all ... Oh, excellent. Welcome, welcome. Ooh, more new people. This is wonderful. Exciting. All right, well, that answers my question for today then. All right, we'll go ahead and go over our agenda here.
So when we start our BADA introductions, we always want to do some overview of what accessibility is, because we know that people are coming that may not have been here before. So for those of you who are returning BADA people, you're going to know what the next 10 minutes or so are, so please feel free to grab that extra snack. But we will talk a little bit about how we are defining accessibility and what that means going forward in these conversations.
Then our topic today, we're going to talk again about some of the guidelines and changes of WCAG 2.2 and learning some techniques to meeting that revised criteria.
So next we're going to talk about some housekeeping. Sarah, I'm assuming you just had your hand raised to say that you're new to BADA, correct? If that's the case, you can go ahead and put your hand down. We appreciate you joining us.
All right, so just some housekeeping. First off, thank you for letting us be a part of your journey. Like we said, this is what Melissa and I live for, is to have these opportunities to teach and learn and grow in accessibility. So if you have questions, please feel free to type them in the chat as we go through the content today. There's always an opportunity at the end for you to jump on the mic.
Julianne and I will be monitoring the chat as the presentation goes on. Sometimes there'll be spots where we can stop and address the questions, but if we don't address it right away, don't worry. We'll always make sure we get to them at the end.
So just a quick little overview of some of the accessibility features. Of course, we have auto-captions enabled through Zoom. If, for future BADAs, you need to have sign language interpretation or if you need to have live captioning, so to have a human captioner, those are just things that you would need to register with us in advance and giving us about 72 hours in advance notice when registering for the next session.
As always, please, please ask for help. We are here. We want to make sure that this is enjoyable and that you're getting the most benefit out of the session tonight.
All right, so just a quick little intro if you're new to Knowbility. We are a nonprofit organization founded in 1999. We're based out of Austin, Texas, but really we operate globally. Our mission is to create an inclusive digital world for people with disabilities, and we do that through, like I mentioned before, several of our different programs that Melissa's going to share with us right now on the screen.
So Community Programs, like I said, has several different programs. We have the Accessibility Internet Rally. That is our annual web competition where we pair nonprofit organizations with web developers to create beautiful accessible websites.
We have AccessU, which is our conference coming up in May. And so, these are really in-depth training sessions, 90 minutes. Oh, excellent. Bruce is already going. 90-minute to 180-minute sessions where participants get to really dig into techniques, skills of accessibility, looking at everything from developing and testing, user testing, design, policy, advocacy, and also organizational strategies for your company. So we'd love to see you there.
We also have our K12 Digital Accessibility arm of things. This includes our webinar of Toolkit Tuesdays happening every month, where we talk more specifically about accessibility needs and how to support assistive technology in K12 spaces. Then, of course, Be A Digital Ally.
As I mentioned before, we are a nonprofit. Thank you to those that have donated through your ticket registration. If you'd like to donate separately, because I know some people, they're registering through their company accounts and they can't make a donation through Humanitix, you can go to knowbility.org/donate and make a direct donation there.
All right, so let's talk about accessibility. The reason why we like to go over this definition is because “accessible” can mean a lot of things to different people. Sometimes they think, oh, it's open, it's available. That means it's accessible. It's sitting on the counter versus being locked in a closet. That means it's accessible. That's not necessarily the case when we're talking about something being accessible for people with disabilities.
So for something to be accessible, people with disabilities must be able to access and utilize it as fully and as independently as someone without a disability. So some of the questions that you might want to ask yourself is can everyone hear and see the content? Do they know where to go or what to do or what to expect as they are going through a website or going through a piece of content? Do they know where to go next? Can they independently navigate that content using their preferred tools?
So if you're somebody who cannot use a standard mouse and keyboard, maybe you're having to use a switch or voice operation or Eyegaze, can you get to all those spots independently? Can you independently complete tasks and explore all the areas? Then, lastly, can you fully participate in an authentic manner?
Really, that's always my goal is I want to make sure somebody's not having to hold back in providing some content or sharing with the group or contributing. I want to make sure everybody has access. Sarah, your hand's still up. So let's check in with you and see if you had a quick question before we dive in too deep. All right, I'm going to go ahead and have your hand lowered. But if you have a question, feel free to drop it in the chat. Okay, so let's go on to inclusive design. There we go.
So 15% of the world's population lives with some form of disability. When we talk about that, we also have to remember that there are many people who may not consider themselves as disabled by the World Health Organization's definition of disability. Think about people that maybe are experiencing hearing loss or some type of maybe degenerative vision. They may not necessarily think of themselves as disabled, but by WHO's definition, they are part of that 15%.
Then also something to think about with inclusive design is there are people that benefit from accessibility but may not have any type of disability. The most common one that we think about nowadays is the ability to turn captions on when we're viewing content. Actually, there was an article or something I read talking about how much captions and subtitles are being used just in general, because people prefer to have those when they're streaming content.
But think about things like curb cuts. Those are things ... I'm not necessarily disabled, but curb cuts can be useful for me, especially if I'm pushing a stroller or if you're just me and I like to trip over myself a lot. Those curb cuts are helpful.
All right. So next we want to talk about assistive technology, because that's terminology we talk about a lot when we talk about accessibility. So assistive technology enables and promotes inclusion and participation, especially of persons with disability, aging populations, and people with non-communicable diseases. The primary purpose is to maintain or improve that individual's functioning and independence, thereby promoting their wellbeing. So this is coming from, again, the World Health Organization. So really the idea is ... Again, that idea of accessibility and assistive technology, being able to access, being able to function, having full ability to do so.
So our next slide is going to actually talk about different types of assistive technology. There is really a very broad range and wide range of assistive technology. It can be any product or equipment or software or system used by people with disabilities, again with that purpose to increase, maintain, or improve functional capabilities.
I'm not going to go through all of these. I do recommend, when you get a chance to explore that very last link at the bottom, the WebAIM examples. They give some really nice definitions what each of these are, as well as some videos, some additional links so you can see them demonstrated. But things like screen readers. That's a way people can navigate their computer if they're visually impaired, because to use a mouse and if you can't see the screen and somebody says click on the folder icon that says this, they're not going to know that. The screen reader has to tell them as they're scanning through the system.
Transcripts, close captions, we talked about. Alternative navigation methods. Again, not everybody can use a keyboard and mouse. I would also remind people not everyone can use a touchscreen. So a lot of times people go, "Oh, well they can't type and use a mouse. Let's have them use a touchscreen." But again that's not necessarily a way for them to use access.
All right, so let's get ready to go. We're going to look at our favorite quote from Maya Angelou. It says, "Do the best you can until you know better. Then when you know better, do better." So we're all learning on this journey of accessibility. I always want to remind people of this because sometimes you just don't know something. You don't know what you don't know until you know it.
And so, the idea is we don't want you to feel embarrassed. We don't want you to feel like, "Oh, I'm a terrible person." I think for some people, they want to create content to be accessible, but then they feel like they're going to mess it up. So then they'd rather just not create anything at all or not try to make it accessible. We're here to tell you try do what you know. Once you get that part, then you'd go on to the next part. With that, I'm going to step back and let Melissa take over.
Melissa: All right. Thank you, Jay. Thanks so much, everyone. We are continuing our journey, or embarking on today's journey, by continuing our discussion of some proposed changes to the Web Content Accessibility Guidelines.
But before we talk about what's proposed to change, let's talk about what the Web Content Accessibility Guidelines are. The Web Content Accessibility Guidelines or WCAG is an international standard and a collection of documents that together explain how to make web content more accessible to people with disabilities.
The guidelines are organized under four overarching principles: perceivable, operable, understandable, and robust. If you think back to how Jay defined accessibility at the beginning of our session, that definition was built from those principles, that in order for web content to be accessible, it needs to be perceivable, it needs to be operable, it needs to be understandable, and it needs to be robust.
The WCAG guidelines also provide testable success criteria or statements where conformance testing is necessary, that detail how to know when an item meets the standard, as well as sufficient and advisory techniques that go beyond what is required, allowing authors to better address the guidelines and usability.
This quote from the Bureau of Internet Accessibility summarizes it nicely. "WCAG offers an actionable framework for creating or remediating websites and apps to be accessible. It 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."
Bureau of Internet Accessibility offers a history of WCAG on its page, as well as the materials on the WRC WAI, W3c Web Accessibility Initiative site. If you're interested in learning more about the history and philosophical underpinnings of WCAG, you'll find many things there.
So now that we understand what the guidelines are, let's talk briefly about how they are used. The guidelines serve as an industry standard. Companies and organizations can require vendors and developers to meet different levels of WCAG compliance, A, AA, or AAA standards, when developing websites.
At Knowbility, when we first encounter a new vendor, we ask for their accessibility conformance report, so we have a snapshot of how accessible their product is, whether it conforms with the Web Content Accessibility Guidelines.
WCAG is also referenced in international law, so where accessibility law exists around the globe. WCAG 2.0 or 2.1, AA frequently serves as the basis of that law. Section 8 requirements currently reference WCAG 2.0, AA levels. More and more companies and organizations are using them.
Ultimately, by meeting expectations for WCAG 2.2, you ensure that you're following usage trends, good practice for web content in general, as well as ensuring access to the widest possible audience.
One thing to remember is how the WCAG is developed or are developed. We aren't going to go into every single detail, but I want to highlight that the guidelines are developed by the Worldwide Web Consortium, the W3C, and its member organizations. When the W3C updates these guidelines, there are several steps that are completed before the guidelines are official.
The first step of five includes a community input of several working drafts. Next, there's a wide review working draft. This means the working group has addressed all the comments and provides a complete document for wide review from the greater community.
The third phase is the candidate recommendation. This is the current phase for WCAG 2.2. You might think of it as the testing phase. Developers are encouraged to use the technical report, the draft, in their projects. At this phase, large changes are not expected. The editors phrase this as not anticipating any changes to the normative content of WCAG 2.2. So not expecting any big changes, but some additional adjustments can occur based on feedback from testing.
The fourth stage is when the W3C announces WCAG version as a proposed recommendation and submits it to members for endorsement. Then, finally, once the technical report has received a wide basis of support for members in the community, it's published as a recommendation.
So considering all of this, you might be wondering when will WCAG 2.2 be approved? The WCAG 2.2 candidate recommendation snapshot was approved for publication in January 2023, so just last month. The group that's working on this, the Accessibility Guidelines Working Group, is currently processing its findings, implementations, comments from the candidate recommendation publications, looking for some additional implementations of some of the proposed criteria.
So that is where we are. If you want to keep up with exactly where WCAG 2.2 is in this process, a good resource for that is the W3C WAI's What's New in WCAG 2.2 draft page. They keep that updated regularly. So while WCAG 2.2 is not yet an official recommendation, the latest published version in the document I just mentioned, the W3C's What's New in WCAG 2.2 draft, give us an idea of what to expect.
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 content more operable and understandable, the O and the U of our POUR acronym, and these changes will be particularly beneficial for users with visual, mobility, and cognitive disabilities.
Additionally, the 2.4.7, Focus Visible criterion, which was at the AA level in WCAG 2.1, has been promoted to the level A criterion in WCAG 2.2. The 4.1.1 Parsing criterion, a single A level criterion present in WCAG 2.1, has been deemed obsolete and removed from WCAG 2. So 2.2 includes all success criteria from WCAG 2.0 and 2.1, with no changes to existing criteria, save for the two I just mentioned, 2.4.7, Focus Visible and 4.1.1, Parsing.
WCAG 2.2 builds on 2.1, and they're backward compatible in the sense that if you design a page now to conform to WCAG 2.2, it should also then be in conformance with 2.1 and 2.0. If you're required to conform with 2.0 or 2.1, the W3C WAI tells us that you can update your content to 2.2 without breaking conformance with those earlier versions.
The proposed success criteria we're taking a closer look at today fall under the area of WCAG guideline 2.4, Navigable. WCAG guideline 2.4 is pretty short and sweet. It reads, "Provide ways to help users navigate, find content, and determine where they are." So we might expand that to say accessible web content provides users ways to navigate, find content, and determine where they are.
Well-organized content helps users to orient themselves and navigate effectively. When content is well-organized, pages have clear titles and are organized using descriptive section headings. There is more than one way to find relevant pages within a set of web pages. For example, through a hierarchical menu or a search.
Users are informed about their current location within a set of related pages. A number of different techniques for that. One is breadcrumbs. There are ways to bypass blocks of content that are repeated on multiple pages. One of the ways that we accomplish this is by using a semantic markup or the appropriate tags to indicate the order and relative importance of different parts of a page, header, footer, menu, and so on.
When content is well-organized and navigable, the keyboard focus is visible and the focus order follows a meaningful sequence, meaning that the focus indicator moves through the content in a way that makes sense. Usually this means it moves through the content in the same order that a visual user would access the content.
Finally, the purpose of a link is evident, ideally when the link is viewed on its own. One of the ways that assistive technology users sometimes navigate web content is to use keyboard shortcuts to bring up a list of links on the page. Descriptive link tests, descriptive link names are vital for ensuring that these users know what a link is and what clicking on it will do. But these are all broad principles around the area of navigation, or different things that we talk about when we talk about ensuring content as navigable.
People navigate and find content using different strategies and approaches based on their skills, their abilities, their preferences. Meeting the navigation guideline helps people to navigate through webpages in different ways, depending on their personal needs and preferences.
So I mentioned this before, but I'll talk a little bit more about it. While some people rely on or prefer hierarchical navigation structures, such as a menu bar at the top of the page or perhaps a hierarchical menu in a left or right sidebar, others rely on or prefer search functions instead. Some people may be seeing the content while others may be hearing it. Others may be seeing it and hearing it at the same time. Some people may be using the content with only a mouse or a keyboard, while others may be using both.
Keyboard users typically use the tab key to jump from one structural item such as a link, a list item, a header, or so on. Keyboard navigation largely depends on web browser support, but also features that we can build into our websites, like skip links.
On the topic of browser support, many functions to support different styles of navigation are built directly into web browsers and assistive technologies. For example, most commonly available browsers provide bookmark functionality, the ability to save frequently accessed sites or favorite sites for easy navigation. Screen readers provide functions to list headings, links, and other structures on webpages. However, in order for these built-in browser features to work, in order for them to be compatible with the assistive technology, we have to design and develop our content accordingly.
Well, how do we do that? The newly proposed success criteria that fall under WCAG guideline 2.4 seek to help users navigate, find content, and determine where they are. The WCAG 2.2 draft proposes three new success criteria under this guideline, 2.4.11, Focus Appearance at the AA level, 2.4.12, Focus Not Obscured at the AA level, and 2.4.13, Focus Not Obscured at the AAA level.
So as with other pairs of minimum and enhanced criteria, 2.4.12 and 2.4.13 are a AA and AAA success criteria. So another way to think of this is 2.4.12 is what you need to do if you're going for AA minimum conformance and 2.4.13 is a little stricter. The bar is a little higher for going for AAA or enhanced conformance.
Before I read the text of the proposed criteria, I'd like to talk terminology. Keyboard users typically navigate their way through websites by pressing the tab key. This allows them to jump from one interactive element to another. Just like mouse users, keyboard users need to be able to see 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.
That's what focus indicators are for. Focus indicators are pixels changed to visually indicate when a user interface component is in a focused state. This slide includes examples of focus indicators from the W 3C WAI way documentation and the Knowbility site.
In one, a solidly bound focus rectangle encloses the third of five stars. In another, a rectangular focus indicator is shown around a tab list. In an example from the Knowbility site, a solid focus rectangle surrounds an image linking to the site's homepage. In another, a solid focus rectangle indicates that a link with the text Accessibility Testing and Auditing is in focus.
You can experience these for yourself on the web. You can navigate to a website of your interest, position the focus of the cursor within the page, and then use the tab key to move throughout the page content. You should see some sort of visual indicator as you navigate, indicating what's in focus. The appearance of these varies depending on browsers and operating systems and so on, but it typically is styled as a rectangle.
More terminology. User interface component. A user interface component is part of the content that is perceived by users as a single control for a distinct function. User interface components include input controls such as check boxes, radio buttons, dropdown lists, list boxes, buttons, toggles, text fields, and date fields, as well as form elements and links.
The examples that appear on this slide are checkbox, which is used to select one or more options from a list, radio buttons, used to select one item at a time, a dropdown list, used to select one item at a time. There's also a list box, used to select multiple items at a time, a text field, used for entry of a single or multiple lines of text, and some buttons. So when we talk about the user interface component receiving focus, this is what we mean, things that are perceived by the user as a distinct control for a function, whether it's entering text, making a choice, and so on.
The success criteria talk about the focus indicator enclosing the user interface component. Encloses is defined to mean solidly bounds or surrounds. These are two fairly established ways of showing focus, something that the editors note in the draft.
Bounds and its related term bounding box generally describe rectangle drawn around the outside of a user interface component. It's the most common form of focus indication and is sometimes referred to as a focus rectangle. This is demonstrated in the first example on the slide, which shows a solid focus rectangle around the second of two buttons.
Surrounds also refers to something that solidly encloses a shape. However, a shape can be surrounded in many ways. For instance, the focus indicator may follow the outline of the object being enclosed.
The difference between bounds and surrounds is illustrated in an image on this slide that shows two sets of rating stars. In both examples, the same three stars have already been selected, and focus is on the third star. In the first example, a solidly bound focus rectangle encloses the third of five stars. In the second, a solid outline indicator, surrounds the third of five stars. So encloses, bounds, and surrounds, three related terms that are used in these criteria.
Solidly, where the indicator does not solidly bound or surround the component, as with a dashed or dotted line, it cannot meet the criteria's consideration of enclosing the element, the component. However, a non-solid line can still pass or can still conform if it meets the area calculations for the size of the focus indicator, which are discussed in detail in the relevant criteria.
This slide includes two figures. In the first, the dash outline of a focus indicator does not solidly bound the third star and does not meet the size requirements. In the second figure, the dashed outline does not solidly bound the third star. However, it does meet the size requirements for focus area calculation.
The success criteria also refer to CSS pixels. So a CSS pixel is what developers use in style declarations, like the ones given on the slide here, font size: 60 pixels, line height: 50 pixels, width: 200 pixels. A CSS pixel is different from a display pixel or device pixel in that device pixels vary depending on the physical pixel density of the device.
Perimeter also comes into play when assessing a focus indicator for sufficient size and contrast. Perimeter is defined as the continuous line forming the boundary of a shape, not including shared pixels, or the minimum bounding box, whichever is the shortest. The success criteria refer to calculating a components perimeter, and comparing the contrasting area to that of the perimeter.
So in the image on the slide is a circle that has a 22-pixel radius and a 138-pixel perimeter, representing an element that is not in focus. On the top right, the focus indicator is a one-pixel solid circular outline. The perimeter of the focus indicator is 172 pixels, which is larger than the shape's boundary at a 138 pixels. With a color change that is higher than the minimum requirement, or change to the color contrast so that it exceeds the requirement, this indicator passes.
On the bottom left, there's a focus indicator with an inner one-pixel solid outline with enough color contrast change, but the area is smaller than the circle's perimeter. It's 113 pixels to the shape's boundary at 138 pixels. This indicator does not pass requirements.
Finally, on the bottom right, the focus indicator is an inner two-pixel thick outline. This outline has double the area of focus indicator, 226 pixel, making it larger than the perimeter of the circle. So it passes the minimum area requirement. There are some math involved, but perimeter is often what we're looking at when it comes to determining whether or not a focus indicator has sufficient appearance.
The success criteria also refer to a bounding box or a minimum bounding box. I think I've mentioned that a couple of times already in passing. The bounding box of a component is the smallest possible rectangle that entirely encloses it and its descendants. You can use non-rectangular shapes for focus indicators, but again some math is involved in figuring out the area.
But now that we've looked at the terminology and underlying concepts, let's turn our attention to the criteria themselves. I'm going to first read the entire proposed criteria and then we'll break it down.
2.4.11, Focus Appearance, is a AA level criterion. It reads: when the keyboard focus indicator is visible, one or both of the following are true. The entire focus indicator meets all the following: encloses the user interface component or sub-component that is focused; it has a contrast ratio of at least three to one between the same pixels in the focused and unfocused states; and, has a contrast ratio of at least three to one against adjacent non-focused indicator colors.
Or, two, an area of the focus indicator meets all of the following: is at least as large as the area of a one CSS pixel thick perimeter of the unfocused component or sub-component, or is at least as large as a four CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component, and has a contrast ratio of at least three to one between the same pixels in the focused and unfocused states, and has a contrast ratio of at least three to one against adjacent non-focused indicator colors, or is no thinner than a two CSS pixels. Whoo. Let's break that down a little.
So this success criterion offers two ways to achieve a sufficient focus appearance: by meeting requirements for the entire focus area as outlined in list item one or by meeting requirements for an area of the focus indicator outlined in list item two. The first example on this slide demonstrates an entire focus indicator that has sufficient focus appearance.
We've seen this example a few times now. The same component labeled example appears twice, first unfocused then in a focused state. The focus indicator meets the criteria by enclosing the component that is focused, having a three to one contrast ratio between pixels in focused and unfocused states, and having a contrast ratio of at least three to one against adjacent colors.
The second example on this slide demonstrates an area of a focus indicator that has sufficient focus appearance. Here a yellow block along the short side of an item, rather than a rectangle, indicates that a component has focus. So two ways, the entire focus indicator and area of the focus indicator can meet requirements.
This slide depicts more examples of focus indicators that have areas that meet size and contrast requirements that comes to us, like many of the examples today, from the W3C WAI. These focus indicators have areas that meet size and contrast requirements. In the first, the focus is indicated by an inner outline that is slightly smaller than the outer edge of the component. In the second, focus is indicated by a yellow underline almost as long as the longest edge.
So there are different considerations for whether you're looking at an entire focus area or indicator or an area of it, a portion of it. We'll look at the considerations for an entire focus indicator first. So, first, the entire focus area must enclose the component that is focused. Remember, from our vocabulary, enclosed means solidly bounds or surrounds. This typically means with a solid line. However, a non-solid line can still pass if it meets requirements. This slide includes that example I've shared a few times now.
Again, I'm sharing it now as an example of an entire focus indicator that has sufficient focus appearance.
One of the things that we talk about is the contrast ratio. In the example, there is significant difference in color contrast between the item when it's in focus and when it's not and the item in focus and its surrounding content.
I don't want to spend too much time on this, but I'll quickly mention there's a lot of free tools that can help you quickly determine color contrast, or if an item meets these requirements, has a contrast ratio of at least three to one between the same pixels in the focus and unfocused states, or has a contrast ratio of at least three to one against adjacent non-focused indicator colors.
There's lots of tools out there. A couple of free ones that we like are the WebAIM Color Contrast Checker and TPGi's Color Contrast Analyzer. The WebAIM Color Contrast Checker lets you check to see if color choices meet the contrast ratio specified by WCAG. If they don't, it helps you adjust your choices of colors until they do meet the requirements.
So for purposes of conformance with this success criterion, what's really helpful is the contrast ratio provided by the checker. The criterion calls for contrast of at least three to one. The color combination in the example on this slide has a ratio of 8.59 to one and would meet the requirement.
I mentioned another one I like is TPGi's Color Contrast Analyzer, which works on the web and with documents and images on your computer. You can enter hex codes or use the eyedropper tool to select combinations of colors to determine their contrast ratio, again to see if it meets that 3.1 requirement for focus appearance or for other purposes.
So those considerations are for the entire focus area. Let's look at the considerations for an area of the focus indicator. An author can also meet the success criteria's requirements by assessing an area of the focus indicator for sufficient size and contrast.
Now this slide is the examples, or includes the examples, of focus indicators that have areas that meet size and contrast requirements. In the first, focus is indicated by an inner outline that's slightly smaller than the rest of the component. In the second, the focus is indicated by a yellow underline almost as long as the longest edge.
So these examples meet all of the considerations for an area of a focus indicator. It's 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 four CSS pixel thick line along the shortest side of the minimum bounding box. The focus indicator in these examples also has a contrast ratio of at least three to one between pixels in the focused and unfocused states and against adjacent non-focused indicator colors, or is no thinner than two CSS pixels.
A few more aspects of this one before we move on to the other criteria. One, there are some exceptions noted in the documentation. There are two situations where the focus appearance does not need to be assessed, and that's when the focus indicator cannot be adjusted by the author or the author has not modified the effects of the user agent default.
What does that mean? Some components or technologies may not allow the author to adjust the focus indicator, and this is the case with HTML select elements where the visual treatments for selection cannot be applied by the author. In this case, the success criteria wouldn't apply. It's an element where it's just not possible to achieve that.
If the focus indicator and the background behind the focus indicator are not modified by the author, the success criterion does not apply. Browser default focus indicators vary by component, by manufacturer, by browser, device, operating systems, and the default focus indicators can be difficult to see.
Authors sometimes override these defaults because they're trying to enhance access. When they make changes, the criterion applies. The changes need to be in keeping with the success criteria. But if they don't make any changes to the default behavior in the browser, then they don't need to assess conformance with this criteria.
There are three notes addressing aspects of this criterion. So these are notes included in the WCAG 2.2 draft. The first talks about what should be considered when assessing a user interface component, depending on its visual presentation. The visual presentation includes the component's visual content, border, and component-specific background. It doesn't include some other things for purposes of assessment, like shadow and glow effects, outside of the component's content or background or border.
The next note provides examples of sub-components that may receive a focus indicator, menu items in an opened dropdown menu or focusable cells in a grid. The third note addresses calculating color contrast and states contrast calculations can be based on colors defined within the technology, such as HTML, CSS, and SVG. Pixels modified by user agent resolution enhancements and anti-aliasing can be ignored. So essentially we're concerning ourselves with the color as authored, not necessarily how the color is rendered by the user agent.
I particularly want to draw your attention to the editor's note that this success criterion is currently labeled at risk in the draft. The editors note that it is at risk due to concerns around implementation and testing challenges. Their note reads, "The success criterion focus appearance and glossary terms related only to it is at risk due to concerns around implementation and testing challenges. 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'd encourage you to do for now is keep in mind that WCAG 2.2 may introduce a new success criteria that aims to ensure that focus indicators are clearly visible and discernible, and that criteria may include or address things like size and contrast.
We've already looked at several examples of focus appearance at play, but, briefly, the W3C WAI suggests a few more. Conformance with this criterion could look like a number of different things. A link that receives focus or when it is in focus has an outline displayed around it and the outline contrasts with the background adjacent to the link, that would be conforming. It could be that when buttons receive focus, an outline is displayed within the button, around the text, that contrasts with the button's background, or when the text receives focus, an outline is displayed around the text field, indicating that the input has focus, or when radio buttons receive focus, an outline is displayed around the control, indicating that the input has focus.
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."
For sighted people who use a keyboard or keyboard-like device, for example, a switch or voice input, knowing the current point of focus is very important. However, when progressing through a page, other content on that page could potentially hide that focused element. This success criterion ensures that the item receiving focus is not entirely hidden by other content.
The success criterion 2.4.12 requires that at least some part of the component. As a result, normally part of its focus indicator as well not be obscured by other author-created content. The AAA version, 2.4.13, requires that the entire focus indicator of the component not be obscured by content created by the author.
An example of content that conforms with these criteria, 2.4.12 and 2.4.13, is a page with a sticky footer attached to the bottom of the viewport. When that is in conformance, tabbing down the page would not hide the focused item. When tabbing down the page, the focused item is not hidden by the footer.
This slide includes an example of this. It is a screenshot, a couple screenshots, from a webpage. It is part of a step-by-step navigation titled Learn to Drive a Car: Step-by-Step. The page has a navigation header positioned right at the top of the page, so users can see it immediately and determine that this page is part of a broader process. It also provides a link back to the main step-by-step navigation page.
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 the component on which keyboard operations will act. In this example, the content seems okay when accessed on a desktop, which is shown in the screenshot on the left side of the slide. On the right side of the slide, the content is shown when access on a mobile device, and that sticky header appears to overlap a link. In testing, it would be important to determine whether any focused items are covered up when scrolling on devices of different viewports.
But as I mentioned before, the other success criterion, the last of the three, 2.4.13, Focus Not Obscured, enhanced, is closely related. While conformance at the AA level requires that a component not being entirely hidden due to author-created content, conformance at the AAA level requires that no part of the indicator be hidden.
Returning to the previous example with the sticky header, in the case of the mobile display on the right side of the slide, the sticky header slightly obscures or covers up part of a link. In order for this content to conform with 2.4.13, no part of that link could be covered up when the link is in focus. So certain level of requirements to meet for AA and then slightly more stringent requirements for conformance with AAA, which provides access to the broadest number of people.
We talked a lot about the technical details, the underlying principles and forms of terminology, and the greater guideline of navigation, and then the technical details of each success criteria. I'd like to wrap this portion of our time together by bringing us back to the benefits of conformance with these success criteria.
These success criteria related to focus are most beneficial to keyboard users. Keyboard users might be individuals with no or low vision. They may be individuals who are sighted, who have mobility impairments, who use a keyboard or device that utilizes the keyboard interface or emulates a keyboard such as a switch or voice input. Visible focus also benefits users with low vision who use the keyboard.
Finally, people with cognitive disabilities, especially attention and memory limitations, or limitations in executive processes, benefit from being able to discover where the focus is located.
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 website, you can find the WCAG 2.2 draft itself, a resource titled What's New in WCAG 2.2 draft, that explains the proposed success criteria with examples. I drew on it heavily for this presentation. You can find WCAG 2.2 supporting documents. That's quick references, guides, and techniques for understanding and meeting WCAG 2.2, as well as other technical and educational resources.
As I mentioned earlier, you might also check out the W3C's mailing list. There are many related to accessibility with much discussion around the guidelines and the work of the working group.
All right. So we have covered a lot today. We have provided you many links as resources. Now that we have put all of this into your brains, do you have any questions for us or thoughts to share? You can ... Yeah, go ahead.
Jay: Yup. We've got one in the chat. It says, "The second exception for 2.4.11, regarding the indicator's background color, is this saying that as long as the default background color of the page is not changed, then you can rely on the default focus color?"
Melissa: That's my understanding. That came from the discussion in the What's New in WCAG 2.2 draft.
Jay: All right. Oh, we've got another one. They were blown away with the yellow bar example button. "It seems to me that would work in a grouping of other similar buttons or controls. But does the 2.2 draft speak to implementing something like that all by itself, no other nearby buttons, then reverting to straight-up rectangular focus indicators for other components/elements on the page?"
Melissa: I'm not sure that it does speak to that specific scenario at this point. I think that's an interesting question, if not just for accessibility conformance but for usability purposes, having focus of one type of element appear visually one way and focus on a different type of element appear visually a different way. I don't know if that would enhance usability or be a challenge to usability.
But as far as I recall, nothing that specific. It's these concerns about implementation and testing that generated the discussion that has this criteria at risk. They're still not entirely clear to the broader web development and accessibility community how to implement some of these guidelines, especially on non-standard elements and interfaces. So I don't think this is addressed, but I would refer you to the same thing, WCAG 2.2, What's New, which they continue to expand, updated in January.
Jay: We had somebody that joined us late. Yes, we record these. We'll have them up in about two weeks, just so that way we can clean them up a little bit, make sure the captions and transcripts are ready.
All right. I'm thinking let's go ahead and go onto our next couple of slides. If you still have questions, please feel free to type them in. If you want to raise your hand and jump on the mic, that's fine, too. But we'll go ahead and do the rest of our slides here.
Again, we love your feedback. We really do use that for us to make some determinations on what's working, what's not working, what kind of topics you want to talk about. So we have a Bitly link. We also provided you a QR code here. It is bit.ly/FebSurveyBADA. That's going to be capital F, capital S, and then of course BADA, all capital B-A-D-A. We'll make sure that link gets in the chat as well. Then we'll go to the next slide.
Unfortunately, I forgot to update this for next month. We're actually going to take March off. We have several of our staff are going to be presenting at various conferences. I will actually be in Austin presenting at South By. So I'll be out there. If you all are in Austin, I'd love to see you.
But please go ahead and check out our website. We've actually uploaded the entire calendar that we have planned for the year for 2023. So check out knowbility.org/digitalally. That will take you to Be A Digital Ally. That's where we upload all the recordings as well. So that way if you miss today, you'll be able to get access to it. Then we have the schedule for April onwards. So definitely check that one out.
Then of course AccessU. We already talked a little bit about it. If this is the kind of stuff you crave where you get to really dig in deep and talk about some things, definitely come to AccessU 2023. One of the things that we really strive for with our sessions is it's not just a lecture style. There's always these opportunities for people to interact with each other. A lot of sessions have opportunities for participants to practice while they're there working with each other and their peers. So definitely please check that out. If you want to go to knowbility.org/accessu. I actually uploaded the deep dive sessions on the website, so they are there live for you all to check it out as well. So definitely take a look.
All right. Lastly, thank you. Thank you so much for being here with us. I'm going to let you hear our website to donate one more time. It is knowbility.org/donate. Again, thank you. Thank you for your feedback. This has been a great series to get going with WCAG and onto the rest of the year. I'm really excited about our upcoming schedule. So we'll see you all in April