W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT - Review of SC 1.3.5 and 1.4.12 for readiness to incorporate into editors draft

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-01-06 to 2023-01-19.

9 answers have been received.

Jump to results for question:

Review of proposal for Success Criterion 1.3.5 Identify Input Purpose
Review of proposal for Success Criterion 1.4.12 Text Spacing

1. Review of proposal for Success Criterion 1.3.5 Identify Input Purpose

Updates were made to the proposal for 1.3.5 based on our 8 December meeting discussion.

Read the draft of the Additional Guidance When Applying Success Criterion 1.3.5 to Non-Web Documents and Software and indicate if you agree with the updated proposal. Note any suggestions for improvement and/or reasoning in the comments field.

Summary

Choice	All responders
Choice	Results
The proposal can be incorporated into the WCAG2ICT editor's draft as-is.	5
The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	4
The proposal isn't ready to incorporate yet.

Details

Responder	Review of proposal for Success Criterion 1.3.5 Identify Input Purpose	Comments
Sam Ogami	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
Loïc Martínez Normand	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	I think that the second note has a missing "for" at the beginning. Suggested edit: Note: for non-web software and non-web documents that present input fields, the terms for the input purposes would be the equivalent terms provided by the technology used.
Olivia Hogan-Stark	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
Phil Day	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	With changes as proposed in the discussion in issue #66
Laura Miller	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	Can we add a note that makes clear the intention is to identify the input type and that alternative methods for identifying the form input (such as screen reader instructions or tutor messaging) are acceptable? This allows for alternative methods to complete if the medium (Android, iOS, form type etc) does not support this identification, and ultimately focuses on usability.
Mary Jo Mueller	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	I see Devanshu made Loic's suggested change, but also made it on the first note which should not start with "for". Suggest removing that. I'm concerned with this first note anyway, as what does this mean for platform software? For user agents? The WCAG criteria, as written, doesn't require that platform software or user agents provide support for the list of input purposes, just that content implemented in technologies that support programmatic input identification (in the user agent or platform) need to implement use of those attributes. It wasn't clear to me from the meeting minutes whether there needs to be a note referring to the Closed functionality section, as closed products wouldn't typically have support for programmatic identification of the form input meaning. I know this is handled by the exception clause, so maybe nothing is needed. However, it might be good to say, "Closed product software often has no user agent nor platform support for programmatic input purpose identification." It wasn't clear from the minutes whether we had decided to add (or not add) an "Input Purposes for User Interface Components" section from WCAG that reiterates the note in WCAG regarding the names of the various input purposes not being the same that says: "NOTE The list of input type purposes is based on the control purposes defined in the HTML specification's Autofill section, but it is important to understand that a different technology may have some or all of the same concepts defined in its specification and only the concepts that are mapped to the meanings below are required." If this is agreed, the editors can add this section with that note.
Mike Pluke	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
Gregg Vanderheiden	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.	I am having trouble with this one. The purpose of an input field is usually presented in its label As long as the text it is programmatically determinable (already required by 1.1) and the label is programmatically attached to the input field it would meet this SC. This should be true for any technology. As for closed functionality - I think the can be handled the same way as all "programmatically determinable" and closed functionality. I think we should handle them in one place rather than individually. Something like "All provisions that mention programmatically determinable are intended to be made accessible via assistive technology. For closed functionality where AT cannot be used, and equivalent method that is build in needs to be provided for all disabilities that would rely on an assistive technology for access"
Bruce Bailey	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.

2. Review of proposal for Success Criterion 1.4.12 Text Spacing

Updates were made to the proposal for 1.4.12 Text Spacing based on our 17 November meeting discussion.

Read the draft of the Additional Guidance When Applying Success Criterion 1.4.12 to Non-Web Documents and Software and indicate if you agree with the updated proposal. Note any suggestions for improvement and/or reasoning in the comments field.

Summary

Choice	All responders
Choice	Results
The proposal can be incorporated into the WCAG2ICT editor's draft as-is.	4
The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	5
The proposal isn't ready to incorporate yet.

Details

Responder	Review of proposal for Success Criterion 1.4.12 Text Spacing	Comments
Sam Ogami	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
Loïc Martínez Normand	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	As I've explained in a comment in Github, I think that the current note and example do not properly cover all possibilities. A software might be using a markup language that is not exposed to the users to modify, but it could provide an alternative mechanism for the user to modify text style presentation properties (i.e., a settings dialog box). So, I suggest a modification of the note and example (the change to the example is minor, by saying "normally not exposed" instead of "never exposed"): Note: Markup is not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is never available to the user. In such cases, the only way the user could modify the text style properties is through a mechanism provided by the software, such as a settings dialog box. In that case, 1.4.12 would still apply. However, if the markup is not exposed to the user and there is no other mechanism for the user to modify the text style properties, then the SC would not apply. Examples of markup that is used internally for persistence of the software user interface and is normally not exposed to the user to modify include but are not limited to: XAML and XUL.
Olivia Hogan-Stark	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	@loicmn recent comment worth discussing
Phil Day	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	With changes in discussion in issue #62
Laura Miller	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
Mary Jo Mueller	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	We lost "implemented" in the phrasing of the substitution - was that intentional? Was thinking it should say: "For non-web documents or software implemented using markup languages..." I am a little concerned with Loïc's suggestion. I want it to be clear that this SC is not requiring that there is a mechanism provided by software for modifying the text style (if the markup is not exposed to the user), but that IF such a mechanism exists, that this SC would apply. Because sometimes it is provided by the software itself and sometimes via the platform or user agent software. But...that mechanism doesn't exist in all cases.
Mike Pluke	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
Gregg Vanderheiden	The proposal can be incorporated into the WCAG2ICT editor' draft with some changes.	Might we modify it just slightly to cover the concerns This applies as written for Markup Languages that are exposed to user manipulation via AT, or built-in features of the software or platform.
Bruce Bailey	The proposal can be incorporated into the WCAG2ICT editor's draft as-is.