Re: Clarification on COGA technique for Identify Purpose

Hi Josh,

So, yes, the responses are correct to date. *The *intent* of the SC is to
be adding pre-defined metadata values at the element level*, and initially
we had a much more robust list of input types, link types and common URL
types (think Home, Help, Contact Us, etc.), but then we stumbled on the
fact that we lacked (in the bulk of the instances) a pre-made taxonomy
(which sadly was out of scope for AG WG to create) as well as any tooling
that would support the goal (the chicken and egg problem).

We looked at a number of differing mechanisms for attaching the
metadata (RDF/RDFa,
Microdata, others
<https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content>),
and each had their pros and cons, but the lack of a for-purpose taxonomy
made the issue moot. We were pooched at two levels. (More on this in a bit)

HOWEVER, there was one existing taxonomy that, while created for a
different purpose, met our needs to a "T" - the taxonomy that is the token
values (and definitions) that came with the @autocomplete attribute of HTML
5. And thus, 1.3.5 emerged as "Purpose of Inputs" (as opposed to "Purpose
of Controls").

Today then, the only technique that actually *does* something is to use
the @autocomplete attribute on form inputs *SCOPED TO THE USER* (this point
seemingly also a bit of a stumbling block, which I need to address via a
promised technique doc to the WG).

But what it does, while tangentially related to the larger goal, is use
element-level metadata to consistently supply input data to form inputs: in
other words, it doesn't matter what the <label> value is (whether it's
Name, Ainm, or 名 - i.e. English, Irish, or Japanese), because we've applied
a fixed-value token (<label> 名   <input type="text" name="name"
autocomplete="first-name"></label>), it has become 'machine-readable', and
so the browser can do the appropriate matching of locally-stored value to
input. *And that unambiguous machine-readable ability matches our larger
goal.*

Josh, I've built two Proof of Concept browser extensions for Chrome, and
would love to find somebody to take the ball and complete the "running",
but for now, I lack the time and resources. (I will forward them to you
off-list, and if anyone else is interested in the seeing the zip files,
ping me directly), but both of those extensions leverage the fact that once
I've applied a fixed and defined token value to an input, I can now (at
least in theory, if not yet in widespread practice) leverage the
machine-readability to output 'information' about those inputs in
"different modalities".

*Personalization Task Force*
Stood up under the APA, one of the larger goals of the TF was to a) develop
and define the 'for-purpose' taxonomy we required, and b) determine an
'attachment' mechanism.

Work on the taxonomy is ongoing (Here
<https://www.w3.org/TR/personalization-semantics-1.0/>, here
<http://w3c.github.io/personalization-semantics/content/index.html>, here
<http://w3c.github.io/personalization-semantics/help/index.html>, and here
<https://w3c.github.io/personalization-semantics/tools/index.html>), and at
the most recent TPAC, the Personalization TF met with the Web Platform WG
searching for a robust 'attachment' mechanism, for while we could likely
mint up a new ARIA attribute (and/or another, different prefixed
attribute), we're optimistically hoping that a "full-fledged" HTML5
attribute could be minted, that would allow us to attach our taxonomy terms
to various page elements (under consideration? @purpose: i.e. <element
purpose="fixed_token">).

If we are successful there however, we'll still have the chicken and egg
problem. Hopefully however, SC 1.3.5 (and to a lesser extent SC 1.3.6 @
AAA) will start to see more and more element-level metadata emerge (for
conformance reasons), thus, if not fully breaking the chicken-and-egg
cycle, disrupting it (hopefully enough) that new tools will emerge. As E.A.
also notes, there is parallel, complimentary work happening external to W3C
(such as a license free icon set emerging from the United Nations!), and so
hopefully we're starting to salt the water enough that 3rd-party tools will
step in and flesh out the delivery.

*Finally...*
While today, the only 'robust' mechanism for delivering on the requirement
is to use @autocomplete, there is nothing in the spec that outright
'forbids' using another attachment mechanism (for example, we've seen
another PoC solution emerge that uses a non-standardized AUI prefixed
collection of attributes and values that meets the requirement), but those
other mechanisms would also require a full eco-system to actually do
anything useful for users in 2019, including a publicly available taxonomy
that could be machine referenced by user-agents, and tooling around support
for actually accomplishing 'anything' on-screen for impacted users. So, the
field is open for experimentation and future development. For now, at the
W3C however, our next step is to reconvene with WebPlat and continue the
discussion that kicked off at TPAC 2018.

More than you asked for, but hopefully helpful.

JF

On Fri, Jan 18, 2019 at 8:12 AM Joshue O Connor - InterAccess <
josh@interaccess.ie> wrote:

> Joshue O Connor - InterAccess wrote:
>
> little chicken again.
>
> lol
>
> --
> Joshue O Connor
> Director | InterAccess.ie
>


-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com