Re: Purpose of Controls SC

> I don't want to get into the weeds here, John, but I think microdata was
discontinued 4 years ago and has no browser support beyond Opera.
Microformats is a better candidate, IF you're using php, etc, etc.

Hi Mike,

Microformats is still alive and kicking today (although it is now called
microformats2 <http://microformats.org/wiki/microformats2>, which according
to their wiki was last updated June 25th, 2017), and it is but *ONE*
publicly available metadata schema - and at AA we don't even ask for that
much (although we'd prefer that). It is only at the AAA level that we ask
for a public schema (and still don't define one, so if you want to use RDFa
you can) - so ya, at AA the proposed SC is still fairly light-weight in
it's ask of content authors: "Here's a list of critical controls/inputs,
provide additional information about them when you use them".

To me, the goal of the AA Success Criteria is to *introduce the list of
critical controls/inputs that authors need to apply additional 'care' to*,
by providing additional data programmatically - that's all, and I am
confused when others are seeing more here than what is written.

In working with Lisa, Alastair, Chris and others, I was cognizant of us not
making the initial ask here too onerous on the content authors, and that
the applicability would work at scale. FWIW, I agree the list today is
still too long, and oddly placed in the draft spec - two concerns that are
being addressed as we speak - but the CfC explicitly notes that we are in
the process of editing down that list (and BTW, we'd love some greater
feedback when the next Draft is published).

NOTE

The Working Group seeks feedback on the lists of terms included in the
definition. These lists are likely to change as items are likely to be
refined, removed or added. *Initial* list of conventional user interface
components (initial draft for public comment only)

(source: https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/
guidelines/#purpose-of-controls)


> the web ecosystem which would allow Purpose of Controls to be met without
a lot of heavy lifting by authors is very immature.

I simply have to disagree. There are robust and mature metadata schemas on
the web today that are fit for purpose here
​, and at the AA level we don't even require metadata - I've previously
shown how the MVP (Minimum Viable Product) requirement could be met using
@title and @aria-describedby​.

>
 I'm objecting to the WG essentially building our own spec.

​At the risk of sounding like a jerk, isn't that what this WG was chartered
to do? Build a spec?​

At both the AA and AAA level, *we are seeking to add a fixed list of
critical controls and inputs* to WCAG 2.1 (a "...spec with good credibility
and momentum..."), and then requiring that the author do *something* with
those critical controls and inputs above and beyond just ensuring an
Accessible Name (it is, in fact, as I previously noted, essentially asking
that we also provide a type of Accessible Description [sic] to those
controls). At the AAA level we get slightly more prescriptive by
additionally stating that the "something" you do requires the use of a
public metadata schema (but we don't specify one).

I struggle to see how the current infrastructure could be described as
'immature'.

JF


On Tue, Aug 15, 2017 at 9:18 AM, Michael Gower <michael.gower@ca.ibm.com>
wrote:

> I will try to be clearer. I'm objecting to the WG essentially building our
> own spec. I believe this is happening because the web ecosystem which would
> allow Purpose of Controls to be met without a lot of heavy lifting by
> authors is very immature.
>
> We are being asked to give approval for something clearly in a state of
> flux --  the list of what authors will actually have to do *may* be put
> in a normative section or may not. The items on the list *may* be pared
> down, or they may be added to. So I have no way of knowing what the actual
> impact from this is.
>
> The closest parallel that has been cited to Purpose of Controls is 4.1.2
> Name, Role, Value. When 4.1.2 was introduced it was light-weight for many
> authors. You essentially met it if you were just using standard HTML
> components. If you added in custom widgets, you could supplement HTML with
> a fairly small subset of aria attributes.
>
> While not expecting Purpose of Controls to be *that *light-weight, I also
> think it should be achievable and testable without overwhelming authors. My
> preferred way of doing that is to base it on a spec (or multiple specs)
> with good credibility and momentum.
>
> I don't want to get into the weeds here, John, but I think microdata was
> discontinued 4 years ago and has no browser support beyond Opera.
> Microformats is a better candidate, IF you're using php, etc, etc.
>
> PS Michael, thanks for correcting me on the state of the COGA semantics as
> a First Public Working Draft.
>
> Michael Gower
> IBM Accessibility
> Research
>
> 1803 Douglas Street, Victoria, BC  V8T 5C3
> gowerm@ca.ibm.com
> voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034
>
>
>
> From:        John Foliot <john.foliot@deque.com>
> To:        Michael Gower <michael.gower@ca.ibm.com>
> Cc:        Alastair Campbell <acampbell@nomensa.com>, Andrew Kirkpatrick <
> akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
> Date:        2017-08-15 06:13 AM
>
> Subject:        Re: Purpose of Controls SC
> ------------------------------
>
>
>
> Mike wrote:
> > It needs to be developed enough to have some level of legitimacy and
> there needs to be evidence of its adoption before we should require its use.
>
> Hi Mike,
>
> TL;DR
>
> NOBODY is requiring the use of COGA Semantics.
>
>
> While a huge goal for the COGA TF is to introduce the ability to provide
> customization/personalization, neither of the draft SC now mention
> personalization in their title or definition (requirements), and so
> "Personalization", while a longer-term goal, is not currently a requirement
> in either of the draft SC (only a potential possibility down the road, once
> tooling matures).
>
> I have previously shown how this SC could be satisfied using Microformats,
> microdata, and RDFa, and I've also suggested that the AA SC could be met
> using aria-describedby. Additionally, there are no Success Criteria today
> that mandate the use of a specific technology, and that remains true today
> with the current drafts(s). The overarching goal of both of these SC
> (both the AA and the AAA) is to encourage the author to add additional
> metadata to a fixed list of inputs and controls, such that the metadata can
> be used to aid those users who required additional information about any
> given input or control.
>
> While the emergent COGA Semantics draft appears to be the built-for-use
> solution today (initially with extremely strong backing from IBM BTW), the
> draft language for both SC studiously avoid calling out COGA Semantics
> specifically:
>
> *Purpose of Controls (AA): *
>           In content implemented using markup languages, the conventional
> name of conventional user interface components can be programmatically
> determined.
>
> *Contextual Information (AAA): *
>           In content implemented using markup languages, contextual
> information for controls, symbols, and regions can be programmatically
> determined using a publicly available vocabulary.
>
> ​(source:
> *https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#purpose-of-controls*
> <https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-6/guidelines/#purpose-of-controls>
> )​
>
>
> ​...In fact, for the AAA SC, given that COGA is still in editor's draft,
> it could be argued (not here please) that *today* COGA Semantics is *NOT*
> publicly available, and so not fit for purpose... today.
>
> Bottom line: there is zero dependency on COGA Semantics in either of these
> SC​.
>
> JF
>
>
> On Mon, Aug 14, 2017 at 10:28 PM, Michael Gower <
> *michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>> wrote:
> > There were objections to using it at all
>
> I'm not sure what the objections were to the COGA semanatics, but for me
> concerns stemmed from its status as a slumbering editor's draft. I
> repeatedly heard we should continue with Personalization on 2.1 because the
> COGA semantics were going to be there in time to give us a framework. My
> concerns have increased, not decreased.
>
> > In which case we go back to saying “Which came first, the chicken or
> the egg?”.
>
> I wasn't involved in the working group back in the days when 4.1.2 Name,
> Role, Value was drafted, but looking at the publication history, the first
> public working draft of ARIA 1.0 came out before the first last call for
> WCAG 2.0. By the time WCAG 2.0 reached CR, ARIA was mature enough that
> multiple browsers supported parts of it. Additionally, 4.1.2 could rely on
> the existence of a well-defined specification for HTML which already
> supported the SC for standard controls.
> That's why 4.1.2 can contain the note it has: "*Note: *This success
> criterion is primarily for Web authors who develop or script their own user
> interface components. For example, standard HTML controls already meet this
> success criterion when used according to specification."
>
> What do we have that's equivalent support right now for Purpose of
> Controls? John trotted out the use of the title attribute. Several of us
> have mentioned the HTML5 input types. Those are pretty slim pickings in
> comparison.
>
> So to me, there really is no chicken and egg discussion. The specification
> comes first. It needs to be developed enough to have some level of
> legitimacy and there needs to be evidence of its adoption before we should
> require its use.
>
> > Do you object to the principle (which has been discussed a lot on the
> list), of including a core set of terms that can be used to identify some
> controls for personalisation/explanation?
>
> Is there precedence for such a large core set of terms in WCAG? Has there
> been any SC that has attempted such a thing on this scale? I know we try to
> find a balance between pushing for progression and cementing existing
> practice. But don't we seem pretty far ahead of the curve in this
> situation? 2.1 is scheduled for CR be end of year. I don't believe the COGA
> semantics will even be a first public draft by then. That raises a lot of
> flags for me. I would much prefer that effort go into a well-thought-out
> and vetted first public draft of COGA semantics.
>
> I suspect part of the sizable push back to a CFC for this item stems from
> a sense we're being pushed to adopt something that is not mature enough for
> level AA.
>
> Michael Gower
> IBM Accessibility
> Research
>
> 1803 Douglas Street, Victoria, BC  V8T 5C3
> *gowerm@ca.ibm.com* <gowerm@ca.ibm.com>
> voice: *(250) 220-1146* <(250)%20220-1146> * cel: *(250) 661-0098*
> <(250)%20661-0098> *  fax: *(250) 220-8034* <(250)%20220-8034>
>
>
>
> From:        Alastair Campbell <*acampbell@nomensa.com*
> <acampbell@nomensa.com>>
> To:        Michael Gower <*michael.gower@ca.ibm.com*
> <michael.gower@ca.ibm.com>>
> Cc:        WCAG <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>>, Andrew
> Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>
> Date:        2017-08-14 02:03 AM
> Subject:        Re: Purpose of Controls SC
> ------------------------------
>
>
>
>
> Michael Gower wrote:
>
> > There have been assurances now for 8 months that the ARIA COGA Semantics
> to Enable Personalization proposal would be mature enough to fulfill that
> role in time for WCAG 2.1.
>
> There were objections to using it at all, that is **why** we proposed to
> move a core set of terms into WCAG, to get over the chicken/egg effect.
>
> > The specification remains an influx working draft, and so we are faced
> with a hastily constructed substitute in this SC. The attributes listed in
> the SC draft not only deviate from the list in the draft spec, but actually
> increase the number -- it isn't even a subset.
>
> It was added to following the feedback about aligning with the HTML5
> attributes, but no-one is saying it cannot be whittled down.
>
>
> > The inference that its 140 some-odd attributes are going to be perfected
> through the public comments process is troubling.
>
> That’s up to 75 tokens/descriptions, which have been put in quickly, and I
> agree they need work.
>
>
> > I believe such effort should be handled by the ARIA WG that first
> published this draft semantics document.
>
> In which case we go back to saying “Which came first, the chicken or the
> egg?”.
>
> Do you object to the principle (which has been discussed a lot on the
> list), of including a core set of terms that can be used to identify some
> controls for personalisation/explanation?
>
> If so, then we’ll have to put off this SC until a later version. If not,
> then I don’t think it’s harmful to use the time after August to refine the
> terms.
>
> Cheers,
>
> -Alastair
>
>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> *john.foliot@deque.com* <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