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

Re: Extra normative level?

From: Jeanne Spellman <jspellman@spellmanconsulting.com>
Date: Mon, 9 Mar 2020 18:47:24 -0400
To: public-silver@w3.org
Message-ID: <a4c5b28f-f959-c8d9-9b22-e2abc633d413@spellmanconsulting.com>
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
>
Received on Monday, 9 March 2020 22:47:37 UTC

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