Re: Purpose of Controls SC

Hi Eric,

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?).

What is being sought here is not the Accessible Name
<https://www.w3.org/TR/core-aam-1.1/#dfn-accessible-name> as defined in the
Accessibility API mappings, it is in fact "more information" about what the
control actually means and what is actually required from the end user. If
you were to map it to an Accessibility API term, it is far closer to
*accessible
description <https://www.w3.org/TR/core-aam-1.1/#dfn-accessible-description>
*:

Accessible Description

An accessible description provides additional information, related to an
interface element, that complements the accessible name
<https://www.w3.org/TR/core-aam-1.1/#dfn-accessible-name>. The accessible
description might or might not be visually perceivable.

So, another way of thinking about this SC is that we are requiring some
"Accessible Description data" on a specific list of key controls, ideally
using metadata (because of what we can do with the power of metadata), but
if you cannot use metadata, you as content author still need to give the
end user something.

As the weak examples illustrate, there is *NO* machine readability or
machine-interaction expected per-se, only additional information to aid
*some* users with cognition issues who struggle to understand what is being
asked of them. It is not an all or nothing solution. It is specific,
explicit, focused "Help" on a fixed list of common controls, where the use
of metadata starts us on a path of controlled terms *and* values (but at AA
today we won't always be able to get controlled values, so if that is the
case, then give us *something* that aids the target user-group against the
list of controlled terms)

JF




On Mon, Aug 14, 2017 at 9:23 AM, Eric Eggert <ee@w3.org> wrote:

> *(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)
>



-- 
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion