- From: Michael Cooper <cooper@w3.org>
- Date: Mon, 14 Aug 2017 21:35:06 -0400
- To: David MacDonald <david100@sympatico.ca>
- Cc: John Foliot <john.foliot@deque.com>, AG WG <w3c-wai-gl@w3.org>
- Message-ID: <892d38e0-4644-f77f-9489-dff6ed5732fc@w3.org>
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