Recommendations / Best Practices

[rachaelbradley]

UPDATE: This was discussed in the Jan 28th Meeting. The outcome was that sub-groups should gather any examples of provisions which could fit into the "best practices" scenario.

---

Gregg proposed that in addition to assertions, we explore adding in recommendations to encourage readers to pick up best practices.

This GitHub discussion is to explore the idea of adding recommendations.

[rachaelbradley]

[Chair hat off]
@GreggVan As I understand it, you are suggesting that under a high level outcome statement, there could be:

• Requirements
• Assertions
• Recommendations or best practices

I suggest that we could instead have Requirements and Recommendations. The assertions would be part of the conformance statement to say which recommendations were followed. This approach might solve some of the issues we've been seeing as we build guidance where the same procedure (AT testing, style guide, end user testing, plain language review, etc) would support multiple outcomes.

Can you provide some examples of recommendations that couldn't be supported by an assertion?

[bruce-usab]

Gregg's email to the list, Organization of W3 provides some additional context. Personally, I am still processing... Thank you @rachaelbradley for moving to a GitHub discussion.

[GreggVan]

@rachaelbradley
Hmmm

• You could put assertions under recommendations...
• but I worry that it might either limit assertions to things that can go under recommendations (when I see many - like user testing - that do not belong to any one recommendation
• also I worry that we might end up twisting recommendations into something that is less readable and understandable in ordr to make work with an assertion.

I suggest we keep them separate to start with -- with Requirements and Assertions being testable -- and recommndations allowing any advice - whether testable or not.

Then after we have them all defined and written up, we can see whether or not assertions can easily pair up with the recommendations or not.

[wareid]

Gregg's email was a good primer to get my head into this, and I find myself agreeing with Rachael's proposal. Once I tried applying Gregg's suggested model to an outcome I realized it's much simpler than it sounds, and adding too many subsections to an outcome could make things complex. My understanding of this is that Recommendations would allow for an extension beyond the existing Methods in an Outcome. Recommendations could include assertions, which I'm understanding as procedures that might document processes to meet an Outcome, but they could also contain best practices, or references to other outcomes that contribute to the overall accessibility of a product.

Just for the sake of visualizing this:

• Outcome
• Requirement
  • Methods
• Recommendations
  • Assertions
  • Best Practices
  • Related Outcomes

[mraccess77]

In WCAG 2.x we have advisory techniques that are not required but best practice. I agree we should continue to have these best practices 1) as they communicate how you can go beyond and 2) they make clear that some items are not covered by the requirement but go beyond.

[GreggVan]

@wareid wrote

• Outcome
• Requirement
  • Methods
• Recommendations
  • Assertions
  • Best Practices
  • Related Outcomes

A few comments on this.

1 - Requirements and Recommendations should be under Outcome - not alongside (I think that is what you intended)
2 - Assertions are testable and recommendations are not - (or don't have to be) so putting testable under a recommendation.... could work but is kind of strange. I can see the rationale for it "We recommend this but it is not testable -- but if you make an assertion that you did it - the assertion is testable"

Comments on Assertions under Recommendations
1 - the assertion won't be the same as the recommendation but rather would be only 'related'. If you think about it and try some you will see what I mean.
2 - Assertions also need to have their own home (in addition to appearing under Outcomes) since some (many?) will relate to many different outcomes. "We do user testing" " include accessibility as part of our regular QA suite" "We treat accessibility like security and is checked at all levels security is" "We don't release without level X of accessibility" etc.

What do you mean by "Related Outcomes"? Is that like "See also....xxx"

I suggest a flatter organization for now -- and only look at placing Assertions under recommendations later when we have them all in front of us and we can see whether or not the assertions pair up well with recommendations or not. We could always tuck one underneath the other later, but if we try to tuck him under too soon, I'm afraid we will end up bending one of the other out of shape to try to make it fit under the other.

Outcomes

• Requirements
• Recommendations
• Assertions
• (any notes and "see also"s.

Methods should not be in the guidelines document because they would be too numerous and need to be able to change, be added to, etc. much more frequently than new issuances of the guidelines.

[rachaelbradley]

[chair hat off] I was suggesting:

• Outcome
  -- Requirements
  --- Methods
  --- Recommendations
  --- Notes & See alsos

Separate section on Assertions as a way to document meeting Recommendations

[alastc]

[chair hat off] Thinking about the conformance models, most of which have a baseline set that must be included and an enhanced set that are scored: Any enhanced requirements, recommendations or assertions should be in a flat list. Otherwise they cannot be used to score.

So I think it would be structured as:

• Outcome
  • Baseline Requirements (with decision tree to pass/fail)
  • Enhanced Requirements (things which are testable but not part of the baseline)
  • Enhanced Recommendations
  • Assertions

[detlevhfischer]

@GreggVan has repeately stated that assertions are testable.

I wonder if I understand that correctly.

What is certainly testable is that an assertion is being made somewhere, on some page. But is that enough?

If we include assertions as contributing to conformance, wouldn't we need some way of testing that the assertion is actually correct, and impacts the content under test? This would often be difficult, I think.

[iadawn]

Might be worth revisiting the Assertions discussion on this point. Particularly the clarification from Gregg

[GreggVan]

Ah this is part of the confusion. You can check that the assertion has been made. Finding the assertion is in fact a proof that it has been made. There is no test that it has been done. You have to understand and rely on ISO 9000 and 9001 for that since they require that if you make an assertion - it is true. And companies very much worry about ISO 9000 since it is basic for business credibility.

re that it did any good. This is not what an assertion says. you can DO user testing. you can DO inclusive design. You can include people with disabilities in your team. And one would hope they would all lead to more accessible designs. but you can't prove they did unless you have a pre- and post- design and compare them. And remember that you are using assertions only when you cannot test the underlying thing in the first place. So how can you have a test of whether the assertion resulted in what you want -- if you can't test what you want in the first place?

Assertions are to help people move and think in the right direction when we cannot provide a testable measure of movement in that direction.

[ChrisLoiselle]

I'm not entirely sure if we've cross referenced the work of ACT https://www.w3.org/WAI/standards-guidelines/act/ and how that could apply to WCAG 3. If we have, please ignore. If we haven't , please read on. A lot what is listed below also relates to questions raised on my comments within #112. This is a thought exercise on how terminology is used throughout W3C and within the areas of accessibility.

Accessibility requirement , per https://w3c.github.io/wcag-act/act-rules-format.html#accessibility-requirement
An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product. In the context of ACT rules mapping, a requirement can be compulsory or advisory. When compulsory, it has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. When advisory, it is recommended, but not satisfying it does not lead to non-conformance or non-compliance.

There are then conformance requirements, https://w3c.github.io/wcag-act/act-rules-format.html#conformance-requirements and the related secondary requirements https://w3c.github.io/wcag-act/act-rules-format.html#secondary-requirements

There is also the definition of requirement from https://w3c.github.io/wcag-act/act-fr-reqs.html#requirement
Requirement
A requirement is a statement of necessity in a given domain (e.g. accessibility). It can be broken down into a set of conditions.

Loiselle - I know in the past we were wary of the term requirement, however this is used elsewhere in W3C and could be beneficial, especially where we are declaring prerequisites.

Per https://www.w3.org/TR/wcag-3.0/#dfn-outcome - Outcome
Result of practices that reduce or eliminate barriers that people with disabilities experience. Which then maps to https://www.w3.org/TR/wcag-3.0/#outcomes

Loiselle - Are practices = best practices? Are practices = to methods? Are practices = to recommendations? Are recommendations best practices? Can recommendations have methods per the other related comments in this discussion thread?

Same term, used a bit differently in ACT Rules , https://w3c.github.io/wcag-act/act-rules-format.html#outcome

Outcome
A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target.

Also related outcome Property per https://www.w3.org/TR/EARL10-Schema/#outcome
Outcome - the outcome of performing the test.

3.3.1 Outcomes per https://www.w3.org/TR/wcag-3.0/#outcomes
Outcomes are verifiable statements that allow testers to reliably determine if the content being evaluated satisfies the user needs identified in the Guideline. All outcomes and assertions that relate to a Guideline will be listed together to encourage adoption of higher levels of accessibility.

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.

Loiselle - How could someone test an assertion that a company has a style guide and that style guide has accessibility requirements built in to it? Do they need to request that to test against it to confirm the assertion is valid? What if the style guide is proprietary and company does not want that shared?

Testing assertions per https://www.w3.org/TR/wcag-3.0/#testing-assertions

The quality of an assertion can be tested based on how well the assertion meets the documentation requirements for assertions (See Documenting Assertions). Conforming to WCAG does not require testing supporting documentation; however, organizations may decide to adopt additional documentation requirements based on the procedure being asserted.

Loiselle - What if the documentation is web based and considered part of the product, wouldn't that fall under WCAG?

Each outcome is associated with at least one method. Methods are informative and kept in how to documents. Each method contains techniques for meeting the outcome, examples, resources, and sets of tests for evaluating the outcome. Methods can apply to a specific technology, such as HTML, or can be more generic where the advice applies no matter what technology, such as the methods supporting the Clear Language 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.

Method
Detailed information, either technology-specific or technology-agnostic, on ways to meet the outcome as well as tests and scoring information.

Similar term used in ACT Rules, https://w3c.github.io/wcag-act/act-rules-format.html#implementation

Implementation
An accessibility test methodology or test tool, containing a set of checks which can be used to determine (non-)conformance of accessibility requirements.

Set of Tests
A group of tests that supports a method.

Test
Mechanism to evaluate implementation of a method.

[GreggVan]

I suggest an update to the terminology in ACT

Currently you have requirements as being required or recommended (", a requirement can be compulsory or advisory.") This is not the usual use of the term in any standard.

Normally you have

• Requirments (that are required) (and normally use Shall or Must)
• Recommendations (that are encouraged - recommended) (and use Should )
• Notes that are informative (cannot use EITHER Shall or should or must or may since these are all reserved terms for normative provisions

In the W3C nothing is required in the same way as other standards or regulations so they call their standards "Recommendations" -- so it can be a bit confusing. They also ask us to not use shall or should for a similar reason.

But we want our WCAG 2 and 3 to be used by other standards groups so we should not confuse things in our standard or support documents by having "requirements" that are not required.

I SUGGEST

• that we use the ordinary term for things that can be either a requirement or a recommendation, and that is "Provision"
• we would then have provisions that can be required (requirements) or recommended (recommendations).

Much clearer

[GreggVan]

RE Assertions.

The whole reason for Assertions wasis to reinforce non-testable recommendations with something testable.

If it were possible for them to have testable outcomes (from a recommendation-related assertion), then it could have been a requirement in the first place.

So

• assertions are testable (did they make an assertion)
• but the outcome of what is being asserted is not testable
  • (again - if it could, then it could have been a requirement, and there would be no need to back it up with an assertion.)

So yes - - Assertions are testable. But the only thing you can test is that the assertion has been made. There is nothing beyond that that is testable. (Unless we want to create assertions for our requirements but there is no need for that - since they are already testable).

[rachaelbradley]

[chair hat on] For anyone responding, if possible, please add your comments to the assertions discussion to make it easier for others to find and track.

[shawna-slh]

Unfortunately "recommendation" is best avoided within W3C documents because W3C standards are called "W3C Recommendations". We already have challenges with people understanding that Web Content Accessibility Guidelines (WCAG) 2.2 is a "W3C Recommendation" which is an international Standard.

If WCAG 3 used "recommendation" for things that are not required, there could be significant confusion with the whole document being called a "Recommendation".

image alt: screen grab of https://www.w3.org/TR/WCAG/ with arrow pointing to "W3C Recommendation 12 December 2024"

[bruce-usab]

This is an excellent point. FWIW, with 2.x, I have also experienced some friction from "guidelines” being in the title and as the middle level of the hierarchical organization (between Principles and Success Criteria).

[rachaelbradley]

Summary 16 January

This thread shows general support for including optional practices in some form.

• Gregg proposed recommendations in Organization of W3
• Shawn has requested we use a word other than "Recommendation" so we will use Best Practice as a placeholder. Jon Avila also used the term "Advisory techniques"
• Chris provided a cross reference of [ACT work](cross referenced the work of ACT https://www.w3.org/WAI/standards-guidelines/act/ )

There was a short discussion on the difference between Assertions and Best Practices. Before going further, chairs suggest we explore the differences with examples between:

1. Supplemental Requirements
2. Assertions
3. Best practices.

For the 21 January meeting, please reply to this comment with examples of assertions and best practices.

[rachaelbradley]

(Chair hat off)

Background Thinking

I am not sure about the difference between assertions and best practices. In my opinion, if an item is testable and applies in definable situations it should be a supplemental requirement. One option might be to list specific best practices with the guidelines and then includes assertions as a separate section of the document.

Examples

Alt text

Best Practices

1. Order Alt text - When similar elements are repeated (edit buttons) place unique information towards the beginning of the accessible name (photo edit button, name edit button, etc.).
2. Punctuation in alt text - Use correct punctuation within alt text

Assertion
Style Guide - We provide and test against a style guide which includes the following best practices:

• Order alt text
• Punctuation in alt text

[ChrisLoiselle]

I know we tend to stay away from analogies, however the game of basketball helps contextualize this:

1. Supplemental Requirements - Not sure where this fits, requirements are needed or they are not.
2. Outcome - I'd like to play the game of basketball (at a high level).
3. Requirements- A basketball and a basketball net.
4. Methods - Dribbling and shooting.
5. Recommendations - A basketball court and a backboard are preferable , however not entirely required. For example, a pick up game in a driveway could do.
6. Assertions - I do practice dribbling and shooting with both hands every Tuesday for 30 minutes.
7. Best Practices - I reinforce my skills that I asserted by practicing dribbling and shooting with both hands every Tuesday for 30 minutes.
8. Related Outcomes - I get better at the game. If I assert something prior to the game and incorporate in to my game, it will showcase in the game. If I assert something and it is false (I didn't practice), it will showcase in game as well, in the form of errors (turnovers via dribbling off my knee or shooting air balls (missing the basketball net and throwing the ball out of bounds).

[alastc]

I am not sure about the difference between assertions and best practices.

(Chair hat off) To me the best-practices are requirements that are not universally applicable, to the extent that we cannot even provide a cut-n-dried scenario for when they would apply. There is so much subjectivity about when you would apply a best practice. Or, they are in the "nice to have" category", building on other requirements in a more specific way.

Compared to assertions, they are more specific with particular techniques than an assertion. An assertion would walk you through the process of creating your own best-practices for your situation.

For example in alt-text:

• Requirement: non-decorative images have a description.
• Best practice: Images that are part of a wrapper which also include a title and a link have null alt text, if the linked-page includes the full size image with alt-text.

Or for headings:

• Best practice: If your homepage includes a logo of the organisation and there is no visual heading that includes the name of the organisation, you can wrap the logo in an H1 to act as the label for the page and the website.

I wouldn't fail a site that did not do either of those best practices, but if I were starting from scratch that's what I'd recommend.

[lauracarlson]

Chris said, "Supplemental Requirements - Not sure where this fits, requirements are needed or they are not." Would a "supplemental requirement" be an additional requirement that complements or completes the main set of requirements? What would be the rationale for not including supplemental requirements in requirements? Is it a type of Supplemental Guidance Ala WCAG 2X?

[alastc]

Hi Laura, if you remember the discussions on conformance model, we've got "foundational" and "supplimental".

The foundational ones all have to be met for basic conformation. From the conformance section of the explainer:

Higher levels of conformance will be defined and met using Supplemental Requirements and Assertions. AG will be exploring whether meeting the higher levels would work best based on points, percentages, or predefined sets of provisions (modules).

So they are not different in form (i.e. both should be testable), but they are different in how they are used in conformance.

[lauracarlson]

Thank you @alastc.

[alastc]

This was discussed in the Jan 28th Meeting. The outcome was that sub-groups should gather any examples of provisions which could fit into the "best practices" scenario.