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>
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://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
>
> Advancing the mission of digital accessibility and inclusion
>
>
> --
> Regards, James
>
> <http://www.oracle.com> James Nurthen | Principal Engineer, Accessibility
> Phone: +1 650 506 6781 <+1%20650%20506%206781> | Mobile: +1 415 987 1918
> <+1%20415%20987%201918> | Video: james.nurthen@oracle.com
> Oracle Corporate Architecture
> 500 Oracle Parkway | Redwood City, CA 94065
> <https://maps.google.com/?q=500+Oracle+Parkway+%7C+Redwood+City,+CA+94065&entry=gmail&source=g>
> <http://www.oracle.com/commitment> 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

Advancing the mission of digital accessibility and inclusion