WCAG22 - focus visible enhanced

[alastc]

There are quite a few changes from this PR implementing focus-visible-enhanced.

The SC changes will appear in the editors drafts when merged.

See the understanding doc preview for the main explanation.

Also changed:

• Added new SC (focus-visible-enhanced) to the guidelines/sc/22/ folder.
• Create a new version of focus-visible in a new guidelines/sc/22/ folder, so it can move to level A.
• Update the index.html to point focus-visible.html to the /22/ version.
• Update the current focus-visible understanding doc, using class=”wcag22” for a new bit of text that shouldn't be included in current versions (until 2.2 is published).
• Added a new technique in the CSS folder.
• Updates the procedure of two current techniques to match the new requirement.

This PR thread is ok for comments, but if you want to suggest a change or have an objection to thise PR, please open a separate issue and tag this PR (#936), and label with focus-visible-enhanced.

It is unusual for us to move a WCAG 2.0 SC from AA to A, but this was the prefered option from this survey and meeting.

---

Preview | Diff

[JAWS-test]

I am very pleased that the new criterion clarifies many of the ambiguities and closes loopholes that existed with SC 2.4.7. I have the following comments:

• I would like to add the following to the new 2.4.11: "The focus must be clearly assignable to the element". The understanding should explain that focus outlines that are, for example, only between two adjacent elements are not permitted. Example at codepen
• I would like to add in SC 2.4.11 or only in Understanding that the focus should be consistent. This is especially important if the interactive elements are far away from each other. If the type of focus highlighting changes, the focused element is not good visible. Example. Note that the focus is particularly invisible if the focused element was previously not in the visible area and is scrolled into the visible area only when it receives the focus.
• The focus in the example "The requirement is to have an indicator that has a 3:1 contrast ratio with the adjacent colors (including the component), or to be separated from the component, or to be at least 2px thick." is barely visible, especially if the element is not in close proximity to the previous one. Here I would like to tighten the SC 2.4.11 (if the color of the focus is the same as the background color of the element, the focus line must be much thicker). Example. Note that the focus is particularly invisible if the focused element was previously not in the visible area and is scrolled into the visible area only when it receives the focus.
• Since I don't speak English, I'm not sure if the first rule "The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels" is unmistakable. When I read it, I thought it meant that the focus highlighting had to be at least as long as the wide side and at least 2 px wide. Perhaps it can be expressed more clearly that this is an area calculation (2px multiplied by the length of the element =< size of the focus highlight).
• "The focus indication area is greater than or equal to the longest side of the bounding rectangle" - what is the bounding rectangle, if there is no visible border? The visible text or icon or the click area or the standard outline if it existed
• If only the text color changes, the calculation becomes difficult, because then the area of the letters must be calculated

My notes 1-3 refer to various web pages that I had to check in the past for the WCAG, i.e. they are not made-up examples, but problems that occur in practice.

[detlevhfischer]

One overall comment and two specific ones:
We will never catch all permutations in the understanding text so we should try to prevent this from going into minutae and becoming endlessly complex.

would like to add in SC 2.4.11 or only in Understanding that the focus should be consistent

Ir is very common that different parts of a page have different focus styles, this should not be discouraged

If only the text color changes, the calculation becomes difficult, because then the area of the letters must be calculated

I fail to see why this should ever be necessary, beyond ensuring contrast between focused and unfocused state is above 3:1

[JAWS-test]

It is very common that different parts of a page have different focus styles, this should not be discouraged

Precisely because it is very common, I mentioned the problem that arises in this context. Have you looked at my example? If we can't make a hard rule out of it for the SC, I suggest that we at least address the problem in Understanding.

I fail to see why this should ever be necessary, beyond ensuring contrast between focused and unfocused state is above 3:1

The SC says: "all of the following are true: ... Minimum area ...". I.e. if only the font color changes with a contrast of more than 3:1 (or only one letter changes the color) the area of the color change must be larger than 2px × length of the text.

[alastc]

Jaw-test wrote:

"The focus must be clearly assignable to the element"

It is already baked in that the focus is a state of a user-interface component, and all the examples keep the focus indicator closely related to the element. I've never come across an example like your codepen, probably because it would take effort to design-in and if you do that, you try to do a better job than the defaults?!

I'm really struggling to see how to include that when very, very similar code would be fine:
https://codepen.io/alastc/pen/YzzOyXg

Have others found tricky examples like this, is it something we should add to the understanding doc?

I would like to add in SC 2.4.11 or only in Understanding that the focus should be consistent.

I can see that would useful in some circumstances, but I think it would be harmful in others.

For example, if your navigation bar is on a dark blue background, then a white/yellow indicator would be best. If the rest of the links are on a white background, you need a completely different indicator. We have to trust that if people are designing things in, it will generally use colour schemes / brand-guidelines to make things consistent where possible.

The focus in the example ... has a 3:1 contrast ratio with the adjacent colors (including the component), or to be separated from the component, or to be at least 2px thick." is barely visible, ... I would like to tighten the SC 2.4.11 (if the color of the focus is the same as the background color of the element, the focus line must be much thicker).

I think it is worth pointing out that this is a worst-case example (perhaps I should change that?!). If you use a different hue for the indicator, then for >90% of people it will be completely obvious.

E.g. a 2px purple outline around a blue button would be visually obvious to most (including low-vision folk), but could have a 1:1 contrast ratio. Therefore I used the worst case to show that for those who can't see the hues, this is what they get.

I went through a lot of examples with the Low Vision task force, the 1px out-set outline was one of the worst performing (that passed), but logically if we increase that requirement we are then ruling-out some indicators that perform well.

I'm not sure if the first rule ... is unmistakable.

NB: I've added the SC text to the understanding preview doc so it's easier to find.

We went through a few itterations, I'm open to suggestions. Note that when published "focus indication area" is a defintion that links to this statement:

Focus indication area: The number of CSS pixels that change between the focused and unfocused states of a User Interface Component

Jaw-test wrote:

what is the bounding rectangle, if there is no visible border?

Bounding box is stated to be of the "focused control", so generally the box the focusable element creates. There are some instances where it isn't a box, which is why we used the (fairly well known) concept of bounding box, but it's rare.

If only the text color changes, the calculation becomes difficult

Indeed, and if that puts people off using a method that is difficult to track visually, I won't loose sleep.

[mraccess77]

Personally I find switching between different focus styles confusing and some harder to spot. For example on one social media site I tab around to buttons which have a border. When I tab agIn it turns out that I am now on a link which is underlined. The underline for a link to identify focus is problematic because it’s not clear to me if the link is always underlined or not. So the switch between styles has me guessing and the underline is ambiguous to me.

[alastc]

@mraccess77 I can appreciate that, but I don't think we can give a blanket "use one style" across the whole page?

With this SC, at least that underline would not pass. It would either have to be 2px thick, or use a complete border...

[JAWS-test]

I've never come across an example like your codepen, probably because it would take effort to design-in and if you do that, you try to do a better job than the defaults?!

As I already wrote, I didn't come up with this idea, but found it out several times during the test. The problem occurs quickly: a focus frame is used, which is around the whole element, but hidden by the surrounding elements due to position:relative and z-index. And the focus frame is no longer visible around the entire element, but only on one side. A nice example of this can be found at w3c/aria-practices#1243 (comment).

Your example, slightly altered: I've seen that before.

For example, if your navigation bar is on a dark blue background, then a white/yellow indicator would be best. If the rest of the links are on a white background, you need a completely different indicator. We have to trust that if people are designing things in, it will generally use colour schemes / brand-guidelines to make things consistent where possible.

I had suggested that the focus should be "consistent". I.e. not that it must be identical. Consistent means e.g.

• always invert foreground and background color
• always an outline of a certain size
• always an underline
• always show an icon etc.

Unfortunately, I don't trust the developers because I've seen too many negative examples already. I'd like it if the hint could at least make it into the Understanding.

[alastc]

That seems to be a different thing, I'm confused.

The first example had a block appearing between links, making it confusing which it was associated with. That's what I was asking for further examples of (from other people), to see if it is common.

You're reply above makes it seem like the focus indicator is getting cut off, which is a different issue (IMO).

For the ARIA practices example, do you mean this page?

It looks ok to me (in FF), so I'm not sure what the issue is, perhaps it was fixed?

[mraccess77]

I think it might also be useful for us to talk through something like Material design and see what fails which SC. https://material.io/design/interaction/states.html#focus

1. Pass 1.4.11 criteria because the icon itself acts enough context. 2.4.11?
2. Pass SC 1.4.11 and Fail 2.4.11 The line on bottom has enough contrast with page background -- but not input background when focused.
3. Fail SC 1.4.11 and 2.4.11
4. Pass SC 1.4.11 - button text alone is enough. SC 2.4.11?

[alastc]

I did look at some examples already (with the 1px * longest side threshold), see examples 13-21 here.

I agree with 1, 2 & 4.

Not sure why 3 would fail 1.4.11, which bit do you mean? Is the block as a whole a User Interface Component?

[mraccess77]

@alastc wrote

Not sure why 3 would fail 1.4.11, which bit do you mean? Is the block as a whole a User Interface Component?

I would treat the card as a whole component here because the whole thing is focused.

[mraccess77]

I can appreciate that, but I don't think we can give a blanket "use one style" across every page?

I agree we probably can't require this because it's not practical. However, it can be very confusing for users and add cognitive load.

[JAWS-test]

The first example had a block appearing between links, making it confusing which it was associated with. That's what I was asking for further examples of (from other people), to see if it is common.
You're reply above makes it seem like the focus indicator is getting cut off, which is a different issue (IMO).

Because the focus frame around the entire element is hidden on some sides, it is only visible on one side and therefore cannot be clearly assigned to the element. I have only simulated this in my example. The cause in CSS is different, the visual effect is the same.

For the ARIA practices example, do you mean this page?
It looks ok to me (in FF), so I'm not sure what the issue is, perhaps it was fixed?

Yes, this page.
The problem occurred on the page, so the CSS had to be adjusted to make the focus visible on all sides. Due to the CSS, however, the screenreader output seems to be incorrect.

If only the text color changes, the calculation becomes difficult
Indeed, and if that puts people off using a method that is difficult to track visually, I won't loose sleep.

If a SC is difficult to test, it doesn't cause designers to do things differently, because they don't care. But the accessibility testers have a problem. That's why a tool would be good, which helps with the test.

[JAWS-test]

The focus is poorly visible when the following occurs, especially if several of them occur simultaneously:

• Focused element is not visible before and is scrolled into the visible area when it receives focus,
• interactive elements are difficult to recognize as such,
• Focus is not consistent,
• The focus order does not correspond to the visual display,
• The focus indicator for one element is similar to the representation of other elements that do not have the focus.

All this, as far as I can see, is not currently a violation of any SC (not even 2.4.11). However, all this can make keyboard operation very difficult because focus visibility is a result of 2 things:

• Focus is well visible
• the user suspects which element will probably receive the focus next in order to search for the focus there.

Therefore, I am in favour of considering whether 2.4.11 can be made clearer in this respect or whether other SCs can be used (e.g. SC 2.4.3 could be extended to require the focus order to correspond to the visual representation as well).

[alastc]

@JAWS-test wrote:

The cause in CSS is different, the visual effect is the same.

That's ok, we're testing the visuals.

The focus is poorly visible when the following occurs, especially if several of them occur simultaneously:

Most of those aren't really solvable by defining the focus change at the element level. Unless we add some page level requirements and a tracking animation (like this demo page), I don't think expanding this SC will help (without making it confusing and overly-broad).

NB: For particularly egregious examples of focus order, or hidden links, we do fail them under 2.4.3 focus order.

If you'd like to pursue those aspects could you open a separate issue please?

[JAWS-test]

Most of those aren't really solvable by defining the focus change at the element level.

I agree with that. Therefore, I would come back to my original proposal:

• Addition to SC that the focus must be assignable to the element (this can be easily tested and concerns the element itself)
• Supplement to the Understanding:
  1. Note about which factors also support focus visibility.
  2. Warning that the focus is poorly visible if the focus indicator is the same color as the element and there is no distance between the element and the focus indicator.
• A method for measuring complicated area contents may be provided (e.g. in the case of irregular shapes of the focus indicator like color change of the font)

[alastc]

Addition to SC that the focus must be assignable to the element (this can be easily tested and concerns the element itself)

I'm not sure what this means. An interactive element must be able to receive focus (via 2.1.1), and when that happens, it must have a visible focus indicator (2.4.7 + this SC).

We've got definitions for user-interface component and 'focus', I'm not sure what "assigned" means that isn't already covered?

[alastc]

Note about which factors also support focus visibility.

We have that sort of information for the positive factors (e.g. more size, more change etc). I take the point that we don't talk about the negative factors which are not covered.

It isn't something we usually do, as we try to keep the understanding docs based on the SC text. I'm considering a small section towards the bottom such as:

---

The factors outlined above help to make the focus seen more easily. There are also contextual factors to be aware of such as:

• Consistency: Users can be tabbing down and the page will scroll down to follow which means the component may not have been visible prior to being focused. If the focus state looks different from the components above, it may not be recognized.
• Order: If the order through the components is not predictable if is harder to follow (see also SC 2.4.3).

---

Warning that the focus is poorly visible if the focus indicator is the same color as the element and there is no distance between the element and the focus indicator.

That is what the 'contrast of thickness' section says:

Where a control is a solid color, and you add a border or outline of a very similar color, it is difficult to perceive the change to the control.

[JAWS-test]

@alastc:

I'm not sure what "assigned" means that isn't already covered?

It is about the problem in my first example at codepen.

I'm not sure if this is already covered? There are various forms of this problem. I created an example where the entire focus frame is around the element, but the focus frame is far away from the element, so it also includes other interactive elements - even then it's not clear which element has the focus.

[alastc]

Ah, I'd probably term that as "focus must be clearly associated with the element".

I created an example where the entire focus frame is around the element, but the focus frame is far away from the element, so it also includes other interactive elements

I think with the definitions of user-interface component ("a part of the content that is perceived by users as a single control for a distinct function") and focus ("The point where the user’s input interacts with the web page.") that is covered.

The focus indicator needs to be part of the UI component, so nesting is intrisically a problem. You could still have (odd) examples like your codepen, but without dictating design in some way, I'm not sure what measure/test we could use to eliminate that.

[JAWS-test]

I'm not sure what measure/test we could use to eliminate that.

Test if focus indicator is clearly associated with the element

[alastc]

Anything with the word 'clearly' in it is going to be too subjective, how could the association be defined? There are many aspects: proximity, spacing, lines, backgrounds. They all work together as 'design', so it's a hard concept to define.

[JAWS-test]

@alastc

Anything with the word 'clearly' in it is going to be too subjective,

Maybe "Test if focus indicator is associated with the element" is better?

I do not want the focus indicator to be clearly and simply assigned to the element, but rather to be able to be assigned to the element at all. In my examples, the focus indicator cannot be assigned. That is why I would classify my examples as violations. I don't think this is subjective. Every tester can clearly decide whether a focus indicator can be assigned to an element or not. There is only yes or no, but none perhaps. The Understanding could give examples of how this criterion is fulfilled and not fulfilled.

[AutoSponge]

I analyzed the example from techniques/css/focus-indicator-inner.html with the following results:

• The inset border of #fff5be is only 2 px wide. (measured and by reading the CSS).
• #fff5be has a 3.41:1 contrast ratio with the previous (and interior) "blue" #3f86d4.
• #fff5be has a 11.46:1 contrast ratio with the 1px solid #333333 border (exterior).
• It's insufficient contrast and needs to be 3px wide to pass.

Did I misread the rules?

[alastc]

Hi @AutoSponge,

For that technique (preview page for others to follow along), from the SC text:

• "The focus indication area is greater than or equal to the longest side of the bounding rectangle of the focused control, times 2 CSS pixels.".
  The indicator is 2px thick along all sides, so the area is significantly greater than 2px along 1 side. The length is slightly smaller along the inside than if it were along the outside, but even a 1px line would pass if it goes all the way around.
• "Color changes used to indicate focus have at least a 3:1 contrast ratio with the colors changed from the unfocused control.".
  The color change is from #3f86d4 to #fff5be, which is 3.4:1.
• "The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least 2 CSS Pixels."
  The yellow indicator is adjacent with the blue and the black, therefore meets the contrast for adjacent colors.

I'm not sure where you got 3px from?

-Alastair

[michael-n-cooper]

I believe the generator issues are fixed and this pull request can now be merged.

[michael-n-cooper]

Technical review only, this seems to generate ok now.