W3C home > Mailing lists > Public > public-silver@w3.org > March 2020

Re: Extra normative level?

From: Jeanne Spellman <jspellman@spellmanconsulting.com>
Date: Tue, 10 Mar 2020 18:08:52 -0400
To: Charles Adams <charles.adams@oracle.com>, John Foliot <john.foliot@deque.com>
Cc: Silver TF <public-silver@w3.org>
Message-ID: <39074851-745c-5414-06b0-48954d0a2865@spellmanconsulting.com>
Actually, Alastair did not propose a testable statement.  We know from 
the Silver research that testable statements are very difficult for 
people to understand.  Great for computers, but not so good for people.  
I would be opposed to normative testable statements.  Alastair proposed 
a functional outcome, which is easier to understand.  I want to make 
things easier for the testing companies wherever possible, but not at 
the expense of being able to include nuanced guidelines that COGA and LV 
need.  I don't want to make Silver into WCAG 2.3.

There is a place for testable statements in the informative tests, 
because the testable statements make sense when they are technology 
specific, Process-lightweight, and easily updated for evolving 
technology and disability needs.


On 3/10/2020 3:54 PM, Charles Adams wrote:
> JF, what do you think of Alastair's proposal?  If I understand it, the 
> proposal consists of providing a plain language explanation followed 
> immediately by a testable statement.
> Chuck
> On 3/10/2020 7: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://urldefense.com/v3/__https://docs.google.com/document/d/1LfzTd_8WgTi0IUOOjUCRfRQ7e7__FRcnZow4w7zLlkY/edit*__;Iw!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPntIsVTVrw$> 
>> 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://urldefense.com/v3/__https://www.merriam-webster.com/dictionary/normative__;!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnt1OmocZA$>*:
>>     of, relating to, or determining norms or _standards_
>>     *Standard*
>>     <https://urldefense.com/v3/__https://www.merriam-webster.com/dictionary/standard__;!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnvUcIp21w$>:
>>     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://urldefense.com/v3/__https://raw.githack.com/w3c/silver/ED-draft=comments-changes-js/guidelines/index.html*visual-contrast-of-text__;Iw!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnvFu7TEKQ$>,
>>>     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 
>> <https://urldefense.com/v3/__http://deque.com/__;!!GqivPVa7Brio!K2X5bRVaQPSOBChUaWfTZIqA2Cb7LcCJtGj5Ctzx4o94FanILkCempgZPnvC7-wNoQ$>
Received on Tuesday, 10 March 2020 22:09:05 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 17 March 2020 10:22:07 UTC