- From: Jeanne Spellman <jspellman@spellmanconsulting.com>
- Date: Tue, 10 Mar 2020 18:00:09 -0400
- To: Silver Task Force <public-silver@w3.org>
- Cc: John Foliot <john.foliot@deque.com>
- Message-ID: <63911e16-032d-535e-1dd2-6836d806f3b5@spellmanconsulting.com>
[resending because I belatedly saw it was sent to the list] Just FYI, John, we have not put a lot of work into the wording of the guidelines. It was not important to the structure and what we were trying to build to show people in the FPWD. Our priority was to get the tests and Methods done and the Guideline was largely a placeholder so there was some text in the spot in the structure. I have no problem with building out the Guidelines more, as long as they are imperative, easy to understand, and in plain language. I could see doing it Alastair's way, or even rewording the Guideline to be more specific. I'm open to a lot of ideas and we had quite a few good ones today. I started messing around with your design for Headings minimums. I think that's a cool idea that could flow down to the Scoring in a way that could provide good info for organizations. I like it much better than the one I put together. I know from TPG days that a lot of people walk in the door wanting to know how they look for a particular disability. It's a good report to give the CEO. There are some interesting opportunities for tool companies. jeanne On 3/10/2020 9:47 AM, John Foliot wrote: > Hi Jeanne, > > All of the plain language examples we've seen to date lack enough > specificity to be a normative requirement IMHO. > > Take Clear Language. > The current "Requirement" states: /Use clear language to make it > easier for readers to understand. / > > Without a clear metric to measure that however, it is a meaningless > ask, as nobody will be able to effectively evaluate whether or not the > goal has been met: I can claim it's clear and easy to understand, you > can claim it's not, and then what? > > (I'll note that the current draft example > <https://docs.google.com/document/d/1LfzTd_8WgTi0IUOOjUCRfRQ7e7__FRcnZow4w7zLlkY/edit#> > has, as a "requirement" the following: "Remove unnecessary words" - my > question is, unnecessary to whom? The end-user with a University > degree reading level vocabulary, or the end-user with a Grade 6 > reading level vocabulary? Would this be "better": "Use clear language > - make easier understand" - there, I removed "unnecessary" words... > Additionally, that very much feels like an "English" language > requirement, but does that apply to all languages? Spanish is > significantly more 'compact' than English, with different grammar > rules - "rules" that already remove superfluous words, so I will argue > against that measurement rule as being too English-centric) > In the context of the W3C being a place where we create STANDARDS, I > will suggest that the "normative" parts are the measurable > standardized parts, everything else is backgrounder and explanation > and non-normative. Merriam Webster backs me up: > > ***Normative > <https://www.merriam-webster.com/dictionary/normative>*: of, > relating to, or determining norms or _standards_ > > *Standard* <https://www.merriam-webster.com/dictionary/standard>: > something set up and established by authority as _a rule for the > measure of quantity, weight, extent, value, or quality_ > > I fully appreciate that today there remains a fair bit of subjectivity > to our evaluation process (what, exactly, is appropriate alt text?), > but it seems to me we should be trying to squeeze out the > subjectivity, not add to it. A vaguely worded, hard-to-measure > "normative" requirement is, frankly, an oxymoron IMHO. > > > JF > > On Mon, Mar 9, 2020 at 5:48 PM Jeanne Spellman > <jspellman@spellmanconsulting.com > <mailto:jspellman@spellmanconsulting.com>> wrote: > > It could also be the guideline itself. It's clear and it wouldn't > take much to make it plain language. > > > On 3/9/2020 6:10 PM, Alastair Campbell wrote: >> >> Hi everyone, >> >> It was an interesting conversation on the normative/informative >> aspects in silver / WCAG 3, I just wanted to provide an example >> for consideration. >> >> We have a sliding scale of granularity, from least granular to >> most granular: >> >> * WCAG 2.x Principle (a categorisation tag) >> * WCAG 2.x guideline >> * Silver guideline >> * WCAG 2.x Success criteria >> * *(Current informative line)* >> * Silver Getting started / WCAG 2.x Understanding >> * Silver methods >> * WCAG 2.x Techniques >> >> My main points were that: >> >> * ‘normative requirement’ does not need to equal ‘testable >> statement’, they can be different things. >> * The more content that is normative, the more that has to go >> through a more complex process. >> >> So my suggestion was to add something concise between the >> guideline and method level. >> >> Taking a concrete example, e.g. Visual contrast of text >> <https://raw.githack.com/w3c/silver/ED-draft=comments-changes-js/guidelines/index.html#visual-contrast-of-text>, >> the ‘normative’ bits could be something like: >> >> *2.3 Visual Contrast of Text* >> >> Provide sufficient contrast between foreground text and its >> background. >> >> Text meets the _Advanced Perceptual Contrast Algorithm_ unless it >> is _incidental_. >> >> The last line could be behind a show/hide, or styled differently, >> or be in the top line of Getting started. The links would go to >> the evaluation tab and a definition of incidental. It could also >> be much longer if that was easier to understand. >> >> Or for clear language: >> >> *2.2 Clear Language* >> >> Use clear language to make it easier for readers to understand. >> >> Ensure that text content follows the _principles for plain >> language_ by editing it to match, following a style guide, or >> testing and updating it. >> >> I hashed that together from the “How” and the method information. >> >> To address another issue around the complexity of language: If >> the normative language is not constrained by being a very concise >> testable statement it could be longer and easier to understand. >> Adjusting some of the ‘how to’ material could also be the >> solution, and marking that as normative. >> >> Another aspect is that some ‘normative requirements’ could be >> process based, e.g. When creating or updating navigation a >> user-centred design approach is included. That might be a >> silver/gold (or whatever the terms are) criteria compared to WCAG >> 2.x, but I don’t see that as a problem for ‘normative requirements’. >> >> Cheers, >> >> -Alastair >> > > > -- > *John Foliot* | Principal Accessibility Strategist | W3C AC > Representative > Deque Systems - Accessibility for Good > deque.com <http://deque.com/> > >
Received on Tuesday, 10 March 2020 22:00:21 UTC