W3C

Site Navigation

Nearby

Results of Questionnaire Initial look - Draft for 1.3.5 Identify Input Purpose

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 2022-11-29 to 2022-12-08.

10 answers have been received.

Jump to results for question:

Initial look at Success Criterion 1.3.5 Identify Input Purpose
Thoughts on notes for SC 1.3.5 Identify Input purpose

1. Initial look at Success Criterion 1.3.5 Identify Input Purpose

This is an initial look at the proposed content for SC 1.3.5 Identify Input Purpose.

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 direction of what has been proposed so far. Note any suggestions for improvement in the comments field.

Summary

Choice	All responders
Choice	Results
Agree with the direction of this proposal.	1
Needs more work on the interpretation for non-web documents and software.	8
I don't know or have no opinion.	1

Details

Responder	Initial look at Success Criterion 1.3.5 Identify Input Purpose	Comments
Gregg Vanderheiden	Agree with the direction of this proposal.
Bryan Trogdon	I don't know or have no opinion.
Mary Jo Mueller	Needs more work on the interpretation for non-web documents and software.	I think we may need to add a section regarding WCAG2ICT's comments on the "Input Purposes for User Interface Components" section. It should highlight the note in that section regarding the names of the purposes, and that not all of the purposes may be available for use in all non-web situations (software and/or documentation). I also agree that this will need something for closed functionality as this is a problematic SC in that case.
Fernanda Bonnin	Needs more work on the interpretation for non-web documents and software.	as discussed in #720: https://github.com/w3c/wcag/issues/720 mobile apps don't have the support to granularly define input purpose
Phil Day	Needs more work on the interpretation for non-web documents and software.	Agree with Loïc - extra guidance is needed for closed systems that may not expose this information at all.
Loïc Martínez Normand	Needs more work on the interpretation for non-web documents and software.	I'm not sure, but I think that we might to think about having a more generic (non-web) version of "Input Purposes for User Interface Components". As it is currently written in WCAG it might be too web-centric. For example, the names of the purposes are different than the names used in the iOS and Android APIs that Devanshu has provided. Alternativelly, a new note could be added to point out that the way of identifying input purposes is platform/technology dependent: For instance (replicating the note in section 7 of WCAG): NOTE NN: The Input Purposes for User Interface Components section in WCAG 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. Developers of non-web documents and non-web software are expected to use the tecnology-specific machanism of identifying input purposes. ----- And then we need to think about closed functionality. We need to add 1.3.5 to Appendix A (Success Criteria Problematic for Closed Functionality) and have the "standard note" -> "Note NN: See also the discussion on Closed Functionality in the Introduction."
Thorsten Katzmann	Needs more work on the interpretation for non-web documents and software.	I agree with Loïc regarding the closed functionality and I would prefer to add some additonal text.
Bruce Bailey	Needs more work on the interpretation for non-web documents and software.	I ask that we have a brief discussion about support for autocomplete with NATIVE mobile apps.
Mike Pluke	Needs more work on the interpretation for non-web documents and software.	I agree with Mary Jo and Loïc that there are issues regarding the existing list of "Input Purposes for User Interface Components" and that this is one that does not map well to closed functionality. I think that we could probably handle the "Input Purposes for User Interface Components" issue by adding some wording that indicates that the equivalent list of input purposes defined in the software API's should be followed.
Laura Miller	Needs more work on the interpretation for non-web documents and software.	Agree with others that have made points about mobile limitations.

2. Thoughts on notes for SC 1.3.5 Identify Input purpose

Think about this SC being applied to various non-web documents and software. Are there any additional notes regarding this SC when applied to non-web documents or software that should be added? If so, provide suggested text or thoughts on situations to consider. Do you agree with the notes that have been proposed? We will have a discussion on this during our 1 December meeting.

Summary

Choice	All responders
Choice	Results
I don't think this SC needs any notes for non-web technologies.
I have additional concerns with the SC being applied to non-web documents and software that the proposed notes don't cover.	2
I have some comments on the proposed notes.	7
I don't know if this needs notes or have no opinion.	1

Details

Responder	Thoughts on notes for SC 1.3.5 Identify Input purpose	Comments
Gregg Vanderheiden	I have some comments on the proposed notes.	there is something wrong with this sentence Note: User agents that do not provide attributes that support for identifying the expected meaning for the form input data, are not in scope for this success criterion.
Bryan Trogdon	I don't know if this needs notes or have no opinion.
Mary Jo Mueller	I have some comments on the proposed notes.	The existing note needs edits, using the flip of the last bullet of the SC text. Suggest that it read: "Note: For non-web documentation and software content implemented in technologies that do not have support for identifying the expected meaning for form input data, this Success Criterion would not apply." Agree that we should add something, as Loic suggested, in the closed functionality section. We'd have to work on what should be said there.
Fernanda Bonnin	I have some comments on the proposed notes.	the proposed note has the right direction. Minor editorial suggestion remove "for" in between support and identifying
Phil Day	I have some comments on the proposed notes.	Agree that user agents in this context is not clear
Loïc Martínez Normand	I have some comments on the proposed notes.	The current note point starts with "user agents" and does not apply as written to non-web documents and software. "User agent" is a valid concept in the case of non-web documents, but it is not in the case of non-web software. I suggest to modify the note to make this clear. Maybe we will need two notes: one for non-web documents (that could be very similar to the current note) and one for non-web software, written to refer to "platform software" instead of "user agent". Below are two proposed notes: Note 1: Non-web documents that are implemented with technologies that do not support the identification of input purposes are not in scope for this success criterion. Note 2: Non-web software that runs in platform software that does not support the identification of input purposes is not in scope for this success criterion.
Thorsten Katzmann	I have some comments on the proposed notes.	I support Loïc's proposal.
Bruce Bailey	I have additional concerns with the SC being applied to non-web documents and software that the proposed notes don't cover.	Non-web documents is okay as-is. Non-web software note should affirm/deny analog to autocomplete on web.
Mike Pluke	I have additional concerns with the SC being applied to non-web documents and software that the proposed notes don't cover.	The user agent reference in the note does not directly apply to non-web software, this will need a different software-specific interpretation.
Laura Miller	I have some comments on the proposed notes.	Agree with Mary Jo's comments on the proposed notes.