RE: Word count of New SC compared to WCAG 2

+1 to Alistair’s points here…..FPWD doesn’t need to be empty and clean, it needs to share what we are looking at, to illicit feedback and comments

 

​​​​​* katie *

 

Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)

 

Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog

NOTE: The content of this email should be construed to always be an expression of my own personal independent opinion, unless I identify that I am speaking on behalf of Knowbility, as their AC Rep at the W3C - and - that my personal email never expresses the opinion of my employer, Deque Systems.

 

From: Alastair Campbell [mailto:acampbell@nomensa.com] 
Sent: Wednesday, January 4, 2017 9:59 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: 'WCAG' <w3c-wai-gl@w3.org>
Subject: Re: Word count of New SC compared to WCAG 2

 

Hi Andrew,

 

> The Working Group has not made any decision that it will include all of the SC proposals in the FPWD and then cull or change them in response to feedback. This is one possible approach, with the other being to build up the FPWD with what the WG agrees 

 

I don’t feel strongly either way, but I had assumed (and I think others have) that we would start with everything and whittle down to what is agreed.

 

The downside to the whittle-down approach is that it will appear far messier to start with.

 

The downside to adding new SCs to later drafts is that reviewers are surprised by new things. I think a lot of people will assume that a later draft would be a revised version of what was in the FPWD, not include new things.

 

If we do add new SCs to later drafts (for 2.1), we need to slap on a ‘big red banner’ (or equivalent) saying that is the case, and perhaps list the potential SCs at the bottom (as Katie suggested) or separately.

 

 

> I favor a document that we build up as a high-quality work-product at every point in time

 

I think that is a good goal, but I’m not sure how feasible it is during the drafts stage? There is a sort of n+1 problem [1] in that each change ripples out to affect other SCs.

 

For example, I thought the metadata on hover SC [2] was pretty straightforward: it doesn’t appear to affect other SCs. However, ‘goetsu’ pointed out on github that using title is a technique for 4 other SCs, which would then be banned by this SC. Perhaps the right call is to have the new SC and remove the other techniques, perhaps not. My point is that you need to know what is “in”, then iron out the ripples.

 

If we have (say) 20 new SCs in the FPWD, then we will get a lot of feedback about the SCs, and the overlaps / impacts of the new ones.

 

If the next draft has 30, we are updating the SCs, the impacts, and the new SCs and new impacts which may overlap with the old impacts. We could flip-flop on certain points because having a new SC changes the landscape… I can see that adding a lot of overhead at each draft.

 

If we have 60 new SCs in the FPWD (and highlight that we are whittling down), then the first round will be painful, but at each round it gets easier and easier.

 

This is all a bit theoretical to me though, is it possible to ask someone heavily involved in the first WCAG 2.0 round their advice about this?

 

Cheers,

 

-Alastair

 

1] http://stackoverflow.com/questions/97197/what-is-the-n1-selects-issue 

2] https://github.com/w3c/wcag21/issues/75