Re: Purpose of Controls SC

**(Not commenting as W3C/WAI team, all personal opinion.)**

I haven’t looked at this in detail, but a lot (all?) of the values 
seem to stem from this list in HTML for the autofill input fields:

https://www.w3.org/TR/html/sec-forms.html#inappropriate-for-the-control 
(weird direct URL hash…)

I think it would be more than OK for WCAG2.1 to piggyback onto that 
established list (which provides enhancements for PwD and others).

Notes inside:


On 14 Aug 2017, at 15:52, John Foliot wrote:

> +1 to Alastair.
>
> Mike, I too am concerned over the sheer number of controls and inputs, 
> and
> I agree they need to be whittled down to a more manageable number.
> Personally, I'd like to see that number reduced to roughly 20-30 at 
> the
> most, and we will be meeting today during the COGA TF regularly 
> scheduled
> conference call to talk about that.
>
> That said, introducing a SC today that, at AA *suggests* (and at AAA
> *requires*) the use of metadata is an important step in addressing the
> needs of PwD, and more specifically those with cognitive issues.
>
> I agree that COGA Semantics is not yet mature enough, but that is but 
> one
> metadata schema that can be used, and the SC as presented is careful 
> to not
> specifically mandate the use of COGA Semantics (in very much the same 
> way
> that WCAG 2.0 did not, and still to this day does not, mandate the use 
> of
> ARIA).
>
> There are in fact other schemas available to authors today, as 
> illustrated
> below:
>
> Common Component: input for Name
>
> Technique(s) for AA:
>
> Good (but weak):
>   (using @title - Spanish Example) <input type="text" 
> aria-label="name"
> title="Proporcione su nombre o apellido">
>   (using @title - English Example) <input type="text" 
> aria-label="name"
> title="Provide your first or given name">

The accessible name for both form fields would be “name” (as title 
would be overwritten) – barely sufficient for the English example but 
not for the Spanish one. I wonder if you meant another aria attribute 
(role?).

>
> Better:
>   (using Microformats) <input type="text" class="fname  styling-hook
>  yet-another-class-value">
>   (using microdata) <input type="text" itemprop="givenName" itemtype="
> http://schema.org/Person">
>   (using RDFa) <input type="text" property="givenName" 
> typeof="Person">
>
> Best:
>   (using COGA Semantics) <input type="text" coga-field="name">

I’d like to see a more general way of doing it, for example specifying

<input type=“text name”> – I think we need to make sure to best 
not use accessibility specific prefixes where possible. Otherwise it 
might be seen as an afterthought.

Eric

>
> *************
> Technique(s) for AAA:
>
> Good:
>   (using Microformats) <input type="text" class="fname">
>   (using microdata) <input type="text" itemprop="givenName" itemtype="
> http://schema.org/Person">
>   (using RDFa) <input type="text" property="givenName" 
> typeof="Person">
>
> Best:
>   (using COGA Semantics) <input type="text" coga-field="name">
>
> So, yes, I agree, COGA Semantics is not yet mature enough, but the 
> fact
> that other forms of metadata have already created taxonomical entries 
> for
> many of these very input and control types illustrate to me both a 
> real
> need, and an existing solution that needs but the additional nudge of 
> WCAG
> 2.1 to start paying off in real benefits soon.
>
> JF
>
>
>
>
> On Mon, Aug 14, 2017 at 4:02 AM, Alastair Campbell 
> <acampbell@nomensa.com>
> wrote:
>
>> 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


--

Eric Eggert
Web Accessibility Specialist
Web Accessibility Initiative (WAI) at World Wide Web Consortium (W3C)