Comments (20)
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.
from wcag2ict.
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.
from wcag2ict.
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.
from wcag2ict.
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
from wcag2ict.
FWIW. Previously we had discussed that input type was not the same as input purpose.
from wcag2ict.
@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?
from wcag2ict.
@mraccess77 is it the conversation in #720?
from wcag2ict.
@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.
from wcag2ict.
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.
from wcag2ict.
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?
from wcag2ict.
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?
from wcag2ict.
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.
from wcag2ict.
@Lboniello Any progress on the editing of the closed product statement?
from wcag2ict.
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."
from wcag2ict.
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.
from wcag2ict.
Yes, this works for me.
from wcag2ict.
@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.
from wcag2ict.
@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.
from wcag2ict.
@maryjom do we keep this open or can we close?
from wcag2ict.
AG WG has a survey open until 16 March with AG WG survey results discussion on 21 March.
from wcag2ict.
Related Issues (20)
- SC problematic for Closed functionality: SC 2.1.1 Keyboard HOT 2
- WCAG2ICT Task Force web page issues HOT 3
- Use of requires or required or requiring HOT 4
- Project task: Update contributors and company affiliations HOT 12
- Project task: Remove, update, or add editor's notes HOT 1
- Project task: Task force review of the draft and agreement to publish HOT 1
- Project task: Set up for AG WG review of latest editor's draft and newly added SC HOT 1
- Project task: Set up and track horizontal review of the draft HOT 4
- Project task: Create communication announcing publication and when comments are due HOT 2
- Project Task: Update the Status of this document and abstract HOT 7
- 4.1.1 Parsing is missing the WCAG 2.2 content in the built document HOT 1
- Remove "previous version" respec key HOT 3
- AG WG Review: 4.1.1 Parsing WCAG2ICT guidance HOT 4
- [Editorial] Take a pass for Oxford comma and decide whether or not to use HOT 3
- AG WG Review: 3.3.8 Accessible Authentication (Minimum) WCAG2ICT guidance HOT 4
- AG WG Review: 3.2.6 Consistent Help WCAG2ICT guidance
- AG WG Review: WCAG2ICT Guidance for Products with Closed Functionality HOT 4
- AG WG Review: WCAG2ICT editor's draft HOT 1
- Focus Not Obscured needs a note for non-web software HOT 5
- Feedback from Microsoft on wcag2ict Reflow notes 5 and 7 HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wcag2ict.