W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT - Closed Functionality bullets: SCs 2.1.2, 2.1.4, 2.4.7, 2.5.2, 3.1.1, 3.1.2, 3.2.3, and 4.1.2

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 2023-11-30 to 2023-12-13.

7 answers have been received.

Jump to results for question:

  1. 2.5.2 Pointer Cancellation
  2. 3.1.1 Language of Page
  3. 3.1.2 Language of Parts
  4. 3.2.3 Consistent Navigation AND 3.2.4 Consistent Identification
  5. 4.1.2 Name, Role, Value
  6. 2.1.2 No Keyboard Trap
  7. 2.1.4 Character Key Shortcuts
  8. 2.4.7 Focus Visible

1. 2.5.2 Pointer Cancellation

The survey results for 2.5.2 Pointer Cancellation in the SC problematic for Closed Functionality section resulted in 2 proposals for this SC:

Option 1: Proposed draft as-is

2.5.2 Pointer Cancellation—There are cases in closed functionality software where there are essential features that would meet the exception to this success criterion. Examples include features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state).


Option 2: Remove bullet

for the reason: It's confusing to repeat the same note as for non-web software in general, but only for some criteria.



Indicate your preference and any potential edit or alternate proposals.

Summary

ChoiceAll responders
Results
Prefer proposal 1, as-is. 6
Prefer proposal 1, with edits.
Prefer proposal 2 - remove bullet.
Something else (provide your alternate proposal) 1

Details

Responder 2.5.2 Pointer CancellationComments
Olivia Hogan-Stark Prefer proposal 1, as-is.
Sam Ogami Prefer proposal 1, as-is.
Bruce Bailey Prefer proposal 1, as-is.
Mike Pluke Prefer proposal 1, as-is.
Mary Jo Mueller Prefer proposal 1, as-is. I don't mind repeating, as it makes it super-clear for closed functionality where this note is more likely to apply.
Mitchell Evan Something else (provide your alternate proposal) I still prefer to remove this bullet. I don't see anything "problematic" with applying the criterion, nor does the bullet offer any "alternate provision" which is the stated purpose of this section.

That said, I'll concede to the majority, in which case I would propose the following phrasing for consistency:

"2.5.2 Pointer Cancellation—As noted in the section [Applying SC 2.5.2 Pointer Cancellation to Non-Web Documents and Software], examples of 'essential' functionality are features for meeting environmental energy usage requirements (like waking a device from sleep, power saver mode, and low power state)."
Phil Day Prefer proposal 1, as-is.

2. 3.1.1 Language of Page

The survey results for 3.1.1 Language of Page in the SC problematic for Closed Functionality section had a comments resulted in 3 proposals for this SC:

Option 1: Updated version, as-is

3.1.1 Language of Page—Requires language information in a programmatically determinable form intended to drive correct pronunciation. Self-voicing is already required for closed functionality software to support, with the correct pronunciation of language(s) supported by the software.


Option 2: With Loïc's suggested edits

3.1.1 Language of Page—Requires language information in a programmatically determinable form intended to drive correct pronunciation. Accessible systems with closed functionality are required to provide speech output and to use the correct pronunciation of language(s) supported by the software.


Option 3: With Mitch's suggested edits

3.1.1 Language of Page—Requires language information in a programmatically determinable form intended to drive correct pronunciation. Where another mechanism achieves correct pronunciation for closed functionality, such as self-voicing, this criterion does not apply.


Indicate your preference and any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Prefer option 1, as-is.
Prefer option 1, with edits.
Prefer option 2, as-is. 1
Prefer option 2, with edits. 1
Prefer option 3, as-is. 3
Prefer option 3, with edits. 2
Something else (provide your alternate proposal)

Details

Responder 3.1.1 Language of PageComments
Olivia Hogan-Stark Prefer option 2, as-is.
Sam Ogami Prefer option 3, as-is. WCAG does not require speech output for closed systems. Adding Options 1 or 2 add additional requirement of being self voiced that are not part of WCAG. Also some closed systems use other auditory or sensory information that is not voice to support accessibility. Examples include beeping or tones, physical controls that also provide information. Add expiation that this SC only applies where language is needed for understanding.
Bruce Bailey Prefer option 3, as-is. +1 to Sam's comments
Mike Pluke Prefer option 2, with edits. +1 to Sam's proposals.
Mary Jo Mueller Prefer option 3, with edits. Should we say "this criterion does not apply" or instead say "this success criterion would be met" or say "the intent of this success criterion would be met". Just wondering if AG WG would balk at us using "does not apply".
Mitchell Evan Prefer option 3, with edits. +1 to Mary Jo's comment, with "the intent of this criterion would be met".
Phil Day Prefer option 3, as-is. But also happy with 2

3. 3.1.2 Language of Parts

The survey results for 3.1.3 Language of Parts in the SC problematic for Closed Functionality section had a comment that this bullet should be removed with a justification. This results in 2 proposals for this SC:

Option 1: Proposed update, as-is

3.1.2 Language of Parts—Requires information in a programmatically determinable form. Support for correct pronunciation of other languages embedded in other content would require alternate means to produce correct pronunciation and can be difficult for closed functionality software to support.


Option 2: With suggested edits

3.1.2 Language of Parts—Requires language information in a programmatically determinable form intended to drive correct pronunciation. Where another mechanism achieves correct pronunciation for closed functionality, such as self-voicing, this criterion does not apply.


Indicate your preference and any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Prefer option 1, as-is.
Prefer option 1, with edits. 1
Prefer option 2, as-is. 3
Prefer option 2, with edits. 3
Something else (provide your alternate proposal)

Details

Responder 3.1.2 Language of PartsComments
Olivia Hogan-Stark Prefer option 2, as-is.
Sam Ogami Prefer option 2, with edits. See comments for 3.1.1 only where language is needed in understanding.
Bruce Bailey Prefer option 1, with edits. For option 1, I suggest dropping the end clause. That is, delete "and can be difficult for closed functionality software to support".

I am also okay with option 2.
Mike Pluke Prefer option 2, as-is. +1 to Mary Jo's wording.
Mary Jo Mueller Prefer option 2, with edits. 3.1.2 Language of Parts—Requires language information in a programmatically determinable form intended to drive correct pronunciation. Where another mechanism achieves correct pronunciation for closed functionality, such as self-voicing, the intent of this success criterion would be met.
Mitchell Evan Prefer option 2, with edits. Like Mary Jo's comment, but ending with "...intent of this criterion would be met".
Phil Day Prefer option 2, as-is.

4. 3.2.3 Consistent Navigation AND 3.2.4 Consistent Identification

The survey results for 3.2.3 Consistent Navigation and survey results for 3.2.4 Consistent Identification in the SC problematic for Closed Functionality section had a comment that this bullet should be removed with a justification. This results in 2 proposals:

Option 1: Original proposal as updated with minor edits (substituted “are” for “is” in proposals)

3.2.3 Consistent Navigation—This Success Criterion is interpreted to only apply to "sets of software programs" which are very rare. See the second note in the section Applying SC 3.2.3 Consistent Navigation to Non-Web Documents and Software.

3.2.4 Consistent Identification—This Success Criterion is interpreted to only apply to "sets of software programs" which are very rare. See the second note in the section Applying SC 3.2.4 Consistent Identification to Non-Web Documents and Software.


Option 2: Remove bullets for both SC

Reasoning provided was, "It's the same as for non-web software in general."


Indicate your preference and any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Prefer option 1, as-is. 4
Prefer option 1, with edits.
Prefer option 2 - remove bullets. 3
Something else (provide your alternate proposal)

Details

Responder 3.2.3 Consistent Navigation AND 3.2.4 Consistent IdentificationComments
Olivia Hogan-Stark Prefer option 2 - remove bullets.
Sam Ogami Prefer option 1, as-is.
Bruce Bailey Prefer option 1, as-is.
Mike Pluke Prefer option 2 - remove bullets.
Mary Jo Mueller Prefer option 1, as-is. I thought we had agreed previously to include bullets on these "sets of" SC in previous TF decisions. See decision made for SC 2.4.1 Bypass Blocks on 21 Sept. and with SC 2.4.5 Multiple Ways on 19 October on the wiki page: https://github.com/w3c/wcag2ict/wiki/WCAG2ICT-Task-Force-Decisions
Mitchell Evan Prefer option 2 - remove bullets. I prefer not to call something "problematic for closed functionality" when it's no different from software in general.

That said, I'll concede to the majority on this one. If we do keep them, I like the current phrasing of option 1 because it clearly says this is the same as for software in general; it doesn't create the impression of adding something new and different.
Phil Day Prefer option 1, as-is.

5. 4.1.2 Name, Role, Value

The survey results for 4.1.2 Name, Role, Value in the SC problematic for Closed Functionality section resulted in 2 proposals:

Option 1: Original proposal

4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Some other mechanism would be needed to contextually reveal needed information to the user.


Option 2: Incorporate suggested edits

4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides this information for built-in assistive technology functions, this criterion does not apply.


Indicate your preference and any potential edits or alternate proposals.

Summary

ChoiceAll responders
Results
Prefer option 1, as-is.
Prefer option 1, with edits.
Prefer option 2, as-is. 5
Prefer option 2, with edits.
Something else (provide your alternate proposal) 2

Details

Responder 4.1.2 Name, Role, ValueComments
Olivia Hogan-Stark Prefer option 2, as-is.
Sam Ogami Prefer option 2, as-is.
Bruce Bailey Prefer option 2, as-is.
Mike Pluke Prefer option 2, as-is.
Mary Jo Mueller Something else (provide your alternate proposal) Would prefer either option 2 or this alternate proposal, as I am loathe to say "does not apply":
4.1.2 Name, Role, Value—Requires information in a programmatically determinable form. Where another mechanism provides equivalent information as built-in assistive technology functionality, this success criterion would automatically be met.
Mitchell Evan Something else (provide your alternate proposal) WIP
Phil Day Prefer option 2, as-is. But also happy with option 1

6. 2.1.2 No Keyboard Trap

Our survey on SC problematic for closed functionality bullets had a question whether any of the SC that have no guidance need notes added to this section. There were some SC listed in the survey results. This and the following two questions are proposals of bullet content for some of those SC. Other proposals are yet to be developed.

Proposed text for 2.1.2 No Keyboard Trap

2.1.2 No Keyboard Trap- Requires a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for focus; for example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, and therefore the keyboard traps cannot exist.


Indicate the readiness to incorporate into the editor's draft.

Summary

ChoiceAll responders
Results
Incorporate proposed text, as-is. 1
Incorporate proposed text, with edits. 3
Something else (provide your alternate proposal). 3

Details

Responder 2.1.2 No Keyboard TrapComments
Olivia Hogan-Stark Incorporate proposed text, with edits. Some edits:

2.1.2 No Keyboard Trap - Requires a mode of operation where users can navigate and control focus using the keyboard. In some closed systems, tactile input like numeric keypads or other functional groups of keys may be available, but there is no mechanism for onscreen focus. For example, keys might be used to select options from a spoken menu rather than moving an onscreen focus element. In such cases, traditional keyboard traps are not applicable due to the absence of a focus.
Sam Ogami Incorporate proposed text, with edits. +1 to Olivia edits
Bruce Bailey Incorporate proposed text, as-is.
Mike Pluke Something else (provide your alternate proposal). +1 to Mary Jo's analysis.
Mary Jo Mueller Something else (provide your alternate proposal). This does not require a mode of operation where focus can be moved and controlled by keyboard. It requires that where focus can be moved and controlled by keyboard, that it not get "stuck". The WCAG requirement specifically states: "If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away."


Therefore, I don't think there is any need for a bullet in the SC problematic for closed functionality. Some closed functionality products do not have a keyboard at all, or keyboard focus. If we want to say something about that, then that's fine, but in cases where there isn't a keyboard or keyboard interface, or the concept of keyboard focus, then this would automatically meet the requirement as it would be N/A.

Mitchell Evan Something else (provide your alternate proposal). For similar reasons to what Mary Jo said, I prefer to omit this bullet from "problematic." That said, the proposed text is interesting and might be useful. If others feel it's important enough information to mention, then I would suggest adding something similar as a new Note under SC 2.1.2 for software in general. Something like this:

This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this criterion is met.

("applies when..." and "...this criterion is met" are the most important edits)
Phil Day Incorporate proposed text, with edits. I agree with Mary Jo that we could just delete, but think that the note clarifying that the SC is met if there is no mechanism of focus is useful. I like Mitch's proposal of adding a new note.

This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore keyboard traps cannot exist and this criterion is met.

7. 2.1.4 Character Key Shortcuts

Proposed text for 2.1.4 Character Key Shortcuts

2.1.4 Character Key Shortcuts- Requires the system to provide character key shortcuts, and thus implies the entry of longer strings or commands through the keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for keyboard shortcuts, as their mode of operation is for a single key to operate a single function; for example, the keys are used to select options from a spoken menu rather than to enter longer strings or commands. In this case, there are no keyboard shortcuts, and thus no need to modify them.


Indicate the readiness to incorporate into the editor's draft.

Summary

ChoiceAll responders
Results
Incorporate proposed text, as-is. 2
Incorporate proposed text, with edits. 2
Something else (provide your alternate proposal). 2

(1 response didn't contain an answer to this question)

Details

Responder 2.1.4 Character Key ShortcutsComments
Olivia Hogan-Stark Incorporate proposed text, with edits. Similar structure to my edits to #6:

2.1.4 Character Key Shortcuts - Requires the system to offer character key shortcuts, implying the entry of longer strings or commands through the keyboard. While certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for keyboard shortcuts. This is because their mode of operation revolves around a single key performing a single function. For example, the keys are used to select options from a spoken menu rather than entering longer strings or commands. In such cases, the absence of keyboard shortcuts eliminates the need for modification.
Sam Ogami Incorporate proposed text, with edits. +1 Olivia edits
Bruce Bailey Incorporate proposed text, as-is.
Mike Pluke Something else (provide your alternate proposal). +1 to Mary Jo's analysis.
Mary Jo Mueller Something else (provide your alternate proposal). The intent of this SC is to prevent single-character key shortcuts from interfering with typed input (key performs some function rather than is input into the entry field) or accidental activation of a single-character keyboard shortcut when it would not be desired.

This SC does not require the system to provide character key shortcuts. Only that when there are keyboard shortcuts that are a single character that it meet the SC by being able to be turned off, reassigned to a multiple key or non-character key, or is not active until focus/interaction is with the specific function/UI element that it would activate. So IMO, this SC would likely be automatically met in most closed functionality situations, as character key shortcuts are not often even used.

So my take is that this SC needs no additional guidance, would apply as written, for closed functionality. If there is no true keyboard interface at all, and no single-character key shortcuts provided then this would be N/A and would automatically meet this SC.
Mitchell Evan
Phil Day Incorporate proposed text, as-is. Hopefully the team can refine my rather clumsy phrasing!

8. 2.4.7 Focus Visible

Proposed text for 2.4.7 Focus Visible

2.4.7 Focus Visible - Requires a mode of operation where focus can be moved and controlled by keyboard. Some closed systems may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for focus; for example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, and therefore there is no need for a visible indicator.


Indicate the readiness to incorporate into the editor's draft.

Summary

ChoiceAll responders
Results
Incorporate proposed text, as-is. 1
Incorporate proposed text, with edits. 4
Something else (provide your alternate proposal). 1

(1 response didn't contain an answer to this question)

Details

Responder 2.4.7 Focus VisibleComments
Olivia Hogan-Stark Similar structure to my edits to #6 + #7:

2.4.7 Focus Visible - Requires a mode of operation enabling focus movement and control by keyboard. While certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for traditional onscreen focus. For example, keys might be used to select options from a spoken menu rather than navigating an onscreen focus element between multiple options. In such cases, the absence of a conventional focus eliminates the need for a visible indicator.
Sam Ogami Incorporate proposed text, with edits. +1 to Olivia edits
Bruce Bailey Incorporate proposed text, as-is.
Mike Pluke Incorporate proposed text, with edits. +1 to Olivia's edits.
Mary Jo Mueller Incorporate proposed text, with edits. Perhaps we should state:
This Success Criterion assumes there is a user interface component that receives keyboard focus. Menu-driven interfaces do not necessarily have visible components that receive focus, as they may have tactilely discernible input keys used to choose from a spoken menu of options. In such cases, there is no concept of focus or need for a visible focus indicator.
Mitchell Evan Something else (provide your alternate proposal). I would add the following Note under non-web software in general for 2.4.7 Focus Visible, not specific to Problematic for Closed Functionality:

"This criterion applies where there are user interface controls that are focusable using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not display user interface controls; for example, the keys are mapped directly to functions without activating on-screen controls. In this case, there is no concept of focus and this criterion is met."

I would then add the following bullet under Problematic for Closed Functionality:

"As noted in the section [Applying SC 2.4.7 Focus Visible to Non-Web Documents and Software], when there are no on-screen controls this criterion is met. In addition, when a product with closed functionality has on-screen controls (for example, buttons on a touchscreen) and does not have a keyboard interface, there is no concept of keyboard focus and this criterion is met; however, as noted for 2.1.1 Keyboard it would need an alternate way to access all functionality."
Phil Day Incorporate proposed text, with edits. +1 to Olivia or Mary Jo's edits.

Olivia:
2.4.7 Focus Visible - Requires a mode of operation enabling focus movement and control by keyboard. While certain closed systems may provide tactile input like numeric keypads or other functional groups of keys, they lack a mechanism for traditional onscreen focus. For example, keys might be used to select options from a spoken menu rather than navigating an onscreen focus element between multiple options. In such cases, the absence of a conventional focus eliminates the need for a visible indicator.

Mary Jo:
This Success Criterion assumes there is a user interface component that receives keyboard focus. Menu-driven interfaces do not necessarily have visible components that receive focus, as they may have tactilely discernible input keys used to choose from a spoken menu of options. In such cases, there is no concept of focus or need for a visible focus indicator.

More details on responses

  • Olivia Hogan-Stark: last responded on 5, December 2023 at 14:57 (UTC)
  • Sam Ogami: last responded on 5, December 2023 at 22:10 (UTC)
  • Bruce Bailey: last responded on 6, December 2023 at 21:12 (UTC)
  • Mike Pluke: last responded on 6, December 2023 at 22:31 (UTC)
  • Mary Jo Mueller: last responded on 7, December 2023 at 01:23 (UTC)
  • Mitchell Evan: last responded on 8, December 2023 at 11:43 (UTC)
  • Phil Day: last responded on 11, December 2023 at 11:34 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Gregg Vanderheiden
  2. Shadi Abou-Zahra
  3. Loïc Martínez Normand
  4. Chris Loiselle
  5. Charles Adams
  6. Daniel Montalvo
  7. Fernanda Bonnin
  8. Shawn Thompson
  9. Laura Miller
  10. Anastasia Lanz
  11. Devanshu Chandra
  12. Bryan Trogdon
  13. Thorsten Katzmann
  14. Tony Holland
  15. 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 w3c/wbs-design or by mail to sysreq.