Re: Extra normative level?

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:

* <https://www.merriam-webster.com/dictionary/standard>**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.

* <https://www.merriam-webster.com/dictionary/normative>*


JF

On Mon, Mar 9, 2020 at 5:48 PM Jeanne Spellman <
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