w3c/wbs-design
or
by mail to sysreq
.
The results of this questionnaire are available to anybody.
This questionnaire was open from 2023-02-09 to 2023-05-30.
31 answers have been received.
Jump to results for question:
The horizontal review raised that WCAG should have a separate section for privacy and security issues in issue 3135.
Obviously this is rather late in the process, but fairly simply solved with PR 3215, as suggested by Andrew.
If we can add this normative text at this stage, we can use that PR. If that is not accepted by W3C members, we can fall-back to updating the "Introduction to understanding WCAG" document.
Assuming we can add it, is the PR acceptable to you (as AG members):
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with the update, with adjustment | 6 |
Something else |
(21 responses didn't contain an answer to this question)
Responder | Separate section for privacy and security considerations #3135 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | Agree with the update | If it helps... no harm. |
Patrick Lauke | Agree with the update, with adjustment | Added a comment to the PR, wondering if security should also include 2.2.1, 3.3.8, 3.3.9 (while they don't include the trigger word "security" in the normative text/notes, they seem related to the area of security) |
Julie Romanowski | Agree with the update | |
Jaunita George | Agree with the update | |
Steve Faulkner | Agree with the update, with adjustment | agree that the SC patrick mentions should be added |
Michael Gower | Agree with the update, with adjustment | As per Patrick's comment, https://github.com/w3c/wcag/pull/3215#issuecomment-1563567893 I feel like a couple of other SCs are relevant, even if they do not contain the word "security" in the normative text or note |
Wilco Fiers | Agree with the update, with adjustment | I think these should be informative sections. I don't think we should (or can) add normative sections anymore. I don't see the need for these this info to be normative either, so I think that's fine. I'm less sure about which criteria are here. It seems to me that if Timeouts (AAA) is there, then Time Adjustable fits just as well. I think there are a good number of other criteria that have some security and/or privacy implications too. |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | Agree with the update, with adjustment | A few thoughts: 1. I would prefer it be in the informative Introduction of WCAG 2.2 but am OK with it here. If the group would prefer it in the current location but we are unable to do so, I would prefer the introduction to the understanding document. 2. Should 2.2.5 Reauthenticating also be included in privacy 3. Should 3.3.8 and 3.3.9 on Accessible Authentication be included in security? |
Jonathan Avila | Agree with the update, with adjustment | I agree with others that we could add some - 1.3.5, 3.3.8, 3.3.9, etc. should be considered as well. I'm ok with separate section or adding it somewhere else as appropriate. |
The following questions are already dealt with, stop here!
Responder | Comments |
---|---|
Shawn Thompson | |
Poornima Badhan Subramanian | |
Todd Libby | |
Jay Mullen | |
Gregg Vanderheiden | |
Stefan Schnabel | |
Daniele Marano | |
Andrew Kirkpatrick | |
Daniel Bjorge | |
Melanie Philipp | |
David MacDonald | |
Andrew Somers | |
Kiara Stewart | |
Alastair Campbell | |
Lori Oakley | |
Jennifer Strickland | |
Gundula Niemann | |
Oliver Keim | |
Ian Kersey | |
Laura Carlson | |
Corey Hinshaw | |
Detlev Fischer | |
Patrick Lauke | |
Julie Romanowski | |
Jaunita George | |
Steve Faulkner | |
Michael Gower | |
Wilco Fiers | |
Bruce Bailey | |
Rachael Bradley Montgomery | |
Jonathan Avila |
Scott opened issue 3091 on whether Target Size Min would fail common data visualisation approaches.
The thread came to: Not where they are 'essential'.
Bruce created PR 3188 to include that aspect.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 9 |
Agree with adjustment | 2 |
Something else |
(20 responses didn't contain an answer to this question)
Responder | DONE: Does Target Size (Minimum) result in widespread failure of common dataviz? #3091 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | Agree with the update | |
Gundula Niemann | Agree with adjustment | I prefer the suggested wording "limitations to fine motor input". For geographical maps and interactive data visualization I would either recommend or request that a zoom functionality is provided. By zooming in, the targets provide sufficient size eventually. This could also be a technique. |
Oliver Keim | Agree with the update | "limitations to fine motor input" seems easier to understand, for readers without having or remembering the context. Graphical contexts may provide zooming (in/out) and panning to allow better access to dense graphical output. Such as on maps, scatters, dense line charts, etc. |
Ian Kersey | Agree with the update | |
Laura Carlson | Agree with the update | |
Corey Hinshaw | Agree with the update | |
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | Agree with the update | |
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In a previous discussion we thought more work was needed on password / passcode / verification code used in Accessible Authentication. Michael Gower opened issue 3180 to capture that.
Michael also created PR 3185 to make updates.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 10 |
Agree with adjustment | 1 |
Something else |
(20 responses didn't contain an answer to this question)
Responder | DONE: Accessible authentication - consider other phrase than one time password #3180 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | Agree with the updates | |
Gundula Niemann | Agree with the updates | |
Oliver Keim | Agree with the updates | |
Ian Kersey | Agree with the updates | |
Laura Carlson | Agree with the updates | |
Corey Hinshaw | Agree with the updates | |
Detlev Fischer | ||
Patrick Lauke | Agree with adjustment | added a few small comments on the PR itself |
Julie Romanowski | Agree with the updates | |
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the updates | |
Wilco Fiers | Agree with the updates | |
Bruce Bailey | Agree with the updates | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
From a previous discussion Bruce raised Issue 3193 on Focus Not obscured.
Bruce has a proposal for review in PR 3194 (file view).
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 9 |
Agree with adjustment | 2 |
Something else |
(20 responses didn't contain an answer to this question)
Responder | DONE: Focus Not Obscured (Enhanced) should permit opaque overlays #3193 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | Agree with the update | |
Gundula Niemann | Agree with the update | |
Oliver Keim | Agree with the update | |
Ian Kersey | Agree with the update | |
Laura Carlson | Agree with the update | |
Corey Hinshaw | Agree with the update | |
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | Agree with the update | |
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | Nice changes overall. The first of the items under Failure techniques needs a bit more information to make it an actual failure, since obscuring the item _with_ focus is not a failure. It's the item being obscured as it _gets_ focus. I also think these listed failures that are not actually links need "(future technique)" added at the end (or however we're indicating that officially, these days) |
Wilco Fiers | Agree with adjustment | On line 23, is this actually correct: > or on a device that operates through the keyboard interface, such as a switch or voice input All the tools I've seen to do this actually just render a focus ring on top of the page. They cannot be obscured. Are there ones that don't do this? |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
A simple failure technique was created for Focus Not Obscured min & enhanced in PR 3178, and you can preview the failure.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with adjustment | 3 |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Failure technique for Focus-not-obscured | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | Agree with the update | |
Jennifer Strickland | ||
Gundula Niemann | Agree with adjustment | It says: "Check whether the focused element is completely obscured by other content" the check should be different for minimum nd enhanced. Partial visibility of the focus fails enhanced, but it is sufficient for minimum. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with adjustment | The technique looks good, but think it needs renumbering (see comment on the PR) |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | By convention, we do not give the name of the SC in failure techniques, just the number, so the title should be "Failure of Success Criterion 2.4.12 due to a sticky footer hiding focused elements" |
Wilco Fiers | ||
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | Agree with the update | |
Jonathan Avila |
Wilco opened Issue 2809 a while ago to discuss focus-not-obscured and whether would encourage keyboard issues.
Most of the issue has been addressed in previously agreed PRs, but there is one remaining to finish it off in PR 3163.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 3 |
Agree with adjustment | 2 |
Something else | 1 |
(25 responses didn't contain an answer to this question)
Responder | DONE: Does 2.4.12 Focus not obscured encourage a keyboard anti-pattern #2809 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | Agree with adjustment | Line 32 understanding/22/focus-not-obscured-enhanced.html: grammer is incorrect "<li>People with limited or low vision, who may primarily user a pointer for screen orientation and repositioning, nonetheless benefit from a fuller visible indication of the current point of keyboard interaction, especially where magnification reduces the overall viewing portion of the screen.</li>". this should be "who may primarily use a pointer. Use not user |
Jennifer Strickland | ||
Gundula Niemann | Something else | Both Focus not Obscured (Minimum) and Focus not Obscured (Enhanced) request the focus is not entirely hidden. Did I read wrong or is there an error in the files? |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | |
Wilco Fiers | ||
Bruce Bailey | Agree with adjustment | Corrected typo Lori noted (user -> use) But "use a pointer for screen orientation and repositioning" reads to me like using a mouthstick to push around a tablet. So I recommend a little more editorial work. I would also ask for conversation if a lightbox-type effect which dims the the entire focus -- Is that a failure of Focus No Obscured (Enhanced)? |
Rachael Bradley Montgomery | ||
Jonathan Avila |
After all the changes in focus-appearance, the associated techniques also need updating. DanB created PR 3112 that updates C40 & C41.
This should allow us to close:
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with adjustment | 1 |
Something else |
(26 responses didn't contain an answer to this question)
Responder | DONE: Rewrite technique C40 and associated example per discussion in #3026 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | Agree with adjustment | In the second not on C40 (about outline: none), would it be helpful to state that "outline: transparent" is ok? I.e. it hides the outline but works with forced-colour modes. |
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | I assume the addition of "solid" background colours is to tackle strange outliers where some background pattern happens to alternate pixel colour in such a way that it c cancels out' the contrasting indicators? |
Wilco Fiers | ||
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In previous discussions we had agreed to add an 'in brief' section to understanding documents. An initial set for the WCAG 2.2 SCs has been created in PR 2905.
More can be added for 2.1 and 2.0, but we thought it best to get this into the new SCs first.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with adjustment | 1 |
Something else |
(26 responses didn't contain an answer to this question)
Responder | DONE: Update approved: https://www.w3.org/2023/05/09-ag-minutes.html#t05Add 'In brief' section at start of 2.2 SCs #2905 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | Agree with the update | |
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with adjustment | Left a comment for accessible authentication (enhanced) in the PR - author task for AAA should include author tasks from AA |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | |
Wilco Fiers | ||
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Patrick opened Issue 3128 about the title of G219, which implies that an alternative to dragging has to be "single pointer", and that dragging is not single-pointer.
In a straightforward PR, PR 3133, Patrick makes that update, and an editorial update to F108 (on the SC name).
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with adjustment | |
Something else |
(27 responses didn't contain an answer to this question)
Responder | DONE: G219 title for 2.5.7 Dragging Movement is misleading #3128 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | I find the wording of the technique a little awkward. I recognize it is largeley pre-existing, but suggest we strive for better wording, along the lines of (though neither of these are great): >Ensuring an alternative to dragging movements OR >Ensuring there is an alternative mechanism for functionality provided by dragging movements |
Wilco Fiers | ||
Bruce Bailey | Agree with the update | +1 to M. Gower concern for a little better phrasing. There is still more work needed to distinguish Understanding on 2.1 single pointer from 2.2 dragging movement. |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Wilco opened Issue 3095 about one-time-codes (OTCs) and how we explain them in the understanding doc.
Patrick created PR 3150 to better explain it.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree, with adjustment | |
Something else |
(27 responses didn't contain an answer to this question)
Responder | DONE: Rewrite OTP section in Accessible Authentication understanding #3150 | |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | I made a trivial editorial suggestion. |
Wilco Fiers | ||
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Patrick raised issue 3045 about the lack of a minimum for target size when you include spacing.
Although we didn't want to update the SC text, Patrick created a big update for the understanding document in PR 3103.
This update will also close issue 2755.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with adjustment | |
Something else |
(27 responses didn't contain an answer to this question)
Responder | DONE: Loophole in 2.5.8 Target Size (Minimum)? #3045 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree with the update | and worth emphasising that this PR does more than that ... it now updates the understanding to match the newly reworded target size (minimum) exception for spacing (as currently the understanding document is out of sync, since it explains the concept of target offset, which is now gone, and doesn't touch on the idea of the 24px circles) |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | |
Wilco Fiers | ||
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
ShawnL raised issue 3016 aiming to combine the exceptions for focus-appearance:
Exceptions:
- The focus indicator is determined by the user agent and cannot be adjusted by the author, or
- The focus indicator and the indicator's background color are not modified by the author.
In previous discussions we had decided to keep the exceptions separate due to different technologies allowing authors different levels of control. For example, authors have no control over focus indicators in PDFs (the first exception). The second exception was worded to allow 'default' indicators where they were not changed, but scoping-in changes of background and they can render the indicator invisible.
Previous discussions on this topic:
The response in the thread was essentially: There is no new information here, we can clarify in the understanding document.
Do you:
Choice | All responders |
---|---|
Results | |
Agree that it should be tackled in the understanding document | 3 |
Agree there is a way of combining the exceptions (please comment on what is different from the previous discussions/decisions) | 1 |
Something else (comment) |
(27 responses didn't contain an answer to this question)
Responder | 2.4.11 Focus Appearance exception doesn't match explanation #3016 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Agree that it should be tackled in the understanding document | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree there is a way of combining the exceptions (please comment on what is different from the previous discussions/decisions) | I am find with either. This wording may work, if combining: > Both the focus indicator and the indicator's background color are determined by the user agent and not modified by the author. One thing I'll mention is that the heading structure needs some H4s in the Exceptions area. They are all H3s, yet there are clearly logical sub-sections. I've created a draft branch for this. Depending on where we land, I will adjust and get some reviews https://github.com/w3c/wcag/pull/3166 |
Wilco Fiers | The way I read the issue Shawn has raised, it doesn't seem like he's suggesting to combine the two exceptions, but to broaden the first exception. I do support that, but it seems like a thing the group already decided not to do. | |
Bruce Bailey | Agree that it should be tackled in the understanding document | |
Rachael Bradley Montgomery | Agree that it should be tackled in the understanding document | |
Jonathan Avila |
Dan-HW created a new failture technique for accessible authentication in PR 2990.
Do you:
Choice | All responders |
---|---|
Results | |
Approve the technique | 3 |
Approve with adjustment (specify in comments) | 3 |
Something else |
(25 responses didn't contain an answer to this question)
Responder | Accessible Authentication failure techniques #1916 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | Approve the technique | At least two financial institutions I'm aware of use this approach, so good to have this to show it is a problem. mbgower - I think your suggested have been incorporated? I couldn't see anything left. |
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Approve with adjustment (specify in comments) | Three terms are used: "Password", "Password or passcode", and "passphrase", Only one term should be used, and if it is not 'password' it needs a definition (I have heard none of the other terms before). |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | Approve the technique | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Approve with adjustment (specify in comments) | I suggested some wording changes for one of the examples in the PR. |
Wilco Fiers | Approve with adjustment (specify in comments) | This seems like a fairly contrived scenario. This kind of thing is done for one-time codes, but those are never stored in a password manager. I don't think I've ever seen or heard of a password that was entered by using different fields. While I guess the technique makes sense, I'm not sure it's all that useful as a technique, since as far as I know this isn't really a thing anyone does? Perhaps a more useful example of a failure for this would be one where copy/paste is prevented through scripting? |
Bruce Bailey | Approve the technique | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In order to partially address issue #1218 which requests references for the WCAG 2.2 SC, PR 3146 adds references to research and recommendations by the COGA taskforce.
Do you:
Choice | All responders |
---|---|
Results | |
Approve these additions | 4 |
Approve these additions with the adjustments listed in the comments | 3 |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Adding references to cognitive SC | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | Approve these additions with the adjustments listed in the comments | Several of these links are still being hosted by **_rawgit.com_**, which is a deprecated host, and should be replaced by the appropriate GitHub.io |
Kiara Stewart | Approve these additions | |
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | I cannot judge whether the links are complete and adequate. I like the idea and do not object. | |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | Approve these additions | With the additions in the PR by Patrick. |
Patrick Lauke | Approve these additions with the adjustments listed in the comments | See comments left on the PR regarding links and the typo |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Approve these additions with the adjustments listed in the comments | The first sentence in the referenced document section (https://www.w3.org/TR/coga-gap-analysis/#table1) has two words spelled incorrectly, and an unconventional spelling of "cannot". It suggests misspellings may be endemic, which in turn suggests a general lack of editorial review. At the least, if the references point to w3c documents, those should be put through a basic spell check before being referenced, which may aid some users. > About users: People with cognitive and learning disabilities may be not able use a Web site becuse they can not use the login or authenitification process. |
Wilco Fiers | Approve these additions | |
Bruce Bailey | Approve these additions | +1 and thanks to @patrickhlauke for editorials |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2751 Melanie asked about scenarios where the user would open some content which could then obscure indicators.
There was a long thread, and some updates have already been made. The recent email to the list also covered the premise and direction.
This question is on the wording and understanding document updates.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 2 |
Agree with adjustment (comment on the adjustment needed) | 2 |
Something else |
(27 responses didn't contain an answer to this question)
Responder | DONE: 2.4.12 Focus not Obscured (Minimum) and user opened / controlled content #2751 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | where can the changes be seen? The PR does not seem to be linked. | |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | Agree with adjustment (comment on the adjustment needed) | The mail has: "If a user opens something (e.g. a chat window), but the position is not configurable, then there needs to be a method for the user to close it without moving focus." The above is from Alastair's mail. I read the "but" as exempting any something (window) where the position *is* configurable - is that the correct interpretation? So if I can pick up a chat window and move it to the other side of the viewport, I am fine? The issue is that if the new window doesn't grab the focus, I may still need to move focus to it before I can move or collapse it (with the keyboard - if it offers that option). Also, the formulation seems to allow that I will technically meet this SC if there is any obscure keyboard-supported method to close the window. Would we not demand either a common (ESC) or documented-in-situ method for that? |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the updates | The PR for these changes is in https://github.com/w3c/wcag/pull/3083 It's my intent to get illustrations and outside references added to this once the general direction has support. |
Wilco Fiers | Agree with adjustment (comment on the adjustment needed) | I agree with the concept, but this is an exception to normative, it cannot be a note. And I would like the wording to be clearer. |
Bruce Bailey | Agree with the updates | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Michael Gower raised issue 3129 to tackle a misconception about Content on Hover of focus. (That skip links which become visible on focus would fail.)
There is a note at the bottom of the intent in the understanding document which explains this. However, it is easily missed.
PR 3130 moves the note to under the SC text (in the spec and the understanding document). Notes are not normative, but carry weight. This could be an errata for WCAG 2.1 as well.
Should we:
Choice | All responders |
---|---|
Results | |
Apply the change across 2.2 and 2.1 | 5 |
Apply the change to 2.2 only | 1 |
Not apply the change at all | |
Something else |
(25 responses didn't contain an answer to this question)
Responder | DONE: For 1.4.13 Content on Hover or Focus, note at bottom of Intent section should be moved up #3129 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | Apply the change to 2.2 only | |
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | Apply the change across 2.2 and 2.1 | |
Patrick Lauke | Apply the change across 2.2 and 2.1 | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Apply the change across 2.2 and 2.1 | |
Wilco Fiers | Apply the change across 2.2 and 2.1 | I tried to wordsmith this for readability. |
Bruce Bailey | Apply the change across 2.2 and 2.1 | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 3807, Patrick Lauke asks that '(Minimum)' be added to the name of 3.3.8 Accessible Authentication.
PR 3132 makes this update to change the name of the SC to 3.3.8 Accessible Authentication (Minimum).
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the addition of '(Minimum)' to the name of the SC. | 7 |
Reject the addtion of '(Minimum)' to the name of the SC. |
(24 responses didn't contain an answer to this question)
Responder | DONE: Add '(Minimum)' to the name of SC 3.3.8 Accessible Authentication #3087 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Agree with the addition of '(Minimum)' to the name of the SC. | |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | Agree with the addition of '(Minimum)' to the name of the SC. | |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the addition of '(Minimum)' to the name of the SC. | I've frequently felt that if one had the same requirement over A, AA, and AAA, you would have: Level A: Requirement X (Minimum) Level AA: Requirement X Level AAA: Requirement X (Enhanced). But reviewing the actual use of "(Minimum)" it isn't like that. There is no mid-point between minimum and enhanced. Plus all the minimums seem to be at the AA level. So this seems to align. |
Wilco Fiers | Agree with the addition of '(Minimum)' to the name of the SC. | |
Bruce Bailey | Agree with the addition of '(Minimum)' to the name of the SC. | |
Rachael Bradley Montgomery | Agree with the addition of '(Minimum)' to the name of the SC. | |
Jonathan Avila | Agree with the addition of '(Minimum)' to the name of the SC. |
Mitchell opened issue 3001, pointing out that there is a similar issue with the 1st example in "Programmatically determined" as Parsing has.
ChristopheS suggested using an example with the Accessibility tree, which is implemented in PR 3049.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update for 2.2 only | 3 |
Agree with the update and include as errata for 2.1/2.0 | 7 |
Something else | 6 |
(15 responses didn't contain an answer to this question)
Responder | DONE: Programmatically Determined example describes outdated direct parsing of markup #3001 | Comments |
---|---|---|
Shawn Thompson | Agree with the update and include as errata for 2.1/2.0 | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update and include as errata for 2.1/2.0 | |
Jay Mullen | ||
Gregg Vanderheiden | Something else | this is the opposite direction from what we should be doing. At is already able to "programmatically determine" things using machine vision and this will increase sharply in the future. As a general rule we should only require outcomes - not methods. And in this case we really should not be moving from "accessible to AT" to "accessible using a particular technological method". It is OK to talk about using the accessibility tree as ONE method for satisfying it -- but others will be available in the future (and I predict the near future) and we don't want to exclude them as being a solution when they are commonly available and used. |
Stefan Schnabel | Something else | <aside class="example"><p>Determined in a markup language from elements and attributes that are accessed via the accessibility tree by commonly available assistive technology I like that better since it reflects programmatically determined (programmatically determinable) def of WCAG |
Daniele Marano | ||
Andrew Kirkpatrick | Something else | I agree with Patrick that it is better as it is. The author can ensure that the information is exposed in the tree but not that it is accessed by assistive technology. Accessibility supported takes care of whether it is handled by AT correctly. |
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update for 2.2 only | I"m ok as errata also |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Something else | The text in line 9 is changed twice,so I can't see which is the version to be decided upon. I agree with the version ">Determined in a markup language from elements and attributes that are exposed in the accessibility tree.", as defining a term by what assistive technology does today is not suitable in my opinion. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update for 2.2 only | I am ok with the errata a well. |
Corey Hinshaw | Agree with the update and include as errata for 2.1/2.0 | If adding this update, the term "accessibility tree" should be defined, or a definition referenced, perhaps by linking to the definition in Accessible Name and Description Computation: https://www.w3.org/TR/accname-1.1/#dfn-accessibility-tree |
Detlev Fischer | Agree with the update and include as errata for 2.1/2.0 | |
Patrick Lauke | Agree with the update and include as errata for 2.1/2.0 | can live with just 2.2 (first option), but would ideally like to see this retrospectively changed in 2.1/2.0 |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update and include as errata for 2.1/2.0 | If it's friendly to do the errata, that works for me. |
Wilco Fiers | Something else | This doesn't seem necessary. I would much prefer we update the understanding documents. |
Bruce Bailey | Agree with the update and include as errata for 2.1/2.0 | I am also okay with this as update for 2.2 only. |
Rachael Bradley Montgomery | Agree with the update for 2.2 only | I am ok with the errata a well. There is an additional suggestion in PR 3049 referencing assistive technology. I am supporting the original PR language here "Determined in a markup language from elements and attributes that are exposed in the accessibility tree." |
Jonathan Avila | Something else | Is the accessibility tree available to web based assistive technology and browser extensions today? If not - then there are still many browser and page based assistive technology that rely on access to the DOM and I don't think we can assume that all modern AT yet has access to the accessibility object model. I use a number of extensions daily that seem to use the DOM to provide text to speech. I'd imagine that overlays which provide accessibility features also use the DOM. |
In preparation for tackling the user-controlled content areas issue, MichaelG created PR 3074 to overhaul the intent section.
One of the main changes was to move a note about configurable interfaces from the understanding document to the bottom of the SC text.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 8 |
Agree with the updates with adjustment (specify in the comment field) | 2 |
Something else | 1 |
(20 responses didn't contain an answer to this question)
Responder | DONE: Focus obscured understanding updates #3074 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | Agree with the updates | |
Daniel Bjorge | ||
Melanie Philipp | Something else | I would really like to see user opened / controlled content treated the same as user movable content in the understanding document as explained in issue #2751: https://github.com/w3c/wcag/issues/2751 |
David MacDonald | Agree with the updates | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Agree with the updates | |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the updates | |
Corey Hinshaw | Agree with the updates | |
Detlev Fischer | Agree with the updates with adjustment (specify in the comment field) | Regarding Bruce's rewording suggestion: Instead of "is considered" I guess it would then have to be "are considered" since it refers to "the initial positions", which is plural? And I agree with Melanie to add user opened / controlled content. |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the updates | |
Wilco Fiers | Agree with the updates | |
Bruce Bailey | Agree with the updates with adjustment (specify in the comment field) | I agree with this update. I have an editorial request that the Note use active voice. Please replace "would be" with "is". Current: > ...then only the initial positions of user-movable content **would be** considered for testing and conformance Proposed: > ...then only the initial positions of user-movable content **is** considered for testing and conformance |
Rachael Bradley Montgomery | ||
Jonathan Avila | Agree with the updates |
In Issue 3086 Patrick pointed out some discrepancies in the two target size SCs.
PR 3097 implements some of the suggestions to:
Also, assuming that we have agreed the inline exception, we can also align that exception with PR 2858.
Those include editorial errata to the WCAG 2.1 Target Size (Enhanced).
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 9 |
Agree with adjustment | 1 |
Something else | 1 |
(20 responses didn't contain an answer to this question)
Responder | DONE: Alignment of structure/wording of Target Size SCs #3086 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | Agree with the updates | |
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the updates | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Agree with the updates | |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the updates | |
Corey Hinshaw | Agree with the updates | |
Detlev Fischer | Agree with adjustment | AA still has the difficult-to-understand target offset concept. What happened to the circle approach? (Not sure though what the latest agreed wording of Target size is). @Wilco: I fail to see what is substantially different in the AAA version - other simpler wording, same meaning. |
Patrick Lauke | Agree with the updates | as noted in my comment to the PR, i'd still love some definitive statement about why the "legal" exception isn't in the AAA version. not that i can think of a legal exception per se off the top of my head, but NOT having that exception there seems to give the impression that AAA is not compatible with certain legal requirements? |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the updates | Obviously there may be changes to this based on other updates of the minimum SC wording, but for current version, this makes a lot of sense. |
Wilco Fiers | Something else | This changes the meaning of target size enhanced. It is not an editorial change. I do not support a substantive change to target size enhanced. We previously discussed the difference between the two SCs and had already decided we weren't going to align them. |
Bruce Bailey | Agree with the updates | |
Rachael Bradley Montgomery | ||
Jonathan Avila | Agree with the updates |
In issue 2692, Jake Abma notes that the pre-amble to the examples of 'Accessible Authentication (Enhanced)' states that the examples for the SC are 'very similar' to the examples found in the AA version of 'Accessible Authentication', when in fact they are exactly the same.
PR 3131 makes an update to the understanding document of 'Accessible Authentication (Enhanced)' which changes the language from 'very similar' to 'the same as'. Further, the understanding document of the AA version of 'Accessible Authentication' adds the pre-ample and refers to the AAA version.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with changing the text from 'very similar' to 'the same as' for both understanding documents. | 3 |
Reject changing the text. |
(28 responses didn't contain an answer to this question)
Responder | DONE: "Very similar" examples are actually "exactly the same" #2692 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | Agree with changing the text from 'very similar' to 'the same as' for both understanding documents. | |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with changing the text from 'very similar' to 'the same as' for both understanding documents. | |
Wilco Fiers | ||
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila | Agree with changing the text from 'very similar' to 'the same as' for both understanding documents. |
Wilco raised issue 3050 on the Spacing clause of target-size on two points:
The 'overlapping' term was introduced to remove a lot of niche overlapping/nested cases. Anything which is nested cannot rely on the 'spacing' exception as there is no spacing. We could update that to "touching", or "abut". However, that would mean that adjacent 24px wide buttons with rounded corner would fail, but without rounded corners or with 1px spacing each side and they would pass.
This was discussed in a WCAG 2.x meeting and there appear to be two options:
The favoured alternative was implemented in PR 3089:
Spacing: Targets are spaced such that if 24 CSS pixel diameter circles are centered on each target, none of the circles intersect another circle or target.
An update like this is pushing what we can do at CR, but if it gets consensus I think it is meeting the same aims (but better) as the previous version.
Should we:
Choice | All responders |
---|---|
Results | |
Mitigate the issue in the understanding document | 3 |
Update to the proposed spacing exception | 4 |
Something else | 3 |
(21 responses didn't contain an answer to this question)
Responder | 2.5.8 Target Size "overlapping any other target" does not work #3050 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | Update to the proposed spacing exception | I agree that we would need to think through edge cases some of the other respondants have mentioned (especially cases where the "center" of a target lies outside the target), and that we'd need to update the understanding document accordingly. But overall, I think this new proposal is so vastly better in principle than the old one that I think it's worth trying to do that work even at this late stage of development. This new version is much easier to visualize, much easier to test, much easier/shorter to read, and much easier to justify as following naturally from the intent of the SC. |
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Something else | What is an undersized target? I feel the definition with circles is a good idea, good to understand and feasible to measure for all typical cases. Yet I see issues with edge cases, like overlapping target, targets which do not fill a simple filled shape and the like. What if one target has an L-shape? What if a target is a non-filled circle? What is the center in such cases? I understand the concept of 'centroid' is more suitable, nevertheless there was also the idea of 'somewhere within'. I think it is worth to be thought through. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Mitigate the issue in the understanding document | Updating the understanding doc is okay too. |
Corey Hinshaw | Update to the proposed spacing exception | |
Detlev Fischer | ||
Patrick Lauke | Something else | After all the to-ing and fro-ing around target offset, this seems to now come in and obviate a lot of the complex wordings/contortions we needed to explain target offset (and it seems to go back to one of the very early suggestions I/we had about circles? minus the use of centroids or similar, just allowing the circle to be anywhere?) https://github.com/w3c/wcag/issues/2695#issuecomment-1327889150 have all the various possible scenarios/cases been run against this idea of non-intersecting circles? we seem to have spent lots of time dreaming up all possible variations on the theme and calculating target offsets, working out how/if diagonal offsets apply, etc ... i'd like to see similar effort/evidence that using this much more simplified circle approach (which conceptually I like, since it goes back to the perhaps naive simplicity that I proposed ages ago) covers all scenarios acceptably, and to see where the weird edge cases that might need explanation are |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Update to the proposed spacing exception | The language is much simplified here (goodbye target offset). Better understanding, better consistency, better harmony. It's unfortunate that this version of the PR was polled without taking into account both the suggestions I made several weeks ago for it as well as subsequent changes that have been discussed, which I believe address a number of legitimate questions we needed to tackle going to this version. The best candid, in my opinion is: Spacing: Undersized targets that do not meet another exception are positioned with sufficient spacing so that if a 24 CSS pixel diameter circle is centred on each, none of the circles intersect another circle or target. -- For the question of how to determine the center, I’m going to suggest it’s fine to detail this in the Understanding document. For the huge majority of targets, can we agree it is straight forward? For shapes where it is difficult to determine the center, such as those that lack bilateral symmetry, are ‘hollow’ ,or are concave, I think the best guidance is to create the minimum bounding box for such targets and center the circle on the bounding box. This seems to hold up well for real world creations. |
Wilco Fiers | Something else | This introduces more problems than it solves. First up, "center" is an ambiguous term. Is that the geometric center (i.e. centroid), is it the center of the bounding box, is it something else? Even with that, what's so special about the center that that's where you'd want to draw that circle? The center of two components could be easily offset so that circle doesn't overlap, and leave no space between them at all. It's passing things that shouldn't. The other side-effect is that this is now not just failing small things for being too close, it's failing bigger things for being close to small things. |
Bruce Bailey | Update to the proposed spacing exception | Understanding will have to address "circles centered on each target" -- and that this is not a reference to "centroid" per se. Example: Bullseye target with center target 23px diameter, dead space ring of 22px thickness, and a 2nd target which is a circular ring outside of that 4px thick. "Circles centered on each target" for this bullseye example means a 24px diameter circle centered in the bullseye and a 24px diameter circle with its center in the middle (i.e., 2px in) **anywhere** on the outside ring. |
Rachael Bradley Montgomery | Mitigate the issue in the understanding document | I can live with updating everything using the 24 pixel circles but would prefer clarify the current language in the SC. |
Jonathan Avila | Mitigate the issue in the understanding document | For me the concept of overlapping makes sense even if it has theoretical technical issues. |
Wilco raised issue 3051 regarding the update "inline exception". Partly because Wilco thought that "link lists" should be in scope, and if numbered lists are included then why not "lettered lists"?
In previous discussions it was very difficult to establish an exception which could be consistently applied across a variety of link, non-link, and partial-link lists. Providing an exception based on the visual appearance of numbers/letter/bulleted lists provided the best correlation with what made intuitive sense. We particularly wanted to avoid people assuming it meant HTML based lists, as that is very wide.
From a WCAG 2.x meeting discussion, there is a proposal to change 'numbered' to 'enumerated' and explain in the understanding document, in PR 3084.
Should we:
Choice | All responders |
---|---|
Results | |
Approve the update | 9 |
Approve with adjustment (comment) | 2 |
Something else | 1 |
(19 responses didn't contain an answer to this question)
Responder | 2.5.8 target size should not have a "lists" exception #3051 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | Approve with adjustment (comment) | Why not "ordered" lists? |
Daniel Bjorge | Approve the update | |
Melanie Philipp | ||
David MacDonald | Approve the update | Although I don't really understand the difference between numbered and enumerated.... |
Andrew Somers | Approve the update | |
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Approve the update | Though I prefer to have a 24px size also in lists, I feel 'enumerated' as what we wanted to say when writing 'numbered'. So I agree to the change. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Approve the update | |
Corey Hinshaw | Approve the update | |
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Approve the update | |
Wilco Fiers | Something else | I didn't raise this issue to point out letters aren't exempt. I raised it because I believe lists shouldn't be exempt at all. This exception significantly degrades the benefit people can have from this success criterion, for really no reason I can think of. |
Bruce Bailey | Approve the update | |
Rachael Bradley Montgomery | Approve the update | |
Jonathan Avila | Approve with adjustment (comment) | Enumerated makes sense - I believe that means that the exception is for things that look like lists with some sort of list item indicator and not simply anything in a list structure. |
Wilco raised issue 2809 about the scenario where developers may make cookie banners modal (for keyboard users) to pass focus-not-obscured.
In a previous meeting we had discussed (but decided against) adding an exception for this purpose.
To help mitigate the potential for negative outcomes, a couple of examples have been added to outline positive ways of passing in PR 3043.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 12 |
Agree with adjustment | |
Something else | 2 |
(17 responses didn't contain an answer to this question)
Responder | DONE: Does 2.4.12 Focus not obscured encourage a keyboard anti-pattern #2809 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with the update | |
Gregg Vanderheiden | Agree with the update | |
Stefan Schnabel | Something else | Check Gundulas comment. |
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Agree with the update | I'd appreciate an additional example which describes how a modeless dialog should be built such that it fulfills focus not obscured. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | Agree with the update | |
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | |
Wilco Fiers | Something else | I don't think this addresses the issue raised. |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila | Agree with the update |
In issue 2850 a public commenter suggested updating what 'object recognition' means. It did indicate a misunderstanding of the intent, so an update to the understanding doc is proposed in 3044.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 13 |
Agree with adjustment | |
Something else |
(18 responses didn't contain an answer to this question)
Responder | DONE: Change wording on 3.3.7 Accessible Authentication's exceptions #2850 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with the update | |
Gregg Vanderheiden | Agree with the update | |
Stefan Schnabel | Agree with the update | |
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Agree with the update | |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | Agree with the update | |
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
A public comment in issue 2866 raised some complications around copy-pasting short-term codes.
There appears to be a straightforward answer (in the thread), which is encoded in PR 3046.
Related, Patrick had another PR in 2618 which added more information about transcription and copy-paste.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 10 |
Agree with adjustment | 1 |
Something else | 2 |
(18 responses didn't contain an answer to this question)
Responder | DONE: One-time-passcodes and the test for when an activity requires 'transcription' #2866 | Comments |
---|---|---|
Shawn Thompson | Agree with the updates | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the updates | |
Jay Mullen | Agree with the updates | |
Gregg Vanderheiden | Agree with the updates | |
Stefan Schnabel | Something else | PR 2618 is better. |
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the updates | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Something else | On: PR 3046: An 'email to yourself' is a security risk (man in the middle attack), so it should not be part of what we describe as a process. Why is it a cognitive function test only if it has to be done multiple times? In general, I like the new paragraph, yet I see severe room for improvement. On PR 2618: I agree with the update |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the updates | |
Corey Hinshaw | Agree with the updates | |
Detlev Fischer | ||
Patrick Lauke | Agree with the updates | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the updates | |
Wilco Fiers | Agree with adjustment | How should a tester determine that a code can be copied? It depends on what device the code is received on. If I'm logging in with my phone, I can copy codes from a text message. If that's a work phone I might not be able to copy a code from my personal e-mail account. I think we should add some guidance on how to make that decision. |
Bruce Bailey | Agree with the updates | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Richard Ishida (internationalisation) raised issue 2996 on the wording of the last note on vertical text.
Rather than saying "in a language displayed top to bottom", it should say "in a language displayed vertically", to allow for languages (e.g. Arabic) with vertically set text displayed bottom to top.
This PR 3047 is normative, but editorial.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 13 |
Agree with adjustment | 1 |
Something else |
(17 responses didn't contain an answer to this question)
Responder | DONE: Target size - "in vertically set text" #2996 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | Agree with the update | |
Stefan Schnabel | Agree with the update | |
Daniele Marano | Agree with the update | |
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Agree with the update | I'm fine with the change, yet it's new to me that Arabic writes from bottom to top. The clarification might yield an additional paragraph in the understanding document. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | Agree with the update | |
Detlev Fischer | ||
Patrick Lauke | Agree with the update | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | I'm find with the change. Is there a PR for this? |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Microsoft have raised 3034, requesting that WCAG 2.0 and 2.1 are updated to align with 2.2 on 4.1.1 Parsing, i.e. not be required for conformance.
We had previously discussed (but not settled on) an option for 2.1 and 2.0. In principle, the options appear to be:
We had already committed to updating WCAG 2.1 with previous errata included (e.g. the updated contrast notes) after we'd dealt with WCAG 2.2 issues.
The ACT Task Force have also requested this information, and what happens with the 4.1.1 ACT Rules depends on this decision.
Dealing with this will close Issues 770, 2776, 3034.
If you choose one of the objection options please provide reasoning or it may not be given the weight of an objection.
Do you think we should:
Choice | All responders |
---|---|
Results | |
Add a note to 2.0/2.1 saying it is obsolete but still required, other options are ok (please comment to specify) | 1 |
Add a note to 2.0/2.1 saying it is obsolete but still required, I'd object to other options (please comment with reasoning) | |
Add a note to 2.0/2.1 saying it is obsolete and not required, other options are ok (please comment to specify) | 4 |
Add a note to 2.0/2.1 saying it is obsolete and not required, I'd object to other options (please comment with reasoning) | 1 |
Remove the SC text and leave a note (as 2.2 does), other options are ok (please comment to specify) | 1 |
Remove the SC text and leave a note (as 2.2 does), I'd object to other options (please comment with reasoning) | 4 |
(20 responses didn't contain an answer to this question)
Responder | DONE: Note and / or removal for 4.1.1 in WCAG 2.0/2.1 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | Remove the SC text and leave a note (as 2.2 does), I'd object to other options (please comment with reasoning) | The first two bullets are contradictory. "obsolete in a standard means that it is no longer required". there are no standards that require obsolete items. Bullet 3 and 4 are redundant -- if it is obsolete it is by definition not required. that leaves only the last two which are now the same as each other. |
Stefan Schnabel | Add a note to 2.0/2.1 saying it is obsolete and not required, other options are ok (please comment to specify) | |
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | Remove the SC text and leave a note (as 2.2 does), I'd object to other options (please comment with reasoning) | Reiterating Microsoft's position from issue 3034: * Removing and leaving a note (as 2.2 does) would be ideal * Adding a note saying it is obsolete and *not required* would be acceptable, but the wording would need to be very explicit about the SC being not required to meet any level of WCAG 2.0/2.1 conformance * We would object to "obsolete but still required" - practically speaking, that would mean we would still need to meet the obsolete old text of the requirement for legal compliance purposes for quite a while until legal standards catch up to a new WCAG version. |
Melanie Philipp | Remove the SC text and leave a note (as 2.2 does), I'd object to other options (please comment with reasoning) | Please see Wilco's comments. |
David MacDonald | Add a note to 2.0/2.1 saying it is obsolete and not required, other options are ok (please comment to specify) | I'm ok to remove it as 2.2 does. |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | Add a note to 2.0/2.1 saying it is obsolete and not required, I'd object to other options (please comment with reasoning) | "Add a note to 2.0/2.1 saying it is obsolete but still required" does not sound reasonable to me, how can something be obsolete (no longer valid) and required at the same time? "Remove the SC text and leave a note (as 2.2 does)" might irritate readers who are used to seeing it in the WCAG 2.0 and 2.1.. |
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | Add a note to 2.0/2.1 saying it is obsolete but still required, other options are ok (please comment to specify) | While editorial and minor updates seem reasonable to make in errata, substantive changes to a published WCAG version blurs the definition of what a version is. Ex: It would not be possible, without some detective work, to determine what guidelines a product was evaluated against - was it 2.1 or 2.1 minus 4.1.1? Does this set a precedent for future alterations of published guidelines? Additionally, the rationale for the removal of 4.1.1 in WCAG 2.2 is that functional impacts of parsing errors should be caught in other 2.2 SCs. There has not been as robust a discussion around 4.1.1 failures being caught by 2.1 SCs. I am in the camp that believes 4.1.1 to be obsolete, but the answer here should be to remove the SC from 2.2 and push for adoption of the new version, rather than make changes to 2.1. |
Detlev Fischer | ||
Patrick Lauke | Add a note to 2.0/2.1 saying it is obsolete and not required, other options are ok (please comment to specify) | |
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Add a note to 2.0/2.1 saying it is obsolete and not required, other options are ok (please comment to specify) | |
Wilco Fiers | Remove the SC text and leave a note (as 2.2 does), I'd object to other options (please comment with reasoning) | WCAG 2.2 should be backward compatible with WCAG 2.1 and 2.0. If we remove SC 4.1.1 from 2.2, but not from 2.1 and 2.0 we break that promise. I know it's been argued that it still is, but given that one of the options here is that 4.1.1 may still be required, that's clearly debatable. Removing SC 4.1.1 from WCAG 2.0 and 2.1 ends all debate. |
Bruce Bailey | Remove the SC text and leave a note (as 2.2 does), other options are ok (please comment to specify) | I would object to options leaving 4.1.1 as (implicitly *or* explicitly) "still required" for 2.0 or 2.1. If its status remain ambiguous, that is terrible but better than "still required" IMHO. |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Accessible authentication: In Issue 2650 someone commented that the understanding document is quite long, and doesn't seem to align with the topic.
Jemma took a pass at the document in PR 2988. The topics are generally aligned with the SC, and answer previous questions we have had on the SC.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 6 |
Agree with adjustment | 2 |
Something else |
(23 responses didn't contain an answer to this question)
Responder | DONE: Suggest more structure to Intent section of 3.3.7 Understanding article #2650 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | I've suggested some editorial changes in the PR which I think improve readability and improve style consistency without altering the meaning. However, I would advocate that we avoid saying "for guidance to be fully inclusive and accessible". The primary reason is that stating such a thing as an absolute, achievable goal poses challenges. There will always be someone whose needs are not fully addressed, IMO. I would prefer to couch things in phrases like "more inclusive and accessible". |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2436 Jake raised that the intent for redundant entry didn't quite match the SC.
PR 3033 makes a small update to the first paragraph.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 10 |
Agree with adjustment | |
Something else |
(21 responses didn't contain an answer to this question)
Responder | DONE: Intent for 3.3.9: Redundant Entry #2436 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with the update | |
Gregg Vanderheiden | Agree with the update | |
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | Agree with the update | |
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2550 Suzanne suggested replacing one of the examples with a better one from an equity point of view.
Detlev added the example, but found that the one to replace had already been updated.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 7 |
Agree with adjustment | |
Something else | 1 |
(23 responses didn't contain an answer to this question)
Responder | DONE: Example Could Be Replaced with an Example that Encourages Greater Equity #2550 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with the update | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Something else | I think the existing text addresses Suzanne's issue > A radial control widget (color wheel) where the value can be set by dragging the marker for the currently selected color to another position, also allows picking another color value by tapping or clicking on another place in the color wheel. |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Focus obscured is missing a technique as it was added after our first round of techniques were created. Francis created one in PR 2746, which can be previewed.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 5 |
Agree with adjustment | 2 |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Focus not obscured margin technique and working example #2746 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | Nice to have a working example! We may be able to come up with a slightly better technique name, but this is definitely sufficient for now. Although it's great to expose the full implementation, it may distract from the context of what the technique is doing? I'm thinking a bit more context might help (or is that in the parent document?) Do we need ALL the code? |
Wilco Fiers | Agree with adjustment | On a narrower viewport the banner is fixed to the top. In that layout the example doesn't actually demonstrate scroll-margin. Feels like the example should work regardless of viewport width. In the code block, why is there no space before the opening curly brace "{"? This looks inconsistent with other code blocks in the techniques. This code block is pretty lengthy. Can we put in a highlight of the key part or something? In the test procedure, I think it would be good to provide a little more clarification on how to determine what is and what isn't a "valid" issue. I.e. It should count if I tab through the page, and reverse-tab through it, but not if I tab and then scroll my focus out of view. I think we have an opportunity here to clarify how to test this. |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
A commenter opened issue 2700 about what the user could to get around the focus being obscured.
Detlev provided an answer, although it isn't clear exactly what the commenter meant, and they have not replied.
I suggest we accept Detlev's response as the official answer.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the response | 6 |
Agree with adjustment | 1 |
Something else | 1 |
(23 responses didn't contain an answer to this question)
Responder | DONE: What are the user's solutions of Focus Not Obscured (minimum)? #2700 | Comments |
---|---|---|
Shawn Thompson | Agree with the response | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the response | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | ||
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | Agree with the response | |
Ian Kersey | ||
Laura Carlson | Agree with the response | |
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Something else | I'm not sure if the question (as I think I understand it) has been fully addressed. To me we should simply say: 1) this SC assess the visibility of the item with focus "When a user interface component receives keyboard focus". It does not apply if the user alters the viewport, etc., after focus has been received 2) regardless of changes a user makes to magnification or the viewport position, when a user presses Tab again to advance the focus, the user agent should bring the item with focus into the viewport. |
Wilco Fiers | Agree with the response | |
Bruce Bailey | Agree with the response | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In the context of Consistent Help, Jon Avila asked in issue 2298 whether we could add more examples to the definition of set of web pages.
PR 3008 adds a couple of examples based on the thread comments.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 4 |
Agree with adjustment | 2 |
Something else | 1 |
(24 responses didn't contain an answer to this question)
Responder | DONE: Clarification sought on "set of web pages" #2298 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | I found the second example to be a bit hard to follow and made some suggestions in the PR. |
Wilco Fiers | Something else | I'm fine with the examples. I do not think we should make this change in the TR document. We have understanding documents to further explain things. Changing the TR doc is a lot more trouble than changing understanding docs is. Think of errata's, translations, copies of WCAG in other standards, etc. This change doesn't need to happen in TR, so let's not. |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Joe Watkins opened issue 2684 asking whether scrolling containers are in scope of Dragging Movements.
PR 3040 was created to say that scrolling based on the user agent (including scrollable containers) is not in scope of dragging.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 5 |
Agree with adjustment | 2 |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Dragging Movements - Carousels - Overflowed Containers #2684 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the update | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | While I agree that user agent scrollbars are not in scope, I wanted to note that a scroll bar does not require dragging to operate in any event. The user can click on a location in the scroll bar area to reposition the viewport there (may need to press and hold in some situations). It may be useful to make note of that -- especially in situations where there are potentially author-generated scrollbars. |
Wilco Fiers | Agree with the update | |
Bruce Bailey | Agree with the update | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Based on some discussion in issue 2706 (since closed), MichaelG created an update to the understanding document in PR 3017.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 5 |
Agree with adjustments | 2 |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Update focus-appearance | Comments |
---|---|---|
Shawn Thompson | Agree with the updates | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the updates | |
Jay Mullen | Agree with adjustments | |
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the updates | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the updates | |
Wilco Fiers | Agree with adjustments | Can we get rid of "whilst" in that sentence? Maybe use "when" or "while". |
Bruce Bailey | Agree with the updates | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2805 JonA asks whether the data "available to select" needs to be in the same step, or page, or something else.
PR 3042 makes a couple of small updates to the understanding document to say that it needs to be on the same page.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the updates | 5 |
Agree with adjustment | 3 |
Something else |
(23 responses didn't contain an answer to this question)
Responder | DONE: Does Redundant Entry require the data available in the current step? #2805 | Comments |
---|---|---|
Shawn Thompson | Agree with the updates | |
Poornima Badhan Subramanian | ||
Todd Libby | Agree with the updates | |
Jay Mullen | Agree with adjustment | |
Gregg Vanderheiden | Agree with the updates | |
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the updates | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | ||
Corey Hinshaw | ||
Detlev Fischer | ||
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | I made a suggestion in the PR. In the same paragraph where I made this suggestion, there is a second sentence about autocomplete which I found difficult to understand, and seems a bit unconnected to this new material. I suggest putting in a different paragraph, and re-writing for clarity. |
Wilco Fiers | Agree with adjustment | The phrase "during a process" reads odd. Maybe just "information is asked for more than once in a process"? "entered in the previously" is definitely wrong. I'm not clear on why we're getting rid of "steps" > location of the data "available to select" is evaluated by the Web page I didn't understand what this pharse means. Can we explain this a little more clearly? |
Bruce Bailey | Agree with the updates | |
Rachael Bradley Montgomery | ||
Jonathan Avila |
Google submitted a document in issue 2704 with quite a few questions and comments.
An initial response was created, but revised as many of the comments hadn't shown up initially. Now there is a full response.
There is also a small PR that adds a visual to the example about overlapping content.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the response and update | 6 |
Agree with adjustment (comment) | 1 |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Google - Success Criterion 2.5.8 Target Size Minimum (AA) #2704 | Comments |
---|---|---|
Shawn Thompson | Agree with the response and update | |
Poornima Badhan Subramanian | Agree with the response and update | |
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the response and update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | Agree with the response and update | |
Ian Kersey | ||
Laura Carlson | Agree with the response and update | |
Corey Hinshaw | ||
Detlev Fischer | Agree with the response and update | |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment (comment) | I have put in a suggested new figcaption |
Wilco Fiers | ||
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2972 Jaws-test pointed out that the offet can be different because of the shape, not just the size of the targets.
The suggestion (in PR 3032) is to add 'or shapes' to the note.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 6 |
Don't agree, just leave it | |
Something else | 1 |
(24 responses didn't contain an answer to this question)
Responder | DONE: Target offset differ not only if the sizes of the targets differ #2972 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | Agree with the update | |
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | Agree with the update | I made a small editorial comment to the PR. |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with the update | I made a minor editorial change to address comments in the PR |
Wilco Fiers | Something else | I think JAWS-test's suggestion is better here. |
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2973 Jaws-test is concerned about odd shapes creating odd results with the updated definition of target-offset.
Alastair proposed a response, basically: This isn't new information, and the current version works better for more common cases.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the response | 2 |
Agree with adjustment | |
Something else | 3 |
(26 responses didn't contain an answer to this question)
Responder | DONE: Definition of target offset returns wrong results #2973 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | Something else | Question: Does the proposed solution of making targets bigger have any minimum specifications (if 24x24 px is an exception to these common cases like stacked links)? |
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the response | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the response | |
Corey Hinshaw | ||
Detlev Fischer | Something else | I don't quite understand what this issue is - the example of overlapping rectangles provided by JAWS-test would already meet the default requirement, without any need for calculating target offset? In any case, I cannot easily relate the proposed answer to the issue raised. |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Something else | This is returning to the questions I was raising last week on the "overlap" language. Both that and the newish need to intersect a second 'edge' of the first target when calculating the offset measure are giving me pause. I'd like to better understand these (and would welcome some background threads to let me investigate more clearly). |
Wilco Fiers | ||
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila |
In issue 2974 Jaws-test is concerned about odd shapes needing complex math to evaluate target offset.
Alastair proposed a response, basically: like the last issue, we are prioritising common cases.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the response | 4 |
Agree with adjustment | |
Something else |
(27 responses didn't contain an answer to this question)
Responder | DONE: Target offset can be determined only with complicated mathematical methods #2974 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the response | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the response | |
Corey Hinshaw | ||
Detlev Fischer | Agree with the response | Just noting that the last bit of the response, "The understanding document is being updated to improve consistency and understandability", seems a bit vague. |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | ||
Wilco Fiers | Agree with the response | |
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila |
Dan raised issue 2803 focused on what "24 by 24px" means.
There were several options discussed in the thread, but the proposal in PR 2978 (lines 67-88) says that: if you can draw a 24 by 24px square at any angle within the target, it would pass the first line of the SC.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 3 |
Agree with adjustment | 1 |
Something else | 1 |
(26 responses didn't contain an answer to this question)
Responder | DONE: 2.5.8 Target Size (Minimum) is ambiguous for non-rectangular targets #2803 | Comments |
---|---|---|
Shawn Thompson | ||
Poornima Badhan Subramanian | ||
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | ||
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | Agree with the update | |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | Agree with adjustment | I made a few suggestions in the PR for improvements |
Wilco Fiers | Something else | Allowing this 24 x 24 square not to align with the page axis makes this so much more difficult than it needs to be. I think that needs to be taken out. If we wanted to account for these sorts of things we should use a circle, as many people have suggested we do. |
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila |
For Accessible Authentication: In issue 2524 someone raised that "Private access tokens" can be used to avoid CAPTCHAs.
Jemma scoured the IETF docs and found a couple of other things as well. A small addition to the understanding doc in PR 2983 outlines that these help, but are not 100%.
Do you:
Choice | All responders |
---|---|
Results | |
Agree with the update | 7 |
Agree with adjustment | |
Something else |
(24 responses didn't contain an answer to this question)
Responder | DONE: Private Access Tokens will impact whether or not Captchas will be needed to be done #2524 | Comments |
---|---|---|
Shawn Thompson | Agree with the update | |
Poornima Badhan Subramanian | Agree with the update | |
Todd Libby | ||
Jay Mullen | ||
Gregg Vanderheiden | ||
Stefan Schnabel | ||
Daniele Marano | Agree with the update | |
Andrew Kirkpatrick | ||
Daniel Bjorge | ||
Melanie Philipp | ||
David MacDonald | Agree with the update | |
Andrew Somers | ||
Kiara Stewart | ||
Alastair Campbell | ||
Lori Oakley | ||
Jennifer Strickland | ||
Gundula Niemann | ||
Oliver Keim | ||
Ian Kersey | ||
Laura Carlson | Agree with the update | |
Corey Hinshaw | ||
Detlev Fischer | Agree with the update | |
Patrick Lauke | ||
Julie Romanowski | ||
Jaunita George | ||
Steve Faulkner | ||
Michael Gower | ||
Wilco Fiers | ||
Bruce Bailey | ||
Rachael Bradley Montgomery | ||
Jonathan Avila | Agree with the update | I agree private tokens are not always a solution as they requiring signing up for accounts and the services can be down. I've personally had trouble getting them to work. |
The following persons have not answered the questionnaire:
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
w3c/wbs-design
or
by mail to sysreq
.