Re: Purpose of Controls SC

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

)​


​...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> 
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
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        Alastair Campbell <acampbell@nomensa.com>
To:        Michael Gower <michael.gower@ca.ibm.com>
Cc:        WCAG <w3c-wai-gl@w3.org>, Andrew Kirkpatrick <
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

Advancing the mission of digital accessibility and inclusion