RE: Question on techniques for Identify Common Purpose

Ø  [John wrote] There is a fundamental difference here however: alt text, aria-label, or a random string of text that describes (somehow) what the purpose of a control is all require the use of human cognition: you need to understand what that string of text means, so the final bit of "processing" is actually the end user comprehending what the string text means.  If the aria-label text string (or @title value) for my control = "left-handed skigglewinker", and you don't know what a skigglewinker is, then you are no further ahead.

I understand, however, I was thinking of using the title in the form of an accessible description for situations where autocomplete could not be used.  That is either the name of description would have to be a value from the autocomplete list.

<label for=”skittle”>SkittleWinker</label><textarea id=”skittle” title=”purpose: given name”></textarea>

Regarding other languages translation tools might change the title attribute causing issues.  But my primary concern is how this can be met for other technologies outside HTML.  How might this be met for Java, PDF, Flash, etc. – these are all web technologies covered under WCAG.  We have no scoping in the SC to even scope it to markup languages.

So would a PDF always fail this SC?  For example, I have a PDF with an input field that collects first name – the SC applies – how can I meet the SC?

Jonathan

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Wednesday, February 14, 2018 2:22 PM
To: Jonathan Avila
Cc: Joshue O Connor - InterAccess; WCAG; lisa.seeman
Subject: Re: Question on techniques for Identify Common Purpose

​​
Hi Jon,

>  A title is programmatically determinable  and can contain a common purpose.  Yes, I agree language issues can be problematic – but the same goes for alt text or aria-label.

There is a fundamental difference here however: alt text, aria-label, or a random string of text that describes (somehow) what the purpose of a control is all require the use of human cognition: you need to understand what that string of text means, so the final bit of "processing" is actually the end user comprehending what the string text means.  If the aria-label text string (or @title value) for my control = "left-handed skigglewinker", and you don't know what a skigglewinker is, then you are no further ahead.

The goal here is to allow for personalization/customization of the GUI to address potential gaps in that type of cognitive processing, and to do so means we need to start off with some commonly held 'understandings' or definitions (+ terms or 'handles'), which means by its very nature a constrained list (aka taxonomy) plus a mechanism to indicate that the value string is originating from *that* fixed taxonomy collection. We need a Rosetta Stone.

However, because the @title attribute does not currently offer a way of qualifying the string value, or otherwise associating it to a fixed definition "to allow for personalization/customization of the GUI", I do not believe that a technique that uses @title would satisfy the intent of SC 1.3.4. (NOTE: I didn't always think this way, but after multiple conversations with trusted colleagues, off list or in-person at TPAC, I ended up concluding that @title wasn't appropriate, because of the reasons I just gave.)

Meanwhile, Jason wrote:

>  ...which maps, let’s suppose, accessible name strings used on my Web site to the corresponding tokens from the HTML autofill list. However, we don’t have a technology for doing this..."

​Not completely accurate Jason: we have a mechanism (technology) to attach​ metadata to specific elements (Microdata), and / but more importantly, it's not the "name" that we seek here, but rather the *purpose* - often tightly bound together, but not always the same. (i.e. a name that equals "screwdriver" has a purpose of "...a tool that drives screws", but you can also drive screws with other tools too, like an electric screw-gun, so name and purpose aren't always synonymous.)

What is true however (and this remains the chicken and egg problem) is once we've attached element level metadata to controls (etc.), we lack tooling today that can do anything useful with that metadata, such as the ultimate goal of Personalization. This is why I agree that "... it won’t happen in time for WCAG 2.1.", and sadly stopped fighting to get the Button and Link types we originally started off with in 1.3.4 into WCAG 2.1.

JF




On Tue, Feb 13, 2018 at 8:06 PM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:

  *   The problem is that we want to be annotating *COMMON* controls, and further with the intent of AT (or at least hardware/software) doing something useful with it. Since @title can take *any* string value (title="asdfklhasdf" is valid and conformant), it quickly loses any real value, unless you can also provide a "lookup" that provides a definition for the string: "asdfklhasdf".

John, thank you for taking the time to respond.

I understand this is not our current intent - I’ve read every one of the thousands of messages that have gone through this list.  However, this will be a question that we need to address either in the understanding documents or failure techniques.  A title is programmatically determinable  and can contain a common purpose.  Yes, I agree language issues can be problematic – but the same goes for alt text or aria-label.  Translation tools should be able to translate these and if they don’t we don’t fail something under SC 4.1.2 because Google translate did not translate the aria-label into Spanish.  Also it’s not clear from the conformance documents that if you only provide the site in one language that are required to go beyond that.  For example, we have link purpose, page title purpose, heading and label description.  The purpose of links might be differently communicated in different languages.  That is – purpose of fields changes across cultures like sir name, etc. but so might other concepts such as headings and labels as well.  I don’t think the conformance requirements indicate that all languages must be evaluated for conformance.   In fact the document indicates Accessibility support of Web technologies varies by language (and dialect).

The conformance requirements indicate that I can make a claim based on specific languages “This conformance claim meets the accessibility support requirement based on testing content in language(s) of the content with User Agents A, B, and C, and Assistive Technologies X, Y, and Z. This means that we were able to pass all of the success criteria for level A of WCAG 2.0 using these products.”  So it’s not without reason that I could just make a claim for English.

I seriously think we will need to address situations beyond HTML and input elements with autocomplete.  If we can’t agree on answers to these issues I’m concerned that this SC won’t be testable.

Jonathan

From: John Foliot [mailto:john.foliot@deque.com<mailto:john.foliot@deque.com>]
Sent: Tuesday, February 13, 2018 11:28 AM

To: Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>>
Cc: Joshue O Connor - InterAccess <josh@interaccess.ie<mailto:josh@interaccess.ie>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
Subject: Re: Question on techniques for Identify Common Purpose

Hi Jon.

>  People will ask can we use a title attribute like David brought up months ago?

Actually, at one time I was advocating for that technique as well (I think it was I that originally proposed that in a smaller sub-meeting that David was at,way back at the beginning, when we split the original SC proposal into the AA and AAA versions), but I got walked back from that position during TPAC 2017.

The problem is that we want to be annotating *COMMON* controls, and further with the intent of AT (or at least hardware/software) doing something useful with it. Since @title can take *any* string value (title="asdfklhasdf" is valid and conformant), it quickly loses any real value, unless you can also provide a "lookup" that provides a definition for the string: "asdfklhasdf".

Additionally, even if one were to use a "common" term, it still doesn't address concerns around internationalization; title="コンタクトページ" will make sense to our colleague Makoto, but will it be usable for any known AT today, or any non-Japanese speaker? (And I am now wondering, when tools such as Google Translate are used, do those tools also translate the text values of the @title attribute as well?)  So, at this time, I think the answer to the question is "No, the @title attribute is not a sufficient technique."

>  as long as the technique is accessibility supported you could use something else to programmatically communicate it.

​That is indeed correct: the issue is finding user-agents that provide any kind of support for any of the techniques that support the *intent* of the SC.

It is for that reason that using the Microdata+ Schema.org values ultimately did not advance (even though it was using an existing stable W3C Rec pieced together with the defacto standard taxonomy of Schema.org) - that 'solution' lacked user-agent support​ today. I had hoped to bang together a browser extension as a proof of concept, and Lisa and the COGA TF have also brought forward other similar mechanisms<https://a11y-resources.com/developer/adaptable-ui-personalisation>, but the end-goal is to prove it does something, not that we can mark up the content to simply support the ideal.


>  It says input field – I can take form input with an ARIA datepicker, or an aria role textbox with contenteditable of true.

​Yes, very good point.

*IF* the author uses ARIA to override native semantics, or to provide actual semantics to a non-semantic element (i.e. <div>)​, then I suppose in practice one could then apply the @autocomplete attribute to those elements.

I'd also be interested in seeing if browsers would support that or not, as traditionally browsers tend to do 'nothing' with ARIA per-se, except to pass the information along to the Accessibility Tree and the AAPIs, so there is an uneasy middle-point here that needs to be better teased apart: would <div role="textbox" id="telephone" autocomplete="tel" contenteditable></div> "work"?

FWIW, the W3C Validator isn't happy with that:


Attribute autocomplete not allowed on element div<http://www.w3.org/html/wg/drafts/html/master/single-page.html#the-div-element> at this point.

From line 7, column 1; to line 7, column 70<https://validator.w3.org/nu/#l7c70>

d>↩<body>↩<div role="textbox" id="telephone" autocomplete="tel" contenteditable></div>


(I will take an action item to ping Michael TM Smith about this vis-a-vis the W3C Validator, a
​s I think that this should be conformant. I now want to also ask Web Plat about this further...
).

JF

On Tue, Feb 13, 2018 at 9:50 AM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:

  *   One of my biggest disappointments was that Purpose of Controls (SC 1.3.4) did not advance fully formed - we had to step back from the Microdata + Schema.org notation entirely Josh, so all that remains is the autocomplete attribute of HTML 5, which only gets applied to form inputs.

That may be in practice – but I’d I read  the SC differently.  It covers the purposes but doesn’t say you have to use those – as long as the technique is accessibility supported you could use something else to programmatically communicate it.    People will ask can we use a title attribute like David brought up months ago?  While this is what we tried to prevent the SC is not worded this way and allows for multiple techniques to be used – that is of course a benefit of the way WCAG SC have been written in the past – to provide flexibility to implement things in different ways.


  *   ​The autocomplete attribute takes a number of different possible values, but the attribute is always constrained to a form input.

In my opinion it doesn’t say it’s constrained only to the input element.  It says input field – I can take form input with an ARIA datepicker, or an aria role textbox with contenteditable of true.  The SC is not scoped to HTML or even markup languages.  A textarea is an input field is it not?

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>
703.637.8957<tel:(703)%20637-8957> office

Visit us online:
Website<http://www.levelaccess.com/> | Twitter<https://twitter.com/LevelAccessA11y> | Facebook<https://www.facebook.com/LevelAccessA11y/> | LinkedIn<https://www.linkedin.com/company/level-access> | Blog<http://www.levelaccess.com/blog/>

See you at CSUN in March!<http://info.levelaccess.com/CSUN-2018-Sessions.html>

From: John Foliot [mailto:john.foliot@deque.com<mailto:john.foliot@deque.com>]
Sent: Tuesday, February 13, 2018 10:38 AM
To: Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>>
Cc: Joshue O Connor - InterAccess <josh@interaccess.ie<mailto:josh@interaccess.ie>>; WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>; lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
Subject: Re: Question on techniques for Identify Common Purpose

Hi Josh, Jon,

One of my biggest disappointments was that Purpose of Controls (SC 1.3.4) did not advance fully formed - we had to step back from the Microdata + Schema.org notation entirely Josh, so all that remains is the autocomplete attribute of HTML 5, which only gets applied to form inputs.

Josh, if you are interested in "seeing" all of the named values in code, swing on by to http://john.foliot.ca/demos/autofill.html (I have more comments about that shortly).

Josh posted the following code-snippet, which I think would be useful to de-construct here:

<code>
legend>Ship the blue gift to...</legend>
  <div> <label> Address:     <input name=ba autocomplete="section-blue shipping street-address"> </label> </div>
</code>


  1.  ​The autocomplete attribute takes a number of different possible values, but the attribute is always constrained to a form input. Additionally, the autocomplete values are only appropriate/conformant for​ their respective input types, so for example  <input type="checkbox" name=ba autocomplete="street-address"> would be non-conformant.


  1.  At the highest level, autocomplete can take the boolean values of on or off. When set to on, the intent is that user-agents should 'offer the hint' (and/or) auto-populate the field with a saved value (so theoretically <input type="tel" autocomplete="on"> tells the browser to auto-populate the field with the telephone number stored on the browser - but I have not tested this example yet).

The off value is intended to explicitly tell browsers to NOT auto-populate the field (so, for example, it could be applied to password fields). Browser support for the on/off values is apparently quite good, with some caveats.
Please see:
https://caniuse.com/#search=autocomplete


  1.  ​Josh brought up a fairly complex example however, one which demonstrates two methods of 'scoping' the autocomplete value. (It is helpful to think along the lines similar to the fieldset element...)​. Looking at Josh's example:

             <input type="text" name="ba" autocomplete="section-blue shipping street-address">

     *   The Autofill spec<https://www.w3.org/TR/html52/sec-forms.html#sec-autofill> contains a number of Autofill detail tokens, along with a number of specific named values. The first detail token is actually quite scalable, as it takes a prefix+random string, using this pattern: section-*

The intention here is to scope potentially repeated values to single 'named' instances (sections), so that, for example, a form could have two shipping addresses, but constrained to either the section-blue  collection or the section-red collection. This would be extremely useful in a situation similar to that which James Nurthen has often brought forward - an HR form that collects the same basic data on multiple users (name, address, email, etc.). There, the form inputs could be scoped to individual users (section-user1, section-user2, section-user3, etc.) and this would avoid "bleed-over" from one user to the next.

     *   A different yet similar scoping mechanism is pretty much constrained to addresses, as autocomplete also uses one of either shipping or billing as possible named detail tokens values, again to constrain data fields. Think of them as shorthand values, as "shipping" and "section-shipping" are effectively synonyms, and operate in the same manner (according to the spec - I'm still doing some testing)
3.            Similar to the 'address' detail tokens, you can also scope telephone data using one of the following:
§  "home", meaning the field is for contacting someone at their residence
§  "work", meaning the field is for contacting someone at their workplace
§  "mobile", meaning the field is for contacting someone regardless of location
§  "fax", meaning the field describes a fax machine’s contact details
§  "pager", meaning the field describes a pager’s or beeper’s contact details
Again here, the intent is to avoid "bleed-over", and (potentially) allows for storing and auto-populating multiple phone numbers associated to the user.

     *   Finally, there are the named values found in the HTML 5 spec. There are currently 53 values supported in the spec, although my on-going testing is suggesting that at this time, NATIVE browser support is limited to roughly 1/3 of the entire collection. (I have not completed investigating browser extensions in support of autocomplete values, but early research is not great.)

J
​osh asked: "
To satisfy Identify Common Purpose - will we use currently enumerated attributes in a similar way - or are we defining new ones
​" - Josh, at this time I think we will  stay constrained by the existing values found in HTML 5 (I think defining new values is out of scope for our WG). Sadly, I am concerned at this time that due to lack of robust native support in the browsers, we might have to limit our SC to those values that are currently supported, unless I can find browser extensions that support the full collection of 53 input values.

Josh also asked: "Are we asking devs to mark up contents 'purpose' using the *name* attribute or by adding the necessary attribute directly to autocomplete only or some other way (a la ARIA). Is this correct, sufficient to satisfy Identify Common Purpose - looking at the autocomplete values used here?"
<code>
<label for="frmNameCC">Name on card</label>
<input name="ccname" id="frmNameCC" required placeholder="Full Name" autocomplete="cc-name">

<label for="frmCCNum">Card Number</label>
<input name="cardnumber" id="frmCCNum" required autocomplete="cc-number">

[...]

</code>

​In a word, yes, you add autocomplete="[value]" to the appropriate form inputs. So, both of your examples are 'correct'​, as they both use @autocomplete correctly, as you would in support of this SC.


Josh concludes with: "
Finally, I'm presuming these name attribute values already do something in the browser, are we happy to piggy back and use these existing values to provide what is needed to satisfy Identify Common Purpose?"
​ That is the intent, yes. WE had to step back from the Microdata + Schema.org stuff because we lacked any tooling that did anything useful with that content today (on my To Do list to try and change that...)​, thus we rolled back to the 'specced' autocomplete attribute in HTML 5 to leverage browser support (to meet the exit criteria).

As noted previously however, I have yet to find a browser that supports all 53 values (making me question the HTML 5 exit criteria somewhat...), but my testing is not complete (and I did find a brow
ser extension that 'sort of' supports all of the autocomplete values)
​.​

Meanwhile, Jon notes:

If the div is an input that uses contentEditable or some other type of input control like a birthday chooser, etc. that falls as input and has a mapped purpose in autocomplete values of 5.2 then it would need to define the purpose – but the autocomplete attribute would not be appropriate.

[JF: Hmmm... it *would* be appropriate, just not conformant as currently autocomplete is constrained to form inputs. Perhaps I need to ping WebPlat WG to see about including any element that also uses ContentEditable. Additionally, I'm not sure how to handle date-pickers, although I suspect that those widgets ultimately end up creating the equivalent of <input type="text" name="birthday">, but I'd want to go de-construct a few of them to ensure that is correct.]

I’d imagine you would need to define the purpose programmatically via techniques related to schema.org<http://schema.org/> – otherwise if it is not be input then it would not fall under this SC at level AA.

[JF: Perhaps, although again, this SC had pretty much walked away from the Schema.org methods due to lack of user-agent support. The intent today is really to mandate the use of the autocomplete values when appropriate, even if we cannot come right out and say that in the spec (due to other constraints around how SC are worded and presented)

​Josh concludes:

Right, and this is important (and likely trickier)  - especially for the AAA Identify common purpose SC. I'm interested in what these schema should look like - even if there are not 'there yet' - any URI pointers appreciated. I guess it looks like the autocomplete schema will mostly be fit for purpose for the AA SC but is potentially insufficient for AAA (and note guys I say this without fear or favour).. ​

Josh, I had previously mapped the button and link types to Schema.org, which can be found here:

https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit?pli=1#gid=1097726724

​...although you will note that there are no "inputs" being mapped, but rather 'actions' (Schema.org can define either of Verbs or Nouns). The following code example (deconstructed) applies Schema.org metadata to a link to the "Contact Page", using Microdata annotation<https://www.w3.org/TR/microdata/>:

<a itemscope
   itemtype="http://schema.org/ContactPage"
​
href="http://example.org/contacts/">contact us</a>
​
​... where the Microdata attribute @itemscope constrains the 'definition' to just the parent element (here, the anchor <a> element), and then the Microdata attribute @itemvalue points to a fully resolved URL that *is* the definition - here the taxonomy being the very public Schema.org taxonomy, but Microdata is flexible enough that a different taxonomy *could* be used, as long as it is public and referenceable, so that down the road AT can do something useful with that definition.

However, to your larger point, yes, @autocomplete is the right tool for meeting SC 1.3.4 (although as jon notes we need to look at other non-HTML documents, and if/how we apply this functionality today - or constrain the SC to those technologies that do support some form of autocompletion. SC 1.3.5 (At Risk) will require something like the Microdata+Schema.org technique (or, by using the not-yet CR Personalization Semantics Content Module<https://w3c.github.io/personalization-semantics/content/index.html>


​I hope to complete my testing by end of the week, and will provide a full report at that time.

JF​


On Tue, Feb 13, 2018 at 8:03 AM, Jonathan Avila <jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>> wrote:
Josh, here are my personal thoughts


  1.  For the moment, are we asking devs to reference what is currently on either spec (in terms of autocomplete values) or  experimental from John et al at [5] and W3C/WHAT WG? [6] [7]
WCAG 2.1 seems to say the purposes covered by HTML 5.2 autocomplete attributes.  So if you are using a technology that doesn’t have one of those I assumed you’d have to use a schema.org<http://schema.org> method or something else that covers it and that is accessibility supported.

2) If so how are they to in practice add these values to their widgets?
[jda] Any technique that is accessibility supported and programmatically available.  This is where we need the most help for methods that are outside of HTML autocomplete attribute.

3) Will the autocomplete attribute need to be added to <div> elements? Which at the moment really looks kind of weird and feels wrong IMO.

If the div is an input that uses contentEditable or some other type of input control like a birthday chooser, etc. that falls as input and has a mapped purpose in autocomplete values of 5.2 then it would need to define the purpose – but the autocomplete attribute would not be appropriate.  I’d imagine you would need to define the purpose programmatically via techniques related to schema.org<http://schema.org> – otherwise if it is not be input then it would not fall under this SC at level aA.

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
jon.avila@levelaccess.com<mailto:jon.avila@levelaccess.com>
703.637.8957<tel:(703)%20637-8957> office

Visit us online:
Website<http://www.levelaccess.com/> | Twitter<https://twitter.com/LevelAccessA11y> | Facebook<https://www.facebook.com/LevelAccessA11y/> | LinkedIn<https://www.linkedin.com/company/level-access> | Blog<http://www.levelaccess.com/blog/>

See you at CSUN in March!<http://info.levelaccess.com/CSUN-2018-Sessions.html>

From: Joshue O Connor - InterAccess [mailto:josh@interaccess.ie<mailto:josh@interaccess.ie>]
Sent: Tuesday, February 13, 2018 7:45 AM
To: WCAG <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Cc: John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>>; lisa.seeman <lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>>
Subject: Question on techniques for Identify Common Purpose

Hi all,

Apologies for long question..

Btw, I think I answered (part of) my own question while writing this out, but it may help others. FYI the chairs are helping out with requests for info on this SC, techniques etc. We know that the mechanics of how to satisfy this success criterion are still being worked out and I have a question about the general advice we should be giving.

Firstly, there are examples referenced such as here, [2] and with demo/code. [3] Are they still useful (as cutting edge ARIA approaches) to satisfying Identify common purpose?

Secondly, initially I did also mention in my feedback, schema.org<http://schema.org> (and was thinking about the work that John F has been doing) but after doing so I then went and had a look at schema.org<http://schema.org> and did a search for 'autocomplete notation', 'autocomplete' etc and found nothing [1] then I was really confused!

I thought there was an autocomplete schema or something there that we could reference and tell people that they can add them as name/value pairs or similar. John et al any light you can shine on how this is to be used or referenced would be great! Especially some examples of how people would practically add these attributes (but I guess these may be on the way - your efforts are appreciated).

So then I looked at the W3C HTML5 and WHATWG HTML5 specs. They both have a list of attributes as defined here. [6] [7]

So I've a couple of questions..

1) For the moment, are we asking devs to reference what is currently on either spec (in terms of autocomplete values) or  experimental from John et al at [5] and W3C/WHAT WG? [6] [7]

2) If so how are they to in practice add these values to their widgets?

3) Will the autocomplete attribute need to be added to <div> elements? Which at the moment really looks kind of weird and feels wrong IMO.

<code>
<div id="SomeUsefulWidget" autocomplete="photo">
</div>
</code>

Or

<code>
<div id="SomeUsefulWidget">
<input type="button" autocomplete="photo">
</div>
</code>

Much of autocomplete attributes are related to <input> elements but some have a semantic potential beyond that and while the example above is contrived - a user agent can gain meaning/purpose from a containing element for
something rather than merely the element itself.

Or is this better:

<code>
<div id="SomeUsefulWidget" role="region" aria-label="The purpose of photo">
<input type="button" autocomplete="photo">
// Meaning the purpose of the widget is outlined and the user agent could inform the user this is an 'upload photo button' or similar.
</code>

Also what is confusing me, in the HTML5 spec HTML5 autocomplete attribute seems to be a simple enum that will take several values:

<code>
legend>Ship the blue gift to...</legend>
  <div> <label> Address:     <input name=ba autocomplete="section-blue shipping street-address"> </label> </div>
</code>

To satisfy Identify Common Purpose - will we use currently enumerated attributes in a similar way - or are we defining new ones - a la some soon to be schema.org<http://schema.org> mapping? Should we suggest enumerated values or single values for our purposes?

Also - are we asking devs to mark up contents 'purpose' using the *name* attribute or by adding the necessary attribute directly to autocomplete only or some other way (a la ARIA). Is this correct, sufficient to satisfy Identify Common Purpose - looking at the autocomplete values used here? [6]

<code>
<label for="frmNameCC">Name on card</label>
<input name="ccname" id="frmNameCC" required placeholder="Full Name" *autocomplete="cc-name"*>

<label for="frmCCNum">Card Number</label>
<input name="cardnumber" id="frmCCNum" required *autocomplete="cc-number"*>

[...]

</code>

NOTE: I found these above examples in this post which I though looked interesting from Chrome dev and was wondering if this kind of info may be useful to provide a technique/guidance? It does just mirror the <input> name and <label> so tbh I'm not sure what extra value it brings (beyond triggering the autocomplete in the browser).[4]

Finally, I'm presuming these name attribute values already do something in the browser, are we happy to piggy back and use these existing values to provide what is needed to satisfy Identify Common Purpose?

[1] http://schema.org/docs/search_results.html#q=autocomplete

[2] https://github.com/ayelet-seeman/coga.personalisation/tree/ExampleWebPage/

[3] https://github.com/ayelet-seeman/coga.personalisation/blob/ExampleWebPage/demo1.0.html

[4] https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill

[5] https://www.w3.org/WAI/WCAG21/Understanding/identify-common-purpose

[6] https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill

[7] https://www.w3.org/TR/html53/sec-forms.html#autofilling-form-controls-the-autocomplete-attribute


Thanks
--
Joshue O Connor
Director | InterAccess.ie



--
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



--
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



--
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