- From: John Foliot <john.foliot@deque.com>
- Date: Tue, 13 Feb 2018 09:38:24 -0600
- To: Jonathan Avila <jon.avila@levelaccess.com>
- Cc: Joshue O Connor - InterAccess <josh@interaccess.ie>, WCAG <w3c-wai-gl@w3.org>, "lisa.seeman" <lisa.seeman@zoho.com>
- Message-ID: <CAKdCpxzHCyGDE4uxOBvQvVByRnn4jTW_RPSFzTbR+EcYCzNJEA@mail.gmail.com>
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.
2. 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
3. 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">
1. 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.
2. 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.
4. 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>
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 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 – 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
>
> 703.637.8957 <(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]
> *Sent:* Tuesday, February 13, 2018 7:45 AM
> *To:* WCAG <w3c-wai-gl@w3.org>
> *Cc:* John Foliot <john.foliot@deque.com>; lisa.seeman <
> 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 (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 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 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
Advancing the mission of digital accessibility and inclusion
Received on Tuesday, 13 February 2018 15:40:17 UTC