SC 2.4.11 Visual Focus (Minimum) and User Agents

[melaniephilipp]

People both inside and outside of AGWG have provided feedback to the AGWG many times on how complex and convoluted this Focus Visible (Minimum) success criterion is. Recently, I brought the existence of an Accessibility setting feature in both Chrome and Edge (>75% usage share of desktop browsers) to the attention of AGWG: Quick Focus Highlight. It substantially / fully meets the user need without placing the heavy lift of this Success Criterion (SC) onto every single site owner and accessibility compliance auditor across the globe.

This SC is a very large ask of Content Authors and auditors, in an area that can be much more efficiently and comprehensively met by User Agents. The onus is on AGWG to clearly demonstrate that a solution such as is provided by Chrome and Edge does not meet the user need.

I would like to see this SC worded in such a way as to allow default or accessibility setting features provided by user agents or assistive technologies - like what is currently available in Chrome and Edge - to fulfill this SC.

[mraccess77]

The highlight focus feature is not persistent and is hidden under advanced settings in Chrome. Users who rely on the indication of keyboard focus need an option that works not just in one browser in a temporary manner. This SC in many ways is less complicated than SC 1.4.11 and the area aspects are similar to SC 2.5.8 which is also be proposed.

[bruce-usab]

We talked a bit about this on the call Tuesday. I understood @GreggVan to note that the current phrasing might already allow an author to assert a branded browser as one of the Web content technologies relied upon. Of course, that would presume the feature be persistent, easier to find, and (I think) just a bit more visible.

[WilcoFiers]

highlight focus feature is not persistent

Do you mean that it fades after a second? Do you know of any research that shows fading focus indicators have negatie impact on users?

I've been using this feature myself for the past two months and have found it very effective. Even when using screen magnification. The fade-out makes it easier to see where the focus is, not harder. And since the browser follows the focus as you tab through the page, it's pretty difficult to lose track of. That it fades out has other benefits too. It lets the focus indicator be fairly big, without permanently obscuring other content. That's especially helpful for things like icon menus. Those often have fairly small focus indicators to save space.

is hidden under advanced settings in Chrome

It's in the accessibility settings. it's not unreasonable to expect from someone who needs accessibility features, that they find out what features are available to them.

that works not just in one browser in a temporary manner

WCAG does not specify which, or how many browsers need to be supported. There is a fairly reasonable argument to be made that if someone needs this feature, they would use one of the browsers that provides it. Even if that wasn't the case; Who's to say that this will not be available in all major browsers before the year is over?

[JAWS-test]

@WilcoFiers

Do you mean that it fades after a second? Do you know of any research that shows fading focus indicators have negatie impact on users?

2.4.7 Benefit:

People with attention limitations, short term memory limitations, or limitations in executive processes benefit by being able to discover where the focus is located

I suspect that for these user groups, an automatically hidden focus is not optimal. In addition, hiding the focus violates SC 2.3.3 in my opinion.

[WilcoFiers]

I suspect that for these user groups, an automatically hidden focus is not optimal.

You're probably right, but when is something ever perfectly optimal for everyone?

If someone spends 3 minutes reading a page, and they can't quite remember where focus was last. All they have to do is press tab to find it again. That may not be perfect, but I don't see how that's would prevent someone from being able to use the page.

I don't want to speculate about this though. My guess is no better or worse than anyone else's here. If Chrome's current solution isn't going to be permitted under WCAG 2.2, we need to provide some evidence that even when enabled, it prevents people from using a page without a built-in focus indicator.

[mraccess77]

The reason we created SC 2.4.11 was to address issues that weren't covered under SC 1.4.11 like comparison between the focused and unfocused conditions.

Disappearing indicators are an issue for people with low vision. For example, consider a person is sitting 4 inches from the monitor and only sees a portion of the screen at once - and/or consider that a person with scotomas (blind spots) is looking at their monitor. They press tab and if they don't see the visual change in their limited field of view they then go looking for where the indicator is. If the indicator disappears before they can locate it then they have missed the indicator. The only way to bring it back would be to tab and shift+tab again to try again to find it. If one sits 24 inches from your monitor and doesn't have a visual impairment or field loss then it's hard to understand the perspective of someone with low vision that needs this.

[WilcoFiers]

If you sit 24 inches from your monitor and don't have a visual impairment then it's hard to understand the perspective of someone with low vision that needs this.

I understand what it's like to have low vision.

The question here isn't if there are any issues at all with a disappearing focus ring. It's whether or not those issues are substantial enough that they would prevent someone from being able to use the page effectively.

I'm but one data point, but as a person with low vision, my answer to that is no. If we have more data, I would love to hear of it.

[mraccess77]

Other than contrast and text resize - keyboard focus indication is one of the biggest issues for me on web pages - so it's probably number 3. Does SC 1.4.11 do enough? Adding a user agent exception to SC 2.4.11 would effectively mean most organizations would just say they support Chromium and therefore they pass.

There is very good reason to believe it won't be in all major browsers by the end of the year - Firefox and Safari have had 15+ years to implement it and haven't.

Also it's not available on mobile and keyboard focus is still needed on mobile even if you use a touch screen because input form fields still must be filled out with an on-screen keyboard. So there is a pretty strong case to say if you expect people to use your site on mobile for input then at least the input fields if not all interactive fields could not rely on on desktop Chrome.

[WilcoFiers]

Other than contrast and text resize - keyboard focus indication is one of the biggest issues for me on web pages

Have you tried this feature?

[mraccess77]

I didn't know it existed until about a month ago - if I didn't know it existed I'm sure most users have no idea it existed. It is under accessiblity but that is listed under "advanced" and many users are going to stay away from advanced settings. I don't find the setting at all on mobile.

I have tried several times to use this since December but find it unusable and each time turn it off.

• It is so large that it covers up other content on the screen obstructing content
• It goes away and I sometimes miss it and am left to figure out where focus went after it disappears - and so I have to press shift+tab and tab trying to find it.
• It's really annoying and distracting to have something big pop up and then disappear - it's almost like animation or movement to me and is disconcerting. I turn off animations in Windows because I find that when things appear and disappear quickly it makes me tired and dizzy. So I am not able to use the feature because of it's giant pop up and move and then disappear functionality.
• Today if I need to override an indicator I use Stylus to create one - but users shouldn't have to write CSS to use websites. Most users without disabilities don't have to write CSS to use a website.

I'd note that I use a positive display with light background and dark text (default). The highlight is not as distracting or bulking in a negative display (dark background with light text) - but I find negative displays difficult to read.

[mraccess77]

The feature also doesn't work for items in a listbox and items in a dropdown select box and also does not work for focused items controlled by aria-activedescendant.

[JAWS-test]

The feature also doesn't work for items in a listbox and items in a dropdown select box and also does not work for focused items controlled by aria-activedescendant.

I have also found a few other cases where Chrome's focus highlighting doesn't work, but I don't think that should matter, because if we say that with Chrome's feature I comply with the WCAG's focus SCs, then of course that only ever applies if I don't use such elements where Chrome's focus indicator is not displayed correctly

[WilcoFiers]

• It is so large that it covers up other content on the screen obstructing content

From what I've heard that's exactly why it fades out.

• It goes away and I sometimes miss it and am left to figure out where focus went after it disappears - and so I have to press shift+tab and tab trying to find it.

They key word there is "sometimes". Even when you don't find it right away it seems like you're able to with a little extra effort. That's certainly not a perfect solution, but from the sound of it you have more preferences related to focus then the SC currently covers. You may still want to change color or size of focus on pages that are conform.

• It's really annoying and distracting to have something big pop up and then disappear - it's almost like animation or movement to me and is disconcerting. I turn off animations in Windows because I find that when things appear and disappear quickly it makes me tired and dizzy. So I am not able to use the feature because of its giant pop up and move and then disappear functionality.

That explains a few things. I can certainly empathise with that, and why you've not left this feature on. Nevertheless animation causing fatigue or dizziness is not the problem this SC is aiming to address. It's a problem under animation from interaction.

The feature also doesn't work for items in a listbox and items in a dropdown select box and also does not work for focused items controlled by aria-activedescendant.

I have also found a few other cases where Chrome's focus highlighting doesn't work, but I don't think that should matter, because if we say that with Chrome's feature I comply with the WCAG's focus SCs, then of course that only ever applies if I don't use such elements where Chrome's focus indicator is not displayed correctly

Interesting... I would think that's 1.4.11, not 2.4.11. If you change the active descendant on a listbox by arrowing up or down, the listbox should still be the focused control. That's at least how it works programmatically. There may very well be edge cases the focus ring doesn't cover. Those will still need to be tested.

---

Let's be clear on this part too. The current SC text does not prevent animation after focus. The exact wording is:

When user interface components receive keyboard focus

If the focus indicator had to persist, the language would need to change to something like:

While user interface components are in the focused state

The question is whether or not assistive technologies or user agent settings can ever be used to satisfy this SC. In that sense it's not too different from asking if Chrome's Live Caption accessibility feature may be sufficient for 1.2.2 or 1.2.4.

[mraccess77]

• I interpret the SC to applies to the focused elements with aria-activedescendant and not just the parent. Only requiring focus indicator on a grid but not a gridcell does not make sense to me.
• The ACT rules group has spend many hours writing test for SC 1.4.2 when Chrome has supported muting a tab for many years. Why do folks still fail auto playing audio when Chrome on the PC solved this years ago?
• There doesn't seem to be a solution for mobile and most sites today unless it's a large display only type of web app will be on mobile - what is your proposed solution for users with low vision on mobile? How can we people rely on something that has no support on mobile browsers?
• I know the SC is not about animation but the Chrome implementation means I can't use this feature and therefore can't get the benefit of the SC because of how Chrome choose to implement it. For Chrome to really implement this correctly they would need to support user preference and we don't have that today.

[bruce-usab]

keyboard focus indication is one of the biggest issues for me on web pages

I agree and want to amplify the concern, and to reinforce @mraccess77 explanation for why the Chrome feature is not sufficient for many (maybe most) people with low vision. I think the biggest weakness is the fade and how it is too quick to disappear away. A fast shift-tab/tab, in actual practice, Chrome enhancement or not, does not do much at all to resolve the real-world difficulty of finding the cursor. Most of the time, for most web pages, tab/shift-tab just restarts some invisible timer and the frustrating game of hide-and-go-seek resets with what is experienced as wholly new starting and end points.

[WilcoFiers]

@bruce-usab Same question then; Have you used this feature yourself, or do you know of anyone who has used it?

[melaniephilipp]

Hey Folks,

Several weeks back during the Friday WCAG 2.X working session (December 10?), we discussed my request to add an exception for user agents defaults. The small group of folks participating in the conversation was not in favor of it, and as requested during that meeting, I’ve been thinking about a compromise position that “I can live with”. This compromise idea: wording the SC in such a way as to allow default or accessibility setting features provided by user agents or for assistive technologies to fulfill this SC, does not appear to be gaining traction.

I’d like to take a step back to explain my position a little more: Focus indicators are a User Agent supplied feature. The W3C’s own Web Accessibility Initiative discusses how Accessibility has multiple essential components that interrelate at Essential Components of Web Accessibility https://www.w3.org/WAI/fundamentals/components/. There is a lot of good information on that page that I won’t rehash here.

I think of the components described by Essential Components of Web Accessibility as a “three legged stool”:

• Users
• User Agents: browsers, media players, assistive technologies, and other “user agents”
• Content Authors: content contributors, developers, authoring tools

WCAG has precedence for allowing tools and user agents to fulfill WCAG requirements. We allow browser features to fulfill 1.4.4 Resize 200%. We expect people who need screen readers to bring their own.

It’s one thing to require that Content Authors make what they author accessible to certain standards. It is another thing to require that they also overcome the deficits of a User Agent. Going back to the three-legged stool analogy, AGWG’s charter only gives it the ability to provide normative guidance to Content Authors. That limitation does not mean we should put onto Content Authors the responsibility to fix what is clearly a deficit of another “leg”, in this case User Agents. It also should not absolve Users from using the accessibility features of their User Agents. (I can’t resist the old saying… When all you have is a hammer…)

If WCAG was intended to be a voluntary protocol like the rest of the W3C’s Recommendations, then providing guidance on improving visible focus indicators is fantastic. It provides guidance on what focus indicators should look like for: 1) User Agents to implement by default or in their Accessibility settings, and 2) for Content Authors to strive for if they choose to modify the default focus indicator. However, the intent of AGWG stakeholders is to have WCAG 2.2 incorporated into global regulations as non-voluntary requirements. So, that’s a different matter. Forcing Content Authors to overcome User Agent deficits is going too far.

I am re-upping my request that an exception for user agent defaults be added to this Success Criterion.

[mraccess77]

SC 1.4.4 explicitly forbids assistive technology from being used to meet the requirement "Except for captions and images of text, text can be resized without assistive technology "

In addition, the feature you describe are not available on any mobile browsers and thus if any site claiming conformance for a mobile browser would not be able to rely on a user agent feature - since it doesn't exist.

[goodwitch]

2.4.11 (AA) Focus Appearance (Minimum) allows for the focus indicator to appear when the user interface component received focus. In other words, 2.4.11 as currently written in the editor's draft does not require the focus indicator to remain static the whole time that element has focus...it just requires a visual focus indicator when it receives the focus.

2.4.12 (AAA) Focus Appearance (Enhanced) does require the focus indicator to stay on the entire time the user interface component has focus.

So, according to the current normative of 2.4.11, it would be sufficient to have a visual focus that appears (and after some reasonable time fades).

I want to thank Chrome for providing the ability to easily (and for free) turn on the "highlight on the focused object".

On the outside chance that we can't let this count because it is in the 'Accessibility' settings section, I'll ping the good folks at Chrome to see if they can add this same setting to the 'Appearance' settings.

[mraccess77]

Some people who are legally blind have vision that is compounded by scotomas (blind spots) and other issues that make finding a disappearing cursor a challenge. Some users who are legally blind only see a small portion of the screen at once because they sit very close to the display and may need a persistent indicator.

The focus indicator highlight as it's implemented in Chrome desktop does not work for me personally given it's jumpy appearance related and it's not available in on mobile at all.

After 3 years of working on this SC these comments come right at the end. While feedback is always useful - constructive work prior to the last minute would have been preferable as this development was unexpected.

There is no problem with the setting being under accessibility. As indicated in my prior response the setting is under accessibility which is under Advanced. Most users will be reluctant to go and change advanced settings. Accessibility should not be under advanced. Apple moved their accessibility settings on iOS out from general several years ago - but they were never labelled advanced.

In my experience working with 100s of people who are low vision or legally blind - most people are not going to dig into advanced settings in order to look for a focus indicator setting. Given that every person is different a setting would likely need to be adjustable to meet real user's needs.

[bruce-usab]

One thing I have always appreciated with AGWG members is that people are able to be informed by their personal experiences even while separating their preferences from what should be in SC text. That is true for everyone one on this thread. Yet, we seem to be challenging each other bona fides.

Same question then; Have you used this feature yourself, or do you know of anyone who has used it?

I tried it briefly when I first heard of it. I thought it was cute, and turned it back off the same day. Chrome is my browser of preference, so prompted by this challenge, I will give it a longer run. I am open to being wrong. I am open to being swayed on this SC.

I don't like disparaging incremental progress, and I think the feature offers significant utility to many, many people. But in my opinion, it is not really comparable with the utility of the cursor enhancement features provided by commercial screen magnification products like ZoomText.

I no longer work in close collaboration with colleagues who rely upon screen magnification. I no longer teach AT. My assessment is based more on how the Chrome feature has been described, not my quick first impression. @WilcoFiers you suggest that "All they have to do is press tab to find it again." That technique works much of the time, maybe even most of the the time. But it frequently does not help at all.

[rachaelbradley]

We would like to encourage comments to focus on the technical discussion and avoid references and judgments about other individuals. Personal, lived experience is a key part of discussions within the AG. While it is appropriate to discuss your personal experience within the context of the technical discussion, judgments about others' experience can be seen as personal attacks and are not appropriate.

[alastc]

This compromise idea: wording the SC in such a way as to allow default or accessibility setting features provided by user agents or for assistive technologies to fulfill this SC, does not appear to be gaining traction.

It is already the case that if user-agents provided default indicators that met the SC then authors would not need to do anything (except not remove the default!). That is stated in the understanding document.

It was already the case (before the Chrome/Edge advanced setting) that you could have a user-agent which over-rides focus-indicators (I use that a lot in testing). Therefore adding an exception for that means the SC would not create a new requirement.

The onus is on AGWG to clearly demonstrate that a solution such as is provided by Chrome and Edge does not meet the user need.

As Jon outlined above, these options aren't available on mobile (over 50% usage, globally). If you use AT they generally provide their own bounding box, but without AT that isn't the case for iOS/Android currently (e.g. with 'full keyboard access' in iOS). It isn't available for desktop FF or Safari users.

This SC is a very large ask of Content Authors and auditors...

I have not found that to be the case. For example, I did a 90 minute session with a client reviewing new components for their site (events listing, date pickers, search with type-ahead find etc). We spent about 15 minutes on the design aspects, less than 5 of that was the focus indicators. We spent the rest of the session going through which aria-patterns best fit the different components and what the keyboard interactions should be.

For most sites you can achieve it for common components with a line of CSS, e.g.

:focus-visible {
 outline: 2px solid transparent;
 box-shadow: 0 0 0 2px #fff, 0 0 0 4px #396196, 0 0 2px 5px #fff;
}

With the added advantage that you can use brand-appropriate colours.

Caveats: Safari has some peculiarities with box-shadow on buttons, I haven't found the right -webkit incantation for that yet, and there should be a fallback for browsers that don't support focus-visible yet.

Do you know of any research that shows fading focus indicators have negatie impact on users?

These are new, so no-one is going to have research on that except perhaps the people that implemented them. What we do have is 20 years experience (each?!) on the negative impacts of a lack of visible focus indicators, so I think that question has to be reversed: Does anyone have research that shows fading indicators are sufficient? Glenda mentioned having contacts, does anyone know what research the fading approach was based on?

Chair hat on: We went through those topics (including the new options in Edge/Chrome) on the 21st Dec with a complete range of options in the survey, including dropping the SC. I'm still looking for something new that wasn't raised before to bring this to the group again.

[melaniephilipp]

I'm afraid my goal of finding a compromise position has created completely unintended consequences. For that I apologize.

Can we please pivot away from discussion on the singular Chrome feature to the larger philosophical question this SC brings to light: Assigning accessibility responsibility to the logical Component of "web development and interaction". (Essential Components of Web Accessibility)

As I've expressed in a survey and multiple AGWG meetings (going back several months) on this topic, assigning responsibility to the wrong Component may seem beneficial at a micro-level but it actually detracts from our goal of accessibility overall.

What do I mean?

Let's face it, we are currently so very far away from meeting the goals of WCAG 2.0, let alone WCAG 2.1 or WCAG 2.2 (see: The WebAIM Million). Taking the position that Content Authors must solve problems better solved by Users or User Agents comes at a cost to people with disabilities (PWD) because:

• We divert energy away from training and implementation for things Content Authors really must do.
• We limit the positive impact for people with disabilities to only those sites that adopt and successfully meet a particular WCAG version - a tiny minority of sites out there.
• We turn people / organizations off to accessibility because "it is too hard" to understand / implement / test. (This SC is a good example of "hard to understand and test")

Being in the weeds of accessibility testing, implementation, and training every day for over 10 years, I firmly believe it is vitally important to take a holistic view of accessibility and assign appropriate responsibilities to the appropriate Components in order to effectively push the ball forward.

I was so encouraged when I saw (or heard) an original intent of WCAG 3 was to provide guidance across all Components including user agents and assistive technologies (subsequent Charter limitations notwithstanding).

That same intent should apply to WCAG 2.X. So far we’ve stayed away from forcing Content Authors to make up for User Agent deficiencies by allowing for browser defaults to pass certain Success Criterion. I’m asking for the same here.

[mraccess77]

This SC as written already allows for browser defaults that meet to criteria to pass it.

[alastc]

it is vitally important to take a holistic view of accessibility and assign appropriate responsibilities to the appropriate Components in order to effectively push the ball forward.

I agree in theory, but in practice if user-agents don't move on something for 20 years at what point should you do something? I think we're well past that point. (NB: for a blast from the past, I wrote about this in 2007, pre WCAG 2.0!)

So far we’ve stayed away from forcing Content Authors to make up for User Agent deficiencies by allowing for browser defaults to pass certain Success Criterion. I’m asking for the same here.

That isn't the case, there are a few SCs currently author responsibility that can be done by user agents, including 1.4.2, 1.4.4, and most relevant here is text-contrast.

There are also quite a few that could be done by user agents, but blanket customisation of sites tends to break things, so SCs like reflow and text-spacing are in the in-between space of trying to ensure that customisation works.

As Jon mentioned, I think the ideal is that we write SC that could be accomplished by the author or the user-agent. If the user-agents step up, then the author can ignore it. That is the intent of the current SC.

[melaniephilipp]

@mraccess77 To be more explicit, I’m asking for an exception in the style of 1.4.11, such as:

Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA): When user interface components receive keyboard focus, an area of the focus indicator meets the following requirements, except where the appearance of the focus indicator is determined by the user agent and not modified by the author:

[rachaelbradley]

@melaniephilipp With that exception as written, I am not sure how this SC would be different than Success Criterion 2.4.7 Focus Visible. All user agents provide a focus indicator, it is just not sufficiently visible for many users.

I would be more comfortable adjusting the understanding document, adding a note, and or adding a sufficient technique to better indicate that if all the user agents that will use the content provide a visible indicator than that is an acceptable solution.

[alastc]

@melaniephilipp The main intent (coming from developing 1.4.11) was to ensure that poor browser defaults are not enough. See #1057, #1156, #1341. (There are others, that's a quick search.)

I would be more comfortable adjusting the understanding document, adding a note, and or adding a sufficient technique to better indicate that if all the user agents that will use the content provide a visible indicator than that is an acceptable solution.

We have that :-) It's near the top of the intent section.

[melaniephilipp]

@alastc I am clear on the intent behind developing the SC.

I am objecting to the intent of making it a legal obligation for Content Authors to overcome the deficits of a User Agent function.

Again, if this were intended to be a voluntary standard, like the rest of W3C standards, that would one thing. However, the intent of AGWG stakeholders is to have WCAG 2.2 incorporated into global regulations as non-voluntary requirements. So, that’s a different matter.

[melaniephilipp]

With that exception as written, I am not sure how this SC would be different than Success Criterion 2.4.7 Focus Visible. All user agents provide a focus indicator, it is just not sufficiently visible for many users.

@rachaelbradley It would still be different from 2.4.7 because it would provide guidance for Content Authors who choose to modify the User Agent default. 2.4.7 doesn't do that.

[bruce-usab]

@melaniephilipp — In my experience, it is not very constructive for AGWG to look at SC through the lens of "legal obligation" or "voluntary standards".

The useful lens we do have is our Acceptance Criteria for Success Criteria.

It is because AGWG has been so diligent that 2.0/2.1 are incorporated into global regulations as non-voluntary requirements — not the other way around. I agree that SC must not be merely aspirational. I understand our work as are codifying minimal best practices. Is your concern that 2.4.11 should be AAA and not AA?

[melaniephilipp]

@bruce-usab While formulating CSs, the document you reference is a great reference. It was helpful as I was getting to understand the SC creation process in 2017 when WCAG 2.1 being formed. Nonetheless, I do think it's extremely important to keep in mind that it is a legal obligation we ultimately (seek to) create.

Without an exception for default browser focus indicators, yes, AAA. But I'd support it at AA with the exception, because the SC guidance is valuable for those who do chose to modify the default. I really do wish it weren't so convoluted to understand, but with the exception I "can live with it".

[mraccess77]

The W3C is not in the business of creating legal obligation. Many regulations including in the EU (EN 301 549), AODA (Ontario) have chosen specific WCAG criteria for including and exclusion and adopted what they wanted. The EN 301 549 went as far to re-write the standards into the document so that they may have ultimate control of the standard.

The Access Board excluded certain WCAG criteria from applicability to software and documents. The Access Board also indicated that they could not give up authority to the W3C and thus could not make the standards evergreen by just following the latest WCAG. Regulators are aware of the challenges with adopting wholesale and can address any concerns through selection of standards.

[LaurenceRLewis]

If the SC is kept as is with guidance that browsers can fulfil the SC if you test it, would it be an option that a function change request be submitted to Chrome, and other browsers? Where the user has the option to toggle the focus indicator between persistent and the current fade functionality. If this is implemented could the browser default exception "except where the appearance of the focus indicator is determined by the user agent and not modified by the author". can be added in WCAG 3?

[alastc]

This issue was resolved at the meeting: https://www.w3.org/2022/02/22-ag-minutes#item05 That included addition of two user-agent based exceptions, although they don't appear in the editors draft yet, there are other edits to make.