SC lists now formatted as bullets Re: Editorial changes to SC

I put in CSS to style the SC definition lists as bullets. It looks good 
to me in 2 Windows browsers, and decent in a 3rd. But I'm not sure how 
brittle the approach is. If people want to test and let me know if it 
doesn't work in your browser. If I get reports that it's awful, I'll 
revert the edit before the publication and sort it for the later 
publication. Otherwise I'll publish with this style change in. Michael


On 08/09/2017 3:59 PM, David MacDonald wrote:
> Hi Michael
>
> I've put up an example of our DL code with some CSS to make the <dt> 
> and <dl> inline and placed a background image for a bullet on the <dt>.
>
> Feel free to use this code if you find it useful and save an hour or 
> so of fiddling with CSS.
>
> http://davidmacd.com/test/definition-list-with-bullets.html
>
>
> 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 Fri, Sep 8, 2017 at 1:09 PM, Michael Cooper <cooper@w3.org 
> <mailto:cooper@w3.org>> wrote:
>
>     On 08/09/2017 11:20 AM, David MacDonald wrote:
>>     ​I could live with that rational... do you think we should remove
>>     numbers where they are in WCAG 2?
>>     1.4.8
>>     3.3.4
>>     3.3.6
>     It's a separate question as to whether we should change the WCAG
>     2.0 SC that are included in WCAG 2.1. For now I didn't touch
>     those, under the rationale that we're keeping them exactly as they
>     appear in WCAG 2.0 for now, to minimize confusion. However, we
>     could decide that we want to apply at least editorial changes to
>     make all of WCAG 2.1 self-consistent; we will also soon explore
>     whether we want to merge some WCAG 2.1 SC with existing 2.0 SC, in
>     which case we would be changing them anyways. In either of those
>     cases, yes I would like to apply the editorial changes to the 2.0
>     SC, but we won't have the decisions to support doing that before
>     the upcoming WD publication.
>>
>>     However, I would not like to loose the actual bullets such as has
>>     been done in the current 2.1 draft. I don't think we want
>>     definition lists instead of the bullets... missing the visual
>>     bullet I think hinders comprehension.​
>     I think the definition list is important for semantics, it
>     provides a semantic for the header that simply putting boldface
>     text doesn't. However, I've said many times that I plan to improve
>     the styling, and it initially makes sense to make it come out like
>     bullets, looking the way it does in WCAG 2.0. I believe this to be
>     possible with CSS but also believe it to be more tricky than one
>     would hope.
>
>     If direct styling fails, it's also an option to have the script
>     output the document as bullets with semanticless boldface headers
>     (which is also what WCAG 2.0 does). But even in that case, for
>     editorial ease I consider it important to keep them as definition
>     lists in the source.
>
>     A very short background to why I'm pushing on this - for WCAG 2.0
>     we had a rich XML format with all sorts of semantics that helped
>     us maintain and transform the document to different outputs. But
>     that proved too hard for people who weren't extensively trained in
>     the format to edit, so for 2.1 we decided to use HTML as our
>     source, which has far fewer of the semantics we need but is easier
>     for WG participants to author. I proposed the closest available
>     semantic to our use cases, which in the case of list with headers
>     is a definition list. We can use script and style to adjust the
>     output - I'm not excellent at either so haven't done as much of
>     those as I expect us eventually to want - but I consider having
>     maximally semantic markup important for our later needs.
>
>     Michael
>
>>
>>
>>     Cheers,
>>     David MacDonald
>>
>>     *Can**Adapt**Solutions Inc.*
>>
>>     Tel: 613.235.4902 <tel:%28613%29%20235-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 Fri, Sep 8, 2017 at 9:59 AM, Michael Cooper <cooper@w3.org
>>     <mailto:cooper@w3.org>> wrote:
>>
>>         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/#graphics-contrast>
>>>         https://www.w3.org/TR/WCAG21/#user-interface-component-contrast-minimum
>>>         <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
>>>         <https://www.w3.org/TR/WCAG20/#visual-audio-contrast>
>>>         VS
>>>         https://www.w3.org/TR/WCAG21/#contrast-minimum
>>>         <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 <tel:%28613%29%20235-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 Monday, 11 September 2017 22:13:27 UTC