W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT-Review draft updates to SC Problematic for Closed Functionality section

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-06-28 to 2023-07-26.

8 answers have been received.

Jump to results for question:

  1. Review proposal for the Introductory paragraph
  2. Review bullet: 1.1.1 Non-text Content
  3. Review bullet: 1.2.1 Audio-only and Video-only (Prerecorded)
  4. Review bullet: 1.2.3 Audio Description or Media Alternative (Prerecorded)
  5. Review bullet: 1.3.2 Meaningful Sequence
  6. Review bullet: 1.3.4 Orientation
  7. Review bullet: 1.3.5 Identify Input Purpose
  8. Review bullet: 1.4.2 Audio Control
  9. Review bullet: 1.4.3 Contrast (Minimum)
  10. Review bullet: 1.4.10 Reflow
  11. Review bullet: 1.4.12 Text Spacing
  12. Review bullet: 1.4.13 Content on Hover or Focus
  13. Review bullet: 2.1.1 Keyboard
  14. Review bullet: 2.4.1 Bypass Blocks
  15. Review bullet: 2.4.2 Page Titled
  16. Review bullet: 2.4.5 Multiple Ways
  17. Review bullet: 2.5.2 Pointer Cancellation
  18. Review bullet: 2.5.4 Motion Actuation
  19. Review bullet: 3.1.1 Language of Page
  20. Review bullet: 3.1.2 Language of Parts
  21. Review bullet: 3.2.3 Consistent Navigation
  22. Review bullet: 3.2.4 Consistent Identification
  23. Review bullet: 4.1.1 Parsing
  24. Review bullet: 4.1.2 Name, Role, Value
  25. Review: SCs that have unchanged guidance for closed functionality
  26. Review: SCs that do not need guidance for closed functionality

1. Review proposal for the Introductory paragraph

The introductory paragraph (line 6 in the original markdown file) was changed to incorporate the original section's final two notes (line 36 in the original markdown file). The group felt that having general notes about software with closed functionality at the very bottom made it confusing. The reader might think they were misplaced and belonged with the SC bullets.


The proposed introductory paragraph is:

There are Success Criteria that can be problematic for developers of closed functionality. Some criteria discuss making information available in text (which can be read by assistive technologies), making it “programmatically determinable” (rendered by a user agent and readable by assistive technologies), or doing something else to make content compatible with assistive technologies. Other Success Criteria would apply to systems with closed functionality either if they are partially closed or if they allow for the connection of some types of devices. As an example, Success Criterion 2.1.1 Keyboard would apply to systems which are closed to screen readers, but have a physical keyboard or a connector for standard keyboards. While these criteria, as written, are not suitable for closed functionality, most of them can inform and aid development of built-in features needed to make closed functionality products accessible. For non-web software on closed functionality products, alternate accessibility provisions might be needed to cover the user needs addressed by the following Success Criteria:

Summary

ChoiceAll responders
Results
Accept proposed introductory paragraph, as-is. 2
Accept proposed introductory paragraph, with changes. 6
Prefer the original content.
Something else. Please suggest alternative content.

Details

Responder Review proposal for the Introductory paragraphComments
Chris Loiselle Accept proposed introductory paragraph, with changes. On the phrase , "closed to screen readers" would you rather systems with closed functionality? I understand that you are highlighting 2.1.1 and how that would be applied to a screen reader user.
Phil Day Accept proposed introductory paragraph, as-is.
Thorsten Katzmann Accept proposed introductory paragraph, with changes. I support Loic's proposal "closed to assistive technologies"
Mike Pluke Accept proposed introductory paragraph, with changes. I like the "closed to assistive technologies" version of Loïc's proposed amendment.

I've recently discovered that not everyone understands the term closed functionality so it is probably better to be more explicit.
Loïc Martínez Normand Accept proposed introductory paragraph, with changes. The start of the example for 2.1.1 is confusing as it refers to "closed to screen readers", but it should refer to any type of assistive technology. My proposal:

... Success Criterion 2.1.1 Keyboard would apply to systems which are closed to **assistive technologies**, but have a physical...

Another option could be to refer to having closed functionality:

... Success Criterion 2.1.1 Keyboard would apply to systems which **have closed functionality**, but have a physical...
Mary Jo Mueller Accept proposed introductory paragraph, with changes. Loïc's "closed to assistive technologies" verbiage is fine with me.
Sam Ogami Accept proposed introductory paragraph, as-is.
Mitchell Evan Accept proposed introductory paragraph, with changes. 1. Add a paragraph at the top to explain what 'closed functionality' is:

"Closed functionality" prevents users from attaching, installing, or using their own assistive technology. To support users with disabilities, products with closed functionality can instead provide built-in features that act as assistive technology.

2. Substitution:
s/are not suitable for closed functionality/are not always applicable to closed functionality/

2. Review bullet: 1.1.1 Non-text Content

Review the proposed bullet for 1.1.1 Non-text Content and answer the question. Provide suggestions for improvement, if needed.

Original version: 1.1.1 Non-text Content—requires text or a text alternative;


Updated version: 1.1.1 Non-text Content—Requires text or a text alternative in a programmatically determinable form.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 6
Accept updated version, with changes. 1
Prefer the original version. 1
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.1.1 Non-text ContentComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, as-is.
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Prefer the original version.
Mitchell Evan Accept updated version, with changes. For consistency with other criteria:

Requires text or a text alternative in a programmatically determinable form.

3. Review bullet: 1.2.1 Audio-only and Video-only (Prerecorded)

Review the proposed bullet for 1.2.1 Audio-only and Video-only (Prerecorded) and answer the question. Provide suggestions for improvement, if needed.

Original version: 1.2.1 Pre-recorded video—requires a text alternative for time based media;


Updated version: 1.2.1 Audio-only and Video-only (Prerecorded)—One of the options available to authors for success criterion 1.2.1 is that of providing a media alternative that is text—which necessarily relies on a connected assistive technology to be presented.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 4
Accept updated version, with changes. 4
Prefer the original version.
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.2.1 Audio-only and Video-only (Prerecorded)Comments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, with changes. 'connected assistive technology' could be argued to imply attaching 3rd party AT - which is, by definition, not possible for a closed system.

I wonder if it should be changed to something like assistive features in the closed system, thus in context:
"- which necessarily relies on assistive features in the closed system to be presented"

I'm not fond of the phrasing of the last few words - hopefully somebody else can improve the language!
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, with changes. Perhaps the part that follows "text -" could read "which assistive technology in the closed system can present in different modalities."
Loïc Martínez Normand Accept updated version, with changes. After going through the other replies, I align with Phil's comment. We should not refer to "assistive technology" in closed functionality. My proposal:

"... media alternative that is text -- ***which can then be presented to the users through the accessibility features of the closed system***."
Mary Jo Mueller Accept updated version, as-is. This would make this bullet the same as what was in the 2013 WCAG2ICT for 1.2.3 Audio Description. If we change this text, we must change 1.2.3 text as well.

It could perhaps be written in better language that might also address Phil's concern. Maybe: One of the options available to authors for success criterion 1.2.1 is providing a media alternative that is text which, in the absence of assistive technology, would need to be available in different modalities.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Accept updated version, with changes. s/—which necessarily relies on a connected assistive technology to be presented/ Presentation of text may rely on a connected assistive technology./

4. Review bullet: 1.2.3 Audio Description or Media Alternative (Prerecorded)

Review the proposed bullet for 1.2.3 Audio Description or Media Alternative (Prerecorded) and answer the question. Provide suggestions for improvement, if needed.

Original version: 1.2.3 Audio description or Media Alternative—requires a text alternative for time based media;


Updated version: 1.2.3 Audio Description or Media Alternative (Prerecorded)—One of the options available to authors for success criterion 1.2.3 is that of providing a media alternative that is text—which necessarily relies on a connected assistive technology to be presented.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 3
Accept updated version, with changes. 5
Prefer the original version.
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.2.3 Audio Description or Media Alternative (Prerecorded)Comments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, with changes. As for 1.2.1.

'connected assistive technology' could be argued to imply attaching 3rd party AT - which is, by definition, not possible for a closed system.

I wonder if it should be changed to something like assistive features in the closed system, thus in context:
"- which necessarily relies on assistive features in the closed system to be presented"

I'm not fond of the phrasing of the last few words - hopefully somebody else can improve the language!
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, with changes. Perhaps the last phrase could read "which assistive technology in the closed system can present in different modalities."
Loïc Martínez Normand Accept updated version, with changes. After reading through the other replies, I propose the same change as for 1.2.1:

"... media alternative that is text -- ***which can then be presented to the users through the accessibility features of the closed system***."
Mary Jo Mueller Accept updated version, as-is. I made a mistake on this question. I provided the same options as for 1.2.3, but forgot to reverse the options. The "Updated version" in this question is actually the original text in the 2013 WCAG2ICT. Just trying to get these two SC to align in the guidance provided so that whatever we say, it's repeated for both 1.2.3 and 1.2.1. So when I answer "Updated version" it's the one labeled above as "Updated version". I prefer that language because this is pointing out the issue of why it is problematic for closed functionality.

It could perhaps be written in better language that might also address Phil's concern. Maybe: One of the options available to authors for success criterion 1.2.1 is providing a media alternative that is text which, in the absence of assistive technology, would need to be available in different modalities.
Sam Ogami Accept updated version, with changes.
Mitchell Evan Accept updated version, with changes. s/—which necessarily relies on a connected assistive technology to be presented./ Presentation of text may rely on a connected assistive technology./

5. Review bullet: 1.3.2 Meaningful Sequence

Review the proposed bullet for 1.3.2 Meaningful Sequence and answer the question. Provide suggestions for improvement, if needed.

Original version: 1.3.2 Meaningful Sequence—requires information in a programmatically determinable form;


Updated version: 1.3.2 Meaningful Sequence—Requires information in a programmatically determinable form; a correct reading sequence should be output that helps the user correlate information that is provided auditorially or through some other non-visual means with the corresponding information displayed on the screen.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 3
Accept updated version, with changes. 5
Prefer the original version.
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.3.2 Meaningful SequenceComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, with changes. I like Loïc's proposed amendment.
Loïc Martínez Normand Accept updated version, with changes. Modified after reading other replies.

The updated version can be improved to be more explicit about intervention of the accessible services of the closed system. I also suggest to replace "auditorally" by "auditory form"

1.3.2 Meaningful Sequence—Requires information in a programmatically determinable form; a correct reading sequence should be output that helps the user correlate information that is provided *** by the accessibility features of the closed system in auditory form *** or through some other non-visual means with the corresponding information displayed on the screen.
Mary Jo Mueller Accept updated version, with changes. I like Loïc's edits.
Sam Ogami Accept updated version, with changes.
Mitchell Evan Accept updated version, with changes. s/auditorially/auditorily/

6. Review bullet: 1.3.4 Orientation

Review the proposed bullet for 1.3.4 Orientation and answer the question, a new SC in WCAG 2.1. Provide suggestions for improvement, if needed.

Proposal: 1.3.4 Orientation—Some closed functionality products have fixed-in-place displays or other limitations to modifying the physical display orientation. See the note in the section Guidance When Applying Success Criterion 1.3.4 to Non-Web Documents and Software.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 3
Accept proposed draft, with changes. 5
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.3.4 OrientationComments
Chris Loiselle Accept proposed draft, with changes. Instead of "some closed functionality" , perhaps defining what the "some" is made of within the SC itself? I understand the counter argument as well and adding it to the note in the example call out too.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, with changes. I support Loic's proposal to avoid reading the cross-reference.
Mike Pluke Accept proposed draft, with changes. I like that Loïc's amendment removes the need for the reader to cross-reference to understand the exception.
Loïc Martínez Normand Accept proposed draft, with changes. I suggest to be explicit about "fixed orientation = essential exception" in this text, and not forcing people to read the full note in "guidance when applying 1.3.4". This could be solved by referring to essential exception in the text.

Proposal: 1.3.4 Orientation—Some closed functionality products have fixed-in-place displays or other limitations to modifying the physical display orientation. ***In these cases, the products are covered under the essential exception and are not required to provide support for orientation changes.*** See the note in the section Guidance When Applying Success Criterion 1.3.4 to Non-Web Documents and Software.
Mary Jo Mueller Accept proposed draft, with changes. I like Loïc's edits.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Accept proposed draft, as-is.

7. Review bullet: 1.3.5 Identify Input Purpose

Review the proposed bullet for 1.3.5 Identify Input Purpose and answer the question. Provide suggestions for improvement, if needed.

Original version: 1.3.5 Identify Input Purpose—requires information in a programmatically determinable form;


Updated version: 1.3.5 Identify Input Purpose—Requires information in a programmatically determinable form; text labels need to be specific and be provided to the user in other modalities (e.g. auditory).

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 7
Accept updated version, with changes.
Prefer the original version. 1
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.3.5 Identify Input PurposeComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, as-is.
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Prefer the original version.

8. Review bullet: 1.4.2 Audio Control

Review the proposed bullet for 1.4.2 Audio Control and answer the question. This is new guidance for an existing WCAG 2.0 SC. Provide suggestions for improvement, if needed.

Proposal: 1.4.2 Audio Control—There are existing closed functionality requirements in standards such as the EN 301 549 and U.S. Revised 508 Standards (402.3 Volume) that cover volume control for closed functionality products. Since there is no AT (by definition) in a closed functionality product, there is no potential for conflict between self-voiced content and screen reader audio. To avoid potential conflicts between the volume control requirements, this WCAG requirement should not be applied to closed functionality software..

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 3
Accept updated version, with changes. 1
Prefer the original version.
Something else. Please provide suggested content. 4

Details

Responder Review bullet: 1.4.2 Audio ControlComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Something else. Please provide suggested content. As Loïc has identified, EN 301 549 already has a closed functionality requirement related to avoiding the interference of auto playing audio and audio used as the non-visual access method. So a closed functionality equivalent of 1.4.2 is definitely needed.

Loïc's proposal explains this need very well.
Loïc Martínez Normand Something else. Please provide suggested content. NOTE: I've modified my initial reply after reading Mary Jo's comment.

I don't agree that 1.4.2 should not be applied to closed functionality software.

First, closed functionality software can have audio that "plays automatically for more than 3 seconds" (for instance, a museum terminal that starts playing some audio when reaching a given screen).

Second, closed functionality software that is accessible must provide non-visual means of access, which will normally be speech-based. In that case, the automatic audio can interfere with the non-visual access mode.

That means that programmers of closed functionality software having automatically playing audio need to consider this and avoid interference with the non-visual access mode (that they have also programmed).

In addition, the introductory paragraph says: "While these criteria, as written, are not suitable for closed functionality, most of them can inform and aid development of built-in features needed to make closed functionality products accessible". So my suggestion is to provide some information to aid the development of these built-in features.

But given Mary Jo's reply, I've modified what I propose

My original proposal was:

1.4.2 Audio Control - When a closed functionality product provides a mode of operation for non-visual access (normally through speech), any audio playing automatically can interfere with this mode of operation. Developers of such systems need to consider this and either avoid automatic audio or enable the users to control that audio. In addition, there are existing closed functionality requirements in standards such as the EN 301 549 and U.S. Revised 508 Standards (402.3 Volume) that cover volume control for closed functionality products.

My new proposal tries to explain the same idea from a different viewpoint (and still keeping the text referring to other standards)

1.4.2 Audio Control - The intent of this success criterion is to avoid interference of audio with assistive products, which are not available in a system with closed functionality. But if the built-in accessibility features of the closed system provide speech output, then the interference may happen and this SC applies. In addition, there are existing closed functionality requirements in standards such as the EN 301 549 and U.S. Revised 508 Standards (402.3 Volume) that cover volume control for closed functionality products.
Mary Jo Mueller Something else. Please provide suggested content. Sorry, these answers don't match the question. If it is possible to have auto-playing audio AND self-voicing at the same time, we should NOT add this SC bullet. This section is all about SC that are problematic to apply to Closed Functionality, not for considerations on how to comply. The interesting thing I just discovered when reading the EN 301 549 Closed Functionality requirements is that 5.3.1.10 Non-interfering audio output is a more stringent requirement than this SC, so this SC couldn't even be used to conform at the same time. The text of the EN requirement is: Where auditory output is provided as non-visual access to closed functionality, the ICT shall not automatically play, at the same time, any interfering audible output that lasts longer than three seconds. There's no option in the EN to allow "a mechanism to pause or stop the audio, or a mechanism to control audio volume independently from the overall system volume level" that is allowed by SC 1.4.2. Therefore, this SC should probably not be applied to closed functionality.
Sam Ogami Accept updated version, with changes. Remove second period in the last sentence
Mitchell Evan Something else. Please provide suggested content. We shouldn't say "there is no AT." Products can have built-in AT.

There are several other references to EN 301 549 and Section 508, with no hyperlinks. I suppose we should omit the hyperlink here too.

Proposed:
—There are existing closed functionality requirements in standards such as the EN 301 549 and U.S. Revised 508 Standards (402.3 Volume) that cover volume control and may be better suited for some closed functionality products.

9. Review bullet: 1.4.3 Contrast (Minimum)

Review the proposed bullet for 1.4.3 Contrast (Minimum). This is new guidance for an existing WCAG 2.0 SC to make it consistent with 1.4.11 Non-text Contrast. Answer the question and provide suggestions for improvement, if needed.

Note: any changes proposed to 1.4.3 will also appear on 1.4.11 so this survey has only one question to cover both SC.


Proposal:1.4.3 Contrast (Minimum)—There are cases where applying this Success Criterion to non-web software on closed functionality products is problematic:

  • When the appearance of the content is determined by the hardware and not modifiable by the software author, the non-web software would meet the exception for this Success Criterion.

    NOTE Hardware requirements for contrast are out of scope for WCAG2ICT (and this Success Criterion), but do exist in other standards' requirements for closed functionality products (e.g. EN 301 549 and Revised 508 Standards).

  • When the color contrast ratio cannot be programmatically measured due to system limitations (e.g. lockdown), precise quantifiable testing of color contrast cannot be performed by a third party. In such cases, the software author would need to confirm that the color combinations used meet the contrast requirement.

    NOTE Photographs are not sufficient for testing that content meets this Success Criteria. This is because the quality of the lighting, camera, and physical aspects of the hardware display can dramatically affect the ability to capture the content for testing purposes.

    • Summary

    ChoiceAll responders
    Results
    Accept updated version, as-is. 7
    Accept updated version, with changes. 1
    Prefer the original version.
    Something else. Please provide suggested content.

    Details

    Responder Review bullet: 1.4.3 Contrast (Minimum)Comments
    Chris Loiselle Accept updated version, as-is.
    Phil Day Accept updated version, as-is.
    Thorsten Katzmann Accept updated version, as-is.
    Mike Pluke Accept updated version, as-is.
    Loïc Martínez Normand Accept updated version, as-is.
    Mary Jo Mueller Accept updated version, as-is.
    Sam Ogami Accept updated version, as-is.
    Mitchell Evan Accept updated version, with changes. 1. The nested <ul> needs to be inside a parent <li>.

    2. Omit "When the appearance of the content is determined by the hardware and not modifiable by the software author, the non-web software would meet the exception for this Success Criterion." There is no such exception for 1.4.3.

    3. Don't mention EN 301 549 here. As of version 3.2.1, it does not include a contrast requirement for closed functionality or hardware.

10. Review bullet: 1.4.10 Reflow

Review the proposed bullet for 1.4.10 Reflow, a new SC in WCAG 2.1, and answer the question. Provide suggestions for improvement, if needed.

Proposal: 1.4.10 Reflow—Many closed functionality products do not allow users to modify the viewport or change font sizes, so there would be no need to impose a requirement on all closed functionality that content is able to reflow. Additionally, many closed functionality products do not display large chunks of text and only have UI controls. In such cases, two-directional scrolling to access the text and UI controls may be considered essential.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 7
Accept proposed draft, with changes. 1
Something else. Please provide suggested content.

Details

Responder Review bullet: 1.4.10 ReflowComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, as-is.
Mary Jo Mueller Accept proposed draft, as-is. We actually approved this last week with a minor edit to change "so" to "thus" (13 July). No further discussion needed, I think.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Accept proposed draft, with changes. Proposed:
—Where closed functionality prevents users from modifying the viewport, but provides a different mechanism for resizing text: ensure that resizing does not cause loss of information or functionality and does not require two-dimensional scrolling. Additionally, content which meets the two-dimensional layout exception may be more common in closed functionality products, such as products with only UI controls and no large blocks of text.

11. Review bullet: 1.4.12 Text Spacing

Review the proposed bullet for 1.4.12 Text Spacing, a new SC in WCAG 2.1, and answer the question. Provide suggestions for improvement, if needed.

Proposal: 1.4.12 Text Spacing—Applicability of this Success Criterion to closed functionality software is limited to software implemented using markup languages, which is rare. Closed functionality technologies also rarely support user modification of line line, paragraph, letter or word spacing. Therefore, there is no need to impose this requirement on all closed functionality software.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 6
Accept proposed draft, with changes. 1
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 1.4.12 Text SpacingComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, with changes. I agree with the two first sentences. But not with the third. I a closed system uses markup language and supports user modification of text spacing, then the closed system should apply the SC.

I propose a replacement for the third sentence:
"In such infrequent cases the SC applies as written."
Mary Jo Mueller Accept proposed draft, as-is.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 1.4.12 from the "problematic for closed functionality" section. This criterion applies to closed functionality the same as it does to non-web software in general (rare in both).

12. Review bullet: 1.4.13 Content on Hover or Focus

Review the proposed bullet for 1.4.13 Content on Hover or Focus, a new SC in WCAG 2.1, and answer the question. Provide suggestions for improvement, if needed.

Proposal: 1.4.13 Content on Hover or Focus—It would be rare for closed functionality software to trigger or hide content when pointer hover is applied or removed, if pointer hover is supported at all. In fact, many closed functionality products do not include a pointing device or touchscreen, so hover may not even be possible. Therefore, there is no need to impose this requirement on all closed functionality software.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 6
Accept proposed draft, with changes. 1
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 1.4.13 Content on Hover or FocusComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, with changes. See my reply to 1.4.12. For the same reasons, I propose a change to the last sentence:

"However, if the system with closed functionality supports pointing devices and hover effects, this SC applies as written."
Mary Jo Mueller Accept proposed draft, as-is. I can concede that **IF** there is a possibility of new content appearing on hover or focus this would apply. I just think it is exceedingly rare (if it exists at all) in closed functionality products.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 1.4.13 from the "problematic for closed functionality" section. I expect this criterion actually applies more often in kiosks than it does in mobile apps, and we didn't bother calling it "rare" for non-web software in general. So this criterion applies to closed functionality the same as it does to non-web software in general.

13. Review bullet: 2.1.1 Keyboard

Review the proposed bullet for 2.1.1 Keyboard and answer the question. Provide suggestions for improvement, if needed.

Original version: 2.1.1 Keyboard—requires operation via a keyboard interface which allows alternative input devices;


Updated version: 2.1.1 Keyboard—Requires operation via a keyboard interface which allows alternative input devices. There is no need to impose this requirement on all closed functionality software. Many closed functionality products do not have a keyboard or have a partial keyboard, such as a numeric keypad. Functions are often available using tactilely discernable buttons or fulfill this requirement through alternate means that are covered by specific requirements intended for closed functionality products.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 6
Accept updated version, with changes.
Prefer the original version.
Something else. Please provide suggested content. 2

Details

Responder Review bullet: 2.1.1 KeyboardComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Something else. Please provide suggested content. We have a text in the introductory paragraph that contradicts the updated new version: "As an example, Success Criterion 2.1.1 Keyboard would apply to systems which are closed to screen readers, but have a physical keyboard or a connector for standard keyboards".

So either we change the example in the introduction paragraph, or we change this bullet point. My proposal is to change the beginning of bullet point:

2.1.1 Keyboard - *** Requires operation via a keyboard interface which allows alternative input devices. This applies to systems with closed functionality that have a physical keyboard or a connector for standard keyboards. However, *** many closed functionality products do not have a keyboard or have a partial keyboard, such as a numeric keypad. Functions are often available using tactilely discernable buttons or fulfill this requirement through alternate means that are covered by specific requirements intended for closed functionality products
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Something else. Please provide suggested content. The current phrase "There is no need to impose this requirement on all closed functionality software" is vague. I propose replacing the whole statement as follows:

Where closed functionality prevents users from attaching their own keyboard (including alternative input devices), and the software is not part of a product that provides its own keyboard or navigation keypad, this criterion does not apply. Such products should support users through alternate means, such as tactilely discernable buttons.

14. Review bullet: 2.4.1 Bypass Blocks

Review the proposed bullet for 2.4.1 Bypass Blocks, which adds this WCAG 2.0 criteria to the list to reiterate the "set of Web pages" rarity to make this list more complete. Answer the question and provide suggestions for improvement, if needed.

Proposal: 2.4.1 Bypass Blocks—The WCAG2ICT interpretation of this SC replaces "sets of Web pages" with "set of software programs" which is extremely rare - especially for Closed functionality software. However, being able to bypass blocks of content that are repeated within software is generally considered best practice.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 3
Accept proposed draft, with changes. 3
Something else. Please provide suggested content. 2

Details

Responder Review bullet: 2.4.1 Bypass BlocksComments
Chris Loiselle Accept proposed draft, with changes. especially for Closed functionality should have a lower case "C" as in "closed" vs. "Closed".
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Something else. Please provide suggested content. This wording avoids directly addressing the dilemma that faces those contemplating applying 2.4.1 to software. It only makes sense to apply a modification of 2.4.1 that addresses blocks that are repeated within a single software program. If this is attempted, it raises the alarm bell about why there is no Web equivalent SC that also applies to repeated blocks within a single web page.

The proposed last sentence repeats the sensible advice given in the "Intent" for 2.4.1, but it is not a requirement within WCAG. Should WCAG2ICT imply that it might be sensible to make it a requirement for software? I would personally love to follow such a recommendation, but I am conscious of the possible controversy this might cause. The current wording is sits on the fence.
Loïc Martínez Normand Accept proposed draft, with changes. I agree with Chris' editorial change, and I add a new one ("sets" is a plural word... so they "are" rare.... My proposal combines both changes:

2.4.1 Bypass Blocks—The WCAG2ICT interpretation of this SC replaces "sets of Web pages" with "set of software programs" which *** are *** extremely rare - especially for *** closed *** functionality
Mary Jo Mueller Accept proposed draft, with changes. Agree with editorial changes. I'm don't think it is in scope for this task force to recommend that additional requirements are developed for these "sets of" requirements to be applied to single software applications - maybe that's debatable. Are there instances in native or closed functionality software where there are "repeated blocks of content" that are not easily bypassed by the user? Sometimes the web poses problems due to its different interaction model and lack of standard UI components that either may not exist or have far fewer examples in software.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 2.4.1 from the "problematic for closed functionality" section. It's the same as for non-web software in general.

15. Review bullet: 2.4.2 Page Titled

Review the proposed bullet for 2.4.2 Page Titled and answer the question. Provide suggestions for improvement, if needed.

Original version: 2.4.2 Page Titled—where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title;


Updated version: 2.4.2 Page Titled—Where software is an integral part of hardware that provides a single function, such as a calculator or IP telephone, there is no need for a title. In addition, a software program does not equate to a "page" or "screen" of content that is a step in a process. Closed functionality products often break processes down to a series of screens, each with a single function. Requiring a page title for each would be distracting and take the user more time to take action and complete transactions.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 7
Accept updated version, with changes. 1
Prefer the original version.
Something else. Please provide suggested content.

Details

Responder Review bullet: 2.4.2 Page TitledComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, as-is.
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Accept updated version, with changes. In the first sentence, add kiosks:

Where software is an integral part of hardware that provides only a single application, such as a kiosk, calculator, or IP telephone, there is no need for the single application to have a title.

Omit the other sentences from the "problematic for closed functionality" section. If it's valuable to talk about titles of screens within software, it would apply equally to non-web software in general.

16. Review bullet: 2.4.5 Multiple Ways

Review the proposed bullet for 2.4.5 Multiple Ways, which adds this WCAG 2.0 criteria to the list to reiterate the "set of Web pages" rarity to make this list more complete. Answer the question and provide suggestions for improvement, if needed.

Proposal: 2.4.5 Multiple Ways—The WCAG2ICT interpretation of this SC replaces "sets of Web pages" with "set of software programs" which is extremely rare - especially for closed functionality software. There are a number of notes in the section Guidance When Applying Success Criterion 2.4.5 to Non-Web Documents and Software that are applicable to closed functionality software.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 5
Accept proposed draft, with changes. 2
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 2.4.5 Multiple WaysComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, with changes. Editorial suggestion, as "sets" **are** very rare (not "is"):

2.4.5 Multiple Ways—The WCAG2ICT interpretation of this SC replaces "sets of Web pages" with "set of software programs" which ***are*** extremely rare...
Mary Jo Mueller Accept proposed draft, with changes. Agree with Loïc's edits.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 2.4.5 from the "problematic for closed functionality" section. It's the same as for non-web software in general.

17. Review bullet: 2.5.2 Pointer Cancellation

Review the proposed bullet for 2.5.2 Pointer Cancellation, a new SC in WCAG 2.1, and answer the question. Provide suggestions for improvement, if needed.

Proposal: 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).

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 7
Accept proposed draft, with changes.
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 2.5.2 Pointer CancellationComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, as-is.
Mary Jo Mueller Accept proposed draft, as-is.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 2.5.2 from the "problematic for closed functionality" section. It's confusing to repeat the same note as for non-web software in general, but only for some criteria.

18. Review bullet: 2.5.4 Motion Actuation

Review the proposed bullet for 2.5.4 Motion Actuation, a new SC in WCAG 2.1, and answer the question. Provide suggestions for improvement, if needed.

Proposal: 2.5.4 Motion Actuation—There are cases in closed functionality software where motion actuation could be considered essential. For example, motion used as a security feature, such as resetting a session, would be considered essential for the function; therefore, it would not need to support the ability to be turned off.

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 8
Accept proposed draft, with changes.
Something else. Please provide suggested content.

Details

Responder Review bullet: 2.5.4 Motion ActuationComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, as-is.
Mary Jo Mueller Accept proposed draft, as-is.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Accept proposed draft, as-is.

19. Review bullet: 3.1.1 Language of Page

Review the proposed bullet for 3.1.1 Language of Page and answer the question. Provide suggestions for improvement, if needed.

Original version: 3.1.1 Language of Page—requires information in a programmatically determinable form;


Updated version: 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.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 5
Accept updated version, with changes. 2
Prefer the original version.
Something else. Please provide suggested content.

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

Details

Responder Review bullet: 3.1.1 Language of PageComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, with changes. I think that the second sentence is difficult to read. I suggest to make it clearer:

... Accessible systems with closed functionality are required to provide speech output and to use the correct pronunciation of language(s) supported by the software.
Mary Jo Mueller
Sam Ogami Accept updated version, as-is.
Mitchell Evan Accept updated version, with changes. Self-voicing is one possibility; a built-in consumer screen reader is another (e.g., locked-down Windows or Android). Proposed:

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.

20. Review bullet: 3.1.2 Language of Parts

Review the proposed bullet for 3.1.2 Language of Parts and answer the question. Provide suggestions for improvement, if needed.

Original version: 3.1.2 Language of Parts—requires information in a programmatically determinable form;


Updated version: 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.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 7
Accept updated version, with changes.
Prefer the original version.
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 3.1.2 Language of PartsComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, as-is.
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Something else. Please provide suggested content. Proposed:

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.

21. Review bullet: 3.2.3 Consistent Navigation

Review the proposed bullet for 3.2.3 Consistent Navigation, which adds this WCAG 2.0 criteria to the list to reiterate the "set of Web pages" rarity to make this list more complete. Answer the question and provide suggestions for improvement, if needed.

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

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 5
Accept proposed draft, with changes. 2
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 3.2.3 Consistent NavigationComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, with changes. I suggest an editorial change... we are talking about "sets" so they **are** very rare:

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...
Mary Jo Mueller Accept proposed draft, with changes. Agree with Loïc's small edit.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 3.2.3 from the "problematic for closed functionality" section. It's the same as for non-web software in general.

22. Review bullet: 3.2.4 Consistent Identification

Review the proposed bullet for 3.2.4 Consistent Identification, which adds this WCAG 2.0 criteria to the list to reiterate the "set of Web pages" rarity to make this list more complete. Answer the question and provide suggestions for improvement, if needed.

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

Summary

ChoiceAll responders
Results
Accept proposed draft, as-is. 5
Accept proposed draft, with changes. 2
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 3.2.4 Consistent IdentificationComments
Chris Loiselle Accept proposed draft, as-is.
Phil Day Accept proposed draft, as-is.
Thorsten Katzmann Accept proposed draft, as-is.
Mike Pluke Accept proposed draft, as-is.
Loïc Martínez Normand Accept proposed draft, with changes. I suggest an editorial change... we are talking about "sets" so they **are** very rare:

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 ...
Mary Jo Mueller Accept proposed draft, with changes. Agree with Loïc's small edit.
Sam Ogami Accept proposed draft, as-is.
Mitchell Evan Something else. Please provide suggested content. Omit 3.2.4 from the "problematic for closed functionality" section. It's the same as for non-web software in general.

23. Review bullet: 4.1.1 Parsing

Review the proposed bullet for 4.1.1 Parsing and answer the question. Provide suggestions for improvement, if needed.

Original version: 4.1.1 Parsing—the Intent of 4.1.1 is to provide consistency so that different user agents or assistive technologies will yield the same result;


Updated version: 4.1.1 Parsing—The Intent of 4.1.1 is to provide consistency in markup implementation so that different user agents or assistive technologies will yield the same result.

NOTE Success Criterion 4.1.1 has been made obsolete and removed in WCAG 2.2.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 7
Accept updated version, with changes.
Prefer the original version.
Something else. Please provide suggested content. 1

Details

Responder Review bullet: 4.1.1 ParsingComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, as-is.
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Something else. Please provide suggested content. 4.1.1 for non-web in general should say "NOTE Success Criterion 4.1.1 has been made obsolete and removed in WCAG 2.2."

Then omit 4.1.1 from the "problematic for closed functionality" section.

24. Review bullet: 4.1.2 Name, Role, Value

Review the proposed bullet for 4.1.2 Name, Role, Value and answer the question. Provide suggestions for improvement, if needed.

Original version: 4.1.2 Name, Role, Value—requires information in a programmatically determinable form.


Updated version: 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.

Summary

ChoiceAll responders
Results
Accept updated version, as-is. 7
Accept updated version, with changes. 1
Prefer the original version.
Something else. Please provide suggested content.

Details

Responder Review bullet: 4.1.2 Name, Role, ValueComments
Chris Loiselle Accept updated version, as-is.
Phil Day Accept updated version, as-is.
Thorsten Katzmann Accept updated version, as-is.
Mike Pluke Accept updated version, as-is.
Loïc Martínez Normand Accept updated version, as-is.
Mary Jo Mueller Accept updated version, as-is.
Sam Ogami Accept updated version, as-is.
Mitchell Evan Accept updated version, with changes. —Requires information in a programmatically determinable form. Where another mechanism provides this information for built-in assistive technology functions, this criterion does not apply.

25. Review: SCs that have unchanged guidance for closed functionality

Review the list of SCs and current text that the sub-group deemed sufficient as-is. Answer the question and provide suggestions for improvement, if needed.

  • 1.3.1 Info and Relationships—Requires information in a programmatically determinable form.
  • 1.4.5 Images of Text—Because there is no need to impose a requirement on all closed functionality that text displayed on the screen actually be represented internally as text (as defined by WCAG 2.2), given that there is no interoperability with assistive technology.
  • 2.5.3 Label in Name—Requires information in a programmatically determinable form; specifically, the programmatic name contains the text of the visual label.
  • 3.3.1 Error Identification—While it's important for errors that can be detected to be described to the user, for closed functionality, the error description doesn't have to be provided in text, as defined in WCAG 2.2.
  • 4.1.3 Status Messages—Requires information in a programmatic determinable form. Additionally, software with closed functionality is not typically implemented using markup languages.

    NOTE Non-web software with closed functionality would need equivalent facilitation to provide access to status messages.

Summary

ChoiceAll responders
Results
Agree no changes are needed. 7
Editorial changes are needed (provide them). 1
Some SCs need change. Please provide suggested content.

Details

Responder Review: SCs that have unchanged guidance for closed functionalityComments
Chris Loiselle Agree no changes are needed.
Phil Day Agree no changes are needed.
Thorsten Katzmann Agree no changes are needed.
Mike Pluke Agree no changes are needed.
Loïc Martínez Normand Agree no changes are needed.
Mary Jo Mueller Agree no changes are needed.
Sam Ogami Agree no changes are needed.
Mitchell Evan Editorial changes are needed (provide them). 1.3.1 Info and Relationships: Make it like 4.1.2:
Requires information in a programmatically determinable form. Where another mechanism provides this information for built-in assistive technology functions, this criterion does not apply.

1.4.5 Images of Text: Revise as follows:
Requires text for interoperability with assistive technology and high-quality resizing. Where other mechanisms achieve equivalent results, this criterion does not apply.

2.5.3 Label in Name: no change needed

4.1.3 Status Messages: Keep the first two sentences. Change the "NOTE" to point to non-web software in general.

Not in the questionnaire, but needs changes:
1.4.11 Non-text Contrast
1. The nested <ul> needs to be inside a parent <li>.
2. Don't mention EN 301 549 here. As of version 3.2.1, it does not include a contrast requirement for hardware. (It is true that Section 508 includes a contrast requirement for hardware "icons" even though it does not include this WCAG 2.1 criterion for web and software.)

26. Review: SCs that do not need guidance for closed functionality

Review the list of SCs are not listed as SC that are problematic for closed functionality. Answer the question and provide suggestions for improvement, if needed.

The following Success Criteria need no further closed functionality guidance:


  • 1.2.2 Captions
  • 1.2.4 Captions (Live)
  • 1.2.5 Audio Description
  • 1.3.3 Sensory Characteristics
  • 1.4.1 Use of Color
  • 2.1.2 No Keyboard Trap
  • 2.1.4 Character Key Shortcuts
  • 2.2.1 Timing Adjustable
  • 2.2.2 Pause, Stop, Hide
  • 2.3.1 Three Flashes or Below Threshold
  • 2.4.3 Focus Order
  • 2.4.4 Link Purpose
  • 2.4.6 Headings and Labels
  • 2.4.7 Focus Visible
  • 2.5.1 Pointer Gestures
  • 3.2.1 On Focus
  • 3.2.2 On Input
  • 3.3.2 Labels or Instructions
  • 3.3.3 Error Suggestion
  • 3.3.4 Error Prevention

Do you agree that no notes are needed specific to closed functionality? Indicate any concerns in the text field.

Summary

ChoiceAll responders
Results
Agree no notes are needed. 2
Some of these SCs need notes. Please provide suggested content. 5

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

Details

Responder Review: SCs that do not need guidance for closed functionalityComments
Chris Loiselle Agree no notes are needed.
Phil Day Some of these SCs need notes. Please provide suggested content. 2.4.7 Focus Visible.
Some closed systems use tactilely discernible input such as a numeric keyboard to enter information in conjunction with private audio prompts. In this case, there is no change of 'focus' as there is no navigation around visible elements. The example I am thinking of is an ATM or kiosk where somebody using the private audio hears "For cash withdrawal, press 1; for deposits, press 2..." and then presses numbers in response.
I would argue that this shouldn't meet the focus requirement, but think we might need to add a note to this effect.

Thorsten Katzmann
Mike Pluke Some of these SCs need notes. Please provide suggested content. Phil raises a valid point. This means of locating controls on a numeric keypad may also be applicable to keys that "form part of a functional group or are strategically positioned so that they can be tactiley discerned" to paraphrase a suggested similar proposed change to a closed functionality equivalent requirement in EN 301 549. T

For example, the "Clear" and "Cancel" keys on an ATM are usually positioned to allow easy non-visual location and might be referred to in a spoken presentation of on-screen instructions.
Loïc Martínez Normand Some of these SCs need notes. Please provide suggested content. First, I agree with Phil about 2.4.7. In addition, 2.1.2 and 2.1.4 are also related to keyboard access. I suggest that we need them with notes similar to 2.1.1

Once we agree on the note for 2.1.1, the notes for 2.1.2, 2.1.4 and 2.4.7 could follow a similar approach.
Mary Jo Mueller Some of these SCs need notes. Please provide suggested content. I agree we need to take a closer look at the SCs mentioned by other reviewers.
Sam Ogami Agree no notes are needed.
Mitchell Evan Some of these SCs need notes. Please provide suggested content. Add 2.4.3 Link Purpose (In Context):
—Requires text and context in a programmatically determinable form. Where another mechanism provides link purpose information for built-in assistive technology functions, this criterion does not apply.

More details on responses

  • Chris Loiselle: last responded on 5, July 2023 at 16:27 (UTC)
  • Phil Day: last responded on 19, July 2023 at 09:45 (UTC)
  • Thorsten Katzmann: last responded on 19, July 2023 at 10:36 (UTC)
  • Mike Pluke: last responded on 19, July 2023 at 14:42 (UTC)
  • Loïc Martínez Normand: last responded on 19, July 2023 at 16:23 (UTC)
  • Mary Jo Mueller: last responded on 20, July 2023 at 04:00 (UTC)
  • Sam Ogami: last responded on 25, July 2023 at 18:52 (UTC)
  • Mitchell Evan: last responded on 26, July 2023 at 12:30 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Gregg Vanderheiden
  2. Shadi Abou-Zahra
  3. Bruce Bailey
  4. Charles Adams
  5. Daniel Montalvo
  6. Fernanda Bonnin
  7. Shawn Thompson
  8. Olivia Hogan-Stark
  9. Laura Miller
  10. Anastasia Lanz
  11. Devanshu Chandra
  12. Bryan Trogdon
  13. Tony Holland
  14. 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.