What levels should be normative?

[rachaelbradley]

This discussion is an item by item discussion of what should be normative within WCAG 3.

• Normative content is required for conformance. It is difficult to change.
• Informative content is provided for information purposes and not required for conformance. It is much easier to change.

Parts of WCAG

Below is a list of the WCAG 3 structure with definitions:

1. Guideline
   • High-level, plain-language content used to organize outcomes.
   • Guidelines provide a high-level, plain-language version of the content for managers, policy makers, individuals who are new to accessibility, and other individuals who need to understand the concepts but not dive into the technical details.
   • They provide an easy-to-understand way of organizing and presenting the outcomes so that non-experts can learn about and understand the concepts.
   • Each guideline includes a unique, descriptive name along with a high-level plain-language summary.
   • Guidelines address functional needs on specific topics, such as contrast, forms, readability, and more.
   • Guidelines group related outcomes and are technology-independent.
2. Outcome
   • Verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline.
   • Outcomes are written so that testers can determine the accessibility of technologies based solely on the outcome, even when methods do not yet exist for those technologies.
3. What/Where/Why Statement (Proposed)
   • Proposed way of writing an outcome or supplementing an outcome written as a statement
   • Alternative way of writing based on EN 301 549 “Conditional Clauses/Requirement/Notes
4. Method
   • Detailed information, either technology-specific or technology-agnostic, on ways to meet the outcome as well as tests and scoring information.
   • Example information: Introduction, description, examples, tests, resources
5. Test: Mechanism to evaluate implementation of a method.
6. Technique: Technology-specific approach to follow a method
7. Assertion: A formal claim of fact, attributed to a person or organization. An attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility.
8. User Need:The end goal a user has when starting a process through digital means.
9. How To
   • Advice written in plain language, including information on how to get started with accessibility
   • Originally at Guideline level
   • Example information: Get Started, Plan, Design, Develop, Examples, Outcomes, Resources
   • In early phases, will include research references

Instructions

• There is a comment for each part of WCAG and asserted in that comment that the item is normative.
• Please respond with a thumbs up if you agree the item is normative and thumbs down if you believe the item is informative. Respond to the comment for that item with reasons for your opinion.
• If you are unsure, please mark the item with the eyes icon to indicate your reviewed it.
• Do not reply to then entire thread. I will copy comments to the thread into the appropriate comment and then delete the original.

[rachaelbradley]

Guidelines are Normative.

Note: Guideline are high-level, plain-language content used to organize outcomes)

[jspellman]

I like Detlev's proposal at the 2/20/24 meeting that the guidelines be normative and there are a variety of outcomes, tests and assertions be the way to meet that guideline. Regardless of whether we use that proposal, having a normative guideline has potential.

[detlevhfischer]

@jspellman Maybe I misspoke - I was mainly concerned about the overall complexity of the new structure with its many nested levels, whereas now, one technique has exactly one test (which may run through several conditions). I am in favor of Outcomes as intended level for conformance, and I am just not sure whether the aggregation up to the Guideline level to determine wether it normatively "passes" or "fails" can work.

As formulated now, Outcomes are already fairly non-specific and could have any number of methods below them. So even on the Outcome level it is not easy to define, via some sort of OR or AND aggregation, what authors need to do to minimally pass an Outcome. Just to grab one draft Outcome from the current sort excercise:

"Related content: Related content (i.e. sub-content, meta-content, and editorial content) and its context or relevant order is presented in an order that supports understanding the content. (168)"

This applies to many different types of content. It would likely include checks of default source code order, other checks whether dynamic content is inserted at the right place, and probably alternative ways of passing for some types of content.

How to keep it all manageable to me seems to be the biggest headache in WCAG 3.

[GreggVan]

I think what exists at outcome level - will change - or at least clarify - once we decide on what that level means. Bit of chicken and egg here I think

[rachaelbradley]

Outcomes are Normative.

Note: Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline.

[rachaelbradley]

What/Where/Why Statement (Proposed) are Normative.

Note: In this discussion Where/What/Why statements are proposed ways of supplementing an outcome written as a statement

[alastc]

@GreggVan in WCAG 2.0 the "guidelines" are normative, despite being categories. Does that matter?

Taking image alternatives, if the outcome is "Provide a text alternative for decorative and informative images", that's pretty wide. (Sidenote: I just copied it from the current list, but I think it should be re-written to something like "Assistive technology can find text-descriptions for each image which conveys information, and images that are decorative are hidden from assistive technology", depending on which approach we take.)

Within that, we could have methods at different levels, e.g.

• At bronze, all images have a description or are hidden.
• At silver, non-decorative images have an 'equivalent' description, so adding a quality aspect.
• At gold there could be some assertion that you have taken site-wide action to ensure reasonable alt text (e.g. a process for applying descriptions to your e-commerce product library with millions of images.)

It is a lot easier to make the method (or what/where/why) more specific and testable than the wider, more abstracted outcome.

Essentially I'm arguing that (in WCAG 2.x terms) the SCs should be allowed a little vagueness but then add a more specific (normative) level underneath, between the SC and the techniques.

[GreggVan]

@alastc What makes you think the guidelines are normative? Only the SC and definitions of terms in SC were normative. Are you referring to the comment "This section is normative" at the top of the section? that is confusing but clearly that does not mean everything below that comment since there is a paragraph of intro then the principles and guidelines and how to meet links and more.

only the provisions are normative. This could /should have been clearer but clearly the guidelines are not requirements and therefore are not normative. And never were intended to be.

those notes at the top of the section were unfortunately badly worded. better would be "The SC in this section are normative"

[alastc]

Well, in my time we've been going from the description and assuming everything (except notes) are normative within the guidelines sections. Something we can learn from and be more specific in WCAG3.

So the question then: Is it harmful for Outcomes + Methods (for example) to be normative together? So the outcome can be quite wide, not necessarily testable on it's own, but testable in combination with the methods.

[GreggVan]

Usually there is only one level normative.
Also - methods sound like that -- they are methods and should be in the HOW category, which is not what we want to "require". we want to require OUTCOMEs and allow methods to change over time.
Now you might want to cite some method as "safe harbor". if you do this it would pass but you aren't required to do it this way

[yatil]

@GreggVan

What makes you think the guidelines are normative? Only the SC and definitions of terms in SC were normative.

This is untrue. In the 5.1 Interpreting Normative Requirements section (which itself is normative), it says:

The main content of WCAG 2.2 is normative and defines requirements that impact conformance claims. Introductory material, appendices, sections marked as "non-normative", diagrams, examples, and notes are informative (non-normative). Non-normative material provides advisory information to help interpret the guidelines but does not create requirements that impact a conformance claim.

If only SCs were normative, then the Conformance Requirements were not normative. But it is the whole document that’s normative, apart from the marked and named sections.

[rachaelbradley]

Methods are Normative

Note: Methods are detailed information, either technology-specific or technology-agnostic, on ways to meet the outcome as well as tests and scoring information.

[dbjorge]

I thought @alastc brought up a good point on the Feb 20 call that we've had issues in WCAG 2 where we had trouble creating certain SCs we wanted because there was no normative means of specifying something technology-specific, which makes me lean a bit more towards "have at least one level where we can talk normatively about technology-specific requirements" (probably methods), even if we decide that individual tests for those technologies shouldn't be normative

[GreggVan]

I don't understand what you are referring to. we didnt have any trouble that I know of. if you wanted to make something technology specific you could just name the technology in the SC. But we specifically didnt want to make anything technology specific. if you make anything normative that is technology specific -- then by definition you are requiring people to use that technology and no other (or they cannot conform). I don't know why we would ever want to do that.

if you want to say "if you use this tech - then do this" that is ok. And we did do that with markup languages

a much better place for tech specific things is in Techniques where they can be 'safe harbor'. (here is an accepted way to do this on this technollogy)

[chaals]

I think it makes sense to have normative methods that as @GreggVan says are "safe harbour". In other words, provide guidance that says "if you do this, in that situation, it will provide this outcome as required". That requires the group to get opinionated, to agree on stuff, and to have a process for revising those things in light of discussion at a reasonably fast pace.

If we took this path, "Methods" would be content that could (and probably should) otherwise be used as non-normative "where/what/why". The difference would be that the group has formally agreed that a particular Method actually provides a pathway to the outcome that developers can rely on.

[alastc]

I don't understand what you are referring to. we didnt have any trouble that I know of. if you wanted to make something technology specific you could just name the technology in the SC. But we specifically didn't want to make anything technology specific.

My point in the meeting was that if a normative requirement has to be applicable across all technologies, and a platform or technology does not provide a way of achieving it, then it would be filtered out.

We've had issue incorporating EPUB accessibility because it uses (underneath) XHTML and CSS, but the page model really doesn't apply in the same way. There are several good EPUB accessibility criteria we could not include because they would also impact websites.

Hypothetically, if we had done an update in 2010-2015 to apply guidelines to mobile apps, there was no mechanism for doing headings. Therefore we'd have needed a exclusion for mobile apps, or throw out 1.3.1.

Not all platforms are useful for all people, e.g. audio+voice devices for people who are deaf. I think we need to allow for normative differences across platforms/technologies so that the ways of achieving an outcome can be radically different. It will allow us to highlight gaps as well. For example, if you rely on reflow for reading and a particular platform doesn't support it, that might be a gap highlighted by applying the guidelines.

[mraccess77]

I agree that general methods should be provided that are not technology specific to the outcome that can be used in situations where there is not a technology specific situation.

[rachaelbradley]

Tests are Normative.

Note: Tests are Mechanism to evaluate implementation of a method.

[jenstrickland]

I would expect tests to be normative as they would be Must, Should, or May, however the folks with the thumbs-down have me curious what I may be missing.

[scottaohara]

i'm wary of saying tests should be normative and thus difficult to change. For instance, something that may not be possible or even valid with HTML/ARIA may change. There are some features being worked on now that come to mind.

[GreggVan]

@jenstrickland - if you make a test normative - you a) can't test in any other way and b) every author has to run that test on their content. but that doesnt make sense. Running the test doesnt make the page more accessible.. So why running the test would be required for conformance doesnt make sense even if it is a good idea to. (that is what normative means).

[chaals]

I suspect that there should be both normative and non-normative tests.

[rachaelbradley]

Techniques are Normative

Note: Techniques are technology-specific approach to follow a method

[u9000-Nine]

I feel like insufficient techniques (AKA failures) should be normative. In 2.x they're not, which allows people practicing adversarial conformance to claim they conform even though they're using a known insufficient technique.

[mraccess77]

In WCAG 2.x you can fail a failure technique but still conform if you use another sufficient method to pass the criterion. Because of that, I don't think we can make techniques normative as there are so many ways to meet the requirements and sometimes you can use both a failing and sufficient technique in combination.

[chaals]

See my comment on methods. I think we're creagting complex and arbitrary divisions here, but in my mental model I consider techniques as non-normative explanations of methods that can provide more detail. They might also just be the same as "where/how/why" and so be unnecessary as a separate category - in which case I might be inclined to keep techniques as the name since that is familiar to about a generation of people who have engaged with WCAG.

[detlevhfischer]

I was under the assumption that Methods are in WCAG 3 what Techniques were in WCAG 2.X. Is this deeply nested proliferation of levels really necessary? I think it is quite confusing.

[alastc]

I don't think making techniques normative is the right solution to adversarial accessibility, it would be like carrying 10kg worth of bike chains and locks around all the time just in case you have your bike and leave it in a high-crime area. (Non-metaphor translation: A lot of effort and it probably wouldn't solve the problem anyway.)

If there is a level of guidance that is basic enough to be binary true/false and not super-complex, there will be gaps and niche cases where people can pass in unusable ways.

I think the best solution would be to have a (required by regulation) level of guidance that is more manually tested, more subjective (but better specified for this purpose than current SCs), and oriented towards practical & usable accessibility.

[rachaelbradley]

Assertions are Normative.

Note: Assertions are a formal claim of fact, attributed to a person or organization. An attributable and documented statement of fact regarding procedures practiced in the development and maintenance of the content or product to improve accessibility.

[jenstrickland]

Assertions may be normative, but I could also imagine they could be informative. Is there a sideways thumb?

[detlevhfischer]

I can't see how assertions (such as "we did this kind of user testing") could fit into the normative/informative scheme. You may assert all sorts of things and the processes referenced are likely to evolve, be replaced etc. - so how could a benchmark for normative assertions be defined (in an international context)?

[GreggVan]

I voted hurricane -- because it is sorta normative.
it is testable ---(did they make the assertion)
and I GUESS we could require assertions . but some companies can't make assertions (lawyers won't let them) So it may have to not be at basic level.

[rachaelbradley]

User Needs are Normative.

Note: User Needs are the end goal a user has when starting a process through digital means.

[chaals]

I think these should be normative in the text - i.e. you really do have to solve these problems. Although they are not obviously testable and actionable without a lot of work, for example by following through the techniques and implementing things that can be described at the outcomes level, it seems important that this is a clear and agreed basis of requirements.

[GreggVan]

@chaals To be normative it has to be testable. To be normative means that you must do these or you don't pass the standard
--and anything that refers to a meeting a user need would require that you name the user (or users) and then confirm that their needs are met. No?

I love / endorse that all our work all be user-need based (our work starts with user needs) but I think it needs to end with us saying what we think needs to be done or be true about content -- not true about users -- since a company would not know how to verify that that user or those users needs were indeed met. And then again is the fact that not all users' needs will ever be met. For example seizure disorders. Some people can be triggered by extremely small or short stimuli. For that provision, it would have to not have any movies to be sure that the needs of all users with seizures are met.

again - we start with user needs. And then we determine exactly what should be true -- what is the minimum that an author needs to go to pass. (And we should remember that WCAG is a minimum accessibility standard -- not the most you should do but the absolute least you should do. And I think we need to do more with saying what more would be better. That was the focus of the proposal that was presented at the TPAC before last. That I think should be the magic that is W3. That we have the information and the motivation to work beyond the minimum requirements.

best

[chaals]

All IMHO... @GreggVan wrote

To be normative means that you must do these or you don't pass the standard...

Yep. That's why we make the core things normative - conforming to the standard is about meeting a set of requirements. And the highest level expression of those is normative statements about what users need. For example:

"Users need to be able to understand and interact with all content."

--and anything that refers to a meeting a user need would require that you name the user (or users) and then confirm that their needs are met. No?

As individuals, no you don't need to name them. It is helpful to describe them in order to explain the needs in a more granular fashion.

"Some users have difficulty hearing, or cannot hear. It is therefore necessary that understanding of the content, and successful interaction with it, does not rely on audio material."

And then you can describe specific things like "Ensure that all warnings are presented to users without requiring the use of sound"...

(This exposes the limits of what we mean by "normative", and gets into the weeds of specification quality, supporting materials, ongoing management and adjudication, etc. To a large extent we can and in this exercise perhaps will make our decisions where we draw what are ultimately arbitrary distinctions. That doesn't mean we are unable to agree on "great" and "terrible" ways to solve a problem, just that at the edges we might have minor disagreements on specific aspects of finer detail.)

[mraccess77]

I share the same thinking with Gregg that if user needs are normative then either some or all users will have to meet them to be met.

• If some users with a specific disability are able to meet the criterion without the site actually doing being accessible that can allow a pass without substantially doing anything
• If all users with a specific disability need to be able to do something then that will never be possible.

[rachaelbradley]

How To content is normative

Note: How To content is advice written in plain language, including information on how to get started with accessibility

[u9000-Nine]

Note from meeting: This is analogous to the 2.x understanding docs

[u9000-Nine]

I feel like the part of the How To content which elaborates on the intentions and details of the guidelines/methods/outcomes/etc should be normative because that influences how people implement and test them.

[GreggVan]

Hmmm Understanding is more like WHY
How to - is more like techniques I think....

[chaals]

I don't see any difference between this and where/what/why.

[detlevhfischer]

@chaals where/what/why: I think what the 'where' means is simply a conditional clause as in Annex C of the EN 301 549, checking whether the requirement appies, as in "Where a video has visual information not covered in the audio, it needs AD" - else not applicable.

[rachaelbradley]

Meeting Minutes from from Discussion
Next Step: Work on Outcome and revisit