Re: Potentially normative change to target size SC, and other edits

On 14/08/2017 9:15 PM, David MacDonald wrote:
> I think there has been quite a bit of discussion around providing 
> numbered lists instead of bulletted lists (or definition lists)
>
> I would suggest we start moving that direction, which gives the 
> benefit of allowing bullets to get referenced lie this.
If we decide to go that direction globally we can. But meanwhile we 
should have consistency, which is the reason I made the change. 
Definition lists provide more semantic meaning when there are headers 
for the bullets. I've been meaning to style them a bit more compactly. 
That might address what you're looking for. Note that lists in SC that 
don't have headers to use bullets, it's just the ones with headers I 
converted to definition lists.

Michael
>
> 2.4.6.3
>
> Principle>Guidline>SC>Bullet.
>
> Cheers,
> David MacDonald
>
> *Can**Adapt**Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd <http://twitter.com/davidmacd>
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
> /  Adapting the web to *all* users/
>
> /            Including those with disabilities/
>
> If you are not the intended recipient, please review our privacy 
> policy <http://www.davidmacd.com/disclaimer.html>
>
> On Mon, Aug 14, 2017 at 6:21 PM, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>
>     Yes. JF's reasoning is the reason I made this change. We should
>     not conflict with other W3C specs, and using a glossary entry
>     makes a "single point of failure" to help ensure this. Including a
>     reference in the term to the other W3C spec that authoritatively
>     defines the term helps avoid forks on our part. If we later need
>     to update or correct the reference, we only need to do it once in
>     the glossary, rather than search for multiple places elsewhere in
>     the document and potentially miss some, or argue about the wording
>     individually in the context of separate SC. Also, the definition
>     of CSS pixel in the glossary references the exact CSS spec that
>     defines it, while the link I replaced just pointed to the CSS2
>     cover page, which is very generic and also somewhat out of date,
>     so this edit increased precision.
>
>     Michael
>
>
>     On 14/08/2017 5:25 PM, John Foliot wrote:
>>     > So I changed the link to point to the term in the WCAG 2.1
>>     spec, instead of CSS 2.
>>     ​> ​
>>     This is technically a normative change; if anybody objects to it,
>>     let me know.
>>
>>     ​I understand both the justification and the concern​
>>
>>     ​.
>>
>>     I personally am not opposed
>>
>>     ​ to replicating the definition in WCAG 2.1​
>>     (given that CSS 2 is a normative spec
>>     ​, and not likely to change​
>>     ), and
>>     ​ so equally​
>>     I am not opposed to pointing to th
>>     ​at
>>      same definition *inside* of WCAG 2.1, but ideally I'd also
>>     ensure that the WCAG 2.1 definition in-turn references the
>>     definitive CSS 2 definition (linked), so that ultimately we have
>>     but *ONE* normative W3C
>>      definition (i.e.some provisional language stating the definitive
>>     definition is at CSS 2).
>>
>>     (In other words, I would hate to see a conflicting definition
>>     show-up down the road due to our failure to closely follow
>>     activities in a different Working Group)​
>>
>>
>>     JF
>>
>>     On Mon, Aug 14, 2017 at 2:53 PM, Michael Cooper <cooper@w3.org
>>     <mailto:cooper@w3.org>> wrote:
>>
>>         I'm preparing WCAG 2.1 for the next formal publication,
>>         scheduled for next tomorrow. I routinely do cleanup at this
>>         stage to ensure consistency.
>>
>>         In this pass, I came across one issue in the two new Target
>>         Size SC recently accepted:
>>
>>         https://rawgit.com/w3c/wcag21/master/guidelines/#target-size
>>         <https://rawgit.com/w3c/wcag21/master/guidelines/#target-size>
>>         https://rawgit.com/w3c/wcag21/master/guidelines/#target-size-(no-exception)
>>         <https://rawgit.com/w3c/wcag21/master/guidelines/#target-size-%28no-exception%29>
>>
>>         They both linked the term "CSS pixels" to the CSS 2
>>         specification:
>>
>>         https://www.w3.org/TR/CSS2/
>>
>>         That link doesn't really provide value, and we already have a
>>         term for CSS pixel:
>>
>>         https://rawgit.com/w3c/wcag21/master/guidelines/#dfn-css-pixel
>>         <https://rawgit.com/w3c/wcag21/master/guidelines/#dfn-css-pixel>
>>
>>         So I changed the link to point to the term in the WCAG 2.1
>>         spec, instead of CSS 2.
>>
>>         This is technically a normative change; if anybody objects to
>>         it, let me know.
>>
>>         Other changes I have made both to recently add SC, and ones
>>         currently under CfC, which I consider editorial but let me
>>         know if you think otherwise:
>>
>>           * Lists in SC changed to definition lists when they have
>>             headers;
>>           * Terms start with a single clause, and any further
>>             exposition in subsequent paragraphs;
>>           * Consistent capitalization;
>>           * Marked everything as "new";
>>           * Removed stray elements like redundant conformance level
>>             markers;
>>           * Changed some paragraphs to editorial notes when it seemed
>>             that was the intent;
>>           * Provide links to Understanding pages (most of them
>>             populated just with a template);
>>           * Other invisible edits like making the file we edit match
>>             the new name of the SC.
>>
>>         Michael
>>
>>
>>
>>
>>     -- 
>>     John Foliot
>>     Principal Accessibility Strategist
>>     Deque Systems Inc.
>>     john.foliot@deque.com <mailto:john.foliot@deque.com>
>>
>>     Advancing the mission of digital accessibility and inclusion
>
>

Received on Tuesday, 15 August 2017 01:35:11 UTC