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


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 



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 (
> ​​
> <>), 
> 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 ( 
> <>), 
> 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:
> <> 
> .
> 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.
> <>
> 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: 
Oracle Corporate Architecture
500 Oracle Parkway | Redwood City, CA 94065
<> Oracle is committed to developing 
practices and products that help protect the environment

Received on Friday, 17 November 2017 18:04:18 UTC