W3C

Results of Questionnaire WCAG 2.2 - Focus appearance

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-08-17 to 2022-06-27.

36 answers have been received.

Jump to results for question:

  1. Tackling wrapped text-links using "border" CSS
  2. DONE: Re-structure of bullets
  3. DONE: SC text review
  4. DONE: Update Focus Appearance Enhanced and split Focus Not Obscured #2365
  5. DONE: Tackling wrapped text-links using "border" CSS
  6. DONE: Adjacent contrast
  7. DONE:Adjusting sub-component requirement
  8. DONE: Bounding box for separated links #2323
  9. DONE: Updaxed understanding document
  10. DONE: Out-of-viewport content #2204
  11. DONE: Updated understanding document for "encloses"
  12. DONE: Replace "encompasses" with "encloses"
  13. DONE: User-Interface Component as basis for size
  14. Note on sub-components / active descendants
  15. Not including the 1px perimiter metric
  16. Definition of Encompasses
  17. DONE: Focus appearance Updates
  18. DONE: Focus appearance and user-agents, again
  19. DEFUNCT: Focus appearance updates
  20. DEFUNCT: Suggested update for understandability
  21. DEFUNCT: Update to 'component' language take 2
  22. DEFUNCT: Time limited focus indicators
  23. DEFUNCT: Update to 'component' language
  24. DEFUNCT: Suggested update for understandability
  25. DONE: Size basis for focus-appearance
  26. DEFUNCT: Using target- area as the basis for size metrics
  27. DEFUNCT: Focus Appearance complexity #1842
  28. DONE: Focus appearance and user-agents
  29. DONE: Insufficient requirement for focus indication via enlargement #1858
  30. DONE: Focus appearance & Visual examples #2071
  31. DONE: Use of the word "state” is not sufficiently consistent #2049
  32. DONE: Focus indicators for large editing areas #2017
  33. DONE: What is a complex shape? #2050
  34. DEFUNCT: Focus indicators for large editing areas #2017
  35. DONE: Focus appearance should be in Perceivable
  36. DONE: Need more info on adjacent contrast #1929
  37. DONE: Inline elements that wrap over multiple lines #1328
  38. DEFUNCT: Minimum Area shape requirement #1928
  39. DEFUNCT: Adobe Comment #1887
  40. DONE: Readability updates
  41. DONE: Update Technique G195 procedure #1931
  42. DONE: Make clearer the method of calculating the minimum area #1883
  43. DONE: Sizing impresise and fairly complicated #1718
  44. DONE: Google feedback
  45. DONE: Non-text contrast update
  46. DONE: Understanding document updates
  47. DONE: Confusing wording due to unconventional state requirement #1859
  48. DONE: Gradient Focus Indicators #1861
  49. DEFUNCT: Non-text contrast update
  50. DEFUNCT: Understanding document updates
  51. DONE: Explain why authors are better enabled than UA at solving this #1911
  52. DONE: Minimum Area clarification #1806
  53. DONE: Browser default focus indicators #1854
  54. DONE: Gradient Backgrounds #1862

1. Tackling wrapped text-links using "border" CSS

Previously Gundula had raised that focus indicators using border on wrapping text links should pass.

The problem arises when you use CSS border (not outline), and a wrapped text-link leaves a gap on each side of the separated link.

Michael Gower is proposing a different solution to the same problem, where we add to the perimeter definition to outline why wrapped links are ok:

"For text links, the perimeter can be established based on how the link would appear contiguously across a single line. Links that break across multiple lines are not considered to have a larger perimeter."

This is implemented in PR 2420. (The definition is the area of focus, there are other understanding updates that can be discussed separately.)

We discussed this again briefly in May, but ran out of time.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 6
Agree with adjustment 3
Something else

Details

Responder Tackling wrapped text-links using "border" CSSComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree with adjustment The PR uses "component" first, and "link" second. I think this needs to use the word "component" in both cases. I would also adjust "if this perimeter is smaller" to "if this perimeter would be smaller", since we're not talking about the actual perimeter, but a hypothetical situation here.
Laura Carlson Agree with the update
Charles Adams Agree with the update
Michael Gower Agree with adjustment Either the word "component" should be changed to "link" or "link should be changed to "component". I _think_ the only thing we're talking about here is links, so unless anyone thinks of another component that might do this, I suggest just using "link".
Bruce Bailey Agree with the update I think @wilco is commenting on this sentence:
> For components which wrap onto multiple lines as part of a sentence or block of text, the perimeter can be established based on how the link would appear on a single line (contiguously), if this perimeter is smaller.

I think this phrasing is okay as-is. The component could, for example, be a small gif inline with text. I am flexible.
Jonathan Avila Agree with the update
Mary Jo Mueller Agree with adjustment Think these different calculations & considerations might be easier to consume in a bulleted list. I also think that the definition could have links to specific examples in the understanding document. It was a little hard to understand the wrapping text part of the definition without knowing that a good example is links.
Rachael Bradley Montgomery Agree with the update
Alastair Campbell Agree with the update Happy with Wilco & Michael's suggested updates.

Mary-Jo: I think the better way around is to explain that part of the definition in the understanding document. We already have a section for that included, it will need updating after this.

2. DONE: Re-structure of bullets

Based on previous comments a slightly updated structure has been suggested, where the exceptions about size/contrast are brought up as an alternative to the primary bullets.

This structure update can be previewed.

This is a last minute adjustment, if we don't agree that it is better, we go with the current structure.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 5
Agree with adjustment
Something else

Details

Responder DONE: Re-structure of bulletsComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the update
Suzanne Taylor Agree with the update
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower Agree with the update The exception could be listed, instead of "Except when:" as "Exceptions:"
This is how it is done in 1.4.12 Text Spacing and 1.4.13 Content on Hover or Focus
Bruce Bailey Agree with the update I think is adjustment is better because it makes (1) and (2) peers. Previously, the second one (which is a quite visually prominent effect) was characterized as an exception.

With (1) and (2) as peers, a AAA "no exceptions" version of this SC makes sense.

This is ambiguous:
> these requirements *can* be applied to the sub-component instead

Proposed:
> it is an option for these requirements to be applied to the sub-component instead
Jonathan Avila Agree with the update
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

3. DONE: SC text review

We have had a few updates recently, this is a chance to review the whole SC text in this preview.

Do you:

Summary

ChoiceAll responders
Results
Agree with publishing Focus-Appearance 5
Agree with adjustment 6
Something else 2

Details

Responder DONE: SC text reviewComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with adjustment It says "At least as large as " which lacks a verb in the overall sentence.
i suggest to write "is at least as large as".
David MacDonald Agree with adjustment I would like to amend the bullet about the same pixels contrasting in focused and unfocused state to make an exception for a 2 colour indicator. (2 focus rings, one light, one dark) , like this:
https://www.davidmacd.com/widgets/focus-ring/focus-ring-contrast4.html

- has a contrast ratio of at least 4.5:1 against the same pixels in the unfocused state, unless the focus indicator is made of 2 colours that have a contrast ratio of at least 4.5:1 with each other
Andrew Kirkpatrick Agree with adjustment Suggestion in first question.
Ian Kersey
Todd Libby Agree with adjustment In agreement with the comments in this survey.
Suzanne Taylor Agree with publishing Focus-Appearance Please notice that this does now require that two-tone focus indicators are tested for change in contrast separately for each link, button, etc: http://manateeroad.com/BugReports/WCAG%202.2%20Level%20AA%20Draft%20Comment%20Internal%20Contrast.html

("no thinner than 2 CSS pixels" prevents the need to test each link, button, etc, for adjacent contrast)

Melanie Philipp Agree with adjustment I echo Wilco's comments. Especially "This SC requires content authors to address issues with browser defaults, something browsers should be responsible for. The exception on this does not go far enough."
Wilco Fiers Something else See my previous objections;

1. Visual appearance of UICs is too vague. This SC is not clear enough on how to test components with fuzzy shapes, shadows, and glow effects. We're going to have poor inter-rater reliability on these.

2. This SC is far too complicated for people to understand and apply without the aid tools, and yet so subjective that it can not be accurately tested with fully automated tools.

3. This SC requires content authors to address issues with browser defaults, something browsers should be responsible for. The exception on this does not go far enough.

4. This SC should not require a permanently persistent focus indicator. We do not have the research to show this is necessary, and it prevents browsers from being able to address this issue.

5. The SC uses the word "may" which is a reserved word for RFC 2119 meaning "optional". Putting the focus indicator on a sub-component isn't optional, it is an alternative to putting it on the UIC. I don't think "may" as defined in RFC 2119 is appropriate in the SC text.
Laura Carlson Agree with publishing Focus-Appearance
Charles Adams
Michael Gower Agree with publishing Focus-Appearance Some changes to the Understanding document were proposed in https://github.com/w3c/wcag/pull/2420/files that would address some minor Understanding updates. Those have not been incorporated (due in part to some related and leap-frogged normative text changes). If the normative wording change is adopted, I will undertake to provice these and other updates to the Understanding document.
Bruce Bailey Agree with adjustment From the conversation last week (5/24) -- I agree that a AAA version of *this* SC is counterproductive -- because the 3rd exception (the one with its own three bullets) is probably a more visual prominent effect than the default requirement.

This is ambiguous:
> these requirements *can* be applied to the sub-component instead

Proposed:
> it is an option for these requirements to be applied to the sub-component instead

Comment below (5/24) still applies, but was addressed with Re-structure of bullets (5/31) last minute adjustment above.

Second bullet of area of the focus indicator (exception, third bullet) should follow same phrasing of second bullet in main clause.

Second bullet in main clause:
> Has a contrast ratio of at least 3:1 between its pixels in the focused and unfocused states;

Current second bullet of area of the focus indicator (exception, third bullet):
> has a contrast ratio of at least 3:1 against the same pixels in the unfocused state, and

Proposed:
> has a contrast ratio of at least 3:1 between its pixels in focused and the unfocused states, and
Jonathan Avila Agree with publishing Focus-Appearance
Mary Jo Mueller
Rachael Bradley Montgomery Something else There is a difference between the understanding doc in 1 and this preview. I would like to approve both sets together as a consistent whole.
Alastair Campbell Agree with publishing Focus-Appearance

4. DONE: Update Focus Appearance Enhanced and split Focus Not Obscured #2365

Michael Gower updated Focus Appearance (Enhanced) language to combine original Enhanced requirements with updates to Minimum language requirements. As part of this, he proposed creating Minimum and Enhanced versions of Focus Not Obscured. There is no increase in requirement outcome, they are just broken out into separate SCs that match the previous versions.

Previews of:

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 6
Agree with adjustment 3
Something else 1

Details

Responder DONE: Update Focus Appearance Enhanced and split Focus Not Obscured #2365Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with adjustment Focus appearance (enhanced):
As the intent explains, the enhanced focus is meant to extend the minimum area.
Yet the normative text still talks about "Encloses the visual presentation of the user interface component;" which does not double the area. It also talks in the exceptions about "has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels." which also does not double the area.
Besides, I do not feel that doubling the area is needed.

Enhancing the contrast though is needed. This also implies the contrast to adjacent colors.
The enhanced contrast requirements in general follow the philosophy to be 1.5 as much as the minimum contrast.
So large text shall contrast 3.0:1 in minimum contrast and 4.5 in enhanced contrast.
Consequently, non-text contrast as well as distinguishability by contrast should / would request a contrast of 4.5:1.
The distinguishability (contrast focused vs unfocused) is requested with 4.5:1 in the draft.
I think the contrast to adjacent colors should also be requested as 4.5:1.

On the other hand, requesting double width spoils designs which rely on theming, as all spacing, padding, margins and the like are influenced. So a minimum contrast theme and an enhanced contrast theme would no longer share the same arrangement, or force the minimum contrast theme to have an arrangement which allows a focus of double area.
And I feel a double area focus indicator is no needed.


------------
Focus not obscured (minimum):
It talks about " keyboard-like device (e.g., a switch, voice input),".
I suggest to explicitly mention keyboard in the parenthesis.
I suggest to also explain whether dynamic content like tooltips and poovers are allowed to hide the focus indicator.

Focus not obsured (enhanced):
The minimum version mentions keyboard, more precisely anyone who rellies on keyboard to operate the page.
I suggest to mention keyboard-like device as in the minimum version.
David MacDonald Agree with adjustment I'm wondering about the 4.5:1 ratio of focused and unfocused pixels.
I think one important way the SC will be met will be with 2 colour indicators. (a light and a dark ring for the indicator)
My two concerns are:
1) I wonder if 4.5 is a big lift, was it not 3:1 before? NOTE: if the number was changed to 4.5 by consensus and I was not present, disregard the comment.
2) I think we should create an exception to this for 2 colour indicators. Where the two colours are more than, say, 4.5:1 with each other.

I would like to amend the bullet about the same pixels contrasting in focused and unfocused state to make an exception for a 2 colour indicator. (2 focus rings, one light, one dark) , like this:
https://www.davidmacd.com/widgets/focus-ring/focus-ring-contrast4.html

- has a contrast ratio of at least 4.5:1 against the same pixels in the unfocused state, unless the focus indicator is made of 2 colours that have a contrast ratio of at least 4.5:1 with each other




Andrew Kirkpatrick Agree with the update Still concerned that the Focus appearance minimum and enhanced have requirements in the exceptions section. Think it should be:

When a user interface component has keyboard focus, the focus indicator either:
* Encloses the visual presentation of the user interface component and is no thinner than 2 CSS pixels;
* Has a contrast ratio of at least 4.5:1 between its pixels in the focused and unfocused states;
* Has a contrast ratio of at least 3:1 against adjacent colors.
OR
* An area of the focus indicator meets all of the following

This would remove the exceptions from the enhanced version (which could also be called “no exception”)
Ian Kersey Agree with the update
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else This was way too much to put into one survey question.

---

On Focus Appearance (Enhanced): Why would in the first case we require both a 2px minimum, and a 3:0 adjacent contrast, but in the area exception we make it an either/or situation? I'll also repeat my statement from last week's call that the numbers feel arbitrary to me. Why did we double the area and not triple or quadruple it? When I look at focus rings provided as part of assistive tech, or as accessibility features, I generally see 3px or 4px thick indicators. Are we saying those are unnecessarily large?

On not obscured (minimum): Should "(minimum)" be in the understanding document? I take it we intend for this to be in the SC text, right?

On not obscured (enhanced): If I have a navbar, and the first item of it sits on the left edge of my screen, and I have a focus indicator that goes around that, part of that focus indicator is clipped. From how I read this SC, it sounds like that's a failure. This is going to be very common, and I'm not sure it actually makes a difference as long as the focus visible part of the focus indicator meets that minimum area requirement. I think this SC, as written now, is a good deal too strict, even for AAA.

Why is the AAA criterion about having the focus indicator obscured, while the AA one is about not obscuring the UIC.



Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update I was tempted to make the not obscured wording consistent between the two (one talks about the focus indicator, the other the component), but I wanted to be able to say I was adding nothing new with this split into a separate SC.

It's tempting to remove the exceptions from Enhanced, but I think it would result in a lot of very visible focus indicators (including two-toned) failing AAA. If we want to keep it crisp and clean, it's an option, as long as we understand the limitations.
Bruce Bailey Agree with the update
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree with the update I think this makes it much easier to understand. I am open to the updates suggested.
Alastair Campbell Agree with adjustment Given the new structure of the SC, could we just keep the primary bit and not include the exceptions?

5. DONE: Tackling wrapped text-links using "border" CSS

Previously Gundula had raised that focus indicators using border on wrapping text links should pass.

The problem arises when you use CSS border (not outline), and a wrapped text-link leaves a gap on each side of the separated link.

Michael Gower is proposing a different solution to the same problem, where we add to the perimeter definition to outline why wrapped links are ok:

"For text links, the perimeter can be established based on how the link would appear contiguously across a single line. Links that break across multiple lines are not considered to have a larger perimeter."

This is implemented in PR 2420.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 7
Agree with adjustment
Something else 1

Details

Responder DONE: Tackling wrapped text-links using "border" CSSComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the update I understand it can (specifically if the result is smaller), it doesn't have to (specifically if the result would be larger than taking the wrapping link as one shape. (We have seen examples.))
David MacDonald I don't have strong opinion on this.
Andrew Kirkpatrick Agree with the update
Ian Kersey Agree with the update
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else Firstly, why does this say "text links". We're making the assumption that links are the only things that can wrap. That's probably not the right thing to do here. I think we can reuse language from the target size exception here. Maybe, "the component wraps onto multiple lines as part of a sentence or block of text"?

More problematically, this introduces fairly significant new problems. Let's say I have a link that wraps over 3 lines. The line is 300px wide, with a line height of 16px. That link then has a 300 width and 48 height, resulting in a 696px perimeter. If instead I ignored the line wrap like the new wording suggests, and pretended the link is just 900px wide and 16 tall, the perimeter of that is 1832px. That's a lot bigger.
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update
Bruce Bailey Agree with the update
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree with the update
Alastair Campbell

6. DONE: Adjacent contrast

One of the (agreed) changes was to use "adjacent colors" in the last bullet point:

Has a contrast ratio of at least 3:1 against adjacent colors, or is no thinner than 2 CSS pixels.

The previous version of this was:

Where the area is adjacent to the component, it has a contrast ratio of at least 3:1 against the component or a thickness of at least 2 CSS pixels.

In practice the difference is slight, but would mean:

  • A focus indicator that uses a gradient would need to have a 2px minimum thickness because it would (probably) not contrast with the rest of the indicator.
  • A focus indicator that is not adjacent to the UIC is still required to have adjacent contrast with the surroundings. For example, if the indicator appeared adjacent to another control or a different background would be required to have contrast (or thickness).

Wilco raised this in issue 2333.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 7
Think we should revert to the previous version 1
Something else 3

Details

Responder DONE: Adjacent contrastComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the update
Peter Bossley Agree with the update
Jaunita George Agree with the update
Gundula Niemann Agree with the update
David MacDonald
Andrew Kirkpatrick
Ian Kersey Agree with the update
Todd Libby Something else I like the proposed solution Mike Gower gives here: https://github.com/w3c/wcag/pull/2341/
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else Mike proposed a solution in PR https://github.com/w3c/wcag/pull/2341/ that I think works here.
Laura Carlson Agree with the update
Charles Adams
Michael Gower
Bruce Bailey Agree with the update
Jonathan Avila Think we should revert to the previous version I think the original way comparing the indicator to its surroundings is easier to understand and takes away an extra step where you have to compare a focus indicator to itself.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Something else See: https://github.com/w3c/wcag/pull/2341/files

7. DONE:Adjusting sub-component requirement

There was a question of the last section of the SC text which is currently:

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components.

The question was: Does that mean the requirements apply to both the component and the sub-components?

The intent was not to apply to both, so the word "instead" has been added.

Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), if the focus indicator is applied to the sub-component then these requirements can be applied to the sub-components instead.

Note that there is some flexibility, the requirements "can" be applied to the sub-components, but the author could decide that it is better to apply to the parent component instead or as well.

There is a section of the understanding document which covers this scenario.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 9
Agree with adjustment 1
Something else

Details

Responder DONE:Adjusting sub-component requirementComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the update
Peter Bossley Agree with the update
Jaunita George Agree with the update
Gundula Niemann Agree with the update the link yields a 404 error
David MacDonald
Andrew Kirkpatrick
Ian Kersey Agree with the update
Todd Libby Agree with the update
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree with the update This addresses one of the biggest concerns I have with the SC; that determining the boundary of a UIC is difficult to do consistently. This change largely mitigates the need for this, which is excellent.
Laura Carlson Agree with the update
Charles Adams
Michael Gower
Bruce Bailey Agree with adjustment My main concern was/is for providing flexibility for meeting the SC to the page owner/author and not to provide rational for third-party auditor to fail a reasonable implementation. This has/is addressed.
Jonathan Avila Agree with the update I agree - only the sub-component needs to have focus - although it can be useful for both to have it - I don't think that was ever a requirement that we were solving for.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

8. DONE: Bounding box for separated links #2323

Gundula posted in a recent survey question and it was transferred to issue 2323.

There are two suggestions, one is to expand the definition of minimum bounding box to:

the smallest enclosing rectangle aligned to the horizontal axis within which all the points of a shape lie. Where a component consists of disconnected parts, such as a link that wraps onto multiple lines, each part is considered to have its own bounding box. Insert: In such a case, the base for further measurement is the concatenation of all boxes for disconnect parts. In the example of a link that wraps onto multiple lines the resulting box would enclose the same link if it would not wrap.

The second suggest was to update the normative from "a" to "the" minimum bounding box:

Is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, or an area at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component;

Should we:

Summary

ChoiceAll responders
Results
Update the definition 3
Update the normative text 1
Both 1
Something else 2

Details

Responder DONE: Bounding box for separated links #2323 Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel Update the definition
Peter Bossley
Jaunita George Update the definition
Gundula Niemann Something else There are several creative ideas how to indicate that a focus indicator continues over disconnected parts (usually a wrapping link). I would not exclude any of them by a measurement definition which is too strict.
David MacDonald
Andrew Kirkpatrick
Ian Kersey Update the normative text
Todd Libby Both
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else I don't understand what it means to concatenate rectangles. What is the mathematical name of what you are hoping to do to these shapes? I really don't know what is meant with this.
Laura Carlson
Charles Adams
Michael Gower
Bruce Bailey Update the definition
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

9. DONE: Updaxed understanding document

The question regarding "Replace 'encompasses' with 'encloses'" was accepted, and in the last meeting we agreed to use "Encloses", it's definition, an update to "minimum bounding box", the note on declared values, and "adjacent colors" in the SC text. The updates can be previewed.

These updates (when the understanding doc is updated) should allow us to close issues:

The understanding document adds some explanation around these factor. Preview of the changed document.

Remembering that further changes can be made later, do you:

Summary

ChoiceAll responders
Results
Agree with the updates 4
Agree, with adjustment 2
Something else 1

Details

Responder DONE: Updaxed understanding documentComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree, with adjustment I do not agree to the following part of the definition for bounding box:
"Where a component consists of disconnected parts, such as a link that wraps onto multiple lines, each part is considered to have its own bounding box."
With the existing definition, a focus indicator is suggested to fully enclose (with four solid lines) each of the disconnected parts, resulting in the appearance of several focus indicators. Next, the link could be named something like "a more detailed view", the part on the first line being "a". As a result the length of the shortest side is the length of the "a", which does not follow the intention of the SC.
Suggestion:
add "In such a case, the base for further measurement is the concatenation of all boxes for disconnect parts. In the example of a link that wraps onto multiple lines the resulting box would enclose the same link if it would not wrap."

The definition of minimum bounding box implies there is only one minimum bounding box for a given UI element. Consequently, the normative text should say 'the minimum bounding box', not 'a minimum bounding box'.
David MacDonald
Andrew Kirkpatrick Something else I don't know if I raised this previously or if it was discussed when I was off the call, but I find it difficult that we are setting requirements within an exception. I would far rather see the formulation: "things must do (a/b/c) OR (d/e/f) EXCEPT when x/y/z"
Ian Kersey Agree with the updates
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree, with adjustment I think the "against adjacent colors" addition now prohibits fading focus indicators.
Laura Carlson
Charles Adams
Michael Gower Agree with the updates I have done substantive changes to the Understanding document. It still needs images added, and I'm thinking of revamping the whole star examples, but I think there is still pretty good supporting material for the most part.
Bruce Bailey Agree with the updates
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree with the updates

10. DONE: Out-of-viewport content #2204

Pavel asked, in Issue 2204 about a scenario where a menu can be hidden (sometimes) as you are tabbing through it.

The response says that it already covered by 2.4.7.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 10
Agree, with adjustment
Something else 3

Details

Responder DONE: Out-of-viewport content #2204Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer Something else I can follow Michael Gower's reasoning. If there has been no agreement whether "there is a mode of operation" could include scolling something hidden back into view and this can be seen as meeting 2.4.7, the issue may be better answered by referring to the new SC ("focus not fully obscured", or whatever the eventual name)?
Oliver Keim Agree with the response
Caryn Pagel Agree with the response
Laurence Lewis Agree with the response
Stefan Schnabel
Peter Bossley
Jaunita George Agree with the response
Gundula Niemann Agree with the response
David MacDonald Agree with the response
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the response
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Something else I disagree with that response. Or rather, I thought it was true, but we didn't get anything like consensus in the working group of that interpretation. It's the whole reason that this bullet was added to Focus Appearance.
I've added a response to the issue that outlines my understanding of the background and the intention.
Bruce Bailey Agree with the response I am also +1 for "not entirely hidden due to author-created content""
Jonathan Avila Agree with the response
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Something else I had forgotten the 'mode of operation' argument that MichaelG mentioned.

Changing "not entirely hidden by author-created content" to "not entirely hidden due to author-created content" makes sense to me.

11. DONE: Updated understanding document for "encloses"

The question regarding "Replace 'encompasses' with 'encloses'" was accepted, as such this is an update to the understanding document to add some explanation. Preview of the changed document (mostly near the top).

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 9
Agree, with adjustment 4
Something else 1

Details

Responder DONE: Updated understanding document for "encloses"Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer Agree with the update minimum bounding box definition:
"Where a component consists of disconnected parts, such as a link that wraps onto multiple lines...":
I just wonder what other things apart for the example gven after "such as" readers might consider to have its own bounding box. Could it ever apply to graphic elements having disconected parts?
Oliver Keim Agree with the update
Caryn Pagel
Laurence Lewis Agree with the update
Stefan Schnabel
Peter Bossley
Jaunita George Agree with the update
Gundula Niemann Something else whether 'surrounds', 'encompasses' or 'encloses' is used, in my opinion does not influence whether it needs to be clarified the enclosing line is solid.
I prefer 'encompass'. I like the definition 'solidly bounds'.
David MacDonald Agree with the update
Andrew Kirkpatrick Agree, with adjustment I find the term "encloses" odd when used in "encloses the visual presentation" form. Do we just want to say "creates a solid border around the complete visual presentation of the user interface component"?

Maybe we discussed this already, but it also seems strange to define focus requirements in the SC body and in the exception. Maybe we need a "Regular focus appearance" and "Irregular focus appearance" pair of SC and meeting either one is an exception to the other?
Ian Kersey
Todd Libby Agree with the update
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree, with adjustment Should this new "Has a contrast ratio of at least 3:1 against adjacent colors.
" bullet be "against all adjacent colors"? Otherwise this could be understood as meaning "against some adjacent colors".

"Access" should be axis

I don't think the active sub-components requirement works. It seems to me that any component that has a sufficient focus indicator, if it has sub-components, that component's indicator will meet all requirements on behalf of its active sub-components.

I.e. we're need to say that the focus indicator of a sub-component has to be different from that of the owner UIC.


I re-repeat that I believe that it is not possible to consistently determine the visual boundary of a user interface component.
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update The diff folks should look at for all the changes from the prior version is here https://github.com/w3c/wcag/pull/2283/files#diff-5141b6e15e630ef38c219252b621af594f043b323334776f948912eb043a05f1
Bruce Bailey Agree with the update Note repeats the word <q>note</q>.

In the note, we use the word <q>can</q> twice. Is this word the best one to convey that it is an option for the developer? Other options: are, should, allowed, should, may, is permitted.
:
Jonathan Avila Agree, with adjustment This would seem to not allow for when the focus indicator was on the border. If the indicator lies on the border - what does that mean for the area and adjacency? We need to communicate what happens in this situation and also when the indicator lies on the border of the component and also is outside - 1px ring on the border and 1px ring abutting the border on the outside.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree, with adjustment Noting that further edits will be needed, but this is a good start.

Topic for discussion: This changes the normative text in the exception to include any adjacent colours not just those of the component. However, the alternative is to put back in "Where the area is adjacent to the component" from the previous version, which is missing.

I would prefer the previous scope but am ok with the proposed change.

12. DONE: Replace "encompasses" with "encloses"

In recent meetings we have agreed to progress with a re-worked version of focus appearance (preview).

One part of that still under discussion was the use of "Encompasses" in the first part, which some people were not sure meant solid.

A recent suggestion from MichaelG was to use "Enclosed" instead, so the SC would start:

When a user interface components has keyboard focus, the focus indicator:

  • Encloses the visual presentation of the user interface component;

The definition would be: "Solidly bounds or surrounds".

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 10
Agree, with adjustment
Something else 1

Details

Responder DONE: Replace "encompasses" with "encloses"Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer Agree with the update @David MacDonald; I don't think the way it is phrased rules out dotted line enclosure als long as it meets the "area of the focus indicator" exception.
Oliver Keim Agree with the update
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George Agree with the update
Gundula Niemann Something else whether 'surrounds', 'encompasses' or 'encloses' is used, in my opinion does not influence whether it needs to be clarified the enclosing line is solid.
I prefer 'encompass'. I like the definition 'solidly bounds'.

David MacDonald Agree with the update I have to admit I'm a little uneasy with forbidding a dotted line. It was one way to get a 2 colour focus indicator. But can live with it.
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the update
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update
Bruce Bailey Agree with the update Encloses connotates "solidly bounds" better than 'surrounds' or 'encompasses' -- thank you.
Jonathan Avila Agree with the update I personally don't think the exact term makes a huge difference - it's how we define what it means that makes the difference.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree with the update

13. DONE: User-Interface Component as basis for size

We have previously discussed using terms other than "User Interface Component", with inconclusive results.

We have also discussed using various basis's for size including the target size, the underlying code, and the perceived size.

The proposal in the document is:

  • We use "User interface component", which is based on the perceived control.
  • One input to that perception is what has a focus indicator (passing 2.4.7). E.g. if you tab to a component and it shows a focus indicator, that is useful for working out the size of the component.
  • It can be the element (e.g. a link), but it could be larger or smaller than that based on what you see. For example, a button with no background/border could have any size indicator that is bigger than the content (text) of that button.
  • The component with perecived focus may be an active descendant of a component. I.e. focus for the UIC is NOT based on browser’s programmatic focus. See the aria examples towards the end of the table in the document.

You can see useful examples for this interpretation that include the text “#UIC-SIzing” in the document.

Do you:

Summary

ChoiceAll responders
Results
Agree to using User Interface Control as the basis of size 9
Something else 1

Details

Responder DONE: User-Interface Component as basis for sizeComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik Agree to using User Interface Control as the basis of size
Detlev Fischer Agree to using User Interface Control as the basis of size
Oliver Keim Agree to using User Interface Control as the basis of size "User Interface Component" should be used consistently, also the "sub component", if the decision is to use "User Interface Component" although ISO Standards make use of "User Interface Element" and "items" for subordinate content.
Typo, should probably be "User-Interface Component as basis for size".
Typo, "perceived"
"element" should probably be "component", see "it can be the element (e.g. a link)"

The document may avoid to use abbreviations, such as Y and N and alternatively show "passes" and "fails".
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree to using User Interface Control as the basis of size Provided, the term 'User Interface Component' was meant here, as described and as used in the proposal in the document.
I assume 'User Interface Control' is a typo. If not, I object.

Remark:
In the note it says "NOTE: Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), this Success Criterion applies to the item with keyboard focus"
The note should end with a period.
In the last phrase it should say 'sub-component' instead of 'item', as the term item is used only in the example, in the main clause it says 'sub-component'.

Further down the heading explaining 'UIC' talks about 'User Interface Control', while the proposal uses 'User Interface Component'. This should be fixed and be consistently 'User Interface Component'.

In the table of example, I feel there is a high cognitive workload by asking questions as column headers and giving the answers as abbreviations. Instead, the column headers should name the condition and the cell entries should say pass or fail, respectively. I feel that is easier to process.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else UIC is fine. No problem with it. But I disagree with the idea that, because UIC says as "perceived by users", that people will understand that to mean the visual size of the component. It's sort of making the assumption that the only way to perceive something is through sight. That's just not true.

Previous iterations of this SC also used "UIC" and we took that to mean the programmatic size of the component. I don't understand how we changed the proposal on how to test this, while keeping the wording the same? We need to be very clear about how to determine the size of components, otherwise we're going to have major issues inconsistencies in testing.

Secondly, I have a strong dislike for using the visual presentation alone to determine the size of a component. I don't think testers can do that consistently. Take the example of a card with an image and a text. What is the component there? The entire thing? The text? The intuitive thing to do there is to just look at what's actually marked up as the link, and use the border box of that, even if users might perceive that card as a complete component, if the text is the only thing that can be activated it doesn't make sense to expect focus around the card.

I previously created edge cases, including ones on why I think appearance alone doesn't work for this SC: https://codepen.io/wilcofiers/pen/OJjrddm
Laura Carlson Agree to using User Interface Control as the basis of size
Charles Adams
Michael Gower Agree to using User Interface Control as the basis of size I'm assuming you mean "User interface component" and that this "User-interface control" in the survey question was someone asleep at the wheel...

Could we please get a clean PR that shows the wording. It seems to be in flux still, and while I firmly support the direction we're going, it's a bit unnerving having a moving target during a survey.

Wilco, your examples serve as good cases of why this SC cannot rely on programmatic target alone (and how if someone wants to come up with really bad designs to try to game SCs, it's always possible). Yet it seems fairly straight forward to apply the latest wording to most of the examples you cite. All but the oval fail the SC wording without exceptions (they don't encompass or in the case of your cloud background don't meet contrast).
I would say any designer who put your monstrous oval example in front of me would be hit with a sock full of manure :) That aside, from a pure 'is this sufficiently visible?' perspective, it's the one that has the best chance of passing. I haven't run the math, but it looks like it fails based on the outline shape (but would pass if the completely pointless outline shape were removed). It's going to come down to a debate on what the heck the oval shading is trying to convey. Is that supposed to be part of the UI component? What's the intent of this design? Such a discussion to me is all to the good, and if this SC causes some discussions before someone tried to release this to the world, it's another argument for why this latest wording is in the right space!
For the exceptions, 1, 2 and 5 fail area, and 4 (clouds) fails contrast (in both bullets).

Bruce Bailey Agree to using User Interface Control as the basis of size
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree to using User Interface Control as the basis of size
Alastair Campbell Agree to using User Interface Control as the basis of size Replying to other commenters:

- The proposal is what is under the section marked "SC: Focus Appearance (minimum) AA", apologies that the survey question had "control" in the title (although they are used inter-changably in WCAG).

- The rest of the information in the documennt is for our discussion, it will need to translated into a PR and the understanding doc will need updating.

- "It's sort of making the assumption that the only way to perceive something is through sight", this SC is about visible focus indicators, I think it is fair to use visual perception as the basis for what is perceived for this SC.

- "Previous iterations of this SC also used "UIC" and we took that to mean the programmatic size of the component." We also had a note that made the measure more specific, and the understanding document will need to expand on this aspect as well.

- "Take the example of a card with an image and a text. What is the component there? The entire thing? The text?" That is one of the examples in the document, and I think fairly easy to evaluate (manually).

- "The intuitive thing to do there is to just look at what's actually marked up as the link." That was my approach before Christmas, but we've had too many examples where that doesn't work.

- "I previously created edge cases...":
-- Items 1 & 2: Doesn't meet the perimeter, or the 4 * shortest size metric.
-- Item 3 (oval): Doesn't meet the perimeter, and a bounding box around the visible control (including shadow) would be 84px tall, so would require 336px area. The size of the outline (without border-radius) is 324px, so definitely doesn't meet the size metric.
-- Item 4 (over background pic): From a quick sampling, only the left hand quarter of the indicator has >3:1 contrast (more on the top than bottom), so doesn't meet the size metric.
-- Item 5 (larger background button than foreground visuals): I think that meets the primary metric, and is a good example of what that's easier with this method than going by the underlying code. The non-focused outer border has so little contrast that when the focus is applied it meets both change and adjacent contrast, and goes around the item.

- "it's a bit unnerving having a moving target during a survey" - nothing has changed during the survey, but prior to that I did line up the exception bullets with the wide-review version.

14. Note on sub-components / active descendants

As part of the updates shown in the Focus appearance reboot document, we added a note:

NOTE: Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), this Success Criterion applies to the item with keyboard focus

The purpose is to make clear that when evaluating the SC you would use the item with focus rather than the parent.

The other notes (that you can see in the editor's draft at the moment) have been removed as they do not seem to be needed with this version.

Do you:

Summary

ChoiceAll responders
Results
Agree with the addition 7
Agree with adjustment 5
Something else

Details

Responder Note on sub-components / active descendantsComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik Agree with adjustment
Detlev Fischer Agree with adjustment "this Success Criterion applies to the item with keyboard focus". may be ambiguous for readers - you use the keyboard to move focus down a dropdown list.
Oliver Keim Agree with the addition the button in "Box shadow" is not pixel perfect in the focused state. The pixels at the rounded corner may be white to keep the rounded corners of the button.
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the addition
Peter Bossley
Jaunita George
Gundula Niemann Agree with adjustment The note should end with a period.
In the last phrase it should say 'sub-component' instead of 'item', as the term item is used only in the example, in the main clause it says 'sub-component'.
David MacDonald
Andrew Kirkpatrick
Ian Kersey Agree with the addition
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree with adjustment This is a bit odd as a note. "sub components" are not applicable for this rule. This introduces an additional requirement. We can not add normative requirements to notes; notes are not normative. I think a better way to do this is through that "Additional, ..." thing we had at the bottom of the previous version of this SC.

I would suggest rephrasing this, something like this:
> Where a user interface component has active sub-components (for example, an opened drop-down menu shows a list of menu items), the above requirements apply to the indicator of the active sub-component.
Laura Carlson Agree with the addition
Charles Adams
Michael Gower Agree with the addition I'm not averse to tinkering with this wording, but I think the note is sufficient. More clarity on it can be included in the Understanding document.
Bruce Bailey Agree with the addition
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree with adjustment I recommend changing "item" to "component or sub-component". "Item" introduces a new term and potential confusion.
Alastair Campbell Agree with the addition

15. Not including the 1px perimiter metric

There is one change in scope compared to the previous version: When using the primary part of the new SC text, it does not allow for indicators with gradients, or thick indicators that lack adjacent contrast. However, the exception will cover almost every circumstance of that.

Mathematically, a 1px outline around a component will always be bigger than a 4px bounding box multiplied by the shortest side, except for:

  • A circle (or very circular oval) will have a 1px perimeter that is slightly smaller than the minimum. That would pass the primary part of the SC if it has contrast, but it would not if it included a gradient/halo. There is an example in the table in the document.
  • A square component with drop-shadow (or other decorative effect). E.g. a 100x100px square would have a 396px perimeter, or a 400px area for the exception metric (that is where the "1px perimeter" and "4px shortest side" metrics meet). With a drop-shadow the visual expands it but neither metric is met by a simple outline that doesn’t include the shadow.

Any rectangular element with an outline will pass even if it has a decorative effect expanding the visible size of the element.

An option for this aspect is to exclude ‘decorative effects’, e.g. “encompasses the user interface component, excluding decorative effects”, however that is difficult to define.

Another option is to add the 1px perimeter metric as another way of meeting the guideline in the exceptions. E.g:

An area of the focus indicator:

  • is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, OR
  • is at least as large as a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, AND
  • (Other bullets)

This adds to the complexity of the exceptions.

Should we:

Summary

ChoiceAll responders
Results
Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC 5
Accept some additional complexity and add the 1px perimeter metric to the exception 2
Something else 3

Details

Responder Not including the 1px perimiter metricComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik Accept some additional complexity and add the 1px perimeter metric to the exception
Detlev Fischer
Oliver Keim Something else in the document the sentence "White outline on a dark grey shadow, where the shadow visually increases the size of the button." indicaters a larger button, but the button has the same size. The shadow may help to perceive the button as a larger element, but the physical size remains equal, for unshadowed or shadowed state.
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Something else In the past, we had the wording "an area of the focus indicator meets the following". We can use it again.
It is not complex, it just says, if a part of the focus indicator fulfills, it fulfills as a whole.

So it could say:
"When a user interface component has keyboard focus, an area of the focus indicator meets the following:"

The exception already talks about an area of the focus indicator in the relevant place.

The second bullet point in this question rather describes an issue arising when including the shadow of the focused component into the size measurement. A shadow does not increase the visual size of the element, it adds emphasis, but not size. Accordingly, the size of the focused User Interface Component should be measured without shadow or halo.

I did not see an example where the focus indicator itself has a shadow or halo and is not a browser default. So I did not find the example referred to in the first bullet of this question.



David MacDonald
Andrew Kirkpatrick
Ian Kersey Accept some additional complexity and add the 1px perimeter metric to the exception
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else This isn't just a problem for ovals. This is true for anything with rounded or clipped corners. I wouldn't consider those rare.

I'm not all too sure what a "decorative effect" is. In WCAG lingo isn't everything that doesn't require semantics under 1.3.1 a decorative effect?

I'm all in favor of simplification on this SC, but while well intentioned, I feel this new proposal has had the opposite effect. It's a good attempt, but it has added complexity and it has failed to account for edge cases that the current version did.
Laura Carlson Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC
Charles Adams
Michael Gower Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC I think simplicity of text overrules these few edge cases. They do not suffer from a 2px indicator.
Bruce Bailey Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC I am also okay with second choice to accept some additional complexity and add the 1px perimeter metric to the exception.
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC
Alastair Campbell Accept that some rare 1px perimeter cases may fail (requiring a 2px indicator), keep the proposed SC Oliver wrote: "The shadow may help to perceive the button as a larger element, but the physical size remains equal, for unshadowed or shadowed state."
Gundula wrote: "A shadow does not increase the visual size of the element, it adds emphasis, but not size. "

AC: Unless we have a good definition of "decorative" that includes shadows, which we then exclude from the size metric, a shadow will increase the perceived size of the component. If you ask someone to draw a box around a component, I think they would include the shadow. Therefore the outline in the shadow example is *inside* the component, and doesn't pass the primary part of the proposed SC text.
These comments really apply to the next question.

Gundula also wrote: "In the past, we had the wording "an area of the focus indicator meets the following". We can use it again.
It is not complex, it just says, if a part of the focus indicator fulfills, it fulfills as a whole."

AC: We had quite a few comments saying that it is complex, that is why we tried to lead with a simpler version to start with, and put the complexity into the exception.

Wilco wrote: "This is true for anything with rounded or clipped corners.".

AC: Not really, they have to be square or close to that. E.g. a very short link with text in it, like <a>Link</a> in the browser defaults is 29 x 19px. Therefore the 4 * shortest size metrix = 76px. The outline is 96px. You can't loose 20px in corners without overlapping the text! It has to be close to square/round
It will apply to things like checkbox & radio buttons, but I think that's a good case where a thicker indicator is warranted.

16. Definition of Encompasses

The new version in the document uses a new definition termed "encompasses".

Continuously surrounds, bounds or includes the whole of

The "continuously" was added to address concerns that you could just put little lines on each corner with big gaps in it.

The definition is used in "When a user interface component has keyboard focus, the focus indicator... encompasses the user interface component"

There was a suggestion to add to the definition "... except for effects that appear to be outside the boundary of the control". However, that would require you to evaluate:

  • what constitutes a decorative effect;
  • what the boundary is without the decorative effect;

That brings in some new problems. The alternative is that the exception is used. For example, if a button has a drop-shadow and uses a standard outline, the outline will be over the shadow, inside the boundary of the component. The "drop shadow" example in the document shows a passing version of this method. See also the section on "scope change".

Do you:

Summary

ChoiceAll responders
Results
Agree with using the defintion 7
Agree with adjustment 2
Something else 2

Details

Responder Definition of EncompassesComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik Agree with adjustment
Detlev Fischer
Oliver Keim Agree with adjustment
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with using the defintion
Peter Bossley
Jaunita George
Gundula Niemann Agree with using the defintion Decorative effects mainly are shadows and halos.
Effects needed to identify the UI component are not decorative.
This can be explained well.
David MacDonald
Andrew Kirkpatrick
Ian Kersey Agree with using the defintion
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else I think we should abandon this rewrite and go back to our currently approved wording.
Laura Carlson Agree with using the defintion
Charles Adams
Michael Gower Agree with using the defintion I think "continuously" makes it clearer for some people and does not detract from the prior definition.
I would be very concerned if we added "effects that appear outside the boundary". There be dragons.
Bruce Bailey Something else Just for clarification, does the common "marching ants" animated dashed line outline "continuously surrounds, bounds or includes the whole of"? (I think/hope so.)
[ Ref: https://en.wikipedia.org/wiki/Marching_ants ]

Late post-meeting change to this survey: marching ant selection (dashed borders, has marks, etc.) should NOT need the exception.
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree with using the defintion Consider adding clarifications about effects to the understanding document or as a note to the definition.
Alastair Campbell Agree with using the defintion Bruce: If it were thick enough it would pass via the exception. (Although I'm not a big fan of animated focus indicators in general, some people might find that quite off-putting.)

17. DONE: Focus appearance Updates

In recent weeks we have reviewed an overhaul of the SC text from Michael Gower,
please see this overview of the update with test cases.

Recently resolved items include:

  • Separating the 'unobscured' aspect helped to make the SC simpler, and moved out the timing aspect to that SC. The group considered that a fading indicator was not sufficient (for the baseline for authored content).
  • Using "user interface component" as the object of scope.

Although this is one update, and one big survey question, in the meeting we will cover these topics as individual items (plus any others raised in the survey comments):

  • The proposal assumes that the vast majority of 'decorative effects' such as drop-shadow would pass via the exception. The alternative is to ignore decorative effects (see the "Scope change" section).
  • Using the UIC perceived size for the metric (Issue #2226).
  • Solving the problem of 1px outlines not being sufficient due to taking a border box (Issue 2222)
  • Application to 'active descendent' items (Issue 2237), which is covered in the document linked above.

The overall question is whether to accept the proposal, but please do make comments on any of the sub-points.

Summary

ChoiceAll responders
Results
Agree with the proposed SC updates 1
Agree with adjustment 5
Something else 1

Details

Responder DONE: Focus appearance UpdatesComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with adjustment datalist: the selected item is neither reflected to value of the input field, nor is the focus visible in the list when using Apple macOS Zoom or Windows Magnifier and large zoom levels. Does "focus visible" include the fact the focus is also visible in huge magnifications and magnifiers are able to detect the "real focus"? Some browser's data list would not conform to this requirement.
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann I don't see the first point: How would decorative effects pass? Are decorative effects of the UI components meant here, or decorative effects of the focus indicator? As I read it, a focus indicator with 1px width with some low contrasting decoration added does no longer pass, as only the exception says 'an area of the focus indicator is' and requests it to be 2px wide, which is not the case in my example.

I don't see which kind of size goes into the metric. It just says 'encompasses', but leaves open, how the UI component is determined. By the way, encompassing does not imply it exceeds a 1px outline in area, as also dotted or dashed lines can encompass an object. Even marking the corners by wedges would encompass.

David MacDonald
Andrew Kirkpatrick Agree with adjustment Think that we should remove "has a contrast ratio of at least 3:1 against adjacent colors." in two places - this is already covered by 1.4.11
Ian Kersey
Todd Libby
Suzanne Taylor Agree with adjustment I think anything that imitates something that in the real world is outside of an object, such as a shadow or a reflection, should be considered to be outside of the UIC. I think a) this would be more intuitive, b) this will help with odd cases, such as shadows that are far away from their components in 3D environments, and c) perhaps most importantly, this would avoid encouraging 1 pixel focus indicators that are far away from a component out at the edges of gradually fading drop shadows
Melanie Philipp
Wilco Fiers Something else Firstly, I'm uncomfortable with a change this substantial. If we're going to go this route, I think we need to put out another working draft. As for the details, here are some things that I'm spotting from just an initial review:

- Given the definition and sort of the common-sense meaning of "encompasses", I think a 1px dotted line could pass this SC now. It did not in the previous iterations.

- This now means that a 1px outline that has sufficient contrast can conform, but if you draw a fade with insufficient contrast around that 1px outline you would fail the SC.

- I very much think we need something in the normative text to help determine the size of a component. Just going off of "as perceived by the user" leaves far too much room for interpretation in my opinion.

- The word "defined" in "the focus indicator is defined by the user agent" is an odd choice of wording to me. I think maybe determined is more appropriate? Or set?

- Personally, I'm not keen on repeating the contrast bullets.

- I continue to be concerned with us prohibiting animated / fading focus indicators without any researching about them.
Laura Carlson
Charles Adams
Michael Gower Agree with the proposed SC updates I was happy with how the new text worked when scrutinizing all these border cases that have been brought forward. Where a design is clear, things pass consistently. Points of debate tend to crop up where a design lacks clarity, but the exception language seemed to accommodate those in situations where the focus indicator was clear and gave context.
Also crucially, with the exception of some user agent defaults, there did not seem to be cases where a poor focus indicator passed.
The definition of "Encompasses" seemed to work consistently in all test cases.
I find the term "indicator's background color" less clear than "page background color". We changed that based on someone's suggestion, but I'd like to get a better idea of what exactly we're covering besides page background.
Thank you Alastair for all the grunt work of getting these samples together. I'd like to think it can form the nucleus of some documentation that can be incorporated into the Understanding document, or linked to from that document as research.
Bruce Bailey Agree with adjustment Great work! My only suggested adjustment is for AAA Focus Appearance (Enhanced) to delete <q>Except when the focus indicator is defined by the user-agent and cannot be adjusted by the author.</q> Rational: SC are AAA mostly because they are not applicable to all technologies, so the exception seems redundant to me.


Jonathan Avila Agree with adjustment I agree that we have to include descendant items that are focusable. The term UIC isn't as clear on this as I'd like and so I'd suggest a note to cover what we describe elsewhere in the document on how focusable descendants of the component are being covered. I want to make sure this is not just in the understanding document but actually in a note or something.

Secondly, I don't think we define what the focus indicator background is when we talk about the user agent exception. The way I read it is that if you modify the background color where the focus indicator is whether that is of the component or of the page background then you are on the hook to meet the requirements. I can agree to that. If this is not the case then I'm sure if I agree or not with this. I think this approach is a good compromise as if you have changed the colors of the component or page background then you need to take some responsibility yet many default situations would pass when you don't modify the page on control background allowing default states to pass.

Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

18. DONE: Focus appearance and user-agents, again

On December 21st we had a discussion about focus visible and user agents, and resolved to "Carry on with the SC as it is and provide guidance in understandings that browsers can fulfil the SC if you test it, with 1 objection requesting including a default focus indicator."

This issue has been raised again in issue 2201.

Uncontested points included:

  • Chrome and Edge (about 75% of desktop browser share) now include an option to add a forced focus indicator.
  • There is no similar mechanism for mobile usage (over 50% of global browser share).
  • The default indicators for Firefox and Safari are still problematic.
  • The SC as written does allow for default indicators to pass, which maybe useful in closed environments where the browsers are known.

There were also points made about the difficulty of implementing the SC, although this was contested both on the actual difficulty, and that we have got to this point by trying to balance the user need with the flexibility and complexity.

Another contested point is how effective the forced focus indicators are because they fade after a couple of seconds. (See the issue thread for more.)

Please consider how/whether an SC should account for browser variations. For example, does an advanced/accessibility setting in a browser fulfilling the user need? Would author effort on this SC take away from other requirements?

Another aspect is whether this should be something that authors have to tackle when it could be accomplished by user agents. For context, we have SCs which:

  • Can only be fulfilled by authors, such as Headings and Labels.
  • Are better when fulfilled by authors but the requirement can be somewhat met by user-agents, such as alt-text.
  • Are intended to make sure that sites function well when user-agents do over-ride the authored styles, such as text-spacing / sizing.
  • Can be met by the user-agent or the author takes on the requirement if they update it, such as non-text contrast.
  • Can be fully met by user-agents, but that may not be popular/known enough, such as 1.4.2 (muting a tab)

The original intent (coming from developing 1.4.11) was to ensure that poor browser defaults are not enough (article summary from Adrian Roselli). The SC does allow for browser defaults to meet the SC if they meet the requirements, but it does not allow for meeting the SC using extra settings / AT.

The suggestion from the thread is to add an exception: "except where the appearance of the focus indicator is determined by the user agent and not modified by the author".

Do you think we should:

Summary

ChoiceAll responders
Results
Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. 12
Add an exception for browser defaults 3
Drop both focus-appearance SC (i.e. you consider that the browser features fulfil the need).
Drop the AA SC but keep the AAA SC

Details

Responder DONE: Focus appearance and user-agents, againComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Sarah Horton Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Michail Yasonik
Detlev Fischer
Oliver Keim Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Caryn Pagel
Laurence Lewis Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
David MacDonald Add an exception for browser defaults I could live with any of these.
There are good arguments for each of the options.
I do feel that a lot of the discussion around focus indicators is academic. For instance,
- the number of sighted (or partially) mobile users who operate mobile with a bluetooth keyboard and therefore would be negatively impacted by the lack of visual focus indicator is very small
- I find the highly visible focus indicator a lot more critical for myself as a tester, than for the users with disabilities who I've accommodated over the years. (Many have AT that does that, or have CSS solutions)
- I agree that its been broken in browsers for a long time, but Chrome and Edge changed the game... I expect FF and Safari, will jump on now that the leaders are doing it.

The complexity of the SC concerns me which weighs against it.

My personal preference, would be to leave the SC in the standard and allow the author to pass it by not overriding browser defaults. I understand it leaves a gap but it will simplify the standard for those who are already overwhelmed with the increasing number of SCs.
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp Add an exception for browser defaults Unfortunately, this survey question only covers a portion of the issue I filed. I’ll copy parts of the larger question here so others can see it.

I specifically asked that we pivot away from the Chrome/Edge Accessibility Settings feature to the larger philosophical question this SC brings to light: Assigning accessibility responsibility to the logical Component of "web development and interaction” discussed on the W3C’s WAI page: Essential Components of Web Accessibility https://www.w3.org/WAI/fundamentals/components/

I think of the components described by Essential Components of Web Accessibility as a “three legged stool”:
1) Users
2) User Agents: browsers, media players, assistive technologies, and other “user agents”
3) Content Authors: content contributors, developers, authoring

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) 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 and/or referenced by courts as non-voluntary requirements. So, that’s a different matter. Forcing Content Authors to overcome User Agent deficits is going too far.

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 for this SC.
Wilco Fiers Add an exception for browser defaults I think it's very reasonable to expect user agent defaults to result in sufficient contrast.

There are even scenarios where it's literally impossible to solve this problem without an overhaul to the design. For example the Chrome PDF viewer always shows a black outline. As far as I'm aware there is no way for content authors to affect that. Without this exception, we'd effectively prohibit dark backgrounds on links in PDF.

Additionally, I feel strongly that this SC needs to allow accessibility features in browsers to eventually make this SC obsolete. I think that's already the case, but we really should make that more explicit. I agree that without this option for mobile, this can not be relied on today. But it would be the saddest thing in the world to me if we wrote this in a way that would forever prevent browsers from solving this massive problem.

2022/02/22: Just to weigh in with an example. WBS is a system that uses browser defaults for input / textareas. Depending on the browser, that may or may not conform. Do we really think it's fair to make them responsible for problems with browser defaults? Or worse yet, caused by us never having defined what a minimally acceptable focus indicator is? I keep seeing fingers pointed at browsers, but honestly, aren't we a little responsible too for not having defined what size / contrast a focus indicator should have? Now that we've wrote this down, they've started to try and improve.
Laura Carlson Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Charles Adams Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Michael Gower Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. I'm trying to incorporate Melanie's feedback into a new version. See below.
Bruce Bailey Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. I am not in favor of the second option (explicit exception) since I agree with the concerns that it defeats the point of creating 2.4.11.

Options three and four are not my preference, but I could tolerate.
Jonathan Avila Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Mary Jo Mueller
Rachael Bradley Montgomery Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. I think the SC is valuable guidance and while some browsers provide a possible solution that can be utilized in closed environments, there is not a mobile solution in place nor is there a solution that is easily available in all browsers. We should make sure the SC is written so authors know that if all browsers including mobile meet the SC with the default focus indicator, they do not need to do anything. An exception in this SC would negate it's value.
Alastair Campbell Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. I created a PR for adding a paragraph to the understanding about closed environments. https://github.com/w3c/wcag/pull/2209/files

Also, on the point of focus indicators which cannot be updated by the author (e.g. PDFs, or select drop-downs) I created a PR with such an exception: https://github.com/w3c/wcag/pull/2225

19. DEFUNCT: Focus appearance updates

Based on the (un-discussed) survey responses last week, Alastair put together one PR to wrap all of the changes into one new version in PR 2230, which you can preview.

NB: It doesn’t show the links to definitions there, but none are new definitions. Also, the understanding document will need an overhaul if the SC proposal is agreed.

To summarise the updates:

  • Added an exception for when the user-agent does not permit styling of the component.
  • Incorporated most of Andrew's understandability update, except the 'adjacent' bullet.
  • Adjusting the size metric to use the definition of User Interface Components, but set the minimum size as a bounding box around the content of the control, i.e. the text or icon. See Issue 2226 for more on that specific update.
  • Move the timing aspect to only apply to the ‘obscured’ clause, which is where it was intended to target originally.

From the discussion on list, it appears that discussion of the sizing method is where we should focus. For example, moving from using the perimeter to using a bounding box around the content.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates 6
Agree with adjustment 3
Something else 2

Details

Responder DEFUNCT: Focus appearance updatesComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the updates
Sarah Horton Agree with the updates
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the updates
Caryn Pagel
Laurence Lewis Agree with the updates
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the updates The requirement should also be reflected in the User Agent Guideline, so that the exception for user-agents does not come into action.
David MacDonald Agree with adjustment The note is a bit awkward. It could be clearer but I wonder if for simplicity, we could just drop it?

>> NOTE: The content of the component can be text or images. For blank inputs the bounding box contains the area that content would go if it were filled.
or reword it for something like this?

... For blank inputs the bounding box contains the area that would contain content if it were filled.



Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else I'm uncomfortable making a change that is this substantial in a single pull request. I think we need to separate this out so each change can be decided on separate. A PR like this makes this seem like an all or nothing deal, which it isn't.
Laura Carlson Agree with the updates
Charles Adams
Michael Gower Something else I've been working on a version which I'm finding even in its draft form easier to read and understand.
It retains all the complexity of the existing SC, but like Wilco did with Target Size, seeks to put the 'best foot forward' and leave the exceptions as... exceptions. https://docs.google.com/document/d/18a4_iDprrXty2Mh4LwNqwKKC7nuklMtNkk0bueFyo9M/edit?usp=sharing
Bruce Bailey Agree with adjustment I agree with the updates.
As I have mentioned in a couple thread, I do not agree with the choice to have a requirement following a bulleted list:

> "Additionally, when a component receives focus, it is not entirely hidden by author-created content."

This detail IMHO should be in the opening condition, before the bullets.
Jonathan Avila Agree with adjustment I generally agree with the updates - but I'm still sure not of the impact of bounding box of content vs. the component.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

20. DEFUNCT: Suggested update for understandability

In a previous discussion AndrewK suggested an update to the SC, aiming to keep the requirement the same but make the text easier to understand..

The suggestion was implemented in PR 2182. This was previously surveyed with just a couple of comments to update

The update was to address the concern that it opened up a loophole for the adjacent contrast, which was addressed by changing "focus indicator" to "contrasting area" in the adjacent contrast bullet (in this update).

It also updates the intro to say "meets all the following" (addressing Bruce's comment about consistency).

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 6
Agree with adjustment 1
Something else 1

Details

Responder DEFUNCT: Suggested update for understandabilityComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis Agree with the update
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the update
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else The "Adjacent contrast" bullet still has a normative change. It now sort of assumes that when the focus indicator is adjacent to the component, that the contrasting area is too. In trying to make this easier we lost accuracy. I think the previous version was better.
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update
Bruce Bailey Agree with the update This part of this SC is okay with me, but "when an the item receives focus, is not entirely hidden by author-created content" remains misplaced IMHO. Item 4 of this survey is more on point I think.
Jonathan Avila Agree with the update
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree with adjustment Tend to agree with Wilco, but suggest this to align with the other updates:
"Where the contrasting area is adjacent to the component, it has a contrast ratio of at least 3:1 against the component or a thickness of at least 2 CSS pixels."
The "contrasting area" is the change to the current text.

21. DEFUNCT: Update to 'component' language take 2

There is a problem with using "user interface component" as the scope of focus-appearance, which is that the definition scopes it the appearance of a component, and it doesn’t (seem to) cover descendant elements which get keyboard focus such as grid items or options in a select. To summarise the issues:

  • Scoping to the appearance leads to odd results for components which have effects like drop-shadow, and items like "cards" where CSS/JS can be used to disguise what the component is. Different people would get very different results for the question: how big is this component.
  • User-interface components include, as one thing, active descendents like grid cells or drop-down options. That would leave the thing the user thinks has focus out of scope.
  • We don’t want to require focus indicators on non-interactive things like landmarks.
  • We don't want to cause confusion by adding a similar term to user-interface controls.

Alastair tried wording that would remove the concept of component so that it was anything with focus, but that became a self-referential mess.

The starting sentence of the SC which sets this scope is:
"When [things] receive keyboard focus, the focus indicator meets the following:

Suggestions for “things” are:

  • "Components"

    (Four SCs use just “component” without “user interface”: 1.3.3, 2.1.2 Keyboard Trap, 2.4.3, 3.2.4.)

  • Elements

    (Used by 4.11 in a similar way to our intent here, and “visual element” is used by 1.4.1 in a different way.)

  • Controls

    (Two SCs use “control” as a noun without “user interface”: 1.1.1, 2.5.5.)

These would be combined with a term to ensure it is only interactive things that are in scope, e.g. keyboard operable components. The PR that would be updated by this decision is PR2188.

Which would be your favourite (yes and prefer), ok (yes), just about ok (yes but prefer not) and couldn't tolerate (no).

Summary

ChoiceAll responders
NoYes, but prefer notYesYes, and prefer
Components 2 1 20 3
Elements 4 22
Controls 1 3 21 1
Something else 2 1 23

Ranking of choices in order of least unacceptable/most prefered:

RanksAll responders:
1Controls
2Components
3Something else
4Elements

Details

Responder ComponentsElementsControlsSomething elseComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Yes Yes Yes Yes
Sarah Horton Yes Yes Yes Yes
Michail Yasonik Yes Yes Yes Yes
Detlev Fischer Yes Yes Yes Yes
Oliver Keim Yes Yes Yes Yes
Caryn Pagel Yes Yes Yes Yes
Laurence Lewis Yes, but prefer not No Yes, and prefer No
Stefan Schnabel Yes Yes Yes Yes
Peter Bossley Yes Yes Yes Yes
Jaunita George Yes Yes Yes Yes
Gundula Niemann No No No Yes I prefer 'user interface components'.
Each element, component or 'thing' we talk about is on the user interface. On the other hand, control is a technical term which does not always coincide with what is focused.
An element often describes a smallest entity (in Chemistry, for example), which is not meant here.
A component can have subcomponents, like tables have rows, columns, cells, and cells can have components as children. Also selection options are subcompoents of dropdowns.So I don't see the second issue.
The requirement starts 'when a user interface component receives focus ...', so when an component is not interactive, it by nature does not fall into the scope of the requirement. Therefore I do not see issue 3.
To solve Issue 4, the term should be used consistently, unless a different term is more appropriate for the context. To be concrete: I feel in 1.1.1 the term 'control' is adequate, while in 2.5.5 the term 'user interface component' might be more appropriate.
David MacDonald Yes Yes Yes Yes
Andrew Kirkpatrick Yes Yes Yes Yes
Ian Kersey Yes Yes Yes Yes
Todd Libby Yes Yes Yes Yes
Suzanne Taylor Yes Yes Yes Yes
Melanie Philipp Yes Yes Yes Yes
Wilco Fiers No No Yes, but prefer not Yes I'm not sure I understand what problem this is trying to solve. UIC seemed appropriate to me.
Laura Carlson Yes Yes Yes Yes
Charles Adams Yes Yes Yes Yes
Michael Gower Yes, and prefer No Yes, but prefer not Yes I still think UIC linked to the definition works. That definition includes a note that reads:
'What is meant by "component" or "user interface component" here is also sometimes called "user interface element".'
Bruce Bailey Yes, and prefer Yes Yes Yes, but prefer not Just to be clear, my understanding is that "components" and UIC are synonyms. I would argue that this is true for 1.3.3, 2.1.1, 2.4.3, 3.2.4 *and* this SC.

If some believe "components" and UIC are *not* synonyms -- I think we need an hour just for that conversion.
Jonathan Avila Yes Yes Yes Yes
Mary Jo Mueller Yes Yes Yes Yes
Rachael Bradley Montgomery Yes Yes Yes Yes
Alastair Campbell Yes, and prefer Yes Yes, but prefer not No (Saying 'no' to the generic something else, but I would revise that if a good something else was suggested.)

22. DEFUNCT: Time limited focus indicators

JonA raised Issue 2219 about the first part of the SC text, "When user interface components receive keyboard focus".

This text was used to ensure that the item receiving focus is itself visible, so that its focus indicator provides some benefit. It also acknowledges that there are circumstances where the viewport or content may end up hiding the focused element after it gains focus.

At the time we had not considered indicators which fade out after a short time.

Also remember that 2.4.7 focus visible has text in the understanding document that says "The focus indicator must not be time limited, when the keyboard focus is shown it must remain.". However, focus-visible doesn't define what visible means.

MichaelG suggest updating the start and end of the SC to make that aspect only applicable to the "obscured" part. This has been implemented in PR 2223.

Do you think we should:

Summary

ChoiceAll responders
Results
Accept PR 2223 2
Accept PR 2223 with adjustment 2
Something else

Details

Responder DEFUNCT: Time limited focus indicatorsComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis Accept PR 2223 with adjustment With correction proposed by Patrick H Lauke in the PR
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower
Bruce Bailey Accept PR 2223 with adjustment Please move the requirement that "the item with focus is not entirely hidden by author-created content" into a bullet or into the opening condition.

We do not have other SC with requirements following a bulleted list. This would be a new pattern.

We do have SC with exceptions following a bulleted list, but that probably is not an option here.

Jonathan Avila Accept PR 2223
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Accept PR 2223

23. DEFUNCT: Update to 'component' language

After the previous discussion on focus-appearance and how to measure the size of a component, a couple of small changes were discussed to make that clearer. These have been implemented in PR 2188.

The aim of the change is to:

  • Make it clear that it is the underlying size of the component that is the basis for measurement, and in HTML that aligns to the location of the CSS border.
  • Remove 'user interface component', because that definition is based on perception of the component.

Do you:

Summary

ChoiceAll responders
Results
Agree with the change 2
Agree with adjustment 2
Something else 1

Details

Responder DEFUNCT: Update to 'component' languageComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the change
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree with adjustment Instead of "If the component size is not programmatically available", I think this needs to be "In technologies where the component size is not programmatically available", so that it is clearer this does not apply to HTML.

---
Unrelated, but I'm going to continue to raise that this SC is already obsolete. The focus ring that can be enabled in Chrome and Edge works well. I've been using it since I learned of it and I don't intend to turn it off again. We can't just make this the sole responsibility of content authors anymore now that user agents are starting to solve this.
Laura Carlson Agree with the change
Charles Adams
Michael Gower
Bruce Bailey Agree with adjustment I am okay with with update, but +1 for Wilco edit. Per Wilco observation that UA are on the cusp of solving this (my understanding is that the contrast is not really sufficient), I will suggest we consider adding "until user agents" type of clause.
Jonathan Avila
Mary Jo Mueller Something else I looked up what designers might call these things on the Nielsen Norman Group website where I found them using the term "clickable item". Will that work?
Rachael Bradley Montgomery
Alastair Campbell

24. DEFUNCT: Suggested update for understandability

In a previous discussion AndrewK suggested an update to the SC, aiming to keep the requirement the same but make the text easier to understand.

The suggestion was implemented in PR 2182.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 6
Agree with adjustment 1
Something else 1

Details

Responder DEFUNCT: Suggested update for understandabilityComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the update
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the update
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the update I recommend to allow rounded rectangles and circles besides bounding boxes (which are usually rectangle) as basis for the calculation. Note one of the examples is a circle. (A circle is a square with maximally rounded corners, so the concept 'rounded rectangle' covers the named shapes.)
David MacDonald
Andrew Kirkpatrick Agree with the update
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else I'm not sure this was intentional, but this changes the requirement on adjacent contrast. The 2px thickness exception now is applied to the entire focus indicator, rather than only to the contrasting area. That seems like it could be a substantial problem. A 1px line can easily end up with a 2px thickness because of aliasing.
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update
Bruce Bailey Agree with adjustment It is an improvement, but for closer consistency with 2.0 pattern (which uses "...ALL the following") I suggest:
1) outer list use OL instead of UL
2) last item (additionally...) be third item in list
3) change "the focus indicator meets the following" to "the focus indicator meets all the following"
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

25. DONE: Size basis for focus-appearance

Based on a previous conversation a discussion document has been created to outline the arguments for the current approach, and for using target-size as the basis for the size measure in focus-appearance.

The questions to consider are:

  • Is using the concept of component sufficient for calculating the size of a component?
  • Are the niche problem cases for either approach a blocker?
  • Would using the target size be a better approach

Should we:

Summary

ChoiceAll responders
Results
Carry on with the current approach, focused on 'component' 4
Change to use target size as the basis 1
Something else

Details

Responder DONE: Size basis for focus-appearanceComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Change to use target size as the basis
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Carry on with the current approach, focused on 'component'
David MacDonald
Andrew Kirkpatrick Carry on with the current approach, focused on 'component'
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower
Bruce Bailey Carry on with the current approach, focused on 'component' I am also okay w/ shift to "target size", even though that might mean more conversation around check boxes and radio buttons.
Jonathan Avila Carry on with the current approach, focused on 'component'
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

26. DEFUNCT: Using target- area as the basis for size metrics

Wilco would like to use the target-size of the component as the basis for size metrics.

PR 2147 makes the change in the SC text. If we agree this, the understanding document will need updating.

Please consider:

  • How you thought the size of a component would be measured before.
  • Components which use javascript to increase the hit area.
  • Components which have 'extra' stuff around their boundary, e.g. drop-shadow.

An alternative would be to leave the SC text alone, and update the note from:

"If the component has a visible boundary smaller than the hit area, or the size of the component is not available, the minimum area can be taken from the visible boundary." to

"The component size is measured up to and including the border. If the size cannot be programatically determined you can use the visible boundary. If there is no visible boundary you can use the bounding box."

Should we:

Summary

ChoiceAll responders
Results
Change to using target size as the basis for measuring components 9
Update the note 4
Something else 3

Details

Responder DEFUNCT: Using target- area as the basis for size metricsComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims Change to using target size as the basis for measuring components +1 to what David MacDonald said
Gregg Vanderheiden Change to using target size as the basis for measuring components Absolutely. in fact having a small visual target and a large active area is a good technique for more accurate pointing. (and Notes are not normative usually)
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer Change to using target size as the basis for measuring components I don't see anything wrong with using target size as a basis for measurement if that can simplify an automatic approach to measurement (no one, I believe, is looking forward to start calculating the focus area of targets on a manual basis) but I may not be sufficiently aware of loopholes that might appear. So it might be worthwhile going through edge cases (Alastair will have some in stock, I guess) to see what this change would imply for those.
Oliver Keim
Caryn Pagel
Laurence Lewis Update the note
Stefan Schnabel Something else Update the note but define the bounding box size in it. is is the same like size + border if they were there? What about white space?
Peter Bossley
Jaunita George
Gundula Niemann Something else The term target area is also used in the target size Success Criterion and implies some white space around the hit area. Using the term here as well might lead to confusion and misunderstandings.
I think the current wording of the note is closer to the intention.
Also, the hit area can be determined while testing (manually), while the new wording suggests the size must be determined programmatically, if possible.

David MacDonald Change to using target size as the basis for measuring components I don't have a problem with the proposed text. It add a bit of complexity to an already complex SC, but I understand that it may make it possible to evaluation the SC with automation.

A precedence for this might be the complicated calculation for colour contrast becomes a black box and authors just use colour contrast tools. (but that calculation is not part of the SC language.)
What would be ideal would be to have some sort of a name for the calculation and then reference it in the SC text...

I don't object to alternatively updating the note if it accomplishes the same thing of making the SC evaluated automatically.
Andrew Kirkpatrick Update the note I don't think that we should make it the target area. There is benefit to just clarifying this as written.
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp Change to using target size as the basis for measuring components
Wilco Fiers Change to using target size as the basis for measuring components 1. Target should be linked to the definition
2. Rather than remove that note, I think we should replace it with something like this:

> Some components have an "extended" target, where both the component and a larger container are interactive. Even in such cases the minimum area is taken from the component's target area, not the container.
Laura Carlson Change to using target size as the basis for measuring components
Charles Adams
Michael Gower Something else I had though the size would be determined by the shape's appearance. My gut tells me that while target area may be easier for machine testing, it ignores the reality that the target area often does not correlate to the physical appearance of a control: it may be larger, it may be smaller. This is a somewhat design-oriented SC; this change makes it more developer oriented. I think we need thorough investigation into possible ramifications.
Bruce Bailey Change to using target size as the basis for measuring components My preference is for the PR, since having the text mention "area" is good. I am also okay with updating the note.
Jonathan Avila Update the note The target area could make it harder to meet and more confusing on how to test. This could mean potentially larger indicators if there are larger target areas.

I am considered that perhaps this might fail outlines that don't have an outset outline.

if we went with target we'd need to address the situations with form fields with labels.
Mary Jo Mueller
Rachael Bradley Montgomery Change to using target size as the basis for measuring components
Alastair Campbell Update the note

27. DEFUNCT: Focus Appearance complexity #1842

priyankad7 raises issue 1842 to say it is too complex.

Alastair created a proposed response.

UPDATE: We have separately discussed the user-agent aspect and resolved not to include an exception for that.

For the comments agreeing that it is too complex, we iterated this a lot and we have found another "triangle", adjusting one of these factors positively will then negatively impact the others:

  • How easy the SC is to understand;
  • How large a range of design options are available;
  • How accurately it maps to the user-benefit.

There is a simpler version, it is at AAA level because it reduces the design options. We could allow for known poor-indicators to pass. These are the options for making the SC simpler.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 10
Agree with adjustment 3
Something else 5

Details

Responder DEFUNCT: Focus Appearance complexity #1842Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims Something else This SC is unreasonably complex to test. It may be possible to use at a design phase...but HELLO, testing for this SC as written is a burden higher than any SC in the history of WCAG. Rather than throw this SC out...let's take a smaller (reasonable) step forward.
Gregg Vanderheiden Agree with the response
JaEun Jemma Ku
Kim Dirks Something else I agree that the example is helpful, but the response doesn't fully address or acknowledge the issue: this SC is too convoluted, and is very difficult to understand. The complexity is greatly exacerbated by the overly complex wording of the SC. It would be helpful if this SC used plain language. I have suggested this in the past and offered ideas on how to simplify as far back as TPAC in Japan but these efforts have been rejected. Q1
Abi James
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer Agree with the response
Oliver Keim
Caryn Pagel Something else The additions and changes to this SC since issue 1842 was initially raised are helpful. I do not, however, think the SC has been simplified at all. I do not feel confident that I can explain this SC to a tester, designer, developer or product owner.

FWIW, the same issues remain that I raised in 1439, which is very similar to what's been raised in 1842.
Laurence Lewis Agree with the response
Stefan Schnabel Agree with the response
Peter Bossley
Jaunita George
Gundula Niemann Agree with adjustment Thinking and reading, I suggest to change the order of the three bullet points.
I feel it makes the requirement more consumable as it follows the way of diving into the topic.
First 'contrast'
second 'adjacent contrast'
third 'minimum area'
This order is closer to how to look at and think through the focus indicator visuals and thus might be easier to perceive.
David MacDonald I would like to examine WIco's suggestion to see if it helps. I agree that the complexity of this SC surpasses any other in the history of WCAG 1.0, 2.0 or 2.1.
Andrew Kirkpatrick Agree with adjustment I agree that this SC is useful and should stay, but I suggested some changes in the wording earlier that I think might help make it more easily comprehended:


@alastaiir - I think I was. Here's my updated suggestion:

When user interface components receive keyboard focus, the focus indicator meets the following:
• Contrasting area: The focus indicator has an area with a contrast ratio of at least 3:1 between the colors in the focused and unfocused states, and that area is at least as large as either:
o the area of a 1 CSS pixel thick perimeter of the unfocused component, or
o the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no part of the area is thinner than 2 CSS pixels.
• Adjacent contrast:
o When the focus indicator is shown by changing the appearance of pixels which are immediately adjacent to the user interface component, the focus indicator must have a contrast ratio of at least 3:1 against the component or a thickness of at least 2 CSS pixels.

Additionally, the item with focus is not entirely hidden by author-created content. (– not needed due to 2.4.7)
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp Something else I agree with the commentor regarding the complexity of this SC.

I've advocated in the past, and I will do it again more strongly here, for an exception for default browser indicators to be added to the SC... or drop the SC altogether given advances in the browser world:

1. Without an exception for browser defaults, we are requiring every website engage Design, Development, and QA staff to design, implement, and test a custom default indicator for each type of focusable control on their site. We are also requiring accessibility auditors to do some convoluted calculations when assessing someone else's website.

2. Allowing web authors to rely on the default focus indicator means that the collective time that designers, developers, QA, and auditors will NOT have to spend understanding, designing, developing, testing, and auditing custom focus indicators could be put to better use on other accessibility issues.

3. Between Chrome and Edge's recently-enhanced focus indicators and their accessibility-enhanced focus indicators (Chrome: Settings > Advanced > Accessibility > Show a quick highlight on the focused element; Edge: Settings > Accessibility > Show a high visibility outline around the area of focus on the page) the desktop browsers with over 75% usage share already substantially fulfill the user need of this SC - without any added extensions or AT required. The premise I've heard over and over again for why AGWG wants to force content authors to do the heavy lifting on this topic is because "the browsers have done nothing after years of our asking" and that appears to be untrue.

More generally... we are so focused on content authors that we are trying to force them to do things that user agents, AT, and/or users are more suited to solve. Instead, we should collaborate with others to make improvements where they are most logical. This content-author-centric view comes at a high cost to people with disabilities (PWD) because:

- It diverts energy away from training and implementation on things content authors really must do and turns people off to accessibility. The hours spent on this SC alone have made my brain hurt. How can non-experts NOT view accessibility as a huge, confusing burden given how we've struggled to define and explain this one SC?
- It limits the positive impact for people with disabilities to only those sites that adopt and successfully meet a particular WCAG version instead of improving things across-the-board, including sites that will never adopt or successfully meet WCAG - which is the majority of sites out there.

Compared to the collective time and energy AGWG members have spent one this one SC, how much time and energy has been spent reaching out to collaborate with browser manufacturers on topics where they can give PWD a big lift at a much lower collective cost? Chrome and Edge, the desktop browsers with >75% usage share, appear to be willing to act.
Wilco Fiers Something else I strongly disagree that removing parts would render the SC useless. Any part of that SC can be removed without making it "useless". I don't think we can ignore this feedback. I think we have two solutions; Either dramatically reduce the complexity of this SC, or make sure it can be automated so people don't have to know. I have a preference, but I can accept either one of those. Doing neither, and arguing we can't is not acceptable to me.
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with adjustment I suggest the response provide a link to the Understanding document, possibly even the figure. Even though the images discussed are in the published version, it makes sense to make it easy to locate

https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#focus-indicator-strong

BTW, figure 14 seems to be missing in both the published version and latest editor's draft.
Bruce Bailey Agree with the response
Jonathan Avila Agree with the response
Mary Jo Mueller
Rachael Bradley Montgomery Agree with the response
Alastair Campbell Agree with the response This is a reply to the other respondants:

Wilco - If you remove either the size, adjacency, or change of contrast then there are common examples of focus indicators which are obviously not 'visible'. That is obvious from running through the test cases, so I think saying 'useless' is justified, but I'm happy to use another word for that.

Gundula - I don't think re-ordering will make much difference, and we have been back and forth a couple of times on the order and it is quite delicate to change.

David & Glenda - We've been testing this for a year, in practice it take much LESS time than 1.3.1 or 4.1.2, or text contrast if you report every instance of both. In fact, compared to just testing focus styles for non-text contrast it is much clearer. (Not to mention trying to work out the flash threshold.)

Melanie:

Point 1 (focus style per type of control) - this isn't true. We've supported several organisations implement this from the design stage, and it has required 1 or 2 types of focus style (dark background and light background).

Point 2 - Relying on default browser styles means not meeting the user need, this is well established and was intended to be tackled by non-text contrast.

Point 3 - Chrome's (fairly hidden, advanced) setting is good. Edge's version is good on some backgrounds, but poor (2:1) on a white background and they both disappear after a couple of seconds. It's possible the large size of it compensates for the lack of contrast, but it is hard to say without research.

The broader point is that the SC *can* be fulfilled by the user-agent, but the question is then what is sufficient coverage? Currently we'd be leaving out anyone using FF or Safari. We provide some guidance on this already "It is generally best to either define a keyboard focus style which meets this criterion, or test the focus styles across the browsers that are relied upon for conformance."

Regarding collaborating with browsers, there are people who have tried without success. The groups efforts in this direction (user-agent guidelines) were blocked (or ignored, I wasn't here at the time) by the browser makers. It is entirely possible that the work on this SC prompted the effort indirectly, it is hard to say.

Andrew: I think you started from an older version of the SC? Also, I'm not sure it's a good idea to make the size only relate to the change of contrast. It /probably/ works, but I'm worried that having been down similar paths before there might be a gotcha.

28. DONE: Focus appearance and user-agents

Following the discussion on focus-appearance complexity, a question was raised about whether the user-agents are fulfilling the user-need.

Uncontested points included:

  • Chrome and Edge (about 75% of desktop browser share) now include an option to add a forced focus indicator.
  • The default indicators for Firefox and Safari are still problematic.

There were also points made about the difficulty of implementing the SC, although this was contested both on the actual difficulty, and that we have got to this point by trying to balance the user need with the flexibility and complexity.

Please consider how/whether an SC should account for browser variations. For example, is a (fairly hidden) setting in a browser fulfilling the user need? Would author effort on this SC take away from other requirements?

One possible way forward is to add 'mechanism is available' language to explicitly allow for browser-based solutions. For example, "A mechanism is available so that when user interface components receive keyboard focus, an area of the focus indicator meets the following:"

Do you think we should:

Summary

ChoiceAll responders
Results
Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. 5
Add 'mechanism is available' language. 6
Drop both focus-appearance SC (i.e. you consider that the browser features fulfils the need).
Drop the AA SC but keep the AAA SC. 3

Details

Responder DONE: Focus appearance and user-agentsComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden Add 'mechanism is available' language. Mech is avail -- allows authors to pass as user agents improve. We should always do that. Take that approach in provisions.

We should add a note in Understanding doc - to increase awareness. (make a technique?? about it? to increase awareness)

People who need this should be taught it - in same way as all other strategies for dealing with their disability - but it should be easy for people to know about it
JaEun Jemma Ku Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Kim Dirks Drop the AA SC but keep the AAA SC. Answering this one because it's so tied to Q1. Unfortunately, 2.4.11 (AA) is not as clear/mature as 2.4.12 (AAA). It is not ready for CR.
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel Drop the AA SC but keep the AAA SC.
Laurence Lewis Add 'mechanism is available' language. I suggest to add 'mechanism is available...' and provide some guidance for browsers forced focus indicator. Testing is required!
Stefan Schnabel Add 'mechanism is available' language.
Peter Bossley
Jaunita George
Gundula Niemann Add 'mechanism is available' language.
David MacDonald
Andrew Kirkpatrick Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. There is clearly a need for the SC, and even if some browsers support this already it is good to include as a requirement that will impact new browsers, help ensure the retention of the accessibility features in the browsers to ease developer work, and also may be applied to other environments where the support doesn't currently exist.

I do think that it might be worth a change to the SC text. I offer this suggestion because I think that it is easier to understand and doesn't force people to understand the relationship between the first two bullets, but recognize that we may have combined/de-combined/re-combined/de-re-combined these several times already. Here it is:

For 2.4.11 (AA):
• Contrasting area: The focus indicator has an area with a contrast ratio of at least 3:1 between the colors in the focused and unfocused states, and that area is at least as large as:
o Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component, or
o Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.
• Adjacent contrast: The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2 CSS pixels.
• Not fully obscured: The item with focus is not entirely hidden by author-created content.

For 2.4.12 (AAA)
• Contrasting area: The focus indicator has an area with a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states, and that area is at least double the area of a 1 CSS pixel perimeter of the unfocused component;
• Not obscured: No part of the focus indicator is hidden by author-created content.
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp Drop the AA SC but keep the AAA SC. Or allow an exception for relying on browser default as in 1.4.11.

Also... I object to the characterization of a setting in a browser's Accessibility settings as (fairly hidden). If you are willing to assign the large effort of meeting (and testing) this SC to every site owner in the world, surely assigning a little effort on the part of users to understand the accessibility features of their user agent is... reasonable?
Wilco Fiers My answer depends on what happens on question 2. If we accept that change, my preference is to keep the SC (option 1). If we don't, my vote is to drop it (option 3), but more because it's just not properly testable then because this new browser feature is so amazing.

I really appreciate browsers stepping up their game here. But what they currently do is significantly inferior to what the SC we're proposing requires. A focus indicator that fades out after a second is problematic for people who have full view of the screen. It also doesn't seem like that cyan outline I'm getting in Chrome actually meets the 3:1 contrast change we're asking for.

I would object to adding the word "mechanism" here. For example the mechanism available in Chrome works on sites with dark background, but for ones with lighter background a tester would need to check. Other browsers, and browser extensions might do other things still. "Mechanism" gets us into a scenario where the same page may have to be tested multiple times with multiple different focus indicator tools enabled to see if any of them work. That would be terrible.
Laura Carlson Add 'mechanism is available' language.
Charles Adams
Michael Gower
Bruce Bailey Add 'mechanism is available' language. Add mechanism is my 1st choice, carry-on 2nd choice. I am probably okay with choices 3/4.
Jonathan Avila Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it. The brief focus highlight feature in Chrome is flawed as it is only temporary and it also covers up other objects on the page and not something I would use as it's too obtrusive. Despite what people say it is hard to find A mechanism is already available with SC if browser uses a default focus indicator that supports. What mechanisms are allowed? According to WCAG assistive technology including extensions could be used to meet. Thus, you can just say ZoomText will always meet this and the author doesn't need to do anything - the SC is totally not needed.

The problem is that most people with less than 2020 aren't using something like ZoomText, keyboard only without visual impairments are not relying on that. Pages should have some level of reasonable focus indicator without having to turn on assistive technology.
Mary Jo Mueller
Rachael Bradley Montgomery Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.
Alastair Campbell Carry on with the SC as it is, provide some guidance that browsers can fulfil the SC if you test it.

29. DONE: Insufficient requirement for focus indication via enlargement #1858

Ben opened Issue 1858 about whether the examples are sufficient.

Alastair & David proposed a response, essentially - we agree but not allowing for those examples would create false-positives.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 9
Agree with adjustment 5
Something else

Details

Responder DONE: Insufficient requirement for focus indication via enlargement #1858Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims Agree with the response
Gregg Vanderheiden Agree with the response
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer Agree with adjustment I find the following part of the reponse very difficult to parse (I am really noi sure what it means):

"Overall, whilst it is a limitation, it is a necessary one to prevent creating false-positives"

What "it"? What limitation? What would be a "false-positive" here?

Oliver Keim
Caryn Pagel
Laurence Lewis Agree with the response
Stefan Schnabel no clear opinion
Peter Bossley
Jaunita George
Gundula Niemann Agree with adjustment I agree that a focus indication by enlargement is not sufficient, specifically as the enlargement requested (2px around) is quite subtle. The focus needs to be identifiable without interaction. Therefore I think it is not justified to rely on the user notifying the focus indicator moving around. This is specifically true if the user uses a magnification tool as well as if the user needs to look somewhere else than the screen to navigate (keyboard, remote control for TV, to name a few examples).
The reality examples referred to during the discussion are intuitively not accessible, that is users usually cannot identify the focus without tabbing or clicking around or asking someone to help find it.
therefore I suggest to drop the last two sentences.
In many contexts dynamically changing content is easier to spot, but we do not rely on it, as a user shall not be bound to see the change.

David MacDonald Agree with the response
Andrew Kirkpatrick Agree with adjustment Agree with the response but the term "false positive" seems a bit off in this context.
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp Agree with adjustment I agree with Detlev and Wilco that "false positive" is not the right phrase here.
Wilco Fiers Agree with adjustment I'd prefer not to use the "false positive" term here. It's a little odd. It's more that it would make the SC too strict in certain cases.
Laura Carlson Agree with the response
Charles Adams
Michael Gower
Bruce Bailey Agree with the response
Jonathan Avila Agree with the response
Mary Jo Mueller
Rachael Bradley Montgomery Agree with the response
Alastair Campbell

30. DONE: Focus appearance & Visual examples #2071

John Foliot requested visual examples be added to the normative guidelines document for focus-appearance in Issue 2071.

Alastair proposed a response (essentially "no, we have lots in the understanding doc").

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 11
Agree with adjustment 2
Something else

Details

Responder DONE: Focus appearance & Visual examples #2071Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims Agree with the response
Gregg Vanderheiden Agree with the response
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer Agree with the response
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the response Images and examples should be part of the understanding document, but not be part of the normative text.
David MacDonald Agree with adjustment Seems like some words are missing from the sentences?? How about this:

Up until now there have never been images as part of the normative text or linked from the normative text in an WCAG document. There are currently 19 visual examples in the understanding document including some at the top of the Understanding. We will continue to look for opportunities to make this Success Criterion more understandable in the text and refine the Understanding document.
Andrew Kirkpatrick Agree with the response
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp Agree with adjustment I agree with David MacDonald's recommendation.
Wilco Fiers Agree with the response
Laura Carlson Agree with the response
Charles Adams
Michael Gower
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree with the response
Alastair Campbell Agree with the response

31. DONE: Use of the word "state” is not sufficiently consistent #2049

In bladerunner issue 2049 Bruce raised that: WCAG 2.1 added the word "state" to the glossary for non-text contrast, which is a term that was already used by 4.1.2 Name/role/value.

Focus appearance (min + enh) uses the term "state" in the contrast bullet:

Contrast: The area has a contrast ratio of at least 3:1 between its colors in the focused and unfocused states.

Bruce is concerned that the usage in focus-appearance implies that 4.1.2. includes requirements for authors to programmatically expose all user interaction possibilities.

Alastair thinks that focus is a state, both visually and programmatically, but not one that authors need to worry about under 4.1.2.

There is plenty to read in issue 2049 if you'd like more details.

If we were to change focus-appearance it would be to something like:

Contrast: The area has a contrast ratio of at least 3:1 between the colors when the component is focused and when not focused.

Should we:

Summary

ChoiceAll responders
Results
Update focus-appearance to avoid the word 'state' 2
Leave it as it is 9
Something else

Details

Responder DONE: Use of the word "state” is not sufficiently consistent #2049 Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels Leave it as it is The updated text could be misunderstood as being about the user's perception of the component rather than about the current programmatic state of the component.
Glenda Sims
Gregg Vanderheiden Update focus-appearance to avoid the word 'state' it is clearer and avoids a technical term. we should always do that when possible.
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Leave it as it is
Sarah Horton Leave it as it is
Michail Yasonik
Detlev Fischer Leave it as it is
Oliver Keim Leave it as it is As focus is elsewhere named a "state" you may leave it as is.
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Leave it as it is The current wording using the term 'state' is much clearer.
The new version could be misunderstood as the component has to contrast when it is in unfocused and it also has to contrast when it is focused instead of a contrast between focused and unfocused.
Also, I agree that being focused is a state.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower Leave it as it is I don't have a strong opinion on this either way -- partially because I don't think I've digested all the fine points sufficiently.
I think that there are a few things in 4.1.2 that could be re-assessed. For instance, despite the fact it is called "Name, Role, Value" there is no definition of value. Both 'state' and 'property' are also unlinked terms in the normative text. I'm not sure if the absence of the cross-reference to state implies or explicitly means that it is not being used in the defined-term sense?

It's resided like this for a few years without big issues in the wild, so I'm inclined to leave it alone.
Bruce Bailey Update focus-appearance to avoid the word 'state' In my maybe-not-so-humble opinion, it is very bad for 2.4.11 and 2.4.12 to use "states" (in SC text) with a slightly looser meaning than it has with 4.1.2 and 1.4.11. The slightly more awkward phrasing is worth it in my view.
Jonathan Avila Leave it as it is
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Leave it as it is I still haven't seen a negative impact from considering focus a state, and I think other groups (including ARIA) have considered it a state.

32. DONE: Focus indicators for large editing areas #2017

We have previously discussed Issue 2017 regarding focus indicators for larged editing areas such as Documents and code editors. We generally agreed that this type of thing was not a distinct user-interface-control, therefore wasn't in scope.

Alastair and Michael created PR 2081 to add a paragraph to the understanding document to explain this.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 4
Agree with some adjustment
Something else 1

Details

Responder DONE: Focus indicators for large editing areas #2017 Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels Agree with the update However, the PR linked here is not correct, so some individuals may be responding to the wrong PR when responding to this particular question. I was able to find it by following the link to the Issue.
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the update
Sarah Horton
Michail Yasonik
Detlev Fischer Agree with the update
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Something else What is "an insertion point in such editing regions" ?
This should be clarified in the text.
Apart from this, I prefer the old text.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower Agree with the update
Bruce Bailey
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

33. DONE: What is a complex shape? #2050

Andrew asked in Issue 2050 why the word 'complex' was used in the definition of perimeter.

Andrew also provided PR 2051 to remove it.

We could also remove the other words, so that it says:
"continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest."

Do you:

Summary

ChoiceAll responders
Results
Agree with the change 8
Agree with the change with adjustment (e.g. the updated version) 2
Something else 2

Details

Responder DONE: What is a complex shape? #2050 Comments
Andrew Somers
Ben Tillyer Agree with the change
Jake Abma Agree with the change
Marc Johlic Agree with the change
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the change
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the change
Caryn Pagel
Laurence Lewis
Stefan Schnabel Something else Complex focus shapes should be possible (floating around complex object borders). This includes also circular focus shapes etc.
Peter Bossley
Jaunita George
Gundula Niemann Agree with the change with adjustment (e.g. the updated version) I'd rather not stick to either the complex shape exact perimeter or a surrounding box, but also allow a surrounding circle or oval.
One of the (positive, that is successful) examples is a surrounding circle.
David MacDonald
Andrew Kirkpatrick Agree with the change
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree with the change
Laura Carlson
Charles Adams
Michael Gower Something else The word was there for irregular shapes. My sense is without it, folks will wonder why we bother with the two measurements. Suspect we could trim it more to:
<p>continuous line forming the boundary of a shape not including shared pixels, or the <a>minimum bounding box</a>, whichever is shortest. For example, the perimeter calculation for a rectangle is 2<em>h</em>+2<em>w</em> -4, where <em>h</em> is the height and <em>w</em> is the width and the corners are not counted twice. The perimeter of a circle is 2????<em>r</em>.</p>
Bruce Bailey Agree with the change
Jonathan Avila Agree with the change with adjustment (e.g. the updated version)
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

34. DEFUNCT: Focus indicators for large editing areas #2017

From an issue originally raised by Michael Gower, Issue 2017 asks whether large editing areas should have an exception.

There is a response in the thread basically saying no.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 8
Agree with the response with adjustment 2
Something else 1

Details

Responder DEFUNCT: Focus indicators for large editing areas #2017
Andrew Somers
Ben Tillyer Agree with the response
Jake Abma Agree with the response
Marc Johlic Agree with the response
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the response with adjustment Keep requirements for focus consistent, focus ring around, no matter which size. For large text input areas the text caret is the second indicator identifying the detailed focus.
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the response
Peter Bossley
Jaunita George
Gundula Niemann Agree with the response +1 to
"I agree with the response to keep the requirement for large editable areas."
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else I think this is a completely valid scenario that deserves a response TBH.

---

This isn't asked in the survey, but I want to repeat my objection to the phrasing "When a user interface component has keyboard". The last time this was discussed the agreed on wording was "When a user interface component has a visible focus indicator".
Laura Carlson
Charles Adams
Michael Gower Agree with the response Would like to see the Understanding document address text areas.
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree with the response with adjustment For Michael's request that it is in the understanding doc, I created https://github.com/w3c/wcag/pull/2081

35. DONE: Focus appearance should be in Perceivable

Jake raised Issue 2037 saying that focus-appearance should be under the Perceivable category.

It is quite easy to change from an editorial point of view, just a little odd to separate it from 2.4.7.

Should we:

Summary

ChoiceAll responders
Results
Keep focus-appearance in Operable (2.4.x) 2
Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15 7
Something else

Details

Responder DONE: Focus appearance should be in PerceivableComments
Andrew Somers
Ben Tillyer Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
Jake Abma Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
Marc Johlic Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
Caryn Pagel
Laurence Lewis
Stefan Schnabel Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
Peter Bossley
Jaunita George
Gundula Niemann Move focus-appearance to Perceivable > Distinguishable > 1.4.14, 1.4.15
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower Keep focus-appearance in Operable (2.4.x) I believe this is under Operable because it is directed at a modality of operation. It only applies for keyboard _operation_. ("receive keyboard focus".) So although it clearly spans two principles, and the bar to meet the requirement is largely around perceivable considerations, it still makes some sense under Operable (just as Focus Visible already does).
Non-text Contrast ends up in Perceivable because it is NOT just about keyboard operations.
Bruce Bailey Keep focus-appearance in Operable (2.4.x)
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

36. DONE: Need more info on adjacent contrast #1929

Michael raised issue 1929 on the relation to non-text-contrast.

The 'adjacent' bullet has already been updated in a question above, so PR 2060 focuses on the understanding document. It makes a significant update, removing the examples with checkboxes, and putting in a simpler example of something which would pass non-text contrast, but fails this SC.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates 8
Agree with the updates with adjustment 1
Something else

Details

Responder DONE: Need more info on adjacent contrast #1929Comments
Andrew Somers
Ben Tillyer
Jake Abma Agree with the updates
Marc Johlic Agree with the updates
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the updates
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the updates
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the updates
Peter Bossley
Jaunita George
Gundula Niemann Agree with the updates
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Agree with the updates
Laura Carlson
Charles Adams
Michael Gower Agree with the updates with adjustment made a slight change to some wording. https://github.com/w3c/wcag/pull/2097
Bruce Bailey Agree with the updates
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

37. DONE: Inline elements that wrap over multiple lines #1328

Previously we had closed Issue 1328 by including a section of the understanding document which said that links split over lines could be treated as one area.

However, Michael Gower raised that in the majority case (outlines) this was not the case, and crucially it doesn't align with the logic of the boundary box. PR 2040 implements a change to reverse that logic.

Do you think we should:

Summary

ChoiceAll responders
Results
Approve PR 2040 7
Remove the section on this topic (it is too niche)
Something else 7

Details

Responder DONE: Inline elements that wrap over multiple lines #1328 Comments
Andrew Somers Approve PR 2040
Ben Tillyer Something else Although I understand the concept, I find both the original version and the wording suggested by PR 2040 to be confusing.
Unhelpfully, I cannot think of how to word it at the moment - I hope to revisit this before the call.
Jake Abma Approve PR 2040
Marc Johlic Approve PR 2040
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Approve PR 2040
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Something else If two focus are displayed the end user cannot decide which one has focus (double focus).
For screen magnifier users open focus visuals indicate the focus spans to another part of the control on the screen.
Caryn Pagel
Laurence Lewis
Stefan Schnabel Something else inks split over lines should be treated as one area.
Peter Bossley
Jaunita George
Gundula Niemann Something else Keep the text before the suggested change.
The missing fourth line indicates that the focused element continues in a different line and thus contains a valuable information in itself.
Having two complete rectangles as focus indicator might be perceived as a duplicate focus.
David MacDonald
Andrew Kirkpatrick Something else Is there an actual problem here? If I have a 2-line link the outline should be the same whether the link wraps or not, and the shortest side along the minimum bounding box will the the height of the line in all but the rarest of examples.
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Approve PR 2040
Laura Carlson Approve PR 2040
Charles Adams
Michael Gower Something else I think the wording change for line 227 is okay, but I'm wondering if we want to retain the example (with figcaption at line 230). To me it adds confusion on what is (let's face it) not the main concern with focus indicators. Link focus tends to be fine unless suppressed, and I don't see either of the implementations causing big issues. But I am concerned where our definitions and tests don't at least accommodate (or exclude) those differences.
Bruce Bailey Approve PR 2040
Jonathan Avila Something else I am confused. I believe it is now saying that if there is only a 1px border on 3 sides of each part of a split link then it would fail when links are split. If that is the case we should be more clear about it as it feels a little indirect and I'd rather us be clearer.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

38. DEFUNCT: Minimum Area shape requirement #1928

Michael Gower raised Issue 1928 suggesting a re-wording of the shape bullet.

The proposed response summarises that: A previous issue (1806) triggered a change to the bullet which appears to address the issue. Also, the suggestion in 1928 slightly adjusted the meaning in a way that would prevent some indicators intended to pass.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 3
Agree with the response with adjustment 1
Something else 1

Details

Responder DEFUNCT: Minimum Area shape requirement #1928Comments
Andrew Somers Agree with the response
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald Something else Interesting I just made a comment above about the shape bullet and then there is an issue on it. I don't think it is clear yet...

Do we mean something like this?

<li><strong>Shape</strong>: Calculated based on the <add>equivalent area</add> of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component and the indicator would be no thinner than 2 CSS pixels at any point.</li>
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with the response with adjustment I'm okay with David's rewording. I also wonder if we need to even talk about a 4 CSS pixel thick line. Can we just say an area equivalent to 4 times the short side of the bounding box? Something like
> The parts of a shape no thinner than 2 CSS pixels, covering an area equivalent to a 4 times the short side of a minimum bounding box of the unfocused component.

Also, do we need to state a 'contiguous shape'? I have concerns about someone creating a bunch of shapes and adding them up.
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

39. DEFUNCT: Adobe Comment #1887

Andrew raised Issue 1887, concerned about the understandability of the criterion.

The response in the thread says: After PR 2000 introduced a new part of the intent aimed at providing simple examples, this issue could be closed. The group will remain responsive to improvements.

Summary

ChoiceAll responders
Results
Agree with the response 6
Agree with the response with adjustment 1
Something else 1

Details

Responder DEFUNCT: Adobe Comment #1887 Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the response
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald Agree with the response Just a note. This sentence is a mouthful...

<li><strong>Shape</strong>: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.</li>

I see the latest draft has a bit of clarification
https://w3c.github.io/wcag/guidelines/22/#focus-appearance-minimum
Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no part of the contributing area is thinner than 2 CSS pixels.

I would like to try to get it a little less convoluted...
Andrew Kirkpatrick Something else Here's a version that I worked on and think is easier to understand:

When user interface components receive keyboard focus, all of the following are true:
• Minimum area: The focus indicator area is either:
o at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component, or
o at least as large as the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.
• Contrasting area: The focus indicator has a minimum area with a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.
• Adjacent contrast: The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2 CSS pixels.
• Not fully obscured: The item with focus is not entirely hidden by author-created content.

What's different? Here's the original:
When user interface components receive keyboard focus, all of the following are true:
• Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.
• Minimum area: The contrasting area is at least as large as:
o Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component, or
o Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.
• Adjacent contrast: The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2 CSS pixels.
• Not fully obscured: The item with focus is not entirely hidden by author-created content.
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with the response If this was for someone other than AWK, I'd want this to be worded more encouragingly, but I think he'll get the idea that he should look and see if this PR sufficiently addresses his concerns.
Bruce Bailey Agree with the response with adjustment I am ok w/ response, but +1 to grouping that AWK proposed in his response, as it seems clearer to me.
Jonathan Avila Agree with the response
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

40. DONE: Readability updates

Based on the discussions of issues 1887 and 1928 an update to the SC text has been made in PR 2059 to improve the readability of the SC, without changing the meaning or scope.

The SC text can be previewed in the understanding doc. Just note that only the SC text has updated, if this goes through we will need to update the rest of the doc to match.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 5
Agree if there is an adjustment (please comment) 2
Something else 1

Details

Responder DONE: Readability updatesComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the update
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the update
Peter Bossley
Jaunita George
Gundula Niemann Agree if there is an adjustment (please comment) I suggest to use the term 'contributing area' also in 'Contrast' and in 'Adjacent contrast',
this saying:
<li><strong>Contrast:</strong> The focus indicator contributing area has a contrast ratio of at least 3:1 between its colors in the focused and unfocused states.</li>
<li><strong>Adjacent contrast:</strong> The focus indicator contributing area has a contrast ratio of at least 3:1 against adjacent colors or a thickness of at least 2 CSS pixels.</li>
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers Something else This does change the meaning in two significant ways:

1. The adjacent contrast is no longer limited to the component.
2. This no longer seems to allow for focus indicators where some part meets the 3:1 contrast, and other parts don't. I'm assuming that's still intended, but I don't see how to read that in the normative language.

It also isn't clear what to do about adjacent contrast on focus indicators with a fade / blend effect. In the current version if there is some pixel between the contrasting area of the focus indicator and the component, then there is no adjacent contrast. But in this proposal it no longer says what pixels to consider as part of the adjacent contrast.
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update
Bruce Bailey Agree if there is an adjustment (please comment) I am not comfortable with "states" being used in SC text here when it is not *exactly* the same use as with 1.4.11 and 4.1.2.

> Contrast: The focus indicator minimum area has a contrast ratio of at least 3:1 between its colors in the focused and unfocused states.

Please replace "states" above with synonym such as "condition" or "presentation".
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery Agree with the update
Alastair Campbell

41. DONE: Update Technique G195 procedure #1931

Michael Gower suggested some updates to G195 in Issue 1931.

PR 2005 updates G195, but also creates a new version that meets the AAA version.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates 7
Agree with the updates with adjustment 3
Something else

Details

Responder DONE: Update Technique G195 procedure #1931Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the updates
Patrick Lauke Agree with the updates with adjustment note the comments left on the PR (only trivial/minor/non-substantive)
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Agree with the updates
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the updates with adjustment In other versions on adjacent colors in context of visible focus it says 'adjacent colors in the focused component'.
Here it says in the test:
"<li>If the focus indicator does not have 3:1 contrast ratio with its adjacent colors, check that it is at least 2px thick.</li>"
The latter allows the focus indicator to blend into the page content.
So this point should be changed as well.
David MacDonald Agree with the updates with adjustment For the example
<h3>Form Elements</h3>

<p>A Web page includes a form inside a table. The borders of both the table and the form elements are thin, black lines. When focus lands on a form element, the element is outlined with a 5 pixel red line that is partially transparent. The red is equivalent to a hex color of #CA0000, providing a 6:1 contrast ratio with the white background.</p>

Why make it a red focus indicator, I would try to reserve red for error messages in general. It might be confusing to have a big red indicator on the focused item...
Andrew Kirkpatrick Agree with the updates
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the updates
Charles Adams Agree with the updates
Michael Gower Agree with the updates
Bruce Bailey Agree with the updates
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

42. DONE: Make clearer the method of calculating the minimum area #1883

momdo in Issue 1883 would like the understanding document to reference the CSS box model to help explain the sizing.

However, when looking to see how that would work, Alastair thought it would make it more confusing, as the boundary of the component will not always align with the box model. We also try to avoid technology specific explanations.

The thread and proposed response outline that.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 8
Agree with the response with adjustement
Something else

Details

Responder DONE: Make clearer the method of calculating the minimum area #1883Comments
Andrew Somers Agree with the response
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the response
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the response
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald Agree with the response
Andrew Kirkpatrick Agree with the response
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Missing a set of radio buttons!
I agree with the response, which is what I assume this question was intended to be :)
Bruce Bailey Agree with the response agree that this is too arcane

Editorial Q: subject/verb? the group does... or the group do...

How about:

The AG WG discussed, and we do not think it would be helpful to relate the calculations to the CSS box model.

Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

43. DONE: Sizing impresise and fairly complicated #1718

Wilco suggested a revised size measure in Issue 1718.

The proposed response generally rejects the suggestions and outlines why.

There was a separate suggestion that might be an improvement, but the responder (Alastair) was uncertain: Changing the 1st size bullet to use "boundary box" instead of perimeter.

Current SC text snippet:

Minimum area: The contrasting area is at least as large as either:

  • Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component, or
  • Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no part of the contributing area is thinner than 2 CSS pixels.

SC text snippet using bounding box in both bullets:

Minimum area: The contrasting area is at least as large as either:

  • Outline: the area of a 1 CSS pixel thick line around minimum bounding box of the unfocused component, or
  • Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no part of the contributing area is thinner than 2 CSS pixels.

Summary

ChoiceAll responders
Results
Agree with the response, and keep "perimeter" 5
Agree with the response, and switch to "bounding box"
Disagree with the response (please comment) 1

Details

Responder DONE: Sizing impresise and fairly complicated #1718Comments
Andrew Somers Agree with the response, and keep "perimeter" Perimeter. Bounding box raises many design issues for non-rectangular elements.
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the response, and keep "perimeter"
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim Disagree with the response (please comment) Does not matter, both ok. However, still missing the "consistency" for focus visuals. As long as no consistency is provided how should the user be able to recognise a
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Something else:
In the current version of the understanding, there are examples referred to as being successful with a found focus indicator.
That won't work out using the term of a bounding box, as the latter is always rectangle.
David MacDonald Agree with the response, and keep "perimeter"
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response, and keep "perimeter"
Charles Adams
Michael Gower
Bruce Bailey
Jonathan Avila Agree with the response, and keep "perimeter"
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

44. DONE: Google feedback

Dahlia opened issue 1896 with various comments.

The editorial is already incorporated, this question is about the response.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 6
Agree with the response with adjustment 3
Something else

Details

Responder DONE: Google feedbackComments
Andrew Somers Agree with the response
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the response
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel Agree with the response
Peter Bossley
Jaunita George
Gundula Niemann Agree with the response with adjustment I still feel that the phrase "against adjacent colors in the focused component" is hard to understand. To which exact colors does it refer to? Only the colors of the UI element itself? Or also its background color (that is, the color next to it, usually the background of the page)? The latter allows the focus indicator to blend into the background, which should not be allowed.
Blending into the focused component results in a focus indication by size change, which was explained to be valid several times along the AGWG discussions.

As some examples show round elements, I'd rather define 'unusual shape' as anything neither rectangular, nor rounded rectangle, nor circle, nor oval.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams Agree with the response with adjustment MG's recommendations.
Michael Gower Agree with the response with adjustment "The contrast of the surface area compared to it's adjacent colours, more is better."
"... working out it's size"
Should be "its"

"reasonable clear to users"
should be "reasonably"

Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

45. DONE: Non-text contrast update

There is an issue for non-text contrast which overlaps focus-appearance.

The issue and proposal is outlined in this Google doc due to needing graphical content.

NB: The document has been updated since last week. The question is whether the updates add reasonable clarification to the SC as currently understood.

Do you:

Summary

ChoiceAll responders
Results
Agree with the proposal 4
Disagree with the proposal (please comment with an alternative) 1
Something else

Details

Responder DONE: Non-text contrast updateComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James Agree with the proposal
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Disagree with the proposal (please comment with an alternative) It still does become clear which exact contrast needs to be fulfilled.
The unchanged https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html, Figure 3, explains for example that the silver outline of the input field does not need to contrast neither to the white input field nor to the dark blue page background, as white and dark blue yield a sufficient contrast for the input field.

Yet in the insertion, Figure 2 fails as the yellow focus indicator does not contrast to the white page background while contrasting to the component, and Figure 3 succeeds for contrasting with the page background while not contrasting to the component.
Figure 5 uses the same colors, but fails the color contrast. Similar in Figure 6.

I feel it doesn't make sense if the very same colors succeed color contrast in one case and fail in another.
In fact, all named examples succeed the color contrast 1.4.11 as it is currently described and lived, but only figure 3 succeeds the contrast between focused and unfocused UI element. Figure 4 fails the area requirement.
So the success should be stated, and similar to Figure 8 it should be referred to at which point the example fails the focus visible criterion.

In order to save the idea that if the focus indicator does not contrast to the UI element (that is, the focus is in fact indicated by size), then the additional size should be considerable, I suggest the wording for Adjacent contrast as follows:

Adjacent contrast: The contrasting area also has a contrast ratio of least 3:1 against the focused UI component, if it is adjacent to it, or the contrasting area has a thickness of at least 2 CSS pixels.

David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower Agree with the proposal I made a couple of comments in the document that could be addressed, but the guidance is well constructed, and I can support even without these changes.
Bruce Bailey Agree with the proposal
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree with the proposal Replying to Gundula - Figure 3 in the current understanding doc is not a focus indicator. It is making a point that each 'thing' (component or state) can have one contrast gradient.

The whole of the new section is going under focus indicators.

For the rest of the comments, Gundula appeared be talking about focus-appearance, which is not the SC this is related to!

46. DONE: Understanding document updates

PR 2000 makes a few general updates to the Understanding document that will help with various issues.

Preview of understanding doc.

  • It adds several visual examples at the top of the understanding document to say: Here is how you easily pass this criteria.
  • Moves the sections around to match the updated SC text. (This makes it look like a lot of change, but actually it's just moving sections.)
  • Applies the editorial updates from #1896
  • Tackles several issues from #1930
  • A couple of suggestions from Jon Avila.

Update: The updates at the top of the understanding document were added due to multiple people asking for clarity on what passes. A good way to address this was to provide several clear examples at the top. If you have issues with the SC text, please raise that separately. If you disagree with the text, please suggest an alternative solution.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates 2
Agree with the updates with adjustment 2
Something else 1

Details

Responder DONE: Understanding document updatesComments
Andrew Somers Something else I wrote the below before I realized this question says "done" — not certain what that means in this case? Has this ship sailed??

It mentions visual examples at the top.

My exception is the first example image "focus-indicators-passing.png" which I see is somehow part of this update.

1) The outline focus indicator of the first button is 2px, but the text says it is 1px.

2) The THIRD button is stated as passing. I believe I've objected to this in the past, and will again. the "thicker outline" is only 2px, with no contrast to the button. It is hard to discern if it is in focus unless in very close proximity to an equally sized button in the unfocused state, of if the changing of state is in direct view by the user. But if it is statically in focus (such as when first landing on the page) it will be very hard to determine focus, not jsut with lower vision but dur to cognitive issues as well.

Interestingly, in the Understanding 1.4.11, there is a similar example with a similarly sized YELLOW border, which is much more visible for normal vision that the dark border version (yellow on white of course is invisible for deutan or protan CVD types).

I do see in Understanding 1.4.11 that there is a disclaimer that the marginally fatter border passes but is considered poor. Okay, but it is only visible as a focus state if there are other buttons in the very near field of view for comparative size.

Side note, this slightly thicker 2px border has essentially no contrast, so it is no different that making the button 2px larger in each direction. The WCAG 2.x contrast reports 2.82:1, though 2.x contrast is not accurate for dark colors as has been demonstrated. It is essentially invisible (perceptual contrast of Lc 9, below the invisibility level).


HERE'S THE THING: the use case is a size contrast, and not really anything else. For a button that size ~(137x57), 2px is pretty weak. But if the button was 6px x 10px then a 2px border would be okay. Following that line, if you have an element that is 300x400, a 2px change in size on each edge will be nearly invisible.

••• TL;DR: •••
An absolute but arbitrary change in size is a size contrast, and if it is not relative to the total size of the element, the size contrast therein mahy be invisible, or may be more than enough.
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the updates with adjustment In the introduction example, the white outline inside the button is an fact 1 px thick.
as it was already agreed this visualization passes, I conclude a 1px inside outline is fine and the text should be changed.

For the unusual shapes I suggest to make clear that measuring the perimeter of an outline box or circle (or in general: a different, but fully enclosing shape) is still fine (the perimeter of an enclosing circle might be smaller than the perimeter of a star).

In the section Adjacent contrast in the third example I cannot detect any contrasting focus line. Please fix. There is only a subtly grey shade.

In the section relationship to non-text contrast, in the second bullet point, it is stressed that the focus indicator also contrasts to the inside color (the subtly indication), which somehow contradicts some previous examples where it was elaborated that the focus indicator does not need to contrast to the inside. This might confuse and in my opinion is not necessary: the focused element still contrasts, the focused element contrasts to the non-focused element. I suggest to drop the last sentence of this bullet point.
In the fourth bullet point it should be stated that the tick still contrasts its background. It does not need to be mentioned that the teal no longer contrasts to the grey. Similar to the second bullet point the contrast of the focus indicator to the inside should not be mentioned to avoid confusion.
Compare the second example of this section which explicitly states that the focus indicator is fine to not contrast to the black checkbox.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson
Charles Adams
Michael Gower Agree with the updates with adjustment I made trivial changes for consistency (and one for clarity). https://github.com/w3c/wcag/pull/2027
Bruce Bailey Agree with the updates
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell Agree with the updates Replying to Gundula: The exact CSS for the white outline inside the button was: outline: 2px #fff solid; outline-offset: -4px;
That is why it is important to describe the dimensions underneath, because the rendering of images can be a little misleading.

Unusual shapes - new issue, that isn't something that was changed in this PR.
Adjacent contrast - that isn't something that was changed in this PR. (Is this refering to figure 16 in the current doc? https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#focus-indicator-outerline)
In the section relationship to non-text contrast - this just fixed a couple of typos.

Please propose those changes in a PR (or google doc) separately from this update.

47. DONE: Confusing wording due to unconventional state requirement #1859

Ben raised issue 1859 regarding the wording of the SC.

The confusion seems to be around the use of 'background', and it not mattering which background you mean when talking about a change of contrast.

There is a proposed response, and some of the changes in PR 2000 should help prevent that misunderstanding.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 4
Agree with the response with adjustment
Something else

Details

Responder DONE: Confusing wording due to unconventional state requirement #1859Comments
Andrew Somers
Ben Tillyer Agree with the response
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with the response And one of my PR changes in the prior survey question also helps address this, I think.
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

48. DONE: Gradient Focus Indicators #1861

Ben, in Issue 1861 asks whether it is too difficult to test indicators with gradients.

There is a proposed response, do you:

Summary

ChoiceAll responders
Results
Agree with the response 5
Agree with the response with adjustment
Something else

Details

Responder DONE: Gradient Focus Indicators #1861Comments
Andrew Somers
Ben Tillyer Agree with the response
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the response
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with the response
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

49. DEFUNCT: Non-text contrast update

There is an issue for non-text contrast which overlaps focus-appearance.

The issue and proposal is outlined in this Google doc due to needing graphical content.

Do you:

Summary

ChoiceAll responders
Results
Agree with the proposal 1
Disagree with the proposal (please comment with an alternative) 1
Something else 1

Details

Responder DEFUNCT: Non-text contrast updateComments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Something else If the focus indicator fails 1.4.11, it does not make sense to have it pass focus appearance minimum.
If the focus indicator passes 1.4.11, it fulfills "The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component, ".
Therefore the alternative to be larger if not contrasting does not make sense, and I suggest to drop it.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the proposal
Charles Adams
Michael Gower
Bruce Bailey
Jonathan Avila Disagree with the proposal (please comment with an alternative) Overall this is good but we need to address a specific point. I'd like the proposal to clarify if the indicator is inset and touches the visible border and adjacent inner pixels of the control background do we need to calculate adjacency against both the border and inner background or only one - and if one which one.
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

50. DEFUNCT: Understanding document updates

PR 2000 makes a few general updates to the Understanding document that will help with various issues.

Preview of understanding doc.

  • It adds several visual examples at the top of the understanding document to say: Here is how you easily pass this criteria.
  • Moves the sections around to match the updated SC text. (This makes it look like a lot of change, but actually it's just moving sections.)
  • Applies the editorial updates from #1896
  • Tackles several issues from #1930
  • A couple of suggestions from Jon Avila.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates 2
Agree with the updates with adjustment 1
Something else

Details

Responder DEFUNCT: Understanding document updatesComments
Andrew Somers Agree with the updates with adjustment Not clear how this differs from #9??? See my comment there...
Ben Tillyer
Jake Abma
Marc Johlic
Rain Breaw Michaels
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann In the new version it says: "The requirement is to have an indicator that has a 3:1 contrast ratio with the adjacent colors of the component, or to be separated from the component, or to be at least 2px thick.".
Th option 'or to be separated from the component' is not part of the normative text, and also I do not agree. In the corresponding example the focus indicator is hardly visible (close to being not visible).
Next, it does not fulfill the 3:1 contrast to the unfocused state.

David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the updates
Charles Adams
Michael Gower
Bruce Bailey
Jonathan Avila Agree with the updates
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

51. DONE: Explain why authors are better enabled than UA at solving this #1911

philljenkins asks in issue 1911 why having the requirement on the author (designer & developer using WCAG) is better than on the browser/AT (using UAAG).

Alastair outlined a response, do you:

Summary

ChoiceAll responders
Results
Agree with the response 7
Agree with the response with adjustment 1
Something else

Details

Responder DONE: Explain why authors are better enabled than UA at solving this #1911Comments
Andrew Somers Agree with the response
Ben Tillyer
Jake Abma
Marc Johlic Agree with the response
Rain Breaw Michaels Agree with the response
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the response
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with the response with adjustment In initial responses, Alastair said:
>Could you elaborate on the scenario where that would become an issue? Particularly as "focus-visible" becomes more available in browsers, anyone using a mouse is unlikely to notice the keyboard focus styles.
The COGA task force is aware of the requirement and has not commented. (That doesn't mean it has been analysed by them in detail, but it didn't seem to ring alarm bells.)

Since the issue specifically mentions COGA, it might be an idea to ask the task force specifically on this, particularly if Phill can provide some specifics on TBI users' reactions.
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

52. DONE: Minimum Area clarification #1806

Dashhouse raised 1806 about the both/either nature of the sub-bullets.

PR 1966 was created to address with a small normative update.

Do you:

Summary

ChoiceAll responders
Results
Agree with the change 8
Agree with the change with adjustment 1
Something else

Details

Responder DONE: Minimum Area clarification #1806Comments
Andrew Somers Agree with the change
Ben Tillyer
Jake Abma
Marc Johlic Agree with the change
Rain Breaw Michaels Agree with the change
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the change
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the change with adjustment Having the 'either'prominent, I prefer to have the 'or' at the beginning of the line, between the bullets (thus being prominent as well).
I'll not die on that hill, though.
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the change
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the change
Charles Adams
Michael Gower Agree with the change
Bruce Bailey Agree with the change
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

53. DONE: Browser default focus indicators #1854

JamesCatt raised issue 1854 about default focus indicators being sufficient.

In the proposed response Alastair disagreed, and pointed out that if browsers improve, authors will have less (or no) work to do.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 9
Agree with the response with adjustment
Something else

Details

Responder DONE: Browser default focus indicators #1854Comments
Andrew Somers Agree with the response
Ben Tillyer
Jake Abma
Marc Johlic Agree with the response
Rain Breaw Michaels Agree with the response
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the response
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the response
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the response
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the response
Charles Adams
Michael Gower Agree with the response
Bruce Bailey Agree with the response
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

54. DONE: Gradient Backgrounds #1862

benja11y raised issue 1862 about gradient backgrounds.

The answer is essentially that it would be tested the same was as text contrast over varying backgrounds, and David suggested an update in PR 1967 that adds to the understanding document.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 8
Agree with the update with adjustment
Something else

Details

Responder DONE: Gradient Backgrounds #1862Comments
Andrew Somers
Ben Tillyer
Jake Abma
Marc Johlic Agree with the update
Rain Breaw Michaels Agree with the update
Glenda Sims
Gregg Vanderheiden
JaEun Jemma Ku
Kim Dirks
Abi James
Patrick Lauke Agree with the update
Sarah Horton
Michail Yasonik
Detlev Fischer
Oliver Keim
Caryn Pagel
Laurence Lewis
Stefan Schnabel
Peter Bossley
Jaunita George
Gundula Niemann Agree with the update
David MacDonald
Andrew Kirkpatrick
Ian Kersey
Todd Libby Agree with the update
Suzanne Taylor
Melanie Philipp
Wilco Fiers
Laura Carlson Agree with the update
Charles Adams
Michael Gower Agree with the update It's a little wordy, but I can live with it :)
Bruce Bailey Agree with the update
Jonathan Avila
Mary Jo Mueller
Rachael Bradley Montgomery
Alastair Campbell

More details on responses

  • Andrew Somers: last responded on 17, September 2021 at 05:12 (UTC)
  • Ben Tillyer: last responded on 11, October 2021 at 12:19 (UTC)
  • Jake Abma: last responded on 12, October 2021 at 09:59 (UTC)
  • Marc Johlic: last responded on 12, October 2021 at 14:47 (UTC)
  • Rain Breaw Michaels: last responded on 29, October 2021 at 12:40 (UTC)
  • Glenda Sims: last responded on 6, December 2021 at 15:26 (UTC)
  • Gregg Vanderheiden: last responded on 21, December 2021 at 16:05 (UTC)
  • JaEun Jemma Ku: last responded on 21, December 2021 at 16:41 (UTC)
  • Kim Dirks: last responded on 4, January 2022 at 22:42 (UTC)
  • Abi James: last responded on 24, January 2022 at 15:31 (UTC)
  • Patrick Lauke: last responded on 21, February 2022 at 18:22 (UTC)
  • Sarah Horton: last responded on 22, February 2022 at 09:47 (UTC)
  • Michail Yasonik: last responded on 18, March 2022 at 17:05 (UTC)
  • Detlev Fischer: last responded on 4, April 2022 at 08:51 (UTC)
  • Oliver Keim: last responded on 4, April 2022 at 16:10 (UTC)
  • Caryn Pagel: last responded on 12, April 2022 at 15:03 (UTC)
  • Laurence Lewis: last responded on 19, April 2022 at 23:17 (UTC)
  • Stefan Schnabel: last responded on 3, May 2022 at 12:25 (UTC)
  • Peter Bossley: last responded on 3, May 2022 at 13:51 (UTC)
  • Jaunita George: last responded on 3, May 2022 at 14:42 (UTC)
  • Gundula Niemann: last responded on 16, May 2022 at 16:05 (UTC)
  • David MacDonald: last responded on 20, May 2022 at 01:31 (UTC)
  • Andrew Kirkpatrick: last responded on 24, May 2022 at 11:49 (UTC)
  • Ian Kersey: last responded on 24, May 2022 at 13:18 (UTC)
  • Todd Libby: last responded on 31, May 2022 at 14:53 (UTC)
  • Suzanne Taylor: last responded on 31, May 2022 at 14:55 (UTC)
  • Melanie Philipp: last responded on 31, May 2022 at 15:05 (UTC)
  • Wilco Fiers: last responded on 24, June 2022 at 12:49 (UTC)
  • Laura Carlson: last responded on 24, June 2022 at 14:24 (UTC)
  • Charles Adams: last responded on 24, June 2022 at 15:48 (UTC)
  • Michael Gower: last responded on 27, June 2022 at 22:01 (UTC)
  • Bruce Bailey: last responded on 28, June 2022 at 12:43 (UTC)
  • Jonathan Avila: last responded on 28, June 2022 at 13:23 (UTC)
  • Mary Jo Mueller: last responded on 28, June 2022 at 13:30 (UTC)
  • Rachael Bradley Montgomery: last responded on 28, June 2022 at 14:20 (UTC)
  • Alastair Campbell: last responded on 28, June 2022 at 14:24 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Chris Wilson
  2. Lisa Seeman-Horwitz
  3. Janina Sajka
  4. Shawn Lawton Henry
  5. Katie Haritos-Shea
  6. Shadi Abou-Zahra
  7. Chus Garcia
  8. Steve Faulkner
  9. Gez Lemon
  10. Makoto Ueki
  11. Peter Korn
  12. Preety Kumar
  13. Georgios Grigoriadis
  14. Romain Deltour
  15. Chris Blouch
  16. Jedi Lin
  17. Jeanne F Spellman
  18. Kimberly Patch
  19. Ian Pouncey
  20. Léonie Watson
  21. David Sloan
  22. John Kirkwood
  23. Reinaldo Ferraz
  24. Matt Garrish
  25. Mike Gifford
  26. Loïc Martínez Normand
  27. Mike Pluke
  28. Justine Pascalides
  29. Chris Loiselle
  30. Tzviya Siegman
  31. Jan McSorley
  32. Sailesh Panchang
  33. Cristina Mussinelli
  34. John Rochford
  35. Sujasree Kurapati
  36. Jatin Vaishnav
  37. Sam Ogami
  38. Kevin White
  39. E.A. Draffan
  40. Paul Bohman
  41. 骅 杨
  42. Victoria Clark
  43. Avneesh Singh
  44. Mitchell Evan
  45. biao liu
  46. Scott McCormack
  47. Denis Boudreau
  48. Francis Storr
  49. Rick Johnson
  50. David Swallow
  51. Aparna Pasi
  52. Gregorio Pellegrino
  53. Nicole Windmann
  54. Ruoxi Ran
  55. Richard Boardman
  56. Wendy Reid
  57. Scott O'Hara
  58. Muhammad Saleem
  59. Amani Ali
  60. Trevor Bostic
  61. Jamie Herrera
  62. Shinya Takami
  63. Karen Herr
  64. Kathy Eng
  65. Cybele Sack
  66. Audrey Maniez
  67. Jennifer Delisi
  68. Arthur Soroken
  69. Daniel Bjorge
  70. Kai Recke
  71. David Fazio
  72. Daniel Montalvo
  73. Mario Chacón-Rivas
  74. Michael Gilbert
  75. Achraf Othman
  76. Fernanda Bonnin
  77. Jared Batterman
  78. Raja Kushalnagar
  79. Jan Williams
  80. Isabel Holdsworth
  81. Julia Chen
  82. Marcos Franco Murillo
  83. Yutaka Suzuki
  84. Jennifer Strickland
  85. Joe Humbert
  86. Charu Pandhi
  87. Poornima Badhan Subramanian
  88. Alain Vagner
  89. Roberto Scano
  90. Kun Zhang
  91. Regina Sanchez
  92. Shawn Thompson
  93. Thomas Brunet
  94. Kenny Dunsin
  95. Jen Goulden
  96. Mike Beganyi
  97. Ronny Hendriks
  98. Breixo Pastoriza Barcia
  99. Olivia Hogan-Stark
  100. Rashmi Katakwar
  101. Julie Rawe
  102. Duff Johnson
  103. Laura Miller
  104. Will Creedle
  105. Shikha Nikhil Dwivedi
  106. Marie Csanady
  107. Meenakshi Das
  108. Perrin Anto
  109. Stephanie Louraine
  110. Rachele DiTullio
  111. Jan Jaap de Groot
  112. Rebecca Monteleone
  113. Mark Applin
  114. Anastasia Lanz
  115. Michael Keane
  116. Chiara De Martin
  117. Giacomo Petri
  118. Andrew Barakat
  119. Devanshu Chandra
  120. Helen Zhou
  121. Bryan Trogdon
  122. Mary Ann (MJ) Jawili
  123. 禹佳 陶
  124. 锦澄 王
  125. Stephen James
  126. Jay Mullen
  127. Thorsten Katzmann
  128. Tony Holland
  129. Kent Boucher
  130. Abbey Davis
  131. Phil Day
  132. Julia Kim
  133. Michelle Lana
  134. David Williams
  135. Mikayla Thompson
  136. Catherine Droege
  137. James Edwards
  138. Eric Hind
  139. Quintin Balsdon
  140. Mario Batušić
  141. David Cox
  142. Sazzad Mahamud
  143. Katy Brickley
  144. Kimberly Sarabia
  145. Corey Hinshaw
  146. Ashley Firth
  147. Daniel Harper-Wain
  148. Kiara Stewart
  149. DJ Chase
  150. Suji Sreerama
  151. Lori Oakley
  152. David Middleton
  153. Alyssa Priddy
  154. Young Choi
  155. Nichole Bui
  156. Julie Romanowski
  157. Eloisa Guerrero
  158. Daniel Henderson-Ede
  159. George Kuan
  160. YAPING LIN
  161. Justin Wilson
  162. Tiffany Burtin
  163. Shane Dittmar
  164. Nayan Padrai
  165. Niamh Kelly
  166. Matt Argomaniz Matthew Argomaniz
  167. Frankie Wolf
  168. Kimberly McGee
  169. Ahson Rana
  170. Carolina Crespo
  171. humor927 humor927
  172. Samantha McDaniel
  173. Matthäus Rojek
  174. Phong Tony Le
  175. Bram Janssens
  176. Graham Ritchie
  177. Aleksandar Cindrikj
  178. Jeroen Hulscher
  179. Alina Vayntrub
  180. Marco Sabidussi
  181. John Toles
  182. Jeanne Erickson Cooley
  183. Theo Hale
  184. Gert-Jan Vercauteren
  185. Karla Rubiano
  186. Aashutosh K
  187. Hidde de Vries
  188. Julian Kittelson-Aldred
  189. Roland Buss
  190. Aditya Surendranath
  191. Avon Kuo
  192. Elizabeth Patrick
  193. Nat Tarnoff
  194. Filippo Zorzi

Send an email to all the non-responders.


Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire