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>
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
>
> 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:* John Foliot [mailto:john.foliot@deque.com]
> *Sent:* Tuesday, February 13, 2018 10:38 AM
> *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>
> *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">
>
>
>    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.
>
>
>    1. 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.
>
>    1. 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: "*A**re 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/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1n
> zVbrevq2lBDvos/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
>



-- 
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 16:28:52 UTC