RE: Purpose of Controls - (Part 1): Form inputs

The difficulty with having it only in the Understanding document is that it has no normative effect there. Although it would be possible to use other means of identifying the “conventional names” of the form fields, crucial context (e.g., whether I should enter my name, my friend’s name, the new employee’s name, etc.) is lost, and would have to be discerned from the label or other aspects of the user interface.

I continue to be soemwaht concerned about this entire proposal and about whether it’s likely to produce more benefit than harm. In large measure, this depends on how the information is used to enhance understanding, and on how the cognitive affordances interact with the wider context of the application.

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Friday, November 17, 2017 1:33 PM
To: James Nurthen <james.nurthen@oracle.com>
Cc: WCAG <w3c-wai-gl@w3.org>
Subject: Re: Purpose of Controls - (Part 1): Form inputs

Hi James,

Yes, I recall our chat. I believe scoping those inputs to the individual (as opposed to the use-case you suggested of an HR application that collects multiple names and addresses) will be important. Would you want to see that scoping in the actual SC language, or would having it in the Understanding doc sufficiently meet the need?

JF

On Fri, Nov 17, 2017 at 11:04 AM, James Nurthen <james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>> wrote:

John,

I believe I talked to you at TPAC about the autocomplete attributes being suitable only for information about the user. if this SC were to encourage a developer to add these autocomplete attributes to all fields in an HR application (for example) then I do not believe that accessibility and usability would be enhanced - rather both would be diminished.

Regards,

james

On 11/17/2017 9:45 AM, John Foliot wrote:
Hi all,

Regarding the fixed list of terms that I believe is a critical part of this SC: splitting the list into two columns (form inputs || controls, buttons, link-types), I'd like to focus first on form inputs. If we can come to an agreement on this part of the proposed SC, then we'll have effectively addressed close to half of the terms currently being proposed.


Currently, HTML 5 (specifically HTML 5.1 2nd Edition
​ and beyond
)
​
has the @autocomplete attribute (
​​
https://www.w3.org/TR/html51/sec-forms.html#element-attrdef-autocompleteelements-autocomplete<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.w3.org_TR_html51_sec-2Dforms.html-23element-2Dattrdef-2Dautocompleteelements-2Dautocomplete%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3DCIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I%26m%3D00hneEFr8_iQYRUUOIxoTSrjAVBBn-3bKSwelkXPTvY%26s%3D01d3f07_OgTu6zJZfg2y_D1XYPWtoACUbo2jQnr29JI%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfcedeeee572949776afd08d52dea051d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636465405488743713&sdata=QFkcWbgaLBMEVBPXTL5Vko7XdDJm1MjwnR%2BVxWjtfpU%3D&reserved=0>), that has a fixed token list as part of the specification: the value of the @autocomplete attribute can only be one of those fixed values.

While "name", "family name" and other related personal identifiers do have cultural issues related to them, they are but a few of the 51 token values that are there: terms such as street-address, address-line1, address-line2, address-line3, city, area, postal-code, country, email, cc-name, cc-number, cc-exp-month (which are all also part of that list), have already been internationalized and are being used by developers in numerous languages and locales today (e.g. a token term of cc-number is the fixed value string that represents the idea (PURPOSE) related to the form < label > of クレジットカード番号 in Japanese, Kreditkartennummer in German, หมายเลขบัตรเครดิต in Thai, etc., and developers in those locales appear clear today on how to use the autocomplete tokens). Additionally, virtually every major browser supports that fixed list of tokens (https://caniuse.com/#search=autocomplete<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__caniuse.com_-23search-3Dautocomplete%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3DCIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I%26m%3D00hneEFr8_iQYRUUOIxoTSrjAVBBn-3bKSwelkXPTvY%26s%3DOUOiKzuo6nb_As44tL0MD22ApcRUcCj8u2KUM7Br7pk%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfcedeeee572949776afd08d52dea051d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636465405488743713&sdata=77xrXaPRhAPvYz9IoClHu02Qn7nXltvrRaCfX6HZZCQ%3D&reserved=0>), and web developers around the globe are already using that token list when building their forms.

Creating a requirement that essentially says that if and when you have a form input that maps to one of those "common input terms", then the SC mandates the use of @autocomplete with the token value seems on the surface to be a fairly light lift and demand for accessibility needs. In conversations with multiple developers of all stripes, the overall feedback *I've* received is that this is a bit of a no-brainer (fully recognizing my enthusiasm and passion for this is likely clouding my input receptors :-) ) Still, it really isn't asking for that much...

The full list of token values, along with prose definitions and examples can already be found in the HTML 5 specification at:
https://www.w3.org/TR/html51/sec-forms.html#autofill-field<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.w3.org_TR_html51_sec-2Dforms.html-23autofill-2Dfield%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3DCIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I%26m%3D00hneEFr8_iQYRUUOIxoTSrjAVBBn-3bKSwelkXPTvY%26s%3DMf26rQdm8Cesk_M0G5hgCPjGHwdzbGZ1SBNtVYfReGY%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfcedeeee572949776afd08d52dea051d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636465405488743713&sdata=aNaxLy0iOuyq4cGo6RKgKrgVQwasiMIPeZgZjCOz%2BaM%3D&reserved=0> .

Finally, to address any uncertainty or i18n concerns, we could also re-reference the current NOTE from the HTML 5 spec in our Understanding document as well:

Generally, authors are encouraged to use the broader fields rather than the narrower fields, as the narrower fields tend to expose Western biases. For example, while it is common in some Western cultures to have a given name and a family name, in that order (and thus often referred to as a first name and a surname), many cultures put the family name first and the given name second, and many others simply have one name (a mononym). Having a single field is therefore more flexible.


​So... can we arrive at any consensus​ around the fixed token list in HTML 5? The current list of 61 proposed buttons, controls and link types still needs to be looked at, but if we can clear form inputs now, we'll have made good progress.

Thoughts?

JF
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

--
Regards, James

James Nurthen | Principal Engineer, Accessibility
Phone: +1 650 506 6781<tel:+1%20650%20506%206781> | Mobile: +1 415 987 1918<tel:+1%20415%20987%201918> | Video: james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaps.google.com%2F%3Fq%3D500%2BOracle%2BParkway%2B%257C%2BRedwood%2BCity%2C%2BCA%2B94065%26entry%3Dgmail%26source%3Dg&data=02%7C01%7Cjjwhite%40ets.org%7Cfcedeeee572949776afd08d52dea051d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636465405488743713&sdata=tMJ8e2lpsL%2BCLKK3zVOcHNYaz2J9wVV0H%2FzYg%2Fbb9%2BE%3D&reserved=0>
Oracle is committed to developing practices and products that help protect the environment



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com<mailto:john.foliot@deque.com>

Advancing the mission of digital accessibility and inclusion

________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________