Re: CFC - Purpose of Controls SC

+1 to Michael

Revised -1 for the SC

________________________________
From: Michael Cooper <cooper@w3.org>
Sent: Friday, August 11, 2017 9:03 PM
To: Andrew Kirkpatrick; WCAG
Subject: 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




----------------------------------------------------------------
ATTENTION:
The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
------------------------------------------------------------------------------------------------------

Received on Sunday, 13 August 2017 11:24:54 UTC