RE: Extra normative level?

Hi everyone,

Indeed, I was not saying add ‘testable statements’, although I’m not sure if it would be a functional outcome either.

I was focusing on what the requirement is, and showing enough of that at a top-level to make clear what action is needed to meet it. (John, it did appear you missed that bit, I included it under the horizontal line below.)

In some cases these might look like testable statements (e.g. language of text might fit that), but my main point was that a ‘normative requirement’ can encompass a lot more than a ‘testable statement’.

It could also include:

  *   A reference to an external (to WCAG3) standard.
  *   A reference to a WCAG3 metric (like the colour contrast algorithm).
  *   An action to take, such as implement & follow a style guide.
  *   A process to follow, such as following some UCD technique when updating the navigation.


There is a scale/continuum, and for WCAG 2.x I would say that if you drill into the definitions, understanding, examples, and then back-track to the statement, then you are in a position to treat it as testable. I.e. It does provide the requirement you need to meet, but there are a lot of references you have to understand in order to test it.


That is always going to be the case in some form, there are simply too many granular requirements (that change to quickly) to go into a spec document. We just need to try and draw a line at a useful level of granularity. Above technical implementation details, but below general guidelines.

IMHO the key difference for WCAG3 is the wider metrics. Words like ‘appropriate’ are like kryptonite for success criteria because they are so subjective. However, if you have a percentage metric for heading use (as discussed today) with clear scoring, then having a normative requirement like “Use heading appropriately” becomes achievable.

Cheers,

-Alastair



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’.