W3C

Site Navigation

Nearby

Results of Questionnaire WCAG 2.2 Miscellaneous Normative Issues

The results of this questionnaire are available to anybody.

This questionnaire was open from 2022-12-01 to 2022-12-12.

20 answers have been received.

Jump to results for question:

  1. Removal or mark obselete for 4.1.1
  2. Difficulties with inconsistency of Target Size (Minimum) #2695
  3. Better clarity on inline targets for Target Size #2767
  4. Potential unintentional failure for Focus Not Obscured (Enhanced), due to wording and definition #2736
  5. Historic Questions, stop here
  6. DEFUNCT: Better clarity on inline targets for Target Size #2767
  7. DEFUNCT: Difficulties with inconsistency of Target Size (Minimum) #2695
  8. DONE: Change First Note 3.2.6 Consistent Help to align better with SC text #2408
  9. DONE: Note in Accessible Authentication needs to be reworded #2714
  10. DONE: 3.3.9 Redundant Entry out of order #2764
  11. DONE: Normative wording inconsistencies for Accessible Authentication SCs #2715
  12. DEFUNCT: Removal or mark obselete for 4.1.1

1. Removal or mark obselete for 4.1.1

After the discussion we had about rewording 4.1.1, which lead to us deciding to remove the SC, Wilco raised Issue 2820 to argue for obsoleting it instead.

Based on the survey results from last week:

  • We agree that we don't want people to be required to test or report on 4.1.1.
  • We agree that any issues that impact end-users that are caught by other SC, so a fully conforming 2.2 site would conform to 2.1/2.0 for those meaningful issues.
  • Several people thought it would be clearer if the SC text is removed, but it should keep the heading and include a note to say why it is removed.
  • If we include the term "obsolete", we would need to define it and how obsolete SCs do/don't impact conformance.
  • Some thought that need to agree whether we intend to do an errata for 2.0/2.1, or publish a revised recommendations for 2.0/2.1 that removes it from those as well.

Note that the urgent deadline is CR for 2.2, we can tackle errata for 2.0/2.1 later.

PR 2823 shows the approach.

The previous survey had 5 people vote in favour of using obsolete, 7 remove (+2 that said 'something' else but appeared to favour removal). This question is re-running in case the discussed above has changed anyone's mind.

Please select a preference, and comment which options you can't live with:

Summary

ChoiceAll responders
Results
Keep the SC text in the main spec and mark it as obsolete 2
Remove the SC text in the main spec and mark it as obsolete 3
Remove the SC text in the main spec 3
Something else 1

(11 responses didn't contain an answer to this question)

Details

Responder Removal or mark obselete for 4.1.1Comments
Patrick Lauke
John Foliot
JaEun Jemma Ku
Shikha Nikhil Dwivedi
Gundula Niemann
Oliver Keim
Shawn Thompson
Laura Carlson
Detlev Fischer
Gregg Vanderheiden Remove the SC text in the main spec and mark it as obsolete Obsolete as a TAG (By itself) is more for voluntary standards -- and makes something RECOMMENDED instead of required. We really don't want to to that.
So I suggest
"4.1.1 Obsolete and removed
<no sc text>
NOTE: This was originally adopted to address problems that AT had directly parsing HTML. This is no longer true so this SC no longer solves any problem and is removed.

Andrew Kirkpatrick Remove the SC text in the main spec Either removal options is fine. Agree with Gregg that we should pursue edited recommendations for 2.0 and 2.1 following that.
Andrew Somers Something else I thought this kind of thing—removing an SC wholesale—was not permitted due to a charter requirement to maintain backwards compatibility?
Stefan Schnabel
Michael Gower I have no preference. Either way, I think we need to provide clarity on how users are supposed to deal with this when reporting. I think the intent is that folks always mark it Yes, but if obsolete N/A may also be appropriate.
Wilco Fiers Keep the SC text in the main spec and mark it as obsolete We shouldn't make this decision without deciding on WCAG 2.0 and 2.1.

I'm not okay with removing the SC text from the spec. It still feels like breaking the promise of a backward compatible spec, feels a bit like rewriting history. If we're worried about people not realising its obsolete we can do something with the styling / semantics to address this, or even hide the SC text behind a toggle.
Alastair Campbell Remove the SC text in the main spec I'm not opposed to marking as obsolete (or some other term), but the key thing is to remove the SC text from the face of the spec (whilst keeping it in the understanding document). Otherwise we're saying "do this, but you don't have to do this", it's just confusing.
Todd Libby Keep the SC text in the main spec and mark it as obsolete
Jonathan Avila Remove the SC text in the main spec and mark it as obsolete Keeping it and marking it obsolete seems like it would create confusion. I also would like to know how removal will impact backward compatibility with WCAG 2.0 and 2.1. It's stated that 2.0/2.1 is not as important but I think these two things need to be tackled at once.
Makoto Ueki Remove the SC text in the main spec and mark it as obsolete +1 to Gregg on having the NOTE to present the rationale. And I can also live with "Keep the SC text in the main spec and mark it as obsolete" only if it has the NOTE.
Bruce Bailey Remove the SC text in the main spec My 2nd best choice Remove the SC text in the main spec and mark it as obsolete.

I would rather not Keep the SC text in the main spec and mark it as obsolete -- unless we explain (which I expect we would) because it seems confusing. But +1 to GreggV survey response -- iff that is what is meant by "Keep the SC text in the main spec and mark it as obsolete"

Federal government regulatory style, as I understand it, would be: 4.1.1 Removed.

That makes it explicit as to why there is a numerical gap, which 2.2 needs to consider.

Please try to avoid the "can't live with" characterization.

2. Difficulties with inconsistency of Target Size (Minimum) #2695

Returning to Issue 2695, where Wilco identified some unexpected results from the target-offset calculation.

We discussed this last week, previous question, minutes.

A problem with any metric that works from the centre is that you don't end up with consistently sized/spaced targets. Diagram showing several rows of targets of different sizes, the implications of which are explained next.

If targets are smaller, e.g. 16px, then the centre of the target moves away from the adjacent target. So measuring 12px from the centre means there is only 20px. If you increase the size of the metric to 16px from the centre to nearest edge, then a 20px target actually requires 26px of size + spacing to the next target.

Circling back to the proposal that kicked off this discussion, Wilco's suggestion was created in PR 2798. The proposal was to update the definition of target ofset, and add a note:

Target offset: size of a target (A) plus the spacing to a second target (B).

Note: For horizontally aligned targets, target offset is the width of target A plus the horizontal space to the closest edge of target B. For vertically aligned targets, target offset is the the height of target A plus the vertical space to the closest edge of target B. For targets that are neither horizontally nor vertically aligned, the target offset is the longest measure from any point of A to the nearest point of B.

PR thread suggested some updates, the first was

For horizontally aligned targets, target offset is the width of target A plus the smallest measurement of spacing between A and B.

That would be repeated for vertical alignment.

Dan Bjorge suggested an update for least ambiguity, although it appears more complex:

For horizontally aligned targets, target offset is the length of the longest horizontal line with one endpoint touching a boundary of A, the other endpoint touching the bounding rectangle of B, and which never intersects any non-A target except at the endpoints.

Should we:

Summary

ChoiceAll responders
Results
Use PR 2798 1
Use the first (simpler) update 1
Use the second update
Something else 9

(9 responses didn't contain an answer to this question)

Details

Responder Difficulties with inconsistency of Target Size (Minimum) #2695 Comments
Patrick Lauke
John Foliot
JaEun Jemma Ku
Shikha Nikhil Dwivedi
Gundula Niemann
Oliver Keim
Shawn Thompson
Laura Carlson
Detlev Fischer
Gregg Vanderheiden Something else None of these work for the reasons cited previously. You need to talk about applying concept to all targets from a common point in the test target. Otherwise for targets A B & C in a row - you measure from the left edge of b when evaluating against C and the right edge of B when evaluating against C. Both pass but there is no place to push B where you have enough offset from A and C at the same time.
Andrew Kirkpatrick Something else I like the apparent simplicity of WIlco's, but I'm not sure how size is measured in the Target offset. In the SC "size" means that the height and width are at least 24 each, but in the Target offset the size isn't a width or a height and it isn't clear what it is.

Maybe:
Target offset is the sum of the larger of the width or height of target A and the smallest measurement of spacing between A and B.
Andrew Somers Something else
Stefan Schnabel Something else Please add visual examples to the last update of Dan. It is a bit hard to to imagine.
Michael Gower Something else In the new wording, "size" infers multiple dimensions: "size of a target (A) plus the spacing to a second target (B)". That seems a bit problematic. How about:
> The distance measured across a target plus the spacing to a second target

We could also try a term like "length" (e.g., the length of target plus the spacing...).
---
Regarding the note: "For horizontally aligned targets...", how about "For targets that occupy the same horizontal or vertical plane, target offset is the width... target B. For targets that occupy neither the same horizontal nor vertical plane, the target offset is..."

I also think "size" in the normative text is a bit of a problem, as per https://github.com/w3c/wcag/issues/2803 . I suggest adding "contiguous"

Wilco Fiers Something else I took another stab at this, taking inspiration from Dan's suggestions:

> Offset is the length of the longest line that starts at an edge of A, intersects a second edge of A, and ends at an edge of B. For horizontally aligned targets, offset is measured with a horizontal line. For vertically aligned targets, offset is measured with a vertical line. For targets that are not aligned the offset is measured horizontal, vertical or diagonal (whichever is longest).
Alastair Campbell Use the first (simpler) update I think I understanding Dan's update, but if I do, then I think it could lead to some odd results for non-rectangular shapes.
Todd Libby Something else
Jonathan Avila Use PR 2798 Center based solutions make assumptions that users will be aiming for the center and are hard to understand. I like our current wording which is think is further clarified by the target size + space between targets example in 2798.
Makoto Ueki Something else Would like to see graphic examples for Dan's suggestion to make sure if I understood the points correctly.
Bruce Bailey Something else Referring to diagram, all but middle third row are acceptable, yes? And the targets in the middle row are short by only 2 px, correct?

If that is correct, why cannot the metric be as simple as: "24 px required" (similar to the `26 px required` in bottom/5th row).

The horizontally/vertically aligned phrasing is okay -- but why do the rules change if targets rotated 45 degrees?

+1 to Wilco's suggestion in this survey:
> [Target] offset is the length of the longest line that starts at an edge of A, intersects a second edge of A, and ends at an edge of B.

3. Better clarity on inline targets for Target Size #2767

In Issue 2767 we discussioned the inline exception of target size.

We discussed this last week, but without conclusion.

Building on the conversation, I'd like to propose:

Inline: The size of the target is constrained by the inter-line-spacing of non-target text.

Please see the working document of examples, which shows what would be included / not-included for both the current text, and the new proposal. It tests a a typical wikipedia page (which is all text links!), and a couple of extra examples from the W3C site.

Do you:

Summary

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

(10 responses didn't contain an answer to this question)

Details

Responder Better clarity on inline targets for Target Size #2767 Comments
Patrick Lauke
John Foliot
JaEun Jemma Ku
Shikha Nikhil Dwivedi
Gundula Niemann
Oliver Keim
Shawn Thompson
Laura Carlson
Detlev Fischer
Gregg Vanderheiden Agree with the update
Andrew Kirkpatrick Something else interline shouldn't be hyphenated, and I am not sure that we want to bring in an additional typographic concept. Can we just say "The size of the target shares a line-height and is constrained by the line-height of non-target text"?

Andrew Somers
Stefan Schnabel Agree with the update
Michael Gower Agree with adjustment I think we want to retain some notion of sentence. I suggest just prefacing by that:

> Inline: The target is in a sentence, or the size of the target...
Wilco Fiers Agree with adjustment I really like this idea, but I'm not sure we're going the right thing by handling this in normative language. Currently 2.5.5 and 2.5.8 use the same language for its exception. If we change use different phrasing here, we give the impression that these may be two different ideas. If we're going to make this change I'd like to see an errata of 2.5.5. If not, I think we're better off putting this language into a note.
Alastair Campbell Agree with the update Just noting that "inter-line-spacing" was to be more internationalised than "line height".
Todd Libby Agree with the update
Jonathan Avila Agree with the update
Makoto Ueki Agree with the update
Bruce Bailey Agree with the update

4. Potential unintentional failure for Focus Not Obscured (Enhanced), due to wording and definition #2736

In Issue 2736 MichaelG pointed out that there is an over-requirement where an item with a compliant focus indicator (per 2.4.11 Focus Appearance) could fail Focus Not Obscured (Enhanced) even though the component and the area of the focus indicator that passes Focus Appearance are not obscured at all.

This is likely to affect focus indicators which have a halo or fade effect, where some of the faded area could be obscured by other content.

Is your preferred solution:

Summary

ChoiceAll responders
Results
To accept this, it is at AAA. 2
Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content." 10
Update the SC to cross-reference focus-appearance, saying that no part of the sufficient indicator in 2.4.11 is obscured. 5

(3 responses didn't contain an answer to this question)

Details

Responder Potential unintentional failure for Focus Not Obscured (Enhanced), due to wording and definition #2736 Comments
Patrick Lauke Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
John Foliot Update the SC to cross-reference focus-appearance, saying that no part of the sufficient indicator in 2.4.11 is obscured.
JaEun Jemma Ku
Shikha Nikhil Dwivedi To accept this, it is at AAA.
Gundula Niemann Update the SC to cross-reference focus-appearance, saying that no part of the sufficient indicator in 2.4.11 is obscured. I can also live with keeping it as it is.
Oliver Keim Update the SC to cross-reference focus-appearance, saying that no part of the sufficient indicator in 2.4.11 is obscured.
Shawn Thompson Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Laura Carlson Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Detlev Fischer Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Gregg Vanderheiden I can't be there for the discussion - so I will pass on this one. but I would favor 2 or 3. We don't want to dismiss things as unimportant because they are AAA.
Andrew Kirkpatrick Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Andrew Somers
Stefan Schnabel Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Michael Gower Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content." I think making the language match the AA is the easiest way to progress. That said, I'm fine referring to the sufficient indicator. That is the most consistent.

I made a pull request for this https://github.com/w3c/wcag/pull/2838
Wilco Fiers Update the SC to cross-reference focus-appearance, saying that no part of the sufficient indicator in 2.4.11 is obscured.
Alastair Campbell Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content." MichaelG implemented the second option: https://github.com/w3c/wcag/pull/2838

Just noting that our original rationale for using the focus indicator was that is was the more difficult aspect, but I'm not objecting to the change.
Todd Libby Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Jonathan Avila To accept this, it is at AAA.
Makoto Ueki Update the AAA SC to only include the component in scope: "When a user interface component receives keyboard focus, no part of the component is hidden by author-created content."
Bruce Bailey Update the SC to cross-reference focus-appearance, saying that no part of the sufficient indicator in 2.4.11 is obscured. I am okay with 2nd option. I am not for ignoring deficits in SC phrasing just because the SC is a AAA.

5. Historic Questions, stop here

The following questions have been resolved, or are not relevant any more.

 

========================== ==============================

 

 

 

 

========================== ==============================

 

 

 

Details

Responder Comments
Patrick Lauke
John Foliot
JaEun Jemma Ku
Shikha Nikhil Dwivedi
Gundula Niemann
Oliver Keim
Shawn Thompson
Laura Carlson
Detlev Fischer
Gregg Vanderheiden
Andrew Kirkpatrick
Andrew Somers
Stefan Schnabel
Michael Gower
Wilco Fiers
Alastair Campbell
Todd Libby
Jonathan Avila
Makoto Ueki
Bruce Bailey

6. DEFUNCT: Better clarity on inline targets for Target Size #2767

In Issue 2767 we discussioned the inline exception of target size.

The preferred option from a WCAG 2.x meeting was:

Inline: The target is a text link dependent on the line-height of non-link text.

This narrows the exception to text links, and is clearer about whether something is in scope or not. It is implemented as PR 2824.

Please see the working document of suggestions and examples, which shows what would be included / not-included on a typical wikipedia page (which is all text links!).

Do you:

Summary

ChoiceAll responders
Results
Agree with the proposal 8
Agree with adjustment (comment) 7
Something else (comment) 2

(3 responses didn't contain an answer to this question)

Details

Responder DEFUNCT: Better clarity on inline targets for Target Size #2767 Comments
Patrick Lauke Something else (comment) limiting the exception to just text links, while expedient, makes no sense though. what is materially different from a text-based link, and a link that looks exactly the same, but is in fact an image of text, for instance? or an icon?
John Foliot Agree with the proposal
JaEun Jemma Ku Agree with adjustment (comment) I would like to recommend to use "is determined by". Therefore, the sentence will be that "the target is a text link is determined by the line-height of non-link text"
Shikha Nikhil Dwivedi Agree with the proposal
Gundula Niemann Agree with adjustment (comment) In general, I like the new wording, yet I do not agree on some of the details in the examples.
1) left nav: in the text it says, it is excepted, in the examples it does not fall under the exception.
2) lists of links: the decision whether the exception applies should not depend on whether one of the items is amended by additional text. All links lists should be treated the same. It should never lass under the exception (neither with numbers nor with bullets nor with headings not anything else).
Oliver Keim Agree with adjustment (comment) Wording is good.
Updates appreciated for the samples section, specifically keeping the decisions consistent. A list with one unlinked bullet should probably not allow non-conformance.
Shawn Thompson Agree with the proposal
Laura Carlson Agree with the proposal
Detlev Fischer Agree with the proposal Better what we had before, but the discussion shows that it will be a constrant struggle to determine if some content qualifies as inline exception or not. Not excepting linline targets does not seem realistic though. So we need some formulation (unless we scrap the whole SC, which I am leaning towards now).
Gregg Vanderheiden Agree with adjustment (comment) Good but not clear what dependent meant.

if it was bullets in a list and they were links -- there is no text alongside in the same line -- so is it dependent?

if it is a pulldown list -- not sure you have control but not dependent on other text

if it is a menu on the side -- can it be the same spacing as the page ? or does it need to be spacey (which may make the menu larger than fits on screen which makes it cognitively more difficult to choose?
Andrew Kirkpatrick Agree with adjustment (comment) Fine in general but am wondering about the "line-height of non-link text" part - if you have a set of text links that are not within paragraph text how does this apply? Can we just say "line-height of text"?
Andrew Somers
Stefan Schnabel Something else (comment) Link list should be no exception. Nav Links are important to hit and therefore they must meet min target size both in with and height.
Michael Gower Agree with the proposal This isn't perfect but it's better than what we have. I think it is worth doing some practical check to make sure we end up with good inter-rater reliability.
Wilco Fiers Agree with adjustment (comment) I don't see a reason to constrain this to text links. Many controls can be part of texts. For example a "fill in the blanks" test may have a text field in the middle of a paragraph. There's also text links with images in them, like those "opens in new window" icons. This introduces the question on if those are text links or not.

The word "dependant" doesn't make sense to me. line-height might be inherited, but it isn't inherited from sibling text nodes. I think the point is that the component can't grow to sufficient size without increasing the line height (note the absence of the hyphen too. This isn't about the CSS line-height property).

This definition loses something important too, that the component should be part of an actual text. If you have a row of links, separated by a slash, that shouldn't fall under the inline exception. With this new definition it seems like it would. I feel a second condition that ensures this exception is only applied to actual text is important.

Alastair Campbell
Todd Libby Agree with the proposal
Jonathan Avila
Makoto Ueki Agree with adjustment (comment) +1 to Wilco
Bruce Bailey Agree with the proposal Similar exception for AAA Success Criterion 2.5.5 Target Size should also be updated or renamed (assuming this gets consensus).

7. DEFUNCT: Difficulties with inconsistency of Target Size (Minimum) #2695

Returning to Issue 2695, where Wilco identified some unexpected results from the target-offset calculation.

The WCAG 2.x issue meeting discussed this for over an hour without a clear preference, all the options seem to have drawbacks.

A last minute option from Gregg showed the most promise, which was:

Spacing: There is at least one point in a target that is at least 12 CSS pixels from the closest edge of all other targets simultaneously.

That removes the need for the target offset definition, and appears to avoid the problems other options had with nested controls and excepting things on the edge of a row. It has been implemented in PR 2825, although further updates to the understanding document would be required if this is accepted.

At this stage in the process we'll need to make a quick decision. I have included the option to remove the SC because some have expressed doubts that this SC will capture enough issues for the effort of testing, and because if we doubt the SC is clear enough, we shouldn't include it.

Should we:

Summary

ChoiceAll responders
Results
Maintain the current target-offset definition 4
Switch to the suggestion above in PR 2825 10
Remove Target size from WCAG 2.2 2

(4 responses didn't contain an answer to this question)

Details

Responder DEFUNCT: Difficulties with inconsistency of Target Size (Minimum) #2695 Comments
Patrick Lauke Remove Target size from WCAG 2.2 agree with the sentiment here "some have expressed doubts that this SC will capture enough issues for the effort of testing, and because if we doubt the SC is clear enough, we shouldn't include it."

could just about live with the idea behind PR 2835, but perhaps it can be explained/visualised with a circle? i.e. that you there's at least one point in the target where you can center a circle with radius 12 CSS px, and no adjacent targets intrude into that circle, or similar.
John Foliot Switch to the suggestion above in PR 2825
JaEun Jemma Ku Switch to the suggestion above in PR 2825 The suggested PR is much more intuitive and easy to understand!
Shikha Nikhil Dwivedi Maintain the current target-offset definition
Gundula Niemann Maintain the current target-offset definition Optimally, I suggest a box-based measurement.
If we cannot have that, I see the current target-offset based definition at least as with benefit.
I feel the new wording might lead to a still unsatisfactory user experience, as it does not imply an element receives action where it is visually seen.
Oliver Keim Switch to the suggestion above in PR 2825
Shawn Thompson Switch to the suggestion above in PR 2825
Laura Carlson Switch to the suggestion above in PR 2825
Detlev Fischer Remove Target size from WCAG 2.2 I find PR 2825 hard to understand and apply in practice in evaluations. If it makes automated assessment harder (and Wilco who has put effort into working this out seems to think so) it cannot be the way forward. Despite the amount of work that has gone into this, I am now leaning towards removal.
Gregg Vanderheiden Switch to the suggestion above in PR 2825
Andrew Kirkpatrick Switch to the suggestion above in PR 2825
Andrew Somers
Stefan Schnabel Maintain the current target-offset definition Box-Measuered measurement.
Michael Gower Maintain the current target-offset definition My concern is that this proposal actually allows for smaller, more tightly spaced targets (imagine the middle of three 10px-wide targets; the mid-point of 5px plus 12px of space means the neighbours can begin only 17px away, or to put it another way, a 10px target with 7px of space). So this would result in passing more difficult to press and less widely spaced smaller targets.

Remembering that we are trying to get targets to a minimum of 24x24, an option is to beef up the spacing dimension, say from 12px to closest edge to 16px (or even more, or maybe something proportional). This would lead to more spacing on smaller targets (that 10px target would have 11px of space for its closest neighbour) but would also disadvantage targets that are _almost_ 24px across (a 20px target would be 10px+16=26 to closest edge, or 6px space -- 4 more than it needs currently). That results in behaviour that is less consistent than our current model.

Ultimately, most of the challengable things that pass with the current wording are text links, which we were inclined to already give a pass to. In situations where a target is used in a menu or left nav, the hit area tends to have a consistent width, and those controls would need the full 24px.

BTW, this PR does not address the diagonal challenge. I think wording that restricts distance measurement on a vertical or horizontal axis is required -- and that alone may solve the majority of this. Maybe that's coming up later (in which case I'll updated my response).

My sense is that this SC is close to getting removed. We still seem to be floundering around in practical application.
Wilco Fiers None of the above. I wrote a proposal in the issue. Why is that not surveyed?

The 12px update doesn't solve the original issue, and makes other things worse. For example, this would allow two 12px by 12px buttons to touch each other and still pass.
Alastair Campbell
Todd Libby Switch to the suggestion above in PR 2825
Jonathan Avila
Makoto Ueki Switch to the suggestion above in PR 2825
Bruce Bailey Switch to the suggestion above in PR 2825 Minor editorial request in PR 2825 (to use "the target" and not "a target" in phrasing of exception.

FWIW, I am okay with delaying the CR to get this right. This is a very valuable SC.

8. DONE: Change First Note 3.2.6 Consistent Help to align better with SC text #2408

In Issue 2408 Jake pointed out that the SC text of Consistent Help and note don't quite align.

The SC text is: "If a web page contains any of the following help mechanisms..."

The note starts: "Access to help mechanisms may be provided directly on the page..."

Jake is suggesting to change the note to: "Help mechanisms may be provided directly on the page" (bold for the change, not to add bold).

This is implemented in PR 2801. Do you think we should:

Summary

ChoiceAll responders
Results
Adopt the PR 14
Adopt the PR with adjustment 2
Reject the change, it isn't needed
Something else

(4 responses didn't contain an answer to this question)

Details

Responder DONE: Change First Note 3.2.6 Consistent Help to align better with SC text #2408 Comments
Patrick Lauke
John Foliot Adopt the PR with adjustment
JaEun Jemma Ku Adopt the PR
Shikha Nikhil Dwivedi Adopt the PR
Gundula Niemann Adopt the PR
Oliver Keim Adopt the PR
Shawn Thompson Adopt the PR
Laura Carlson Adopt the PR
Detlev Fischer Adopt the PR
Gregg Vanderheiden Adopt the PR
Andrew Kirkpatrick Adopt the PR
Andrew Somers
Stefan Schnabel Adopt the PR
Michael Gower Adopt the PR
Wilco Fiers Adopt the PR
Alastair Campbell
Todd Libby Adopt the PR with adjustment
Jonathan Avila
Makoto Ueki Adopt the PR
Bruce Bailey Adopt the PR

9. DONE: Note in Accessible Authentication needs to be reworded #2714

In Issue 2714 MichaelG pointed out that the wording on one of the notes got a bit mangled in previous changes.

PR 2812 aims to de-mangle.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 15
Agree with adjustment
Something else 2

(3 responses didn't contain an answer to this question)

Details

Responder DONE: Note in Accessible Authentication needs to be reworded #2714Comments
Patrick Lauke Agree with the update
John Foliot Agree with the update
JaEun Jemma Ku Agree with the update The change is much easier to understand the intent. Thanks, Michael.
Shikha Nikhil Dwivedi Agree with the update
Gundula Niemann Something else I feel the new wording is misleading and says something different than the original.
The personal content may be an image, not the term 'Personal content'.
Oliver Keim Something else The quotation marks seem to change the meaning of the within the quotations.
Shawn Thompson Agree with the update
Laura Carlson Agree with the update
Detlev Fischer Agree with the update
Gregg Vanderheiden Agree with the update
Andrew Kirkpatrick Agree with the update
Andrew Somers
Stefan Schnabel Agree with the update
Michael Gower Agree with the update I liked it better when we combined into one bullet, but this is the easier fix.
Wilco Fiers Agree with the update
Alastair Campbell
Todd Libby Agree with the update
Jonathan Avila
Makoto Ueki Agree with the update
Bruce Bailey Agree with the update

10. DONE: 3.3.9 Redundant Entry out of order #2764

In issue 2764 AndrewK points out that the ordering, with regard to levels, of three new SCs is not how it has previously been done. It is currently:

  • 3.3.7 Accessible Authentication - AA
  • 3.3.8 Accessible Authentication (No Exception) - AAA
  • 3.3.9 Redundant Entry - A

Previously we have order by A/AA/AAA, then by version, so that you'd get WCAG 2.0 A/AA/AAA, then WCAG 2.1 A/AA/AAA.

PR 2819 moves 3.3.9 up. Do you:

Summary

ChoiceAll responders
Results
Agree with the update 15
Something else 2

(3 responses didn't contain an answer to this question)

Details

Responder DONE: 3.3.9 Redundant Entry out of order #2764 Comments
Patrick Lauke Agree with the update
John Foliot Agree with the update
JaEun Jemma Ku Agree with the update It sounds like a good idea.
Shikha Nikhil Dwivedi Agree with the update
Gundula Niemann Something else I reader might not have all the history in mind and recognize this structure.
In addition, changing the numbers in the current state is a no-go.
Oliver Keim Something else Keep it as is.
Shawn Thompson Agree with the update
Laura Carlson Agree with the update
Detlev Fischer Agree with the update
Gregg Vanderheiden Agree with the update since they are all new we can do this.
Andrew Kirkpatrick Agree with the update I agree that we don't want to change the numbers but that applies only after we publish the recommendation. Now is the time to tidy this up for clarity.
Andrew Somers
Stefan Schnabel Agree with the update
Michael Gower Agree with the update I can't see why we wouldn't want them ordered properly when we are adding three, as in this case!
That said, we do explicitly say order doesn't matter in our preamble 0.5.2 Numbering in WCAG 2.1.

>The order of success criteria within each guideline does not imply information about conformance level; only the conformance level indicator (A / AA / AAA) on the success criterion itself indicates this.
Wilco Fiers Agree with the update
Alastair Campbell
Todd Libby Agree with the update
Jonathan Avila
Makoto Ueki Agree with the update
Bruce Bailey Agree with the update

11. DONE: Normative wording inconsistencies for Accessible Authentication SCs #2715

In Issue 2715 MichaelG pointed out that, with the re-structuring of the Accessible Authentication SCs, they both have exceptions. Therefore the name "Accessible Authentication (No exception) doesn't make sense anymore.

PR 2813 renames the AAA sc to "Accessible Authentication (Enhanced)".

The issue also included a suggestion to update the items listed, e.g. "Another authentication method exists that". I (Alastair) didn't think that was necessary, but please "agree with adjustment" and comment if you feel strongly that should be updated.

Do you:

Summary

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

(3 responses didn't contain an answer to this question)

Details

Responder DONE: Normative wording inconsistencies for Accessible Authentication SCs #2715 Comments
Patrick Lauke Agree with the update
John Foliot Agree with adjustment
JaEun Jemma Ku Agree with the update
Shikha Nikhil Dwivedi Agree with the update
Gundula Niemann Agree with the update
Oliver Keim Agree with the update
Shawn Thompson Agree with the update
Laura Carlson Agree with the update
Detlev Fischer Agree with the update
Gregg Vanderheiden Agree with the update good catch
Andrew Kirkpatrick Agree with the update
Andrew Somers
Stefan Schnabel Agree with the update
Michael Gower Agree with the update
Wilco Fiers Agree with the update
Alastair Campbell
Todd Libby Agree with the update
Jonathan Avila
Makoto Ueki Agree with the update
Bruce Bailey Agree with the update

12. DEFUNCT: Removal or mark obselete for 4.1.1

After the discussion we had about rewording 4.1.1, which lead to us deciding to remove the SC, Wilco raised Issue 2820 to argue for obsoleting it instead.

PR 2823 shows the approach.

Should we:

Summary

ChoiceAll responders
Results
Change the decision to include the SC but say it is obsolete 5
Keep the decision to remove it 7
Something else 4

(4 responses didn't contain an answer to this question)

Details

Responder DEFUNCT: Removal or mark obselete for 4.1.1Comments
Patrick Lauke Keep the decision to remove it As discussed in the github issue, I personally don't see any difference (in terms of the mentioned problems) between removing and keeping-but-obsoleting. Any materials that refer to/explain WCAG SCs would need to be updated either way, and software/tools would still need to special-case 4.1.1 in a 2.2 assessment (and they would already need to do special-casing anyway for 2.4.7 since that changes from AA to A in 2.2).
John Foliot Something else I would prefer 'deprecated' versus obsolete (mostly for legacy/backward compatibility reasons) - however that is a preference and not a hard blocker.
JaEun Jemma Ku Change the decision to include the SC but say it is obsolete
Shikha Nikhil Dwivedi Change the decision to include the SC but say it is obsolete
Gundula Niemann Keep the decision to remove it
Oliver Keim Keep the decision to remove it
Shawn Thompson Change the decision to include the SC but say it is obsolete
Laura Carlson
Detlev Fischer Keep the decision to remove it Removal or Obsoleting: I have no clear preference here. We should choose whatever approach is less disruptive and easier to understand.
Gregg Vanderheiden Something else Either remove it or leave 4.1.1 (obsolete) and leave the note BUT REMOVE THE TEXT OF THE SC. (otherwise it is too confusing and looks like it is gone.)

Better yet (though probably breaks a rule) Change it to

4.1.1 (Obsolete and removed)

NOTE: Modern web technologies have standardized how user agents parse incorrect markup.
Any invalid markup is therefore allowed under 4.1.1. Parsing for technologies such as
HTML 5 and CSS 3. This success criterion is always satisfied for these technologies.
This success criterion is therefore obsolete and has been removed.

if you are going to leave the text in and just put an OBSOLETE label on it -- the we should add an NOTE to it that explains what OBSOLETE means. PS What does it mean exactly for 2.2 for 2.1 and 2.0?
Andrew Kirkpatrick Keep the decision to remove it And pursue removal from 2.0 and 2.1 via edited specifications route.
Andrew Somers
Stefan Schnabel Change the decision to include the SC but say it is obsolete
Michael Gower Something else I have no strong opinions on either method. It seems to me that both removal and deprecation are going to affect checkers and reporting. I would suggest that once we understand how we _intend_ this to be understood, we can provide information on that, either as part of the conformance section, or possibly right in the revised 4.1.1 text (in whatever form its guidance may be retained).
I _AM_ assuming that deprecation in WCAG is not the same as deprecation in HTML. For instance, I'm assuming (and hope) we don't want teams to actually report 4.1.1 issues/results in WCAG 2.2.

If the position is that 4.1.1 has no effect, and that issues that do cause problems should be reported elsewhere, why would we not encourage teams to do that in both 2.1 and 2.0?

Ultimately, the interest here is reducing churn and align people's understanding and behaviour. Whatever leads to the best result in relation to these two goals is the path to take. Both seem capable of doing so.
Wilco Fiers Change the decision to include the SC but say it is obsolete We need to do an errata also. I don't think we can decide one without the other. Doing this through notes makes an errata much more appropriate too.
Alastair Campbell
Todd Libby Keep the decision to remove it
Jonathan Avila
Makoto Ueki Something else +1 to Gregg. Having that kind of Note is a good idea.
Bruce Bailey Keep the decision to remove it Obsolete is not strong enough. HTML has evolved to the point that 4.1.1 is now counterproductive.

More details on responses

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

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

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.