Re: Editorial changes to SC

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

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> 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 <(613)%20235-4902>
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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> 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/#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 <%28613%29%20235-4902>
>>
>> LinkedIn
>> <http://www.linkedin.com/in/davidmacdonald100>
>>
>> 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> 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/19ac37387f3c8a82c5d3838
>>> b9fa5327b28b37dab
>>>
>>> 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_C
>>> hecklist&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), where I changed
>>>
>>> "When content becomes visible when triggered by a user interface
>>> component receiving 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 component which receives keyboard focus or
>>> pointer hover causes 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
>>>
>>
>>
>>
>
>