Re: CFC - Purpose of Controls SC

On 15/08/2017 3:17 AM, lisa.seeman wrote:
> Hi Michael
> Before the list there was a heading that read "note" with a provision 
> . So it was part of the CFC that the lists were in a note, even if 
> that was not clear and noticed by everyone.
> This is the wording in the issue on github 
> <> 
> before the lists that went to CFC
>           Note
>             *Initial* list of conventional user interface components
>             (initial draft for public comment only)
The wording in the SC is a "note", which is still part of the body of 
the SC, and something I can't live with for such a long block of 
detailed text. If it were an "editorial note" then it would not 
technically be part of the SC, and I would have lived with it, albeit 
extremely reluctantly as the long block of content still makes it harder 
to review the surrounding SC. I'm hearing from various people that 
different alternate scenarios were actually intended, but I'm voting on 
the basis of what I see will be merged into the guidelines, as that is 
what the public will review, without any background context or insider 
insight into real intent. I do hope we can get some edits, such as 
putting the lists in definitions (my preferred temp solution) or putting 
them into an editorial note and then issue a CfC based on that.

> The problem might be that these are complex spaces and we have a lot 
> going on, making it hard to track the full issue.
I agree there's a lot going on, it's challenging for all of us, and I'm 
having a hard time staying on top as well. But partly for that reason, 
I'm voting based on what the public will see, not on what I think the WG 
means, to make sure we don't wind up with stuff we never fully intended.

> All the best
> Lisa Seeman
> LinkedIn <>, Twitter 
> <>
> ---- On Mon, 14 Aug 2017 23:52:04 +0300 *Michael Cooper< 
> <>>* wrote ----
>     On 14/08/2017 11:05 AM, John Foliot wrote:
>         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.
>     During the call Thursday I was in principle ok with going to CfC
>     with the promise of an ednote. However, when looking at the
>     content after the CfC opened, this issue became apparent to me and
>     it was not clear if the planned ednote would address it, so I had
>     to issue my -1. Yes, I should have looked closer sooner and I
>     might have raised it earlier, but here we are.
>     While I think the lists proposed in this SC are too long for any
>     single SC in the normative content, I did say in my -1 that I
>     would live with it for now if we moved the lists to definitions,
>     or put the lists into the ednote. I'm hearing now that this was
>     the plan all along, but that wasn't evident to me, and I would say
>     the CfC was premature in that case.
>     Another way of looking at why I'm concerned about these lists in
>     the body of an SC: We now have 74 SC between WCAG 2.0 and WCAG
>     2.1, not including ones still under open CfC. In my environment,
>     these come to 24 printed pages. However, the purpose of controls
>     SC alone would come to 6 printed pages if included. This would
>     mean 1.3% of the SC would take up 20% of the space, or 15 times
>     the average space required for an SC. An outlier statistic like
>     that always triggers me to question things.
>     Moving the lists to definitions won't solve the core problem of
>     too much content for one SC, but it'll move it to a less
>     disruptive place. I think people reading the guidelines, and
>     suddenly coming across an SC that takes up 6 pages, might just
>     stop reading there. I would. So I think including the lists in the
>     SC will disrupt review of the entire rest of the guidelines, and
>     that's ultimately why I vote against it, notwithstanding that in
>     general I support having unfinished stuff in the spec for the
>     moment so we can obtain review. Moving the lists to the
>     definitions section I think is less likely to disrupt reading and
>     overall review because I think people are less likely to attempt
>     to read those top-to-bottom, so even though I don't think that is
>     the ultimate solution to the structure of this SC I can live with
>     that for now.
>     While I know there are other concerns around this SC, I think
>     implementing that change might remove a lot of the -1 votes,
>     including mine. I would like to encourage review of the SC, so
>     hope people with other reservations would accept its inclusion for
>     that purpose. I'm just trying to make sure we don't  break the
>     review of other SC while trying to obtain it for this one. If we
>     could get the edits of moving the lists to definitions and a new
>     CfC out for that, from my perspective we could still get it
>     included in a couple more days.
>     Michael

Received on Tuesday, 15 August 2017 13:44:31 UTC