Re: CFC - Purpose of Controls SC

mcooper wrote:

> A better solution is to move those lists to terms, with the ednote either
in the SC or the terms themselves saying "we're still working on this".

This is *exactly* the plan moving forward, discussed and agreed to on
Thursday's call.

There is a recognition by many (all?) that the initial list is way too
long. Fair point. That list needs to be worked on and whittled down (and a
number of us agreed to meet on Monday (today) to start work on that). It is
disappointing that this was either poorly captured in the meeting minutes,
or that dissenters are otherwise unaware of that fact.

Was the CfC released too soon? Perhaps. Is that reason to walk away from
this proposed SC? Hardly. Are we still looking to whittle down that list -
indeed we are. We are scrambling hard and fast, and the CfC was predicated
on the fact that we would have *a* list (not the definitive list) in time
for the August cut-off, and then seek feedback from the larger community,
knowing and understanding that the list will likely evolve further between
now and December 2017.


> I really think the right solution is to put those lists in Understanding,
if we really have to have such super-precise stuff

I respectfully disagree, the final list will need to be included in the
normative document, either as directly part of the SC itself, or in a
definition section that is still part of the normative text. We have
evidence that when we are less than specific and precise in our SC that the
ambiguity causes us a world of difficulty in the real world application of
WCAG: I need only point to the ambiguous SC 1.3.1 as our poster-child
there. The real key is to get the list to a manageable size, and NOT to
just dump it off in some non-normative region of WCAG.

*****

Meanwhile, Jason wrote:

> I think the most likely effect would be the emergence of a multiplicity
of techniques for satisfying it – poorly supported by assistive
technologies, and of limited benefit to actual users with learning and
cognitive disabilities, who have a great need for real, sustainable, well
specified solutions that actually deliver improved accessibility.

Jason, you say "multiplicity of techniques" like that is a bad thing. Can
you please elaborate on why having multiple techniques to meet a SC is
undesirable to you?

As you also note, the support for using metadata in AT today is poor, but
remember as well that AT only solves some problems for some users - if
screen reader support for metadata is poor today, that alone is hardly a
reason to NOT use metadata (and additionally, it is unclear to me why
text-to-symbol transformation would matter to a screen reader user: it
would seem here that additional prose help information would be the most
useful anyway). Remember too, when we first started seeking authors to use
ARIA, screen reader support for ARIA was pretty pitiful at that time as
well. It was a chicken-and-egg problem, which is what we are faced with
again here.


> text that would appear in a title or label raises unresolved concerns
regarding internationalization, localization, and inability to adapt the
text to suit the context in which a control appears in a given Web site or
application.

Please elaborate. Can you give an example where you feel that providing
additional prose information (via @title), in the native language of the
source document, is going to cause an internationalization or localization
issue? Can you provide us sample/examples showing that this prose content
could not be translated in exactly the same fashion that page content today
can be translated?

What is the difference in your mind between providing "advisory information
<https://www.w3.org/TR/html51/dom.html#the-title-attribute>" via @title
(per HTML5.1) and having a small icon (eg a small circle with an
italicised "I" in it, with the alt-text of "help for this input") next to a
form input that the end user clicks on to get additional information (in
the native language of the document) regarding that input via a modal
dialog?
(And, in fact, that *may* also be a potential Technique for this newly
proposed SC).

It is important to understand (and remember) that at AA, the newly emergent
SC is not explicitly intended to offer "transformation" capabilities (as
was originally envisioned in the first "Support Customization" SC).

Instead, at AA we've sought to first establish that specific controls and
inputs (from a list yet to be finalized) will generally *always* require
some additional help-type data for some users. If we can start by
identifying and augmenting those controls and inputs (even if it is only
with prose advisory information) then we are leading our content authors on
the journey the culminates in the currently proposed AAA SC, where machine
transformation *can* be achieved (and perhaps with something as simple as a
browser extension).

This is a process not unlike what we did with ARIA itself, where we
establish a "success" condition which obviates the fact that "hey,
by-the-way, this new technology called ARIA is the simplest/best way to
meet this SC" (or here, replace ARIA with COGA Semantics, or simply
"metadata"), but without specifically say that authors *MUST* use ARIA (or
COGA Semantics).

JF

On Mon, Aug 14, 2017 at 8:42 AM, ALAN SMITH <alands289@gmail.com> wrote:

> -1
>
>
>
> Alan Smith
>
>
>
> *From: *Andrew Kirkpatrick <akirkpat@adobe.com>
> *Sent: *Thursday, August 10, 2017 11:22 PM
> *To: *WCAG <w3c-wai-gl@w3.org>
> *Subject: *CFC - Purpose of Controls SC
> *Importance: *High
>
>
>
> Call For Consensus — ends Monday August 14th at 11:30pm Boston time.
>
>
>
> The Working Group has reviewed and approved two new related Success
> Criteria for inclusion in the Editor’s Draft: Purpose of Controls and
> Contextual Information, at AA and AAA respectively, with the goal of
> obtaining additional input external to the working group. This CFC is for
> the AA version of the SC.
>
>
>
> Call minutes: https://www.w3.org/2017/08/10-ag-minutes.html#item02
>
>
>
> The new SC can be reviewed here, in the context of the full draft:
>
> https://rawgit.com/w3c/wcag21/support-personalization_ISSUE-
> 6/guidelines/#purpose-of-controls
>
>
>
> Please note that an editor’s note will be added to this SC to gather
> feedback on the lengthy list of conventional names before it is published.
>
>
>
> If you have concerns about this proposed consensus position that have not
> been discussed already and feel that those concerns result in you “not
> being able to live with” this decision, please let the group know before
> the CfC deadline.
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
>
>



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

Advancing the mission of digital accessibility and inclusion