Re: Personalization Task Force meeting minutes

Hi Sharon, Colleagues,

Thanks for this - I had a last-minute fire-drill and had to miss the call.
My apologies.

I see from the minutes some discussion around using the data-* mechanism in
our work. From the minutes (attributed to Janina):

  ... Two specific things to nail down. Are we ready to ask HTML WG / WCAG,
we've done what you ask. We need to move forward. Can we replace it with a
prefix?
... We can work with them on what the prefix should be. We need to lock
down a prefix.
... Second point, what is the minimum ask we have from the main stream
browsers?
... Suggesting we want to be in the DOM. We need to decide early so we can
understand what we are asking from the browsers.


The reason for using the data-* mechanism is because it is a tool that
HTML5 has given us. (see:
https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes.
Another great explainer can be found here:
http://html5doctor.com/html5-custom-data-attributes/ )

HTML5 <https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/HTML5> is
designed with extensibility in mind for data that should be associated with
a particular element but need not have any defined meaning. data-*
attributes
<https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/data-*>
allow
us to store extra information on standard, semantic HTML elements without
other hacks such as non-standard attributes, extra properties on DOM, or
Node.setUserData()
<https://developer.mozilla.org/en-US/docs/Web/API/Node/setUserData>.
(source:
https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes
)


The data-* attribute mechanism allows for the creation of custom
("proprietary" [sic]) attributes that, 1) the browsers will automatically
pass-through to the DOM, and 2) will not throw errors with the W3C code
validator. The intent of data-* is to get implementation experience, with
(and this is the point) a longer-term goal that *IF* we get sufficient
implementation, we can then "drop" the prefix, so that down the road, we'll
ultimately end up (we hope) an attribute known as "symbol" (versus our
experimental attribute of data-symbol).  I'll also note that this has been
a long-standing implementation mechanism at the W3C, most notably with the
CSS WG, where we've (in the past) seen prefixed CSS attributes (see:
https://en.wikipedia.org/wiki/CSS_hack#Browser_prefixes)
See also: https://en.wikipedia.org/wiki/CSS_hack#Example

This was the recommendation from TAG at the 23018 TPAC in Leon, as it also
helps avoid the "ghetto-izataion" of accessibility mechanisms (a "problem"
with ARIA today - it's directed exclusively towards specific Assistive
Technology tools, and NEVER impacts the UI - per an earlier agreement
between the ARIA WG and the browser vendors).

And so, to answer Janina's questions in reverse order:

   - JS: "Suggesting we want to be in the DOM. We need to decide early so
   we can understand what we are asking from the browsers."
   JF: By using data-*, we *will* be exposed in the DOM *today*, but
   browsers will not (at this time) do anything else with the data or values.
   (I don't think that's a bad thing per-se)

   - JS: "Second point, what is the minimum ask we have from the main
   stream browsers?"
   JF: Nothing at this time. Once we get an established collection of
   attributes, we next need to get some implementation experience. One answer
   from that exercise is to also determine whether this will be a thing
   that browsers will need to do, or whether it will still ultimately rely on
   helper-agents - whether they are browser extensions or stand-alone
   software/hardware packages.

   - JS: "We can work with them on what the prefix should be. We need to
   lock down a prefix."
   JF: Do we? If the ultimate goal is to emerge with prefix-free attributes
   (@purpose, @destination, @action), then experimenting with data-purpose,
   data-destination and data-action (for example) gives us the ability to test
   out implementations with valid code. If ultimately we discover that not all
   of our proposed *data-attributes advance to prefix free attributes, I'll
   suggest that *THEN* will be the time for that discussion. (and, we've sorta
   had that discussion already, looking at attributes such as AUI-*)

   - JS: "Are we ready to ask HTML WG / WCAG, we've done what you ask. We
   need to move forward. Can we replace it with a prefix?"
   JF: As this appears to be somewhat truncated minute entry, I'm not 100%
   clear on the statement/question, however I will argue that it is far from
   ready to be taking to AG WG for inclusion in WCAG 2.2. And replacing it
   with a prefix (???) does nothing but rearrange the deck-chairs: any prefix
   is at some level meaningless (all it does is sort of create a namespacing
   mechanism, without it being a namespace).

We have a great plan, we're making awesome progress, and it's cool that
we've already got implementers willing to work with our experimental
attributes. Everything is poised for more progress, but we've got nothing
on the ground today that works as envisioned (outside of early experimental
stuff, like the Proof of Concept work that Mozilla did behind a browser
flag).

As part of the Chartering of AG WG, it was agreed that as a matter of
practice we will be publishing updates to the collection of Success
Criteria on a two-year cycle. I will suggest that this gives us two years
to get some implementation experience, perhaps to the point where we can
approach WHAT WG and seek to have new attributes added to the "mainstream"
HTML5 specification. It has been my belief that to get wider adoption of
our work, relegating it to a prefixed attribute long-term limits adoption.

Meanwhile, if any of our experimental attributes start to gain traction, we
can always seek to add new "Techniques" to the WCAG corpus, which are both
non-normative and are not linked to the 2-year publishing schedule for WCAG
(or whatever comes next) - Techniques can be added at any time.

<opinion>
I'd very much like that we de-link our work from WCAG work at this time,
and stay focused on solving the problems we set out to solve. Getting a
Success Criteria into WCAG is a long process, and without implementation
experience we're trying to get the cart before the horse. And with the
impending deadline for WCAG 2.2, it's simply too late in the process (IMHO).
</opinion>

JF





On Mon, Feb 3, 2020 at 10:01 AM Sharon D Snider <snidersd@us.ibm.com> wrote:

> Hi all,
>
> Here's a link to today's Personalization Task Force meeting minutes -
> https://www.w3.org/2020/02/03-personalization-minutes.html
>
> Regards,
> Sharon Snider
> IBM Hybrid Cloud ► IBM Accessibility Leadership Team
> (512)965-3957
> www.ibm.com/able and w3.ibm.com/able
> [image: Slack logo]  #accessibility-at-ibm
>
>

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