Re: CFC - Purpose of Controls SC

Come to think of it, I second Michael's concerns on this one. Putting the
entire list in the Understanding document seems like a more viable
approach. I just can't picture myself teaching about this SC with the list
included in front of clients, let alone defend the working group in the
fact that this was the right approach.

/Denis



On Fri, Aug 11, 2017 at 3:04 PM Michael Cooper <cooper@w3.org> wrote:

> -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
> http://twitter.com/awkawk
>
>
> --
/Denis

--
Denis Boudreau
Principal SME & trainer
Web accessibility, inclusive design and UX
Deque Systems inc.
514-730-9168

Keep in touch: @dboudreau