Success Criterion 1.3.5: Identify Input Purpose (Level AA)

[devchan4188]

From Success Criterion 1.3.5: Identify Input Purpose:

The purpose of each input field collecting information about the user can be programmatically determined when:

• The input field serves a purpose identified in the Input Purposes for user interface components section; and
• The content is implemented using technologies with support for identifying the expected meaning for form input data.

Additional Guidance When Applying Success Criterion 1.3.5 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5 (also provided below).

Note: non-web software and non-web documents that do not provide attributes that support identifying the expected meaning for the form input data, are not in scope for this success criterion.

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.

[devchan4188]

Here are the links which support that non web technologies like iOS and Android have the capability of identifying input purpose:
https://developer.android.com/reference/androidx/autofill/HintConstants
https://developer.apple.com/documentation/uikit/uitextcontenttype

[mraccess77]

FWIW. Previously we had discussed that input type was not the same as input purpose.

[maryjom]

@mraccess77 Could you explain or give us a pointer to that conversation? We are trying to analyze and show the applicability or notes that might accompany this SC in the WCAG2ICT document. Is your point that a native mobile application should not be required to use these attributes as a way to meet this SC? Do you think that this SC should be inapplicable to all native software? Is there something else in the context of non-web software or non-web documentation that is an equivalent capability?

[ferBonnin]

@mraccess77 is it the conversation in #720?

[mraccess77]

@ferBonnin yes, that thread has some of the discussions. The contentType values have some of the needed items but input types in general such as number do not. We had discussed in HTML whether something like input type="email" would be acceptable rather than using autocomplete="email".

The Understanding doc for 1.3.5 states:
For some input fields, the type attribute already offers a way to broadly specify the intention of the input field, for example, input type="tel", input type="email", or input type="password". However, these are only very broad categories, describing the type of input, but not necessarily its purpose, especially as it relates to user-specific input fields. As an example, type="email" indicates that the field is for an e-mail address but does not clarify if the purpose is for entering the user's e-mail address or some other person's e-mail.

So, we should be clear in the ICT note which methods are acceptable and which are not - that is input type for formatting or keypad display as an example is not enough - but content type used for communicating purpose is acceptable.

[bruce-usab]

My own understanding (i.e., paraphrasing) is that SC 1.3.5 is essentially a requirement to provide good support for autocomplete. This follows from the 1.3.5 use of this new-with-2.2.1 section 7.

Is there an analog for autocomplete on native mobile apps?

I am not sure of how well autocomplete would apply to non-web documents. But maybe that is not a problem? SC 1.3.5 is okay (i.e., not applicable) to static documents on web). So no-harm, no-foul? OTOH, if an employee is filling out some off-line PDF, I think autocomplete sometimes works as expeccted.

[bruce-usab]

From survey, and above, mobile apps don't have the support to granularly define input purpose

And from that thread @mraccess77 linked to Optimize your app for autofill -- which seems like a reasonable way to interprets 1.3.5 for native apps. Is there something similar on iOS?

[GreggVan]

perhaps something like this for a note:

NOTE: For non-web software and non-web documents that present forms, the equivalent terms for the purposes that are supported in the technologies used for the forms should be used?

[GreggVan]

NOTE: For non-web software and non-web documents that present forms, the terms for the purposes would be the equivalent terms of the technologies used.

[patrickhlauke]

@bruce-usab

My own understanding (i.e., paraphrasing) is that SC 1.3.5 is essentially a requirement to provide good support for autocomplete

probably splitting hairs, but note that facilitating autocomplete is only one of the outcomes of following 1.3.5, not the core reason for it. the theory at least goes that if controls can more explicitly expose their purpose, there'll be a host of possible enhancements that may be possible (autocomplete being one of them, but also ability to add custom overlays/stylings to particular types of fields to make them more immediately understandable if a user needs it, for instance). but yes, in practical terms, autocomplete is the only one that really has seen any actual real-world effect.

[loicmn]

I think that the second note needs "for" at the beginning:

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.

[maryjom]

From the survey results, I made suggestions that were supported by the group and the editors will take care of these, namely:

• 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.

• Add to the SC section the standard pointer to the closed products section appendix.

• Add to the closed products section an item for this SC that says something like

  Closed product software often has no user agent nor platform support for programmatic input purpose identification.

@Lboniello is tasked with editing the above closed product statement to make it better address her concern from the survey.

[maryjom]

@Lboniello Any progress on the editing of the closed product statement?

[Lboniello]

Suggestion to change "Closed product software often has no user agent nor platform support for programmatic input purpose identification."
to
"Closed product software may not allow for input purpose identification. Input purpose identification should be conveyed via other programmatic means if not supported by the specific closed product software."

[maryjom]

Programmatic identification is typically only for assistive technologies to use. Closed functionality is defined by the 508 standards as:

Characteristics that limit functionality or prevent a user from attaching or installing assistive technology. Examples of ICT with closed functionality are self-service machines, information kiosks, set-top boxes, fax machines, calculators, and computers that are locked down so that users may not adjust settings due to a policy such as Desktop Core Configuration.

This means it wouldn't necessarily need to be conveyed via "programmatic means" per se, but through some other mechanism (voice, visual labeling, etc.). I should have done this before I had made the original suggested text, but now that I look at what is written in the current WCAG2ICT Closed functionality section, there is very basic information on several of the success criteria regarding programmatic information. Maybe it would suffice for now to add this SC to that list with the same notation, such as:

• 1.3.5 Identify Input Purpose—requires information in a programmatically determinable form.

I think it is valuable to go back after adding all of the SC to focus on the closed functionality section and expand on things as a whole there, maybe give examples, etc. It seems that was also what @bruce-usab and @GreggVan were supporting in today's discussion.

@Lboniello Does this seem a reasonable approach for now? Definitely kicking the can down the road a bit. If you're good with it, the editors can handle updating/incorporating 1.3.5 into the draft.

[Lboniello]

Yes, this works for me.

[maryjom]

@ChrisLoiselle This is ready to incorporate into the document. You will need to add the text in the note at the very top of this issue. Also at the bottom of the notes add the standard text that links to the closed functionality section.

Note: See also the discussion on Closed Functionality in the Introduction.

Then in the Success Criteria Problematic for Closed Functionality section, add a bullet to the list of problematic SC that states:

• 1.3.5 Identify Input Purpose—requires information in a programmatically determinable form.

[ChrisLoiselle]

@maryjom happy to do so, I'll set up an meeting with you to discuss where file should be placed within the branch. I've made my first attempt within my own branch.

[ChrisLoiselle]

@maryjom do we keep this open or can we close?

[maryjom]

AG WG has a survey open until 16 March with AG WG survey results discussion on 21 March.