W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2017

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

From: Michael Cooper <cooper@w3.org>
Date: Mon, 11 Sep 2017 18:54:13 -0400
To: Andrew Kirkpatrick <akirkpat@adobe.com>, David MacDonald <david100@sympatico.ca>
Cc: AG WG <w3c-wai-gl@w3.org>
Message-ID: <d2094304-0423-e0b3-5564-d35138bb7689@w3.org>
Essentially in WCAG 2.0 we formatted elements, which had the semantics 
of definition lists, as bullet lists, and removed semantics from the 
code to make it work. When I set up the HTML 5 format for WCAG 2.1 I 
restored the semantics but not the style - but always intended to 
address the style for consistency with 2.0. When I started enforcing the 
semantics harder in the course of the code cleanup I got pushback on the 
style impact, so I prioritized updating the style.

I personally would be fine with leaving the lists styled as definition 
lists. I also don't object to styling them as bullet lists with 
bold-faced headers, I think it's readable and the underlying semantics 
are still there and supported afaik. So I was just executing what I 
understood to be the will of the group (within the "no I won't 
compromise on the semantics aspect of this" response I had given earlier).

If the will of the group is not to make definition lists look like 
bullet lists, that's fine, I'll revert the commit. If the will of the 
group is for them to look like bullet lists, then we need this style 
hack because I think the semantics of the definition lists are important 
for the type of content, lists with headers, which we use a lot in WCAG.


On 11/09/2017 6:26 PM, Andrew Kirkpatrick wrote:
> I prefer the way that it is done in the CSS spec: 
> https://www.w3.org/TR/CSS/#levels
> It feels peculiar to me to say that the right semantics involve using 
> the definition list, but we should make them look like a bulleted 
> list. I like the way it looks as a bulleted list and it makes sense to 
> me, but maybe it should just be a regular unordered list?
> Thanks,
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
> akirkpat@adobe.com
> http://twitter.com/awkawk
> From: Michael Cooper <cooper@w3.org <mailto:cooper@w3.org>>
> Date: Monday, September 11, 2017 at 18:13
> To: David MacDonald <david100@sympatico.ca <mailto:david100@sympatico.ca>>
> Cc: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Subject: SC lists now formatted as bullets Re: Editorial changes to SC
> Resent-From: WCAG <w3c-wai-gl@w3.org <mailto:w3c-wai-gl@w3.org>>
> Resent-Date: Monday, September 11, 2017 at 18:13
> 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 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdavidmacd.com%2Ftest%2Fdefinition-list-with-bullets.html&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=5bggb3WkMT4reC3AYXkhGo%2FnDIlFqdbrBP74Trv9IAI%3D&reserved=0>
>> Cheers,
>> David MacDonald
>> *Can**Adapt**Solutions Inc.*
>> Tel:  613.235.4902
>> LinkedIn
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=wZzNNsl2ZNjXzM67tofCckwxNAaxg33WCqbUt0tRi%2BU%3D&reserved=0>
>> twitter.com/davidmacd 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=fjlhSqeBi2VZZrqvDlUGZeGn3okKXwtzxTqtBlc8RIk%3D&reserved=0>
>> GitHub 
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=r0U1EYnYUA6SXDgxUUMWdeDUYQ8Futw7Wm6Al5D2rXE%3D&reserved=0>
>> www.Can-Adapt.com 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=rtQrKeXal3mxWlX23DgLYIbu8TAXPrVAMOpXxO4jAKg%3D&reserved=0>
>> /  Adapting the web to *all* users/
>> /Including those with disabilities/
>> If you are not the intended recipient, please review our privacy 
>> policy 
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=D69z1TP%2F8KfarxJ0E8idZJ36zqZAIqta6OMSnBHMGNU%3D&reserved=0>
>> 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
>>>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=wZzNNsl2ZNjXzM67tofCckwxNAaxg33WCqbUt0tRi%2BU%3D&reserved=0>
>>>     twitter.com/davidmacd
>>>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=fjlhSqeBi2VZZrqvDlUGZeGn3okKXwtzxTqtBlc8RIk%3D&reserved=0>
>>>     GitHub
>>>     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=r0U1EYnYUA6SXDgxUUMWdeDUYQ8Futw7Wm6Al5D2rXE%3D&reserved=0>
>>>     www.Can-Adapt.com
>>>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=rtQrKeXal3mxWlX23DgLYIbu8TAXPrVAMOpXxO4jAKg%3D&reserved=0>
>>>     /Adapting the web to *all* users/
>>>     /Including those with disabilities/
>>>     If you are not the intended recipient, please review our privacy
>>>     policy
>>>     <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=D69z1TP%2F8KfarxJ0E8idZJ36zqZAIqta6OMSnBHMGNU%3D&reserved=0>
>>>     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
>>>>         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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F%23graphics-contrast&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=zeQr3EdQDBR0jAN5ivF%2BhnYkamYxT8W8lSjoLXRNDkM%3D&reserved=0>
>>>>         https://www.w3.org/TR/WCAG21/#user-interface-component-contrast-minimum
>>>>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F%23user-interface-component-contrast-minimum&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=ld2ltERhjd4igJCUm83FMZZsjySofA2NKeyaMZ4N3L4%3D&reserved=0>
>>>>         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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG20%2F%23visual-audio-contrast&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=shpRSgHfPO3f4xx16z6U%2B4ScUiZFf8AFi%2FSIcFnzOlY%3D&reserved=0>
>>>>         VS
>>>>         https://www.w3.org/TR/WCAG21/#contrast-minimum
>>>>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG21%2F%23contrast-minimum&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=MqK%2BiHMs40P2ROs0%2FOlwtLgmysho5sd8emCWno%2BdMvI%3D&reserved=0>
>>>>         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
>>>>         <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=wZzNNsl2ZNjXzM67tofCckwxNAaxg33WCqbUt0tRi%2BU%3D&reserved=0>
>>>>         twitter.com/davidmacd
>>>>         <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=fjlhSqeBi2VZZrqvDlUGZeGn3okKXwtzxTqtBlc8RIk%3D&reserved=0>
>>>>         GitHub
>>>>         <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=r0U1EYnYUA6SXDgxUUMWdeDUYQ8Futw7Wm6Al5D2rXE%3D&reserved=0>
>>>>         www.Can-Adapt.com
>>>>         <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=rtQrKeXal3mxWlX23DgLYIbu8TAXPrVAMOpXxO4jAKg%3D&reserved=0>
>>>>         /  Adapting the web to *all* users/
>>>>         /            Including those with disabilities/
>>>>         If you are not the intended recipient, please review our
>>>>         privacy policy
>>>>         <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=D69z1TP%2F8KfarxJ0E8idZJ36zqZAIqta6OMSnBHMGNU%3D&reserved=0>
>>>>         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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fcommit%2F19ac37387f3c8a82c5d3838b9fa5327b28b37dab&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=Ya3UVY8KkJm8nDNE0K%2Bi8hg6VDLezakJz4j2pZT%2FjRg%3D&reserved=0>
>>>>             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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FGL%2Fwiki%2Findex.php%3Ftitle%3DWCAG_2.1_QA_Checklist%26diff%3D8139%26oldid%3D8109&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=pot%2F6MWM0lrOtLncs4oHEd5qZKrLkW%2FDKwwWdLSYb6E%3D&reserved=0>
>>>>             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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c.github.io%2Fwcag21%2Fguidelines%2F%23content-on-hover-or-focus&data=02%7C01%7C%7Ca61175799de44e587f4408d4f962814d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636407648852661289&sdata=Bi4LTkAeLyv6FS9FT7wu5p1u%2BYrPijto56wj9XcWM4o%3D&reserved=0>),
>>>>             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:54:18 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:16 UTC