w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire WCAG2ICT - SC Problematic for Closed Functionality: Keyboard SCs
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: maryjom@us.ibm.com
This questionnaire was open from 2024-03-04 to 2024-03-07.
7 answers have been received.
Jump to results for question:
- SCs Problematic for Closed: 2.1.2 No Keyboard Trap
- SCs Problematic for Closed: 2.1.4 Character Key Shortcuts
- SCs Problematic for Closed: 2.4.7 Focus Visible
- SCs Problematic for Closed: 2.1.1 Keyboard
1. SCs Problematic for Closed: 2.1.2 No Keyboard Trap
We will review the four SC related to keyboard together to ensure consistency and to see if the proposed updates are ready to incorporate into the editor's draft.
Read the proposed SC Problematic for Closed Functionality content for 2.1.2 No Keyboard Trap, specifically the new note for the "Applying SC 2.1.2..." section and the proposed content for the SC Problematic for Closed Functionality section found near the end of the comment.
Indicate the readiness to incorporate this proposal into the editor's draft.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Incorporate proposed text, as-is. | 7 |
| Incorporate proposed text, with edits. | |
| Something else. |
Details
| Responder | SCs Problematic for Closed: 2.1.2 No Keyboard Trap | Comments |
|---|---|---|
| Chris Loiselle | Incorporate proposed text, as-is. | |
| Sam Ogami | Incorporate proposed text, as-is. | |
| Phil Day | Incorporate proposed text, as-is. | |
| Mitchell Evan | Incorporate proposed text, as-is. | |
| Bruce Bailey | Incorporate proposed text, as-is. | |
| Loïc Martínez Normand | Incorporate proposed text, as-is. | |
| Mike Pluke | Incorporate proposed text, as-is. | "**in** the [non-web document or software]" seems more correct than "**on** the [non-web document or software]". This is a minor point and sets a precedent of editing to existing WCAG text beyond the minimum essential changes, but it does read better to me and certainly does not change the substance of the WCAG meaning in any way. |
2. SCs Problematic for Closed: 2.1.4 Character Key Shortcuts
Read the proposed SC Problematic for Closed Functionality content for 2.1.4 Character Key Shortcuts, specifically the proposed content for the SC Problematic for Closed Functionality section found near the end of the comment. The rest of the content in that comment is provided for context.
Indicate the readiness to incorporate this proposal into the editor's draft.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Incorporate proposed text, as-is. | 3 |
| Incorporate proposed text, with edits. (Provide the specific changes needed.) | 3 |
| Something else. (Provide the alternate proposal either in the survey or the issue) |
(1 response didn't contain an answer to this question)
Details
| Responder | SCs Problematic for Closed: 2.1.4 Character Key Shortcuts | Comments |
|---|---|---|
| Chris Loiselle | Incorporate proposed text, as-is. | |
| Sam Ogami | Incorporate proposed text, as-is. | |
| Phil Day | Incorporate proposed text, as-is. | |
| Mitchell Evan | Incorporate proposed text, with edits. (Provide the specific changes needed.) | In the proposal, "keyboard interface" is a definition link: "input mechanisms that are not a full [keyboard interface], such as numeric keypads or other functional groups of keys..." This implies that a keyboard with fewer keys than a typical desktop keyboard is not a keyboard interface, which I disagree with. Furthermore, SC 2.1.4 does not actually mention or depend on the normative definition of "keyboard interface." So I propose: "input mechanisms with fewer keys than a typical desktop keyboard, such as numeric keypads or other functional groups of keys" |
| Bruce Bailey | ||
| Loïc Martínez Normand | Incorporate proposed text, with edits. (Provide the specific changes needed.) | I agree with Mitch's edits. |
| Mike Pluke | Incorporate proposed text, with edits. (Provide the specific changes needed.) | Mitch's edits simplify the text and removes unnecessary uncertainties over what is and what is not a keyboard interface. |
3. SCs Problematic for Closed: 2.4.7 Focus Visible
Read the proposed SC Problematic for Closed Functionality content for 2.4.7 Focus Visible in the Google doc. The rest of the content in that document is provided for context.
Indicate the readiness to incorporate this proposal into the editor's draft.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Incorporate proposed text, as-is. | 3 |
| Incorporate proposed text, with edits. (Provide the specific changes needed.) | 4 |
| Something else. (Provide the alternate proposal either in the survey or the issue.) |
Details
| Responder | SCs Problematic for Closed: 2.4.7 Focus Visible | Comments |
|---|---|---|
| Chris Loiselle | Incorporate proposed text, as-is. | |
| Sam Ogami | Incorporate proposed text, as-is. | Option 5 |
| Phil Day | Incorporate proposed text, with edits. (Provide the specific changes needed.) | Option 4 is good, but I had a few very minor editorial suggestions: change "UI" to "user interface" change last sentence from "... this Success Criterion would be satisfied because it is not applicable." to "...this Success Criterion would be satisfied." |
| Mitchell Evan | Incorporate proposed text, with edits. (Provide the specific changes needed.) | I'm voting for option 4 with Phil's survey edits. I believe the survey intended Option 4 as the "proposed text" and other options are "something else", but that was not clear in the survey. Please confirm that folks' votes for "proposed text" mean what I think they mean. |
| Bruce Bailey | Incorporate proposed text, as-is. | |
| Loïc Martínez Normand | Incorporate proposed text, with edits. (Provide the specific changes needed.) | I agree with Option 4, with Phil's edits. |
| Mike Pluke | Incorporate proposed text, with edits. (Provide the specific changes needed.) | Option 4 with Phil's edit. |
4. SCs Problematic for Closed: 2.1.1 Keyboard
Read the existing SC Problematic for Closed Functionality content for 2.1.1 Keyboard below:
2.1.1 Keyboard—Requires operation via a keyboard interface which allows alternative input devices. When a product with closed functionality either does not have a standard keyboard or one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings.
Are any changes needed to make this content consistent with the guidance proposed for the other criteria related to keyboard operation? If so, please propose what the changes should be.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Existing text is fine, as-is. | 6 |
| The existing text needs edits. (Provide the specific changes needed.) | |
| The existing text needs more extensive work. (Provide the alternate proposal or concerns in the survey.) | 1 |
Details
| Responder | SCs Problematic for Closed: 2.1.1 Keyboard | Comments |
|---|---|---|
| Chris Loiselle | Existing text is fine, as-is. | |
| Sam Ogami | Existing text is fine, as-is. | |
| Phil Day | Existing text is fine, as-is. | |
| Mitchell Evan | The existing text needs more extensive work. (Provide the alternate proposal or concerns in the survey.) | I believe the following edits would better convey the intended meaning of the proposal: Requires operation via a keyboard interface which allows alternative input devices. When a product with closed functionality [strike: either] does not have a standard keyboard [strike: or] *and* one cannot be connected, it would need an alternate way to access all functionality that does not require accurate pointing, path-based movements, or specific timings. However, I do not agree with the proposal. I understand the intent of 2.1.1 to mean that preventing users from attaching their own keyboard or keyboard-emulating device cannot pass 2.1.1. We should say that, while encouraging closed functionality to achieve as much as it can of the intent. For achieving as much as it can, the phrase "...alternate way..." is good. However, the phrase "does not require accurate pointing, path-based movements, or specific timings" does not approximate the "intent" from 2.1.1 Understanding: "When content can be operated through a keyboard or alternate keyboard, it is operable by people with no vision (who cannot use devices such as mice that require eye-hand coordination) as well as by people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip-and-puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. Individuals with low vision also may have trouble tracking a pointer and find the use of software much easier (or only possible) if they can control it from the keyboard." By the way, 2.1.1 is the only Level A or AA SC that requires operation through a "keyboard interface" in order to pass. All other Level A or AA keyboard-related SCs either make the keyboard interface a precondition (therefore passing if there is no keyboard interface), or do not depend on the normative definition of "keyboard interface". So whatever we decide for 2.1.1 is limited to 2.1.1. |
| Bruce Bailey | Existing text is fine, as-is. | |
| Loïc Martínez Normand | Existing text is fine, as-is. | |
| Mike Pluke | Existing text is fine, as-is. |
More details on responses
- Chris Loiselle: last responded on 5, March 2024 at 16:42 (UTC)
- Sam Ogami: last responded on 5, March 2024 at 19:22 (UTC)
- Phil Day: last responded on 6, March 2024 at 09:51 (UTC)
- Mitchell Evan: last responded on 6, March 2024 at 21:04 (UTC)
- Bruce Bailey: last responded on 6, March 2024 at 22:26 (UTC)
- Loïc Martínez Normand: last responded on 6, March 2024 at 23:31 (UTC)
- Mike Pluke: last responded on 6, March 2024 at 23:33 (UTC)
Non-responders
The following persons have not answered the questionnaire:
- Gregg Vanderheiden
- Shadi Abou-Zahra
- Mary Jo Mueller
- Charles Adams
- Daniel Montalvo
- Fernanda Bonnin
- Shawn Thompson
- Olivia Hogan-Stark
- Laura Miller
- Anastasia Lanz
- Devanshu Chandra
- Bryan Trogdon
- Thorsten Katzmann
- Tony Holland
- Kent Boucher
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project