W3C

Site Navigation

Nearby

Results of Questionnaire WCAG 2.x issue backlog (1)

The results of this questionnaire are available to anybody.

This questionnaire was open from 2023-05-05 to 2023-10-31.

33 answers have been received.

Jump to results for question:

Rewrite SCR37 as an HTML technique #3024
Adding why it is important to 2.1 SCs #3312
Clarification on Focus Not Obscured's "user-opened content" #3333
Tweaks/additions to Understanding Pointer Gestures #910
Added third line to In brief section for WCAG 2.0 SCs #3356
Text Spacing and scoped styles with shadow dom #2495
Clarity for programmatically determined link context term example #3361
Historic Questions: Stop here
DONE: Clarity around a "change initiated by the user" #3226
DONE: Understanding for Contrast does not call out Color Blindness #2033 (take 3)
DONE: Update PDF techniques #3354
DONE: Use of Color Understanding doc: add note concerning same color case #3286
DONE: Update to Focus-not-obscured technique #3277
DONE: Understanding doc for 1.2.9 mentions video #1836
DONE: Non-text Contrast - Figure on background changes #2494
DONE: Understanding for Contrast does not call out Color Blindness #2033
DONE: Suggested improvement to Understanding 2.2.1: Timing Adjustable #1814
DONE: Adjustment to 'in brief' sections
DONE: Parsing update for WCAG 2.1 understanding #3280
DEFUNCT: Suggested improvement to Understanding 2.2.1: Timing Adjustable #1814
DONE: Focus-not-obscured note & understanding document
DONE: Understanding Focus Appearance CR3 updates #3259
DEFUNCT: How to add audio descriptions to videos? #1768
DEFUNCT: Is static content in tab order a failure of 2.4.3? #1572
DEFUNCT: Understanding for Contrast does not call out Color Blindness #2033
DONE: Separate techniques for Target Size #3231
DONE: Adding brief descriptions for all WCAG 2.0 A and AA requirements, understanding docs
DONE: Is visited link color a failure of Use of Color? #905
DEFUNCT: Add definition for “path-based gesture” for 2.2 #758
DEFUNCT: C42 good for 2.5.5, not as example for 2.5.8 Target Size (Minimum) #2433
DEFUNCT: Add 'In brief' section at start of 2.1 SCs #3191
DONE: Do issues with Windows high contrast mode fall under WCAG 2.1? #623
DONE: How to work out 'three flashes' in modern terms
DONE: Delete H45 (longdesc) #2502
DONE: Clarify 1.4.11 and 2.47 relationship in understanding doc #2146
DONE: Are browser/OS settings (prefers-* features) acceptable as a mechanism? #2909
DONE: Mechanism provided by the platform AND stopping 1.4.2: Audio Control #1533
DONE: Does 1.3.1 apply to off screen content? #2520
DONE: 1.4.12 Text Spacing - Clarify text-overflow: ellipsis applicability #728
DONE: Changes to Reflow note and Understanding #1201
DEFUNCT: Add 'In brief' section at start of 2.1 SCs #3191
DONE: Update/correct 3.3.3 understanding #1804
DEFUNCT: WCAG F85: Clarify guidance about where the focus should go when the modal dialog is closed #518
DONE: Clarification on 3.1.2 Language of Parts #297
DONE: 2.2.6: Timeouts - reference to compliance #421
DEFFERED: What is part of accname for Label in Name? #2302 #2276
DONE: Focus being set to the first interactive element in a dialog #2241
DONE: Changes/corrections to 1.4.3 and 1.4.6 understanding #3020
DONE: Inactive components in 1.4.3 & 1.4.6 Understanding #481
DONE: 2.5.3 Label in Name - aria-hidden on part of visual label #2302
DONE: Updating landmark techniques

1. Rewrite SCR37 as an HTML technique #3024

The technique SCR37 is, um, showing it's age. Francis re-created the technique as an more modern HTML version in PR 3024.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	6
Agree if it is adjusted (comment)	3
Something else

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

Details

Responder	Rewrite SCR37 as an HTML technique #3024	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland	Agree with the update
Lori Oakley	Agree with the update
Scott O'Hara	Agree if it is adjusted (comment)	comments/suggestions added to the PR
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree if it is adjusted (comment)	1) The focus does not necessarily go back to the triggering element (even if it still is present. See the second example in https://w3c.github.io/wcag/understanding/focus-order#examples, compare https://github.com/w3c/wcag/issues/3469 . Proposal: "focus management back onto the triggering element (assuming the trigger is still on the page) or back into a given context when the modal dialog is closed;" Step 5 in the test needs to be rewritten accordingly. 2) As using focus-visible means the user sees the focus indicator only after interacting, which might move the focus already or add a tab to the tab change (depending on the implementation and situation, like changing focus position using the mouse). We recommend to not use this technique, but write the example in a way that the focus indicator is immediately visible, as otherwise the focus order is spoiled. 3) Please add a live version of the example for exploring.
Michael Gower	Agree with the update	I fixed some minor typos. Did you intend to provide a working example?
Wilco Fiers	Agree if it is adjusted (comment)	It's not clear (to me) what the relationship to WCAG is. This looks like an advisory technique of SC 2.1.1. It has parts in it that I don't think WCAG requires, and touches on different criteria. That's a problem for a sufficient technique, but I'm okay with this as an advisory technique. We do have to give this an H{number}.html filename though. Various systems rely on us using this letter(s)+number pattern for identifying techniques. If that's something we want to consider changing, we need to do that as a separate project, and consider how to do that in a way that doesn't break existing tools. I don't think we should though; the issue is that if we ever want this technique's title changed we're going to need to change the URL to match. That requires setting up a redirect, so that over time we end up with redirect on top of redirect. I appreciate wanting readable URLs, but this creates downstream problems.
Daniel Henderson-Ede	Agree with the update	Added 1 very minor comment in the PR.

2. Adding why it is important to 2.1 SCs #3312

Michael Gower is continuing with the 'in breif' sections, and PR 3312 adds the 'why is it important' line to the WCAG 2.1 SCs.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	6
Agree with adjustment (comment)	1
Something else

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

Details

Responder	Adding why it is important to 2.1 SCs #3312	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland	Agree with the updates
Lori Oakley	Agree with the updates
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the updates
Laura Carlson	Agree with the updates
Gundula Niemann	Agree with adjustment (comment)	identify input purpose and identify purpose: Both also target screen reader users, so assistive technologies should be mentioned. Text spacing: The SC does not request that a font change is supported. therefore it should not be part of the in-brief section.
Michael Gower	Agree with the updates
Wilco Fiers
Daniel Henderson-Ede	Agree with the updates

3. Clarification on Focus Not Obscured's "user-opened content" #3333

Francis opened Issue 3333 on the user-opened content section of the Focus Not Obscured understanding doc.

Francis added some examples to the document in PR 3341 which would clarify the section.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	3
Agree if adjusted (comment
Something else	1

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

Details

Responder	Clarification on Focus Not Obscured's "user-opened content" #3333	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland	Agree with the updates
Lori Oakley	Agree with the updates
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the updates
Laura Carlson
Gundula Niemann	Something else	Line 126 is not understandable. I also still lack to understand the following: User opened content, except for tooltip, usually receives focus (menu, dialog). So it can never obscure the focus. Can you please clarify? "<li>using the <kbd>Escape</kbd> key to dismiss the obscuring content;</li>" How can a different UI element react on keyboard input than the one which has the focus?
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

4. Tweaks/additions to Understanding Pointer Gestures #910

Patrick is proposing a couple of updates to the Gpointer Gestures understanding document in PR 910.

The content focused on the definition of gestures, trying to clarigy this difficult area.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	8
Agree with adjustment	2
Something else	1

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

Details

Responder	Tweaks/additions to Understanding Pointer Gestures #910	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer	Something else	I have added comments to the PR. I think we need a more fundamental rethinking of the definition of pointer gesture that defines it as (this is a mere draft here): any pointer input that evaluates direction of movement and possibly also speed of movement and (path) length of engagement of pointer - while in contrast, dragging movements may be defined as not being dependant on any of these attributes. See also the discussions around the end of issue https://github.com/w3c/wcag/issues/3344 (Aside: Can we get at some point a fresh survey without umpteen DONE and DEFUNCT items to scroll through?)
Ian Kersey	Agree with the update
Shane Dittmar	Agree with the update
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with adjustment	Please fix the typo in this question: it's "Pointer Gestures". The first image: I'd like it even more of the depicted path containd a curve and wasn't a straight arrow. The second image: A user cannot reach three points at the same time. The visualization should indicate, that these are alternatives. The third image: The second hand is on the path and not on a point. It looks like dragging a path, which is nonsense in this context. The hand should point to a point.
Michael Gower
Wilco Fiers	Agree with adjustment	Maybe just replace the "SC" abbreviation.
Daniel Henderson-Ede

5. Added third line to In brief section for WCAG 2.0 SCs #3356

Michael has continued to work on the 'in brief' sections for the understanding documents. This update adds the 'why it's important' to the WCAG 2.0 SCs in PR 3356.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	8
Agree with adjustment	2
Something else	2

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

Details

Responder	Added third line to In brief section for WCAG 2.0 SCs #3356	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar	Something else	Added a comment to the PR, but I think we need to standardize the form these lines take before accepting them.
Rain Breaw Michaels	Something else	I generally think this is great. A few notes, though. CONCERNS In understanding/20/audio-control.html: There are actually times that the intention is to disrupt, or take the user's attention away from something and direct it to something else out of urgency. Recent example from my own life: local tornado warning with immediate threat to life and property. Can this edit be re-written to acknowledge that this is only meant for unnecessary times? Another possible example: the individual is reaching a time limit and needs to be redirected to options to extend or mitigate the effects of that time limit. In understanding/20/headings-and-labels.html and understanding/20/section-headings.html: Reduced cognition implies that there is equivalence between cognitive disabilities and intellect. Suggest rewording to "Users with reduced sight or cognitive disabilities can orient themselves." FOR CONSIDERATION Not a concern, but a recommendation for consideration, in understanding/20/audio-description-or-media-alternative-prerecorded.html, understanding/20/audio-description-prerecorded.html and understanding/20/extended-audio-description-prerecorded.html: Consider extending why it's important to not just include people who are blind or with low vision, but also "and individuals with a cognitive disability that makes it difficult to understand implied meaning such as facial expressions." Similarly, in understanding/20/audio-only-live.html, understanding/20/captions-live.html and understanding/20/captions-prerecorded.html: Consider extending why it's important not just to include individuals who are deaf or hard of hearing, but also to include "and individuals with a cognitive disability that impacts attention and working memory, so that they have a way to access what they may have missed." In understanding/20/bypass-blocks.html, understanding/20/focus-order.html, understanding/20/focus-visible.html and understanding/20/keyboard-no-exception.html: Consider extending why it's important to include individuals who use switch devices or other AT inputs. In understanding/20/help.html: While this is especially important for individuals with cognitive disabilities, it is really something anyone with a disability may need given that their may be an unexpected barrier between the site, and their abilities or AT. Help is the catch all when all else fails. In understanding/20/images-of-text-no-exception.html: Suggest extending "People cannot alter how text looks in images." to "People cannot alter how text looks in images, and at the time of publishing, assistive technology is inconsistent in its ability to read text in images aloud." In understanding/20/low-or-no-background-audio.html: Consider including people with audio processing disabilities. In understanding/20/media-alternative-prerecorded.html: Consider including people with cognitive disabilities. In understanding/20/parsing.html: Should this be changed to "people can browse the web" instead of "surf"? Or maybe even "people can browse and understand web content more easily"? In understanding/20/pause-stop-hide.html: Consider changing "some people with cognitive disabilities and attention deficits cannot concentrate with continual movement." to "Continual movement can be detrimental for some individuals with cognitive disabilities, attention barriers, and vestibular or other sensory processing disorders." In understanding/20/sensory-characteristics.html: Consider including people with visual processing disorders. In understanding/20/three-flashes-or-below-threshold.html and understanding/20/three-flashes.html: Consider expanding: "migraines, dizziness, nausea, or even seizures." In understanding/20/timing-adjustable.html: Consider moving to person first as in much of the other content, "people with disabilities" instead of "disabled people."
Oliver Keim	Agree with the update
Jennifer Strickland	Agree with the update
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden	Agree with adjustment	I am sending my comments to this question to the list right after I submit this questionaire because this questionaire keeps throwing much of it away when I submit.
Jedi Lin	Agree with adjustment	Some focus on its importance for (general) users, some focus on its importance for people with disabilities. Perhaps list both?
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update
Michael Gower	Agree with the update
Wilco Fiers
Daniel Henderson-Ede	Agree with the update

6. Text Spacing and scoped styles with shadow dom #2495

In issue 2495 Scott raised that a (relatively) new feature of HTML blocks the user's ability to apply their own styles.

To clarify this aspect Scott created PR 2794.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	5
Agree if it is updated (specify change in the comment)	3
Something else	2

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

Details

Responder	Text Spacing and scoped styles with shadow dom #2495	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland	Agree with the update
Lori Oakley	Agree if it is updated (specify change in the comment)	Please explain what ShadowRoot is, by using a link to the explanation or in the text.
Scott O'Hara
Gregg Vanderheiden	Agree if it is updated (specify change in the comment)	We can't add an exemption in the understanding document that is not in the provision itself. the way to fix this is to point out that the SC says it applies where the technology allows it. "In content implemented using markup languages that support the following text style properties" So it should not say it is exempted. We should instead say that it is not required in this instance because it is not supported by this technology the tricky bit is that HTML does not support it but the particular implementation blocks it. I will leave it to the SC authors as to the intent -- but if allowed it should be because the SC says it is not required. Not that it is exempted. Seems like small point but important.
Jedi Lin	Agree with the update
Bruce Bailey	Something else	From call 9-19, uses of Shadow DOM should not be some kind of exception. We might consider a new Failure Technique to add some clarification. Wilco noted that there is a significant difference between "Open Shadow DOM" and "Closed Shadow DOM" and the former is not problematic.
Laura Carlson	Agree with the update
Gundula Niemann
Michael Gower	Agree if it is updated (specify change in the comment)	I'd like to consider the changes suggested by Dan https://github.com/w3c/wcag/pull/2794#pullrequestreview-1631210332 as well as feel that it probably _does_ make sense to capitalize Web Components (or maybe link?) to avoid confusion
Wilco Fiers	Something else	There is nothing in the SC that supports this exception. It is entirely possible for content authors to meet this SC with closed shadow DOM. They can either ensure sufficient default, or provide an alternative method that lets users adjust text spacing. Either one is a perfectly reasonable thing to expect from authors that insist on preventing users from controlling spacing themselves.
Daniel Henderson-Ede	Agree with the update

7. Clarity for programmatically determined link context term example #3361

Scott raised issue 3361 about the definition of "programmatically determined link context".

The core point was that paragraph and table cell are one type of thing, but the example in the definition uses the term "list" instead of "list item".

The change in PR 3362 makes it 'list item', and adds a link to the HTML definition of paragraph (as this is an HTML example).

As this is normative text, it would be an erratum.

Do you:

Summary

Choice	All responders
Choice	Results
Agree to add this as an erratum	11
Agree if it is adjusted (please specify in the comment)	1
Disagree with adding this as an erratum

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

Details

Responder	Clarity for programmatically determined link context term example #3361	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Agree to add this as an erratum
Oliver Keim	Agree to add this as an erratum
Jennifer Strickland	Agree to add this as an erratum
Lori Oakley	Agree to add this as an erratum
Scott O'Hara
Gregg Vanderheiden	Agree to add this as an erratum
Jedi Lin	Agree to add this as an erratum
Bruce Bailey	Agree to add this as an erratum
Laura Carlson	Agree to add this as an erratum
Gundula Niemann	Agree to add this as an erratum
Michael Gower	Agree to add this as an erratum
Wilco Fiers	Agree if it is adjusted (please specify in the comment)	I don't really like this linking to WHATWG's HTML. Since that's a living standard and WCAG isn't, there is no guarantee this won't be pointing to a different definition 10 years from now, or to nothing at all. I also think if we're going to change this example, we should make it clearer that this isn't a complete list of things to look for. I suggest: "In HTML, information that is programmatically determinable from a link in English can for example include text that is in the same paragraph, list item, or table cell as the link or in a table header cell that is associated with the table cell that contains the link."
Daniel Henderson-Ede	Agree to add this as an erratum

8. Historic Questions: Stop here

The questions below have been dealt with, stop here!

Details

Responder	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey
Laura Carlson
Gundula Niemann
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

9. DONE: Clarity around a "change initiated by the user" #3226

Scott raised issue 3226 about Consistent Help, and what constitutes a 'change initiated by the user', for example, whether logging in would constitute that.

DanB created PR 3349 to clarify.

Do you

Summary

Choice	All responders
Choice	Results
Agree with the update	11
Agree if it is adjusted (comment on how)	1
Something else

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

Details

Responder	DONE: Clarity around a "change initiated by the user" #3226	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Agree if it is adjusted (comment on how)	+1 to this but would like the final statement to be expanded as follows: unless logging in would present the user with a distinct set of web pages and/or controls
Oliver Keim	Agree with the update
Jennifer Strickland	Agree with the update
Lori Oakley	Agree with the update
Scott O'Hara	Agree with the update
Gregg Vanderheiden	Agree with the update
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update
Michael Gower	Agree with the update
Wilco Fiers
Daniel Henderson-Ede	Agree with the update

10. DONE: Understanding for Contrast does not call out Color Blindness #2033 (take 3)

We have discussed issue 2033 previously, and did not approve PRs 2034 and 3240 in a previous meeting.

Bruce has taken the feedback and created PR 3284, which we discussed last week, but has been updated based on that discussion.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with update	10
Agree with adjustment	1
Something else

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

Details

Responder	DONE: Understanding for Contrast does not call out Color Blindness #2033 (take 3)	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with update
Andrew Somers	Agree with adjustment	Minor nit pick: I normally use the term “lightness-darkness contrast” because the words lightness-darkness are nouns. But the words light-dark are adjectives, verbs, transitive verbs… and also nouns… in the context the actual meaning is ambiguous. When using “lightness-darkness” the intended meaning is more clear, as nouns only, the words are much less ambiguous.
Detlev Fischer	Agree with update	MInor note: am not a fan of "For all consumers of visual content" but can not think of a better alternative...
Ian Kersey
Shane Dittmar	Agree with update
Rain Breaw Michaels	Agree with update	For consideration in the future (perhaps as a separate issue), it may be worth adding a note here that lets people know that color can, for some individuals, be extremely helpful, so color is not actually a bad design tool. This can be true for individuals with some cognitive and learning disabilities, as well as for some individuals with low vision. It is unfortunately common for people to interpret WCAG as saying that color is purely decorative and/or bad, when in fact it can have real accessibility value when used well, for some individuals.
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree with update
Bruce Bailey	Agree with update
Laura Carlson	Agree with update
Gundula Niemann
Michael Gower	Agree with update	Thanks for working this through to resolution, Bruce! BTW, since you offered the preview of the changes, I had a chance to read this in context, and I think the 3rd paragraph on decorative text should be repositioned after the first sentence of the 11h paragraph much further down the document, which reads "This requirement applies to situations in which images of text were intended to be understood as text." I'm fine to create this as a new PR, but if there is general agreement, I thought it could be snuck in here.
Wilco Fiers
Daniel Henderson-Ede	Agree with update

11. DONE: Update PDF techniques #3354

Quite a few of the PDF techniques were showing their age, so Francis and Lori took it on to update in PR 3354.

There is quite a lot of editorial change, but also image updates, and new OpenOffice content.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	6
Agree with adjustment
Something else	1

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

Details

Responder	DONE: Update PDF techniques #3354	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer	Agree with the update	I trust that these changes are for the better if they are the first since 2011 - but don't have the time and PDF skills to vet these.. thumbs up fro all the work that has gone into these changes!
Ian Kersey	Agree with the update
Shane Dittmar
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Something else	Adobe LiveCycle content might be updated with Adobe AEM Designer rather than removed, as @awkawk pointed out.
Bruce Bailey	Agree with the update
Laura Carlson
Gundula Niemann
Michael Gower	Agree with the update	I did not review every one of these due to binary diffs, etc., but what I could see all looked solid.
Wilco Fiers
Daniel Henderson-Ede

12. DONE: Use of Color Understanding doc: add note concerning same color case #3286

In issue 1467 Scott raised the question of: Does it fail "use of color" if there is no colour difference? The answer is "no" (it's terrible for everyone), but the understanding document doesn't say that.

Scott (now a member of the group) created PR 3286 to add a note about this scenario.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	9
Agree with adjustment	2
Something else	1

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

Details

Responder	DONE: Use of Color Understanding doc: add note concerning same color case #3286	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers	Agree with adjustment	Minor: can we add “alone” to the sentence such that: “… apply to situations where color alone has <em>not</em>” So this is not a fail here… but the example seems it should fail somewhere else? 1.4.11?? Just to add that this feels like the kind of thing that can stir unintended consequences. In the example, if an in-line link has no styling at all, is that a failure of 1.4.11? Or some other SC? Outside of color vision issues, this brings up coga issues and understanding the document issues IMO… As such: would it be prudent to say, instead of “this is a bad experience for all” should it say “while this does not fail color, it could potentially fail other SCs such as ….”
Detlev Fischer	Agree with the update	I have left two wording change suggestions in the PR but approve regardless of whether these are taken up.
Ian Kersey	Agree with the update
Shane Dittmar	Something else	Concur with the suggestions that the language include an explanation that this doesn't fail this SC but may fail other SCs (although based on GitHub conversations about how this is a basic assumption of understanding docs I don't need this to be included). I'm also not sure that "all sighted users" is the best way to identify the group of people for whom an un-styled link would be a poor experience. I think it causes more problems than it solves to explicitly call this a poor experience. Additionally, the current PR contains a sentence fragment. I'd propose this paragraph instead: This criterion does not apply to situations where color has <em>not</em> been used to convey information, indicate an action, prompt a response, or distinguish a visual element. For instance, a hyperlink which has been styled to appear no different than the static text surrounding it would not fail this success criterion, as there would be no color differentiation between the actionable hyperlink text and the static text adjacent to it.
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann
Michael Gower	Agree with adjustment	I suggested some rewording. Still room for improvement, but I think getting the guidance in is more important than perfect wording.
Wilco Fiers
Daniel Henderson-Ede	Agree with the update

13. DONE: Update to Focus-not-obscured technique #3277

We have a published CSS technique for focus-not-obscured, which James raised issue 3187, and Frances has updated in PR 3277.

Do you:

Summary

Choice	All responders
Choice	Results
Agree to the update	8
Agree with adjustment
Something else

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

Details

Responder	DONE: Update to Focus-not-obscured technique #3277	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree to the update
Andrew Somers
Detlev Fischer	Agree to the update
Ian Kersey	Agree to the update
Shane Dittmar
Rain Breaw Michaels	Agree to the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree to the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree to the update
Bruce Bailey	Agree to the update
Laura Carlson	Agree to the update
Gundula Niemann
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

14. DONE: Understanding doc for 1.2.9 mentions video #1836

MattG raised in issue 1836 that the understanding document aimed at audio-only mentions video.

Patrick made a tweak in PR 1837 to avoid a misunderstanding.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	13
Something else	1

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

Details

Responder	DONE: Understanding doc for 1.2.9 mentions video #1836	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp	Agree with the update
Corey Hinshaw	Agree with the update
Daniel Bjorge	Agree with the update
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Something else	By strictly saying "audio" here it implies that tools such as Zoom, Google Meet, and Teams might be exempt because they have both audio and video. Perhaps "web based audio and/or audio-visual conferencing" or "the audio portion of web-based conferencing" would be more clear? I realize that sounds wordy, but want to make sure the scope is clear.
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara	Agree with the update
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update	In PR, I recommended a couple alternatives to "voice conferencing".
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update
Michael Gower	Agree with the update
Wilco Fiers	Agree with the update
Daniel Henderson-Ede

15. DONE: Non-text Contrast - Figure on background changes #2494

giacomo-petri opened issue 2494 on the overlap between non-text contrast and use-of-color.

Patrick created PR 2574 to address the issue, and keep the other images consistent.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	13
Agree if it is adjusted (comment)
Something else (comment)

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

Details

Responder	DONE: Non-text Contrast - Figure on background changes #2494	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp	Agree with the update
Corey Hinshaw	Agree with the update
Daniel Bjorge	Agree with the update
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara	Agree with the update
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update
Michael Gower	Agree with the update
Wilco Fiers
Daniel Henderson-Ede

16. DONE: Understanding for Contrast does not call out Color Blindness #2033

We have discussed issue 2033 previously, and did not approve PRs 2034 and 3240 in a previous meeting.

Bruce has taken the feedback and created PR 3284.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	8
Agree if adjusted (please comment)	1
Something else (please comment)

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

Details

Responder	DONE: Understanding for Contrast does not call out Color Blindness #2033	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the update
Daniel Bjorge	Agree with the update	Thanks for persevering through so many rounds of this, Bruce! I feel much more comfortable with this update than the earlier proposals.
Patrick Lauke
Andrew Somers	Agree with the update
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update	PR 3284 incorporates feedback from issues and PR threads as of Friday 8/18/2023.
Laura Carlson
Gundula Niemann	Agree with the update
Michael Gower	Agree if adjusted (please comment)	My biggest concern with the proposed change is that "luminance" is used throughout the update, yet I don't see the benefit. In the existing text, there's something of a definition in a note on why it makes more sense to use 'relative luminance' than 'luminance'. But the phrase "relative luminance" is not used in these updates at all. My recommendation would be to alter the uses of "luminance contrast" to simply "contrast" and update the note on relative luminance as necessary to provide sufficient context. The name of the SC is Contrast (Minimum), not Luminance Contrast. I also find the inclusion of citations within the text quite unusual for WCAG, where references are kept in a section, not cited in parentheses throughout.
Wilco Fiers
Daniel Henderson-Ede

17. DONE: Suggested improvement to Understanding 2.2.1: Timing Adjustable #1814

We previously discussed issue 1814 about Timing Adjustable and temporary messages such as toast messages.

After the previous discussion updates were made to PR 3281.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	6
Agree if adjusted (comment)	3
Something else (comment)

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

Details

Responder	DONE: Suggested improvement to Understanding 2.2.1: Timing Adjustable #1814	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the update
Daniel Bjorge	Agree with the update
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels	Agree with the update
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara	Agree with the update
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree if adjusted (comment)	I agreed if not adjusted, but I suggest explaining that the 5 second limit on the notification is so the message does not cause a failure against SC 2.2.2 2.2.2 Pause, Stop, Hide. Did we decide if wholly redundant Toasts messages (e.g., a submit button generating a "Form Submitted" brief pop-up) failed SC 2.2.1?
Laura Carlson
Gundula Niemann	Agree if adjusted (comment)	I see two points are missing: 1) Even if there is the ability to verify the arrival of a mail by other means, the timing should be adjustable by user settings. For some users, these message toasts are distracting, so they might wish to switch them off entirely. As a consequence they rely on alternative means. For some users, the time might just be right. Some users are irritated if they can't perceive the notification, yet still prefer the notification over actively verifying. They might wish to have the toast being displayed until dismissed. 2) If the message (toast) contains further information, the message(s) themselves should be retrievable.
Michael Gower	Agree if adjusted (comment)	I suggested some minor tweaks in the PR
Wilco Fiers
Daniel Henderson-Ede

18. DONE: Adjustment to 'in brief' sections

MichaelG and the Education & Outreach group have continued to itterate on the In Brief sections in PR 3252.

The main updates are:

Repositioning the section so it is above the normative text.
Adjusting the terms to "Goal", "What to do", and "Why it's important"
Adding the content for 'why it is imporant'.

These updates have been implemented for the WCAG 2.2 SCs, and if approved can be rolled out to the other SCs.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	6
Agree with adjustment	4
Something else

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

Details

Responder	DONE: Adjustment to 'in brief' sections	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell	Agree with the updates
Melanie Philipp	Agree with adjustment	I left a comment in the PR for Accessible Authentication Enhanced.
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with adjustment	I liked the terseness of the previous approach, but am ok with the more split-out version as well. The specific phrasing on some of these could still do with some amendments though, I think. Will post suggestions to the actual PR.
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the updates
Scott O'Hara	Agree with the updates
Gregg Vanderheiden
Jedi Lin	Agree with the updates
Bruce Bailey	Agree with the updates
Laura Carlson	Agree with adjustment	Great job! I noticed a typo in Redundant Entry. The word "remember" should be "remembering". So it would read, "Some people with cognitive disabilities have difficulty remembering what they entered before." Than you for all of your hard work, Mike.
Gundula Niemann	Agree with adjustment	(I do not manage to comment in the PR.) accessible authentication: I am confused as to what is restricted with which accessible authentication level. The what to do "Don’t make people recognize objects or recall personal information to login" and "Don’t make people solve, memorize, or transcribe something to log in." to me basically means the same. Rather the second restricts more, yet it was cited from the 'minimum' version. Dragging Movements: The SC is about mouse and touch, and the point is that the user cannot perform a reliable and exact dragging movement. This should be reflected int he Why it's important section. Suggestion: Some people cannot perform an exact dragging movement. Focus not obscured enhanced: The point is not, what people do not use nor whether they would be able to use a mouse, but what users in fact chose to use. Why it's important: People who use a keyboard need to easily see what has keyboard focus. focus not obscured minimum: The point is not, what people do not use nor whether they would be able to use a mouse, but what users in fact chose to use. Why it's important: People who use a keyboard need to see what has keyboard focus. redundant entry: not sure about the grammar as I not a native speaker. Some people with cognitive disabilities have difficulty _to_ remember what they entered before. target size minimum: I prefer "cannot" instead of "find it hard to".
Michael Gower	Agree with the updates
Wilco Fiers
Daniel Henderson-Ede

19. DONE: Parsing update for WCAG 2.1 understanding #3280

We previously agreed a note for WCAG 2.1 & 2.0 for Parsing, which is in PR 3152. That will need to be an errata, and a CFC will be coming soon.

To go with that, we should update the WCAG 2.1 (and hopefully 2.0) understanding documents to align. That is done in PR 3280.

The update is quite minimal, remember that the normative text with the new note will appear above the intent section.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	9
Agree if adjstusted	1
Something else

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

Details

Responder	DONE: Parsing update for WCAG 2.1 understanding #3280	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp	Agree with the update
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara	Agree with the update
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update	Just asking, since I am fine with it: > Since this criterion was written, the HTML Standard has adopted specific requirements governing how user agents must handle incomplete tags, incorrect element nesting, duplicate attributes, and non-unique IDs. Is it that the html standards has adopted -- or user agents have adopted in response to evolving HTLM standards?
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update
Michael Gower	Agree with the update
Wilco Fiers	Agree if adjstusted	My recollection is that we did CFC the note for WCAG 2.1 and 2.0. Why do we need another? I think we need to add this note to the understanding document of WCAG 2.1 and 2.0.
Daniel Henderson-Ede

20. DEFUNCT: Suggested improvement to Understanding 2.2.1: Timing Adjustable #1814

AWK suggested in issue 1814 that the understanding document for timing adjustable should cover things like toast messages, which is more common now.

The suggestion is implemented in 3281. It is basically an exampleof the principle that if there are multiple ways to doing things, this one is ok.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	5
Agree if adjusted	4
Something else	1

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

Details

Responder	DEFUNCT: Suggested improvement to Understanding 2.2.1: Timing Adjustable #1814	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp	Agree with the update
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara	Agree if adjusted	i've provided suggested wording updates, but otherwise am good with the intent of this change.
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree if adjusted	I agree in principle, but I thing there is some more wordsmithing need. For example, recommend using "Toast" only as an example of the behavior we allowing for as "decorative" because it seems to mean different things to different people.
Laura Carlson	Agree with the update
Gundula Niemann	Agree if adjusted	I suggest to stick to "messages conveyed via toast" instead of toast message, bevcause not the toast message itself needs to be verified, but the information which it contains. The email example clearly addresses the latter, as it exploits other means to find new messages, not the wording of the toast itself.
Michael Gower	Something else	I am completely fine with the concept suggested by AWK; however, it is not supported by the existing normative text (another of my least favourite SCs). There does not seem to be wording in 2.2.1 that allows timing to exist so long as there is another method of the user accomplishing the same task (in this case, reviewing the toast message, or acting on any link or other UIC in the toast). For this reason, I think this needs to be a normative change. In fact, the normative text for 2.2.1 is inappropriately broad, and would seem to also cause a failure of any author-timed sequence, such as millisecond timing in scripting, etc. It is comprehensive and not even restricted to 'user time limits', even though this seems to clearly be the intent, based on the Understanding document.
Wilco Fiers	Agree if adjusted	I think this should be a little clearer on why something like this is allowed. Can we change the first sentence to something like this: > Content that operates on a timer does not need to be time adjustable if there is an alternative that does not rely on a timer.
Daniel Henderson-Ede

21. DONE: Focus-not-obscured note & understanding document

We had previously surveyed, emailed and discussed some updates to non-normative text for Focus-not-obscured previously.

Unfortunately that wasn't quite resolved, the approved PR was merged into an alternative branch and didn't make it into "main".

Those (generally agreed) changes have been collated into PR 3266 which can be previewed.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	7
Agree with adjustment	1
Something else

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

Details

Responder	DONE: Focus-not-obscured note & understanding document	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley	Agree with the update
Jonathan Avila	Agree with adjustment	I have read and still find this doesn't clearly state some of the intent. What I understand is that a chat region that can be opened by the user that could obscure completely focused elements would need to be closable with the keyboard without moving focus. I agree with that principle - but I'm not sure that is totally clear by the wording. I don't want to block this though - so if this is the intent then I'm ok with the wording rather than not having any wording on this.
Francis Storr
Alastair Campbell
Melanie Philipp	Agree with the update	Editorial: A subject / verb disagreement was introduced in the first note: “…only the initial POSITIONS of user-movable content IS considered …” Options: “…only the initial POSITIONS of user-movable content ARE considered…” or “…only the initial POSITION of user-movable content IS considered…” Spelling error “revealled” should be “revealed” Other: The use of "user-disclosed" vs "user-opened" and "disclosed content" vs "opened content" and similar seems less understandable. "Disclosed" has other connotations and "opened" is very straightforward.
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann
Michael Gower	Agree with the update	This went to CFC and was already adopted, so I'm not sure why we're being resurveyed on it. If the question is 'this merge didn't appear before the standard went to CR, is that okay?' my response is 'yes", since 1) the second 'missing' note was a technical glitch -- the update had already been approved through a CFC showing a Preview version of the PR second note as well as changes to Understanding document, and 2) the note does not increase the requirement.
Wilco Fiers
Daniel Henderson-Ede

22. DONE: Understanding Focus Appearance CR3 updates #3259

DanB undertook and update to the focus-appearance understanding document in PR 3259. (the PR includes an overview of the updates.)

A lot has changed, so it is probably easiest to preview the whole document.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	4
Agree if these adjustments are made (comment)
Something else (comment)

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

Details

Responder	DONE: Understanding Focus Appearance CR3 updates #3259	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley	Agree with the update
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin	Agree with the update
Bruce Bailey	Agree with the update
Laura Carlson
Gundula Niemann
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

23. DEFUNCT: How to add audio descriptions to videos? #1768

Guy Hickling opened an issue on audio descriptions, claiming that any syncronised media without audio-desc would fail.

JonA pointed out that the definition of audio-description actually narrows the scope a little, so including it in the SC text makes it clearer:

1.2.5 Audio Description (Prerecorded): narration is added during existing pauses in dialogue. (See also extended audio description.) and is provided for all prerecorded video content in synchronized media added to the soundtrack to describe important visual details that cannot be understood from the main soundtrack alone (Level AA)

So that could be interpreted as: If there are no pauses in dialogue, then audio-desc may not be applicable.

Patrick created PR 1790 to update the understanding documents on this issue. Patrick's PR took the point of view that even if you don't have pauses then it would fail. There is an alternative version included.

Do you think:

Summary

Choice	All responders
Choice	Results
We should accept PR 1790 as-is.	4
We should accept PR 1790 with the alternative	6
Something else	4

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

Details

Responder	DEFUNCT: How to add audio descriptions to videos? #1768	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	We should accept PR 1790 with the alternative	As what constitutes sufficient amounts of description is subjective, without the alternative we would forever be responding to debates about whether some video failed because the evaluator felt that more audio description was needed. Audio description quantity (and thoroughness) is dependent on the media content.
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp	Something else	WilcoF, MikeG, and BruceB all make good points for "something else". The concept of "extended audio description" is not introduced until the AAA level in 1.2.7 in both the SC name and the definition of extended audio description. I see 1.2.5 as "go as far as you can with the pauses available" and 1.2.7 as "insert pauses to provide full audio description".
Corey Hinshaw
Daniel Bjorge	We should accept PR 1790 as-is.	I think 1790 without the alternative (ie, considering no AD on a video without pauses as a failure) is the most in line with the normative text. The "existing pauses in dialogue" bit comes from an informative note. The normative text demands that if there are important visual details that cannot be understood from the main soundtrack alone, there must be narration added to the soundtrack to describe them. The normative text does not specify the mechanics of how to do so (ducking vs existing pauses vs other), and it does not contain any exception for media without pauses. I think the contested note in the PR is a natural consequence of the lack of any exception in the normative text. I am sympathetic that it makes for a pretty thin line between 1.2.5 and 1.2.7, but I think that tradeoff is preferable to having a note in the understanding document attempt to invent an exception where none exists normatively.
Patrick Lauke	We should accept PR 1790 as-is.
Andrew Somers
Detlev Fischer	We should accept PR 1790 with the alternative	Agree with Mike's observations. In my experience, audit customers very rarely opt for just sticking extra audio on top of their exisiting audio track. Some can be educated to change the video production routine to cater for visual info as part of the main audio from the outset, so no additional AD is needed. As a side note, very often the issue is speakers' names just visually inserted. A common headache is then to determine whether the name of the 'guy on the street' is actually important information that requires AD. I opt for inclusion of the alternative only because that has historically been BITV-Test's common practice in auditing. But I agree with Dan's point that there is nothing in the normative text that suggests this exception.
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland	We should accept PR 1790 with the alternative
Lori Oakley	We should accept PR 1790 with the alternative
Scott O'Hara	We should accept PR 1790 with the alternative
Gregg Vanderheiden
Jedi Lin	We should accept PR 1790 with the alternative
Bruce Bailey	Something else	The WCAG definition of "audio description" is consistent with with decades of theatrical use of the term. If the media is such that extended AD is required to provide good AD, that is not a failure of 1.2.5. I am okay with Understanding describing that audio ducking (of background sound — noise or a music track) may be required for AA conformance. I am not okay with Understanding requiring insertions of pauses or other extended audio description techniques at AA.
Laura Carlson	We should accept PR 1790 as-is.
Gundula Niemann	We should accept PR 1790 as-is.
Michael Gower	Something else	First, I'd like to state for the record that the 1.2.3/1.2.5/1.2.7 is a low-point of the 2.0 standards. They are neither consistently cumulative, nor logical in the hierarchy. It's the only situation I know of in WCAG where you can pass the AAA requirement while failing the clearly matched AA. I'm not even sure how to assess that! That said, I feel like this interpretation has set up something of a false dichotomy. I question how often an example comes up where a video that needs audio description cannot provide _any_ descriptions because there are not _any_ sufficient breaks in the dialog. I think 1.2.5 Audio Descriptions is met when the available breaks in dialog are used to provide additive visual information. Its language supports this. Unlike, say 1.1.1, it does not say ALL important visual information needs to be described. And there can be value in adding 'what one can' in a video. I have certainly suggested ways of shoe-horning some key information into dialog breaks on already produced videos. It's not always pretty, but it can be done and useful. If there are no audio descriptions at all (AND there is important visual information that is not revealed through the dialog/audio in the video) then I do not believe one can say one has passed 1.2.5. Please remember, as well, that there is 1.2.3. So in a situation where there are no dialog breaks, obviously you are going to have to provide a media alternative, or you are going to fail 1.2.3 as well. Yes, that can get one in an odd situation where a single audio description could pass 1.2.3/1.2.5. But to me, the much bigger issue is the absence of ANY audio descriptions on the vast majority of web videos. I get concerned that the original issue focused on high-production movies, etc., whereas the majority of videos on the web do not fit this category. I don't want to introduce any more subjectivity into this than there already is, so the formula should be simple: 1) Is there important visual information not provided in the audio track? 2) Is the video without audio descriptions? If the answer to both questions is YES, then it fails 1.2.5. In terms of the PR, I'm not comfortable with adding the following to the note: > Usually, this will also require lowering the volume of background music and other non-informational sounds. Especially in a non-film context, I do not think this is true. It also directly contradicts this "rare cases" language being added elsewhere in the PR: >In rare cases where the original audio does not provide sufficient pauses, it may be possible to create them by lowering the volume ("ducking") some of the existing dialogue, if the need for audio description is deemed to be more important. I disagree with both alternatives. 1) I do not think you fail Audio Descriptions if you attempt to provide as much contextually meaningful descriptions as there is space. If you have 2 pauses and make use of them in a way that makes sense, you pass 1.2.5 2) Unless there is no important additional visual information, I do no think you pass 1.2.5 if you supply no Audio Descriptions at all.
Wilco Fiers	Something else	The way I read / understand 1.2.3, 1.2.5 and 1.2.7 is that AAA can include modifications to the video to better fit the audio description, but that A / AA do not. So no pausing, no ducking, audio description cues may not be timed perfectly. The additions suggest that ducking / pausing may be required under 1.2.3 and 1.2.5, even if they can't outright say so because the normative text doesn't say so.
Daniel Henderson-Ede

24. DEFUNCT: Is static content in tab order a failure of 2.4.3? #1572

In issue 1572 Patrick raises an issue that perculates up on various lists: Is static content in the tab order a failure of 2.4.3?

In the thread people outlines various problematic and beneficial scenarios for non-interactive content to receive focus. The general theme was that it is not a fail, but can cause problems.

Patrick proposed an update in PR 1643 which proposes a small addition to 2.4.3 understanding to the effect it's not a normative failure unless it creates an illogical focus order - such as double/redundant focus on elements/widget. However, it can cause a usability issue and as best practice should be avoided.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	17
Agree with adjustment	4
Something else

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

Details

Responder	DEFUNCT: Is static content in tab order a failure of 2.4.3? #1572	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel	Agree with adjustment
Chris Loiselle	Agree with the update
Andrew Kirkpatrick	Agree with adjustment
Peter Bossley	Agree with the update
Jonathan Avila	Agree with the update
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp	Agree with the update
Corey Hinshaw	Agree with the update
Daniel Bjorge	Agree with the update
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer	Agree with the update
Ian Kersey	Agree with the update
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with adjustment	Focus order follows reading order, including static components, if needed (e.g. for copy & paste of readonly or display only content).
Jennifer Strickland	Agree with the update	I would also like to see a clarification in visible focus that clarifies when focus should be visible on static content. I tend to make focus visible wherever this is focus because in user research with Veterans it was preferred, resulted in more successful comprehension, and less rage building. Yet I am hesitant to propose a change because I think we recently had a lot of discussion on visible focus and I don't feel fully up to date on the subject. Eric Eggert's recent article is worth reflection. https://yatil.net/blog/wcag22-visible-focus
Lori Oakley
Scott O'Hara	Agree with the update
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with adjustment	The point is valid, yet I feel it can be expressed shorter. Currently the first paragraph suggests the reading order in two columns is following the lines, that is reading a part of column 1, than a part of column 2, again a part of column 1, and so on. Also, some UI elements need to be available for copy and paste.
Michael Gower	Agree with the update	Good update. I'd still like a greater division between items that can have focus put on them (i.e. tabindex="-1") and items which are in the focus/tab order. But that does not need to be made any clearer here; I think the desired outcome is the same -- we don't want items getting focus in an illogical or disruptive order.
Wilco Fiers	Agree with the update
Daniel Henderson-Ede

25. DEFUNCT: Understanding for Contrast does not call out Color Blindness #2033

In issue 2033 Bruce raises that the understanding doc for color contrast does not mention colour blindness.

After some discussion (including why it's a problematic term) Bruce proposed PR 2034 which provides:

Light editorial to opening intent.
Add paragraph about color blindness being addressed.
Add sentence about 4.5:1 permitting black-on-grey-on-white.
Add link to NEI explainer on color blindness.

Update: Bruce took the feedback from last week and created an update to address those in PR 3240.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	11
Agree with adjustment	4
Somethning else	2

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

Details

Responder	DEFUNCT: Understanding for Contrast does not call out Color Blindness #2033	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel	Agree with adjustment	Link to the Knoblauch study or give its exact reference since it is key to the argumentation in the adjustment.
Chris Loiselle	Agree with the update
Andrew Kirkpatrick
Peter Bossley	Agree with the update
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the update	As someone with a form of color blindness, I support the inclusion of the term in the understanding document. I understand the concerns raised in the issue discussion about how the term "color blindness" may be somewhat inaccurate and perhaps too broad, but its use is extremely widespread and omitting it will impede rather than enhance understanding. Support the parallel introduction of the term "Color deficiency" or similar, as a way to bridge the gap in terminology.
Daniel Bjorge	Somethning else	Meta-point: Using one PR that builds on another like this makes it challenging to review the change in totality, which is actually represented by the diff from the PR 3240 branch compared against main (not compared against PR 2034's branch, which is what the PR 3240 view shows). I bet there's a lot of folks this week reviewing just PR 3240 and not giving attention to the bits 2034 already changed. Feedback on change: I'm supportive of the intent of making the intent section identify the impact for folks with color vision deficiencies, but I think this PR needs a lot of editing. * The first paragraph is rambling and the second half of it is misleading. * The second and fourth paragraphs are out-of-place - they would be better suited for the "Rationale for the Ratios Chosen" section * The third paragraph is inaccurate, according to our invited experts on color perception I would much prefer to see the first four paragraphs replaced completely with something based on the suggestions in the "Please Consider This Alternate Wording" section of @Myndex's comment at https://github.com/w3c/wcag/pull/2034#issuecomment-1590353554 - I think taking the first two paragraphs from that suggested wording would be a big improvement.
Patrick Lauke	Agree with adjustment	made a few tiny suggestions in code comments on the PR to increase readability (subjective, of course)
Andrew Somers	Somethning else	I discussed my objections and provided an alternate suggested text in this post: https://github.com/w3c/wcag/pull/2034#issuecomment-1590353554
Detlev Fischer	Agree with the update	Minor suggestion in PR. Agree with Patrick's PR suggestions.
Ian Kersey	Agree with the update
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with adjustment	Line 19: In contrast to that, users with color deficiencies rely on luminance differences.
Jennifer Strickland	Agree with the update
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update	PR 3240 incorporates feedback as of 14 June 2023.
Laura Carlson	Agree with the update
Gundula Niemann	Agree with adjustment	(comment is also given in github) Suggestion: (last sentence changed) The intent of this Success Criterion is to provide enough contrast between text and its background so that it can be read by people with moderately low vision. This user group does not typically use contrast-enhancing assistive technology. For many people, luminance contrast has a significant impact on legibility. For people without color deficiencies, hue and saturation have minimal or no effect on legibility as assessed by reading performance (Knoblauch et al., 1991). Yet color deficiencies can also affect luminance contrast.
Michael Gower	Agree with the update	I find this phrase a little hard to work through. "The luminance and contrast calculations associated with this criterion are formulated in such a way that color (hue) is not a key factor." I think we just need to say this simply and clearly, which I think is something like: "... not a key factor; color combinations that meet 4.5:1 should have improved contrast for all users." I see lots of different suggestions in the PR comments for further information. I suggest we work in changes we can agree on now, and leave stuff we cannot for a future PR.
Wilco Fiers	Agree with the update
Daniel Henderson-Ede

26. DONE: Separate techniques for Target Size #3231

We previously discussed updates to technique C42, but thought it would be better to separate the techniques for the AA and AAA versions of target size.

Frances updated PR 3231 to implement this.

Previews of the new C42 and the new technique (number TBC) are available.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	3
Agree with adjustment	6
Something else

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

Details

Responder	DONE: Separate techniques for Target Size #3231	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel	Agree with adjustment
Chris Loiselle	Agree with the updates
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge	Agree with adjustment	I like splitting the techniques, but it looks like the implementation of the split is a bit incomplete still - C42 looks like it's intended to be for the AAA version and the second example/procedure were updated accordingly, but it's still talking about spacing in the description, title, and first example. Left some more specific suggestions inline in the PR.
Patrick Lauke	Agree with adjustment	left comments on the PR, but copying here: looking at https://raw.githack.com/w3c/wcag/issue-2433/techniques/css/C42.html and https://raw.githack.com/w3c/wcag/issue-2433/working-examples/css-sufficient-target-spacing/index.html ... I would question the use of `rem` there. This makes the size dependent on the root element's font size, which may be the default 16px ... or it may not. I'd say just go with explicit `44px`. more fundamentally, if the idea here is that we want to separate out AA and AAA, and the new https://raw.githack.com/w3c/wcag/issue-2433/techniques/css/adding-spacing-to-undersized-targets.html technique is meant to cover the AA scenario ... then I'd question what that first example in C42 is meant to convey? AAA doesn't have any kind of spacing clause, so what's the point of showing targets that are smaller than 44x44px but then saying that they have sufficient spacing? am I missing something?
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with adjustment	The examples may provide a consistent visual style and emphasis for the visual artifact(s) in question.
Jennifer Strickland	Agree with the updates
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the updates
Laura Carlson
Gundula Niemann	Agree with adjustment	The example in the new technique is not as easy to grasp. The schematic drawings in C42 are easier to grasp, so I feel adding a drawing of that style to the new technique might improve it (even ore).
Michael Gower	Agree with adjustment	I thought the concerns were that some folks didn't want a technique that had both AA 24x24 and AAA 44x44 metrics. C42 seems to still have that? For the new technique, I wonder if it wouldn't work better as : "For all undersized targets that have no equivalent:" 1. Check that they are excepted due to being inline, a user agent control, or essential. 2. Check that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target. #1 or #2 is true
Wilco Fiers
Daniel Henderson-Ede

27. DONE: Adding brief descriptions for all WCAG 2.0 A and AA requirements, understanding docs

Michael Gower has been working on the "In brief" sections for the WCAG 2.0 criteria in PR 3219.

Please add any editorial comments to that PR 3219 github thread, this question is about broad approval.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with adding these in-briefs	11
Agree with adding these in-briefs, if they include these critical changes (comment)
Something else

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

Details

Responder	DONE: Adding brief descriptions for all WCAG 2.0 A and AA requirements, understanding docs	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle	Agree with adding these in-briefs
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp	Agree with adding these in-briefs
Corey Hinshaw
Daniel Bjorge	Agree with adding these in-briefs	Awesome work, thanks Michael! Editorial comments only, inline in PR.
Patrick Lauke	Agree with adding these in-briefs
Andrew Somers
Detlev Fischer	Agree with adding these in-briefs	Great job. I provided some suggestions for mostly editorial changes in the PR now.
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland	Agree with adding these in-briefs
Lori Oakley
Scott O'Hara	Agree with adding these in-briefs
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with adding these in-briefs
Laura Carlson	Agree with adding these in-briefs
Gundula Niemann	Agree with adding these in-briefs	good job! (One comment added asking what is a simple pointer action in contrast to a single pointer action.)
Michael Gower	Agree with adding these in-briefs	Once we get this round through, anticipate a new iteration involving input from EOWG
Wilco Fiers
Daniel Henderson-Ede

28. DONE: Is visited link color a failure of Use of Color? #905

A common question from teams is whether visited and unvisited link colors result in a failure of "Use of Color", as outlined in issue 905.

A couple of key factors for this scenario are that:

There are many states links can be in (visited/unvisited, active, hover, focused, and combinations of those).
You run into the 3-way (or more) colour contrast issues very quickly as they need to contrast with both the background, other text, and potentially other states.
Browsers severely limit what authors can do to visited links so that authors can only change the colour. They will even lie (in javascript) and always return that a link is not visited for privacy reasons.

MichaelG created PR 3222 to update the Use of Color understanding doc.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	13
Agree with adjustment	2
Something else	2

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

Details

Responder	DONE: Is visited link color a failure of Use of Color? #905	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the updates
Stefan Schnabel	Something else	PR 3222 contains "to modify the <code>:visited</code> CSS psuedoclass style" If this is used, it must contain more than only a contrast-compliant diferent color definition, otherwise 2 senses concept is violated, e.g. an additional visual hint style different than color only (italics etc.) https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html
Chris Loiselle
Andrew Kirkpatrick	Agree with the updates
Peter Bossley
Jonathan Avila	Agree with the updates
Francis Storr	Agree with the updates
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the updates
Daniel Bjorge
Patrick Lauke	Agree with the updates
Andrew Somers	Agree with the updates	I agree, I won't get into the veracity of 3:1 for meta states or data coding... if anyone is interested, I have a draft relating to links: https://github.com/Myndex/SAPC-APCA/discussions/65
Detlev Fischer	Agree with the updates
Ian Kersey	Agree with the updates
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the updates
Jennifer Strickland	Agree with the updates
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with adjustment	Nice job tackling this bit of mischief! I have a minor editorial suggested in PR (to drop or modify "Under certain conditions"_). Is this Understanding update a reasonable place to note that UA could/should address this as an end-user preference setting?
Laura Carlson	Agree with the updates
Gundula Niemann	Something else	Though all considerations made are valid, I feel the main point is whether a visited link should be distinguishable from a non-visited link. It makes a difference whether it does not need to be distinguishable or whether it is technically not possible (currently). As visited links are also listed in the browser history, I think they do not need to be indicated on the page itself. To the contrary, indicating them might cause visual noise.
Michael Gower	Agree with the updates
Wilco Fiers	Agree with adjustment	The way I see it, visited isn't a state. Calling it a state and then saying it's exempt for some technical reasons doesn't work for me. It's either a state, in which case all requirements about state apply, or it isn't.
Daniel Henderson-Ede

29. DEFUNCT: Add definition for “path-based gesture” for 2.2 #758

Issue 758 is requesting that a definition for path-based gestures is added.

Although it is only used in 1 SC (2.5.1 Pointer Gestures) directly, it is also referenced in the definition for single pointer.

Previously the argument has been that the understanding document of Pointer Gestures covers this, but we want to get a read from the group for whether to add this as a normative definition. (We'll assume it is possible for the purpose of this question, and work out the details if the group do wish to include a normative change.). The update is implemented in PR 3234.

(Apologies this proposed normative change is being raised now, but it wasn't raised as one of the WCAG 2.x errata people were concerned about last year.)

Do you think we should:

Summary

Choice	All responders
Choice	Results
Add this definition for path-based gestures, it's very important	8
Add this definition for path-based gestures, but not concerned if we don't	2
Rely on the understanding document's explanation
Rely on the understanding document's explanation, strongly against adding the normative definition	3
Something else

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

Details

Responder	DEFUNCT: Add definition for “path-based gesture” for 2.2 #758	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Add this definition for path-based gestures, it's very important
Stefan Schnabel	Add this definition for path-based gestures, but not concerned if we don't
Chris Loiselle
Andrew Kirkpatrick	Rely on the understanding document's explanation, strongly against adding the normative definition	Concerned that we will also need to update 2.1.1 if we do this. Understanding doc can clarify this sufficiently.
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Add this definition for path-based gestures, it's very important
Daniel Bjorge
Patrick Lauke	Add this definition for path-based gestures, it's very important
Andrew Somers
Detlev Fischer	Add this definition for path-based gestures, it's very important
Ian Kersey	Add this definition for path-based gestures, it's very important
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Add this definition for path-based gestures, it's very important
Jennifer Strickland	Add this definition for path-based gestures, it's very important
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Add this definition for path-based gestures, it's very important	In SC 2.1.1, the words "input that depends on the path of the user's movement" should also be linked to this new definition. In Understanding, immediately after Figure 1, add scrollbars to list of examples. The line would then read: > Examples of path-based gestures include swiping, sliders, scrollbars, and carousels dependent on the direction of interaction,...
Laura Carlson
Gundula Niemann	Add this definition for path-based gestures, but not concerned if we don't
Michael Gower	Rely on the understanding document's explanation, strongly against adding the normative definition	This would be a normative change, no? I think we're too far down this path to alter now. Since 2.1 has been out for some time, and AFAIK, this is the only issue that's been opened against this, I think it can stand for now. If I'm right and it has to go in as normative, it can be discussed after 2.2 is complete. In other words, there's no benefit to doing this now, is there?
Wilco Fiers	Rely on the understanding document's explanation, strongly against adding the normative definition	I don't support changing already published criteria, let alone to make substantive changes to them. My understanding of W3C process, this would require re-issuing candidate recommendation, not just for WCAG 2.2, but also for WCAG 2.1 if you want it there. I don't think this can be done in an errata.
Daniel Henderson-Ede

30. DEFUNCT: C42 good for 2.5.5, not as example for 2.5.8 Target Size (Minimum) #2433

In Issue 2433 Jake raised that C42 works for the previous target-size SC, but not the new one.

Frances created PR 3231 to update the technique, with an overview in the PR description.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	10
Agree with adjustment	3
Something else

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

Details

Responder	DEFUNCT: C42 good for 2.5.5, not as example for 2.5.8 Target Size (Minimum) #2433	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley	Agree with the update
Jonathan Avila
Francis Storr	Agree with the update	Comments from Jennifer and Detlev have been addressed and are in the PR.
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the update
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer	Agree with the update	Minor suggestion in PR (align new h1 text and page title)
Ian Kersey	Agree with the update
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the update
Jennifer Strickland	Agree with adjustment	On line 211: <h2>Making pagination links at least least 44px wide and 44px high</h2> "least" is repeated
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann		I like the idea, yet it is hard to verify the details if there is no preview.
Michael Gower	Agree with adjustment	I find the phrase "space around it" a bit odd. If the target was 24x24, it would not have 'space around it' yet it would pass this the criterion, right? We spent some time on the language in target size, to avoid unintentional passes or failures, and this seems to depart from it. Perhaps "bounding box" could get used?
Wilco Fiers	Agree with adjustment	I find it quite confusing that this technique mixes the 24x24 requirement with the 44x44 requirement. I don't think we should put these two measures in the same technique.
Daniel Henderson-Ede

31. DEFUNCT: Add 'In brief' section at start of 2.1 SCs #3191

Michael Gower has continued to work on the 'in brief' sections, in PR 3191, after our previous round of feedback.

We think the previous comments have been addressed.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	8
Agree with adjustment	4
Something else

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

Details

Responder	DEFUNCT: Add 'In brief' section at start of 2.1 SCs #3191	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the updates
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley	Agree with the updates
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with adjustment	Minor suggestion for Content on Hover or Focus added to PR
Daniel Bjorge
Patrick Lauke	Agree with the updates
Andrew Somers
Detlev Fischer		Sorry, have nit found the time to review these...
Ian Kersey	Agree with the updates
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with adjustment
Jennifer Strickland	Agree with adjustment	#### understanding/21/animation-from-interactions.html ##### Current `<dt>Key beneficiaries</dt><dd>Users with vestibular dysfunction</dd>` ##### Recommended `<dt>Key beneficiaries</dt><dd>Users with vestibular dysfunction and motion sensitivity</dd>` ##### Why The distinction is that many with cognitive considerations have motion sensitivity that can trigger a range of symptoms that differ from those with vestibular conditions.
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the updates
Laura Carlson	Agree with the updates
Gundula Niemann	Agree with adjustment	My main comment is on Understanding reflow: As enlarging is not part of then normative text, In think the in brief section should not go for enlargement. What about: “Content can be perceived on a small viewport without requiring horizontal scrolling.” ? Minor remarks have been shared in a mail conversation.
Michael Gower	Agree with the updates	I am in conversation with EOWG, and these are likely to get transformed. But I think having a set of them all a certain of level of validation will help that work along.
Wilco Fiers	Agree with the updates
Daniel Henderson-Ede

32. DONE: Do issues with Windows high contrast mode fall under WCAG 2.1? #623

Jon opened an issue about High Contrast Mode and whether WCAG covered it, or should cover it.

There is a proposed response, essentially for the record to establish consensus in the group.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the response	11
Agree if the response is adjusted (specify in the comment)	4
Have an alternative proposal (specify in the comment)	1

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

Details

Responder	DONE: Do issues with Windows high contrast mode fall under WCAG 2.1? #623	Comments
Steve Faulkner	Agree with the response
Makoto Ueki	Agree with the response
Rachael Bradley Montgomery	Agree with the response
Julie Romanowski	Agree with the response
Jaunita George	Agree with the response
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	Agree with the response
Peter Bossley
Jonathan Avila	Agree if the response is adjusted (specify in the comment)	Rather than just saying no - it might be helpful to note that there are some failure techniques today in WCAG such as failure techniques for pseudo content and CSS Background images as well as defining both foreground and background colors. I believe the intent is not to tell authors how to support it with hacks -but how not to break overrides. We do have other SC today such as 1.4.12 and 1..4.8 that support user preferences. I agree there is not enough support with CSS properties in all cases to support effective implementation and there is no criteria that fully addresses this requirement today in WCAG although there are analogous requirements in EN 301 549 and Section 508 - so this is something to be considered in WCAG 3.0.
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the response	I'd note that the line between user agent / AT responsibility and author responsibility does become blurred these days, though, with an author's ability to also create specific `forced-colors` styles
Andrew Somers	Agree with the response	My statement of agreement is in the thread in a post in April.
Detlev Fischer	Agree if the response is adjusted (specify in the comment)	There was a comment by MReschenberg (platform engineer at Mozilla's a11y team) pointing to new resources - is there anything in there that would suggest an update to the WG answer? If the intent is to have something to point to when the issue arises, one would hope to find a somewhat more comprehensive text describing the aspects of the problem (how author's styles UA behavior and WHCM interact, and what eat side can or should do) which might be more helpful than the response itself (no, I am not putting myself forward to produce this document...) If there are now meaningful adjustments in the list of the comments and / or technical developments since June 2022, I am happy to agree with the response.
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the response
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the response
Laura Carlson	Agree if the response is adjusted (specify in the comment)	Agree with Jon Avila that it would be helpful to include in the response that WCAG does have some failures for pseudo content and CSS Background images as well as defining both foreground and background colors. We also have 1.4.12 and 1.4.8 that support user preferences.
Gundula Niemann	Have an alternative proposal (specify in the comment)	In fact is is 'something else': According to my experience, issues with Windows high contrast mode are usually connected to and fixes requested arguing with Success Criterion 1.4.6 Contrast (Enhanced), not with SC 1.4.8 Visual Presentation (first part). If we agree that the resulting contrasts of a page, when Operating System high contrast mode is applied, do not lie within the responsibility of the author, I suggest to make that crystal clear naming both SC as not being affected. Also the corresponding understanding pages should receive an according update.
Michael Gower	Agree with the response	As noted in my comments in the issue, a Window High Contrast mode issue can be reported in 508/EN. It can also potentially be addressed by 'accessibility supported' in WCAG, but it's unclear _how_ to report that in the VPAT (nor what the author responsibility is).
Wilco Fiers	Agree if the response is adjusted (specify in the comment)	I think a clear "no, not required by WCAG 2.1" in the response would be useful.
Daniel Henderson-Ede

33. DONE: How to work out 'three flashes' in modern terms

Detlev raised issue 1132 based on trying to work out whether a site failed Three Flashes.

Based on more recent updates to SCs like Reflow, there are changes proposed in PR 2127.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	7
Agree with adjustment
Something else	1

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

Details

Responder	DONE: How to work out 'three flashes' in modern terms	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery	Agree with the update
Julie Romanowski	Agree with the update
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers	Agree with the update	I agree in part, but this does not close the issue. I’ve been on record advocating for a smaller area and different luminance thresholds, as the original research was in the 90s with broadcast sets in living rooms. Those were 80nit sets, only half a meter diagonal and a meter and a half away. Today people are inches from devices which can be as bright as 1200nits (or more). There is research ongoing to define the important thresholds more clearly — in the interim I’ve made a few posts on the subject. An area 150px square is more appropriate IMO… and an argument could be made for smaller for mobile. The critical area is effectively 5 degrees of visual angle. Intensity is another issue, the current SC was based on a 200nit display. And it should be noted that “flash” can mean something like in video. A helicopter with blades casting rotating (flashing) shadows, or driving under trees causing pulsing light. And intensity of a cycle (on/off) is not needed to cause a seizure if the flash is a cycle of red/blue for example. SIDE NOTE: And to answer the question in the thread, one flash is the complete cycle of on to off. So three flashes is three on to off cycles. Ex: Red/blue/red/blue/red/blue is three flashes.
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update	This is a fine update to Understanding. But it is not clear to me that it closes the issue. But if OP (detlev) is happy, I am happy!
Laura Carlson
Gundula Niemann	Something else	1) I do nnot see the rationale behind these numbers 341x256. In the overall context of WCAG 320x256 seems more logical. 2) if a user enlarges text via zoom, the procentual part of the screen that plashes increases. 3) if a user uses a screen magnifier, suddebnly the flashing part could fill the whole screen. Therefore I suggest to choose a much smaller size threshold (like the 24x24 px approach).
Michael Gower	Agree with the update	I totally forgot I'd written this!
Wilco Fiers	Agree with the update	Fine, except why is the PR merged already?
Daniel Henderson-Ede

34. DONE: Delete H45 (longdesc) #2502

As outlined in the Issue 2502, the longdesc attribute has been deprecated and has limited support.

PR 2503 removes technique H45, and edits other files to remove the links to that technique.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the change	7
Agree with adjustment	1
Something else	2

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

Details

Responder	DONE: Delete H45 (longdesc) #2502	Comments
Steve Faulkner
Makoto Ueki	Something else	We don't necessarily have to remove H45. WCAG 2 was developed to be flexible so that we could apply WCAG to any kinds of web content technologies. The versions don't matter. We can say this is a kind of the Accessibility Support issue. For example, H45 can be a sufficient technique if the following two conditions are met. - The web page uses HTML 4.01 or XHTML 1.0. - The web page is intended for known and limited user's environments that support the longdesc attribute (e.g. Intranet page where all users are using Chrome/Edge+JAWS) In reality, this is rare and it would not be recommended to use HTML 4.01 or XHTML 1.0 any more. But if it is a old website developed before HTML5 era, this can happen and it should be okay in theory. It is WCAG compliant for intended users. It is not necessarily required to use the latest version of web content technologies in order to meet WCAG 2.x. It just means the longdesc attribute is not deemed as well accessibility-supported to meet WCAG SC in most cases. But I can live with removing H45 though.
Rachael Bradley Montgomery	Agree with the change
Julie Romanowski	Agree with the change
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	Agree with the change
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers	Agree with the change
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the change
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the change	Long live aria-describedby -- but I am shedding a tear for longdesc.
Laura Carlson	Something else	Agree with Makoto that it is an accessibility support issue.
Gundula Niemann
Michael Gower	Agree with adjustment	Should this also be removed from the Conformance info? https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html https://www.w3.org/TR/WCAG21/#conformance > Note: the longdesc attribute is used as an example in Understanding Requirement 2 in WCAG 2.0's Understanding Conformance document, which is linked to from WCAG 2.1's Conformance section.
Wilco Fiers	Agree with the change
Daniel Henderson-Ede

35. DONE: Clarify 1.4.11 and 2.47 relationship in understanding doc #2146

In issue 1385 Yatil pointed out that a line in the understanding document over-stated the effect on 2.4.7 (which doesn't have an exception for default indicators).

The suggested update is in PR 2146.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	11
Agree with adjustment	1
Something else

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

Details

Responder	DONE: Clarify 1.4.11 and 2.47 relationship in understanding doc #2146	Comments
Steve Faulkner
Makoto Ueki	Agree with the update
Rachael Bradley Montgomery	Agree with the update
Julie Romanowski	Agree with the update
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	Agree with the update
Peter Bossley
Jonathan Avila	Agree with the update
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers	Agree with adjustment	1) remove the parenthetical “(but must still be visible)” as redundant (conveyed in 2.4.7) and as ambiguous (visible not clearly defined, therefore not testable) 2) rewrite to remove passive voice and reorder subject/predicate. Example: When the website author does not adjust the default focus style for interactive controls (such as links, form fields or buttons), the user agent’s default focus style is exempt from contrast requirements.
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update	Good enough, but I would prefer if the update could track just a little closer to SC prose of "except ... where the appearance of the component is determined by the user agent and not modified by the author". I do not have an adjustment to suggest.
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update	It's more precise.
Michael Gower	Agree with the update
Wilco Fiers	Agree with the update
Daniel Henderson-Ede

36. DONE: Are browser/OS settings (prefers-* features) acceptable as a mechanism? #2909

In issue 2909 Patrick asked whether user-preferences could be thought of as a mechanism to conform (moving some responsibility onto the user/user-agent).

Rather than a change, a response was drafted , essentially saying that it needs to be considered on a case-by-case basis.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the response	10
Agree with adjustment	1
Something else

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

Details

Responder	DONE: Are browser/OS settings (prefers-* features) acceptable as a mechanism? #2909	Comments
Steve Faulkner
Makoto Ueki	Agree with the response
Rachael Bradley Montgomery	Agree with the response
Julie Romanowski	Agree with the response
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	Agree with the response
Peter Bossley
Jonathan Avila	Agree with adjustment	While I agree it may be usable on a case by case basis - I worry that this could open a slippery slope of creating situations that are accessible in one aspect and not in another. So we say you can use it we must then say that mode then must meet all other WCAG requirements - you can't have one mode that meets some and breaks access in other ways.
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers	Agree with the response	I agree as “case by case” seems best for now, but ultimately, the direction we really want to head toward is user preference facilitation as best practice.
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the response
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the response	Response is fine, but it would be nice to have written up as a Sufficient Technique. It would necessarily be very technical.
Laura Carlson
Gundula Niemann	Agree with the response	Basically it is a technique.
Michael Gower	Agree with the response
Wilco Fiers	Agree with the response
Daniel Henderson-Ede

37. DONE: Mechanism provided by the platform AND stopping 1.4.2: Audio Control #1533

We previously discussed whether to update the 'mechanism' language for Audio control from issue 1533, and decided not to.

After that, another proposal was to update the understanding document, which is in PR 2621.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	6
Agree with adjustment	2
Something else	1

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

Details

Responder	DONE: Mechanism provided by the platform AND stopping 1.4.2: Audio Control #1533	Comments
Steve Faulkner
Makoto Ueki	Agree with the update
Rachael Bradley Montgomery
Julie Romanowski	Agree with the update
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	Agree with adjustment	Agree with the understanding doc change but there is a normative document change showing up in the PR that seems to not actually have any changes in it - please confirm. If no normative change here then I'm a full agree.
Peter Bossley
Jonathan Avila	Something else	I can't tell what is being changed here. Are we saying it's ok if the change is for the background? If the question is about the browser mute capabilities - what are we saying? Are we saying it's ok if it's one stream but not if it's multiple? I don't understand what the pull request is changing.
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson
Gundula Niemann	Agree with adjustment	It says:"Therefore, it is important that the user be able to turn off the background sound. " I feel it should say "the user is able" or better: the user has the option to"
Michael Gower	Agree with the update
Wilco Fiers	Agree with the update
Daniel Henderson-Ede

38. DONE: Does 1.3.1 apply to off screen content? #2520

Wilco asked in issue 2520 whether off-screen content could fail 1.3.1.

Detlev proposed an official response.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the response	4
Agree with adjustment	4
Something else	2

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

Details

Responder	DONE: Does 1.3.1 apply to off screen content? #2520	Comments
Steve Faulkner
Makoto Ueki	Something else	I don't think invisible headings are covered by SC 1.3.1. SC 1.3.1 is about "Information, structure, and relationships conveyed through presentation". Invisible data tables used as alternate version of data charts must have proper table mark-up as it is the "alternate version". I'd rewrite to say "Content with visually intrinsic semantics should use the mark-up appropriate for that content. If content is not visible in the viewport, it is not the case for SC 1.3.1 as it is not "conveyed through presentation" as the SC 1.3.1 describes. For example, on the other hand, invisible data tables used as alternate version of data charts for users without vision should have proper table mark-up so that header cells can be identified. Because invisible data tables are the alternate version of the data charts." Although I'd like to suggest that the data tables should be also visible so that more users who are not good at data charts can get the same data.
Rachael Bradley Montgomery	Agree with the response
Julie Romanowski	Agree with the response
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick	Agree with adjustment	Shoulds need to be musts in the response.
Peter Bossley
Jonathan Avila	Agree with adjustment	While I generally agree with things such as data tables, lists, etc. 1.3.1 applies to presentation and it can get tricky for things like headings knowing the intent. I do wonder though about other things - e.g. for example, when text is inserted for a sale because the del element is not supported - some of the techniques for 1.3.1 are met by using text. So as long as we make it clear that this can be met by text as well. In brief, SC 1.3.1 allows for in text as well and I think we need to note that.
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the response
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the response	It also seems relatively common to add invisible text as way to meet 1.3.1 or just to to provide improved SR user experience. This proposed official response is consistent with that practice.
Laura Carlson
Gundula Niemann	Agree with adjustment	just a typo: structire
Michael Gower	Something else	Can't agree. The wording of 1.3.1 is explicit. If something is not conveyed through presentation, it is not covered by 1.3.1. Obviously if at some time it is brought into the viewport, it would be. I get the intent, and there might be an approach to this, but my gut tells me that we could have some very unintended consequences by trying to cover such things under 1.3.1. I'd encourage some thought experiments to try to come up with real world examples that fit the scenario, and see if there is not another way to fail that context in existing SCs.
Wilco Fiers	Agree with adjustment	I think this needs to be explained and justified in the understanding document. Understanding 1.3.1 is all about visual and auditory cues. Nothing in there suggests (to me) that offscreen content requires semantics, nor that inappropriate semantics on offscreen content would be prohibited.
Daniel Henderson-Ede

39. DONE: 1.4.12 Text Spacing - Clarify text-overflow: ellipsis applicability #728

Issue 728 was opened to ask about ellipsis in the context of text-spacing.

MichaelG created PR 2827 to clarify in the understanding document.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	11
Agree with adjustment	3
Something else	2

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

Details

Responder	DONE: 1.4.12 Text Spacing - Clarify text-overflow: ellipsis applicability #728	Comments
Steve Faulkner	Agree with adjustment	https://github.com/w3c/wcag/pull/2827/files#r1208565299
Makoto Ueki
Rachael Bradley Montgomery	Agree with the update
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel	Agree with the update
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila	Agree with adjustment	I think it should be allowed when the link goes to the same text or when the text is contained on the page. We should make it more clear that a link to another page is a way to meet this.
Francis Storr	Something else	I think "generally" in "Where text is not generally truncated but it is when text is spaced…" complicates the sentence. It would be clearer with that word removed.
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the update
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer	Agree with the update
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the update
Jennifer Strickland
Lori Oakley	Agree with adjustment	<li>a mechanism is provided to reveal the truncated text on the page (for instance, the text appears on focus or on activation)</li> On many web sites the entire text will appear on hover no matter the length, e.g. video titles in youtube, subject titles in Outlook.
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update
Michael Gower	Agree with the update
Wilco Fiers	Something else	I'm not keen on this list of options here. It looks too much like a new exception to the success criterion. The only time truncation is allowed is, as the SC says, when there is no loss of content; I.e. there must be some other way for you to get at the truncated information. Also, don't abbreviate Success Criterion to SC.
Daniel Henderson-Ede

40. DONE: Changes to Reflow note and Understanding #1201

MichaelG created PR 1201 with changes to clarify intent of Reflow in answer to issue 1049.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	8
Agree with adjustment	4
Something else	3

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

Details

Responder	DONE: Changes to Reflow note and Understanding #1201	Comments
Steve Faulkner	Agree with the update
Makoto Ueki
Rachael Bradley Montgomery	Agree with adjustment	I agree with Detlev's comments in the issue.
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel	Agree with the update
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila	Agree with adjustment	I don't think we should be removing the examples with the data tables and toolbars.
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Something else	Do not agree with the removal of "However, cells within data tables should fit within the size requirement unless the cell contains types of content that also requires two-dimensional layout for usage or meaning".
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer	Agree with the update	with minor editorial suggestions...
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Something else	is this deletion on purpose? Why?
Jennifer Strickland
Lori Oakley	Agree with adjustment	A better example for this would be a data table with many columns, wrapping the data would make it impossible for the user to understand the data.
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Something else	The only change I can spot is that the folllowng phrase was deleted: "However, cells within data tables should fit within the size requirement unless the cell contains types of content that also requires two-dimensional layout for usage or meaning" I do not agree to this deletion, as having to scroll while reading a single cell content spoils the intention of the requirement.
Michael Gower	Agree with the update
Wilco Fiers	Agree with adjustment	Remove line 42
Daniel Henderson-Ede

41. DEFUNCT: Add 'In brief' section at start of 2.1 SCs #3191

Michael Gower has continued to work on the 'in brief' sections, in PR 3191 the WCAG 2.1 understanding documents are updated.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	8
Agree with adjustment	3
Something else	1

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

Details

Responder	DEFUNCT: Add 'In brief' section at start of 2.1 SCs #3191	Comments
Steve Faulkner	Agree with adjustment	comments added on pr
Makoto Ueki
Rachael Bradley Montgomery	Agree with adjustment	In Key Shortcuts, consider changing "<dt>Author task</dt><dd>Ensure custom shortcuts can be turned off or modified</dd>" to "<dt>Author task</dt><dd>Ensure custom, single-letter keyboard shortcuts can be turned off or modified</dd> Consider changing to better use plain language: Original <dt>Author task</dt><dd>Do not prevent users from varying their mode of input</dd> <dt>Key beneficiaries</dt><dd>Users requiring specific means of operation or using assistive technology</dd> Suggested Revision <dt>Author task</dt><dd>Do not prevent users from inputing data in various ways</dd> <dt>Key beneficiaries</dt><dd>Users who use assistive technology or requireva specific way of inputing data</dd> Is the Objective of input purpose "It is easier to fill out forms." or to "Allow users to customize their forms to make it easier to fill out" ?
Julie Romanowski
Jaunita George	Agree with the updates
Stefan Schnabel	Agree with the updates
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the updates
Daniel Bjorge
Patrick Lauke	Agree with the updates
Andrew Somers
Detlev Fischer	Agree with the updates
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with adjustment	1. <Understanding Content on Hover or Focus>, Key beneficiaries</dt><dd>Blind users and those with low vision</dd> Shouldn't users with cognitive disabilities be added here? e.g. a user with dyslexia needs extra time to decipher the text, a user with a lower level of reading comprehension will also need more time to determine what they are reading. 2. Pointer Gestures, this is misleading as all mobile devices use swipes with multiple swipes, does it need to be noted that this is only computer touchscreens? 3. Understanding SC 2.5.5 Target Size (Enhanced) -a key beneficiary would also be a user with low sight, this user might have blurred vision so the extra distance would help them find the target more accurately.
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the updates
Laura Carlson	Agree with the updates
Gundula Niemann	Something else	I do not agree to all of them. The document titles do not seem to be consistent. Can this also be checked? On the PR: Animation from Interactions: I understand it should be possible to eliminate animation. This should be reflected. The text talk about eliminating unnecessary animation, which lacks a definition of which animation is necessary. Character Key Shortcuts: why does it talk about custom shortcuts? It should be possible to customize character key shortcuts. Concurrent Input Mechanisms: The intent implies the possibility to switch between input modes. This should also be reflected in the 'in brief' section. Suggestion: "Key beneficiaries</dt><dd>Users requiring specific means of operation or using assistive technology, or need to switch input modalities" Content on Hover or Focus: I feel users with cognitive issues (maybe more specific) should be mentioned with the beneficiaries, Identify Input Purpose: The point that the input purpose can be programmatically determined is missing as well as the fact that the input fields collect information. At the moment the in brief section reads like good labels would lead to compliance. While in fact it is about prefilling content. Identify Purpose: The point that the purpose of user interface components, icons, and regions can be programmatically determined is missing. I think it is important to understand that the SC is not about labels and visible text. Label in Name: <no remark> SC 2.6.1 I could not find an SC with this number. The paragraph seems to talk about motion actuation, which is SC 2.5.4 (compare my search result on 2.6.1: https://www.w3.org/WAI/WCAG21/implementation-report/implementation?implementation_id=114) Non-text Contrast: <no remark> SC 2.6.2 I could not find an SC with this number. The paragraph seems to talk about display oroientation, SC 1.3.4 (compare my search result on 2.6.2: https://www.w3.org/WAI/WCAG21/implementation-report/implementation?implementation_id=138) Pointer Cancellation: <no remark> Pointer Gestures: This is not only about touch screens, but also on mouse input. Suggestion: <dt>Objective</dt><dd>Let users operate touchscreens with one finger and let users operate with mouse with single clicks</dd> <dt>Author task</dt><dd>Provide single-point operation for all functions</dd> <dt>Key beneficiaries</dt><dd>Users with some physical disabilities</dd> Reflow: The Reflow Succes Criterion is motivated by text enlargement, yet its normative part is only about display width (or restricted display height, not both at the same time). It alows horizontal scrolling, if tehre is no vertical scrolling on the page (and if the page height is restricted). In addition, it allows content to no longer enlarge when zooming in (see the understanding document). Enlarging without horizontal scrolling is rather the last point in SC 1.4.8. Next, the intent explains that is is mainly about eliminating the need to scroll in reading direction while reading a line of text. This has implications on complex UI elements like flow charts, tables, contaiers with boxed content and even multi-column text. This needs clarification. As a consequence, I do not agree to this in brief text. Status Messages: <no remark> Target Size (Enhanced): <no remark> Text Spacing: The section reads the author of the page is obliged to offer personalization option for ext spacing. According to the SC itself, this is not the case. Suggestion: <dt>Objective</dt><dd>Users can adjust text spacing to make it easier to read</dd> <dt>Author task</dt><dd>Ensure content adapts to user defined text settings</dd> <dt>Key beneficiaries</dt><dd>Users with low vision or some cognitive disabilities</dd> Timeouts: <no remark>
Michael Gower	Agree with the updates
Wilco Fiers
Daniel Henderson-Ede

42. DONE: Update/correct 3.3.3 understanding #1804

Patrick created an update to the understanding doc of error suggestion in PR 1804 which addresses several issues:

The plain version of the whole document can be previewed.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	6
Agree with adjustment (comment)	2
Something else (comment)

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

Details

Responder	DONE: Update/correct 3.3.3 understanding #1804	Comments
Steve Faulkner	Agree with the update
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer	Agree with the update
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with adjustment (comment)	Typo: Thedefinition of "input error" a black is missing <li>A description of the set of values, e.g., "Please provide the name of the month."</li> I feel a description of the set of values is fine. For example, months have very different names in other calendars, several calendars might be used at the same time. I agree the fix suggestion should not repeat the label. The label could be (in such a case): date (in long format) (not a good one) or a question: Which month of the year is your favorite? The month example might not be the best one to trigger a description of the set of values. It is more typical for pasword: "The password must contain three of the following: lower case letters, uppercase letter, numbers, or special symbols." To sum it up, I suggest to keep the option, yet to give it a better example.
Michael Gower	Agree with adjustment (comment)	I suggested a typo correction
Wilco Fiers
Daniel Henderson-Ede

43. DEFUNCT: WCAG F85: Clarify guidance about where the focus should go when the modal dialog is closed #518

In issue 518 a conflict between the WCAG and ARIA guidance is pointed out.

After quite a bit of discussion, Frances did some testing and outlined a proposal. That proposal was implemented in PR 3214.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	3
Agree with adjustment	3
Something else

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

Details

Responder	DEFUNCT: WCAG F85: Clarify guidance about where the focus should go when the modal dialog is closed #518	Comments
Steve Faulkner	Agree with adjustment	refer to @patrick laukes comment https://github.com/w3c/wcag/pull/3214/files#r1206062351
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George	Agree with the update
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with adjustment	left a comment: change "focus in" to "focus on" in the "Dismiss the menu or dialog" section
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann
Michael Gower	Agree with adjustment	In a situation where a button exists in a table row to delete that table row, when the user activates it, the focus cannot be put back on the target. At IBM we provided guidance to put the focus on the prior UIC in the focus order. This has seemed to work well in such a situation. It matches the guidance on focus order in the dialog, but contradicts the order "forward" in the change. I'd like to see it made a bit less prescriptive.
Wilco Fiers
Daniel Henderson-Ede

44. DONE: Clarification on 3.1.2 Language of Parts #297

In issue 297 Glenda was looking for clarification on whether "language of the parts" included single words. Similar questions are asked in issue 1174 and issue 287.

Patrick created PR 808 to change the top of the intent from "content" to "words, phrases or passages". Although closed, the proposed change appears to solve the various issues.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the change	8
Agree with adjustment
Something else	2

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

Details

Responder	DONE: Clarification on 3.1.2 Language of Parts #297	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel	Agree with the change
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Something else	Agree with Wilco's comment in the PR. While I don't feel that authors should be discouraged from adding lang attributes to individual words, the SC and understanding doc should not require this level of granularity.
Daniel Bjorge
Patrick Lauke	Agree with the change
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the change
Jennifer Strickland
Lori Oakley	Agree with the change
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the change
Laura Carlson	Agree with the change
Gundula Niemann	Agree with the change
Michael Gower	Agree with the change
Wilco Fiers	Something else	I think individual words in a sentence should be explicitly exempt as something that is out of scope of SC 3.1.2. I think the PR takes this in the wrong direction. See my comment on the PR as well.
Daniel Henderson-Ede

45. DONE: 2.2.6: Timeouts - reference to compliance #421

In issue 421 'ghost' requested that the 'compliance' aspect of Timeouts be specified.

An additional paragraph was added in PR 501 to outline two examples.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	9
Agree with adjustment
Something else	1

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

Details

Responder	DONE: 2.2.6: Timeouts - reference to compliance #421
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel	Agree with the update
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the update	Agree with the idea of adding examples, but wanted to note that the examples in the PR are US-centric.
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the update
Jennifer Strickland
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update	@Gundula -- PCI and HIPAA abbreviations are fine.
Laura Carlson	Agree with the update
Gundula Niemann	Something else	I like the idea, yet cannot check whether the references are correct.
Michael Gower	Agree with the update	Is there any value in adding this info to the note, instead to the Understanding doc?
Wilco Fiers	Agree with the update
Daniel Henderson-Ede

46. DEFFERED: What is part of accname for Label in Name? #2302 #2276

Issues 2276 and 2302 are on the topic of what should count towards the accname for Label in Name.

MichaelG created PR 2725 to address these with understanding doc updates.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	4
Agree with adjustment
Something else	3

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

Details

Responder	DEFFERED: What is part of accname for Label in Name? #2302 #2276	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel	Something else	For me, invisible and visible label text may differ but should be focused on the same context. If not: authoring error.
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Something else	I'm okay with the content. Note that I pushed up an update to the page that adds support for syntax highlighting (when that bug is fixed) and removes the use of `br` tags in code samples. I also replaced one image where part of it didn't have enough contrast. No changes to the words on the page were made. This is in the LabelInNameUnderstandingUpdates branch.
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the update
Jennifer Strickland
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update	@Wilco, would not a voice input user be likely to speak "email work" and not "email left parenthesis work right parenthesis" ?
Laura Carlson
Gundula Niemann
Michael Gower	Agree with the update
Wilco Fiers	Something else	I think there is nothing magical about parentheses that would suggest they should be exempt. Yes, for "name (required)" it makes sense, but what about a form that has "Email (work)" and "Email (personal)"? Whether something appears in parentheses is a heuristic to use on whether you may not want to consider it part of the label. It's not a hard rule you can apply across the board.
Daniel Henderson-Ede

47. DONE: Focus being set to the first interactive element in a dialog #2241

Phil Jenkins opened issue 2241 about whether the first interactive item in a dialogue must be focused.

The proposed response is:

It isn't a failure of Focus Order if, when a modal dialog is opened, focus isn't set to the first interactive element within the dialog. Focus does need to be set within the dialog.

There is a very small change in PR 2306 to update one of the examples.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the response and change	7
Agree with adjustment of the response / change	1
Something else	1

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

Details

Responder	DONE: Focus being set to the first interactive element in a dialog #2241	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel	Something else	As a default recommendation, yes. In applications, focus can be put on a different interactive element if app input flow requires so.
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the response and change
Alastair Campbell
Melanie Philipp
Corey Hinshaw	Agree with the response and change
Daniel Bjorge
Patrick Lauke	Agree with the response and change
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim	Agree with the response and change	I appreciate a meaningful focus position is now supported.
Jennifer Strickland
Lori Oakley
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the response and change
Laura Carlson
Gundula Niemann	Agree with the response and change	fully agree
Michael Gower	Agree with adjustment of the response / change	I made a suggested tweak in the PR
Wilco Fiers	Agree with the response and change
Daniel Henderson-Ede

48. DONE: Changes/corrections to 1.4.3 and 1.4.6 understanding #3020

In PR 3020 Patrick has tried to correct various little issues and better align the understanding contrast-based understanding documents.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	6
Agree with adjustment
Something else

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

Details

Responder	DONE: Changes/corrections to 1.4.3 and 1.4.6 understanding #3020	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the update
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with the update	Nevertheless, we found that not rounded contrast measurement results might leas to impossible situations: high contrast text on a highlighted area (like button) for example: There is not color combination that leads to exactly 3.0:1 between highlight color and page background (black) and 7.0:1 between highlight color and text color(white), as the color values are discrete. Should a new issue be opened for that?
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

49. DONE: Inactive components in 1.4.3 & 1.4.6 Understanding #481

JamesN opened issue 481 to align the text-contrast documents with non-text contrast on the topic of inactive controls.

MichaelG created PR 3177 to achieve that.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the update	4
Agree with adjustment	1
Something else	1

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

Details

Responder	DONE: Inactive components in 1.4.3 & 1.4.6 Understanding #481	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Something else	It would be useful to add in an example to demonstrate whether the text in a <label>, programmatically connected to a disabled form input, is also exempt from color contrast requirements.
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the update
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the update
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the update
Laura Carlson	Agree with the update
Gundula Niemann	Agree with adjustment	According to our experience, the term 'inactive' is interpreted as 'not receiving action' which implies read-only elements as well as ordinary text. It is also interpreted as 'not currebtly active' like tabs in a tab strip which are not currebtly selected. Therefore please use the term 'disabled' exclusively and do not use the term inactive in this context.
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

50. DONE: 2.5.3 Label in Name - aria-hidden on part of visual label #2302

In issue 2302 JoeW pointed out a scenario where Label-in-name clashed with good practice for screenreader usage.

MichaelG updated G11 and the label-in-name understanding doc to try and mitigate these issues in PR 2725.

These changes also address issue 2276.

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the changes	4
Agree with adjustment
Something else

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

Details

Responder	DONE: 2.5.3 Label in Name - aria-hidden on part of visual label #2302	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the changes
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the changes
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the changes
Laura Carlson	Agree with the changes
Gundula Niemann
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

51. DONE: Updating landmark techniques

Back in issue 291 Carolyn MacLeod suggested updating ARIA 11 to remove the application role, and some other changes.

Some were completed a few years ago, but other changes on this topic have been suggested and are available in:

Do you:

Summary

Choice	All responders
Choice	Results
Agree with the updates	5
Agree with adjustment
Something else

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

Details

Responder	DONE: Updating landmark techniques	Comments
Steve Faulkner
Makoto Ueki
Rachael Bradley Montgomery
Julie Romanowski
Jaunita George
Stefan Schnabel
Chris Loiselle
Andrew Kirkpatrick
Peter Bossley
Jonathan Avila
Francis Storr	Agree with the updates
Alastair Campbell
Melanie Philipp
Corey Hinshaw
Daniel Bjorge
Patrick Lauke	Agree with the updates
Andrew Somers
Detlev Fischer
Ian Kersey
Shane Dittmar
Rain Breaw Michaels
Oliver Keim
Jennifer Strickland
Lori Oakley	Agree with the updates
Scott O'Hara
Gregg Vanderheiden
Jedi Lin
Bruce Bailey	Agree with the updates
Laura Carlson	Agree with the updates
Gundula Niemann
Michael Gower
Wilco Fiers
Daniel Henderson-Ede

More details on responses

Steve Faulkner: last responded on 28, May 2023 at 15:10 (UTC)
Makoto Ueki: last responded on 2, June 2023 at 14:56 (UTC)
Rachael Bradley Montgomery: last responded on 6, June 2023 at 14:45 (UTC)
Julie Romanowski: last responded on 6, June 2023 at 14:47 (UTC)
Jaunita George: last responded on 8, June 2023 at 18:12 (UTC)
Stefan Schnabel: last responded on 19, June 2023 at 12:48 (UTC)
Chris Loiselle: last responded on 23, June 2023 at 15:12 (UTC)
Andrew Kirkpatrick: last responded on 27, June 2023 at 15:01 (UTC)
Peter Bossley: last responded on 11, July 2023 at 02:13 (UTC)
Jonathan Avila: last responded on 11, July 2023 at 15:51 (UTC)
Francis Storr: last responded on 14, July 2023 at 16:24 (UTC)
Alastair Campbell: last responded on 16, July 2023 at 23:33 (UTC)
Melanie Philipp: last responded on 18, July 2023 at 01:34 (UTC)
Corey Hinshaw: last responded on 15, August 2023 at 13:49 (UTC)
Daniel Bjorge: last responded on 21, August 2023 at 20:39 (UTC)
Patrick Lauke: last responded on 25, August 2023 at 18:02 (UTC)
Andrew Somers: last responded on 25, August 2023 at 19:44 (UTC)
Detlev Fischer: last responded on 29, August 2023 at 13:23 (UTC)
Ian Kersey: last responded on 29, August 2023 at 13:47 (UTC)
Shane Dittmar: last responded on 29, August 2023 at 14:36 (UTC)
Rain Breaw Michaels: last responded on 18, September 2023 at 11:52 (UTC)
Oliver Keim: last responded on 18, September 2023 at 12:23 (UTC)
Jennifer Strickland: last responded on 18, September 2023 at 13:27 (UTC)
Lori Oakley: last responded on 18, September 2023 at 14:27 (UTC)
Scott O'Hara: last responded on 18, September 2023 at 18:05 (UTC)
Gregg Vanderheiden: last responded on 19, September 2023 at 06:04 (UTC)
Jedi Lin: last responded on 19, September 2023 at 08:20 (UTC)
Bruce Bailey: last responded on 19, September 2023 at 16:11 (UTC)
Laura Carlson: last responded on 27, October 2023 at 12:18 (UTC)
Gundula Niemann: last responded on 30, October 2023 at 13:57 (UTC)
Michael Gower: last responded on 30, October 2023 at 19:31 (UTC)
Wilco Fiers: last responded on 31, October 2023 at 11:43 (UTC)
Daniel Henderson-Ede: last responded on 31, October 2023 at 14:57 (UTC)

Non-responders

The following persons have not answered the questionnaire:

Chris Wilson
Lisa Seeman-Horwitz
Janina Sajka
Shawn Lawton Henry
Katie Haritos-Shea
Shadi Abou-Zahra
Chus Garcia
David MacDonald
Gez Lemon
Peter Korn
Preety Kumar
Georgios Grigoriadis
Romain Deltour
Chris Blouch
Jeanne F Spellman
Kimberly Patch
Glenda Sims
Ian Pouncey
Léonie Watson
David Sloan
Mary Jo Mueller
John Kirkwood
Reinaldo Ferraz
Matt Garrish
Mike Gifford
Loïc Martínez Normand
Mike Pluke
Justine Pascalides
Tzviya Siegman
Jan McSorley
Sailesh Panchang
Cristina Mussinelli
John Rochford
Sarah Horton
Sujasree Kurapati
Jatin Vaishnav
Sam Ogami
Kevin White
E.A. Draffan
Paul Bohman
JaEun Jemma Ku
骅杨
Victoria Clark
Avneesh Singh
Mitchell Evan
biao liu
Scott McCormack
Denis Boudreau
Rick Johnson
David Swallow
Aparna Pasi
Gregorio Pellegrino
Jake Abma
Nicole Windmann
Ruoxi Ran
Wendy Reid
Charles Adams
Muhammad Saleem
Amani Ali
Trevor Bostic
Jamie Herrera
Shinya Takami
Karen Herr
Kathy Eng
Cybele Sack
Audrey Maniez
Jennifer Delisi
Arthur Soroken
Kai Recke
David Fazio
Daniel Montalvo
Mario Chacón-Rivas
Michael Gilbert
Caryn Pagel
Achraf Othman
Fernanda Bonnin
Jared Batterman
Raja Kushalnagar
Jan Williams
Todd Libby
Isabel Holdsworth
Julia Chen
Marcos Franco Murillo
Yutaka Suzuki
Azlan Cuttilan
Joe Humbert
Ben Tillyer
Charu Pandhi
Poornima Badhan Subramanian
Alain Vagner
Roberto Scano
Kun Zhang
Regina Sanchez
Shawn Thompson
Thomas Brunet
Kenny Dunsin
Jen Goulden
Mike Beganyi
Ronny Hendriks
Breixo Pastoriza Barcia
Olivia Hogan-Stark
Rashmi Katakwar
Julie Rawe
Duff Johnson
Laura Miller
Will Creedle
Shikha Nikhil Dwivedi
Marie Csanady
Meenakshi Das
Perrin Anto
Stephanie Louraine
Rachele DiTullio
Jan Jaap de Groot
Rebecca Monteleone
Anastasia Lanz
Michael Keane
Chiara De Martin
Giacomo Petri
Andrew Barakat
Devanshu Chandra
Helen Zhou
Bryan Trogdon
Mary Ann (MJ) Jawili
禹佳陶
锦澄王
Stephen James
Jay Mullen
Thorsten Katzmann
Tony Holland
Kent Boucher
Abbey Davis
Phil Day
Julia Kim
Michelle Lana
David Williams
Mikayla Thompson
Catherine Droege
James Edwards
Eric Hind
Quintin Balsdon
Mario Batušić
David Cox
Sazzad Mahamud
Katy Brickley
Kimberly Sarabia
Ashley Firth
Daniel Harper-Wain
Kiara Stewart
DJ Chase
Suji Sreerama
David Middleton
Alyssa Priddy
Young Choi
Nichole Bui
Eloisa Guerrero
George Kuan
YAPING LIN
Justin Wilson
Tiffany Burtin
Nayan Padrai
Niamh Kelly
Matt Argomaniz Matthew Argomaniz
Frankie Wolf
Kimberly McGee
Ahson Rana
Carolina Crespo
humor927 humor927
Samantha McDaniel
Matthäus Rojek
Phong Tony Le
Bram Janssens
Graham Ritchie
Aleksandar Cindrikj
Jeroen Hulscher
Alina Vayntrub
Marco Sabidussi
John Toles
Jeanne Erickson Cooley
Theo Hale
Gert-Jan Vercauteren
Karla Rubiano
Aashutosh K
Hidde de Vries
Julian Kittelson-Aldred
Roland Buss
Aditya Surendranath
Avon Kuo
Elizabeth Patrick
Nat Tarnoff
Filippo Zorzi
Mike Pedersen
Rachael Yomtoob

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.