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

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_html51_sec-2Dforms.html-23element-2Dattrdef-2Dautocompleteelements-2Dautocomplete&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=00hneEFr8_iQYRUUOIxoTSrjAVBBn-3bKSwelkXPTvY&s=01d3f07_OgTu6zJZfg2y_D1XYPWtoACUbo2jQnr29JI&e=>), 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__caniuse.com_-23search-3Dautocomplete&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=00hneEFr8_iQYRUUOIxoTSrjAVBBn-3bKSwelkXPTvY&s=OUOiKzuo6nb_As44tL0MD22ApcRUcCj8u2KUM7Br7pk&e=>), 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.w3.org_TR_html51_sec-2Dforms.html-23autofill-2Dfield&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=CIHu8rc_0wRTTC_7DvWtiGNKjpA-3oTgbu_6ve6hP0I&m=00hneEFr8_iQYRUUOIxoTSrjAVBBn-3bKSwelkXPTvY&s=Mf26rQdm8Cesk_M0G5hgCPjGHwdzbGZ1SBNtVYfReGY&e=> 
> .
>
> 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

<http://www.oracle.com> 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 
<sip:james.nurthen@oracle.com>
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
<http://www.oracle.com/commitment> Oracle is committed to developing 
practices and products that help protect the environment