Re: CFC - Purpose of Controls SC

-1: I cannot live with the SC in its current form, with that MASSIVE 
list of terms in it. I'm sorry I didn't get that in the survey in 
advance of yesterday's call, but I was only prepared for the first three 
items in the survey.

There are three reasons the lists should never be part of the SC wording 
itself - one is it's super-long and will just stop people in their 
tracks, another is lists like this risk creating exclusion by omission, 
and another is it's super-hard to test such a large set of potential 
normative conditions.

I know there is a plan to put in an ednote, but until I see that I can't 
refine my vote, and I can't see enough from minutes / remember enough 
from discussion to predict the shape of the ednote. If the *entire* set 
of lists gets put in the ednote, I will live with it - barely. It's 
still a huge block to plunk into a set of otherwise fairly brief SC, but 
at least as an ednote it's clear it's not intended to be part of the SC 
wording.

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". That would also allow me to remove my objection. That complicates 
things though because there are three lists yet only one obvious term. I 
think we would have to change the SC wording to "In content implemented 
using markup languages, the conventional name of conventional user 
interface components for <a>form fields</a>, <a>buttons or controls</a>, 
or <a>links</a> can be programmatically determined." Then there would be 
terms "conventional names for form fields", "conventional names for 
buttons or controls", and "conventional names for links". I'm still not 
super keen on this, as the massive lists with their attendant problems 
are still there, but at least less disruptively.

I really think the right solution is to put those lists in 
Understanding, if we really have to have such super-precise stuff. I 
think ultimately a success criterion that depends on huge over-precise 
lists in normative content is not going to succeed. If we can't agree on 
a wording for the SC that allows this content to be in Understanding, I 
don't see how the SC will pass later stages of guidelines development. I 
recognize that right now with a goal of getting in a draft for public 
review, that is not a solution on the table, and the ednote is the 
interim approach, but think we need a clear plan to evolve towards a 
more workable SC.

Michael


On 10/08/2017 11:21 PM, Andrew Kirkpatrick wrote:
> 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 <mailto:akirkpat@adobe.com>
> http://twitter.com/awkawk
>