Re: Personalization Task Force meeting minutes

Hi Janina,

> as to point #2 there was suggestion that the implications of a permanent
prefix actually would satisfy the minimum ask from browsers, because values
provided by our prefixed attributes would make it into the DOM by
definition.

That is not my recollection of the discussion at TPAC 2018 - did this
change since then? Do we have any documented or anecdotal evidence that
this is indeed what the browsers are seeking from us at this time?

By definition, data-* attributes are already exposed in the DOM by design,
and if the longer term goal is to try and get *non-prefixed attributes* as
much as possible, deciding on a prefix at this time seems counterproductive
to that goal.

As I recall, we've already had something of a discussion on this topic
(please see:
https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content),
and it was my understanding to continue to proceed with using data-* to
gather implementation experience. (I note in passing that initially Lisa
had concerns, as some of the early experimentation was based around a
working hypothesis of using aui-* attributes - to the point that the early
implementation of using those attributes were cited as evidence to advance
WCAG SC 1.3.6. I know this, because Chuck Adams [Oracle] and I ran the
functional tests for that SC at CSUN 2017's AGWG F2F).

At the end of the day, what we name our tokens is less important than
demonstrating that our approach delivers real value to end-users, and
re-treading paved cowpaths seems far simpler to me than seeking to build
everything from the ground up. I am unconvinced that deciding on a prefix
at this time is that critical.

Respectfully,

JF

On Mon, Feb 3, 2020 at 11:40 AM Janina Sajka <janina@rednote.net> wrote:

> Hi, John:
>
> We missed you on p13n.
>
> To your first point, my suggestion to the call was that we needed to
> decide very soon whether it is now time to ask for a permanent prefix. I
> think I suggested at some point we should decide during February.
>
> And, as to point #2 there was suggestion that the implications of a
> permanent prefix actually would satisfy the minimum ask from browsers,
> because values provided by our prefixed attributes would make it into
> the DOM by definition.
>
> Best,
>
> Janina
>
> John Foliot writes:
> > 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
>
> --
>
> Janina Sajka
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa
>
>

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