Re: Editorial changes to SC

Using list numbering to refer to things is very brittle. Things can 
change all the time in ways that affect numbering, and if we start using 
particular numbers to refer to particular things and don't want to 
change numbers as a result, it puts a major constraint on our work for a 
fairly artificial reason.

I would also argue that ordered lists should only be used when there is 
an inherent sequential order required for meaning in the list. I did not 
find any SC where I believed that to be the case. I think with any of 
these SC, if we changed the order of list items the SC would mean the 
same thing.

If you want to be able to easily refer to list items in a SC, you should 
use the lists with headers approach, used by many SC, and implemented as 
definition lists in our source code. I personally would like to see all 
SC use that pattern, but did not propose it as a rule, and did not 
consider it merely editorial to introduce that pattern to SC that 
weren't using it. If somebody wants to make proposals we could decide to 
implement that on SC during the normalization period of the next couple 
months, or the WG could declare that editorial and delegate me to do it.

Michael


On 08/09/2017 2:51 AM, David MacDonald wrote:
> In general I think they look great and it helps a lot...
>
> I would like to discuss with the group the option of making all 
> bulleted lists into orderded lists that are numbered... it would then 
> be easier to refer to individual bullets in reports of conformance.
>
> For instance in User Interface components if referring to the part on 
> Inactive components an evaluator could list.
>
> 1.4.12 #2
> OR
> 1.1.12.2
>
> Currently many SCs don't have bullets OR numbers which is a departure 
> from WCAG 2
>
> https://www.w3.org/TR/WCAG21/#graphics-contrast
> https://www.w3.org/TR/WCAG21/#user-interface-component-contrast-minimum
>
> Even some of  the WCAG 2 SCs that have bullets in the original don't 
> have them in the last draft.
> See the original 1.4.3
> https://www.w3.org/TR/WCAG20/#visual-audio-contrast
> VS
> https://www.w3.org/TR/WCAG21/#contrast-minimum
>
> And I think the latest draft is confusing without these bullets 
> because it looks more like glossary terms than part of the SC text.
>
> 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 Thu, Sep 7, 2017 at 10:21 PM, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>
>     Following up on the QA checklist I sent around last week, I have
>     done an editorial pass of the SC in WCAG 2.1. The changes I made
>     are shown in:
>
>     https://github.com/w3c/wcag21/commit/19ac37387f3c8a82c5d3838b9fa5327b28b37dab
>     <https://github.com/w3c/wcag21/commit/19ac37387f3c8a82c5d3838b9fa5327b28b37dab>
>
>     Please let me know if you disagree that any of these changes are
>     editorial. Most are simple things like punctuation, but in a
>     couple places I moved clauses around to improve coherence and
>     readability.
>
>     I added a couple things to the QA checklist as I went, and
>     implemented those in these edits:
>
>     https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_QA_Checklist&diff=8139&oldid=8109
>     <https://www.w3.org/WAI/GL/wiki/index.php?title=WCAG_2.1_QA_Checklist&diff=8139&oldid=8109>
>
>     The change that I think might give people the most pause is
>     Content on Hover or Focus
>     (https://w3c.github.io/wcag21/guidelines/#content-on-hover-or-focus
>     <https://w3c.github.io/wcag21/guidelines/#content-on-hover-or-focus>),
>     where I changed
>
>         "When content becomes visible when triggered by a user
>         interface componentreceiving keyboard focus or pointer hover,
>         the following are true, except where the visual presentation
>         of the content is controlled by the user agent and is not
>         modified by the author:"
>
>     to
>
>         "When a user interface componentwhich receives keyboard focus
>         or pointer hovercauses content to become visible, the
>         following are true:"
>
>     and moved the exception to after the bullet list. I made this
>     change because I was finding the dependent clauses to be very hard
>     to follow. I think I didn't change meaning, but want to point this
>     out for extra review in case you disagree this change was editorial.
>
>     I plan to make a pass through terms as well but didn't get to that
>     today.
>
>     Michael
>
>

Received on Friday, 8 September 2017 13:59:17 UTC