Find a consistent phrase to use in Understanding documents for recommended approaches

[mbgower]

As per the discussion in today's AGWG, the group wishes to arrive at a consistent phrase to use

The location in a smaller viewport may be different than in a larger viewport but it is best if the mechanism or link is consistent across a set of web pages. A consistent location, both visually and programmatically, is the most usable.

Suggestions included "Best if, Prefer, Recommended, Suggest, Advise"

[mraccess77]

Historically WCAG has used the term advisory for things that are not required - so advise is in line with that. Another term might be ideally.

[patrickhlauke]

Using simple wording would be my preference. Not sure if the nuance of "advise" might work for all readers (and especially non-native english speakers)

[mbgower]

Something that is relevant to this discussion occurs in the preamble to WCAG .21:

The key words MAY, MUST, MUST NOT, NOT RECOMMENDED, RECOMMENDED, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].

That reads, in part:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

I believe "recommended" is the most natural fit, although it does involve the use of the passive voice:

The location in a smaller viewport may be different than in a larger viewport, but a mechanism or link that is consistent across a set of web pages is recommended. A consistent location, both visually and programmatically, is the most usable.

[bruce-usab]

FWIW, if this comes to survey as-is, it will be my recommendation that AGWG avoid recommended in Understanding. That is because, in my experience, it has been difficult to disambiguate our meaning from RFC2119 implications.

Some other standards/guidance documents avoid our particular conundrum via a more rigid approach (e.g., they list musts followed by shoulds — in a single document) but that has not been our practice.

All of Understanding, per the RFC2119 terms and because they are non-normative, are recommended. Designating portions (but not the whole) of a recommendation as a recommendation is problematic IMHO.

My own strong preference is that we continue to characterize things which go beyond the bare minimum requirement of the SC as advisory. The other characterization which I believe has worked well is best practice.

In this case, that could be:

The location in a smaller viewport may be different than in a larger viewport, but it is a best practice for the mechanism (or link) to have a consistent location across a set of web pages. A consistent location, both visually and programmatically, is the most usable.

[awkawk]

My own strong preference is that we continue to characterize things which go beyond the bare minimum requirement of the SC as advisory. The other characterization which I believe has worked well is best practice.

@bruce-usab, why would we characterize something that goes beyond the SC as advisory? If it meets or exceeds an SC then it would be regarded as sufficient as a technique. Things that are advisory are usually good ideas but aren't required to meet an SC, for example https://www.w3.org/WAI/WCAG21/Techniques/general/G141.html for 1.3.1.

[bruce-usab]

Thanks @awkawk — such a good point! Thanks for that correction!

Yes, I agree we use advisory as helpful-but-not-sufficient. I agree that it would be bad to suggest that advisory was going above and beyond the bare minimum. Ping to @mraccess77 since his comment on this thread implies that he also was caught by this!

That said, I think my editorial suggestion (which avoids recommended and didn't use advise) is still okay.

[mraccess77]

I agree advisory may not be sufficient but tangentially related and go beyond related SC.

[alastc]

Yes, I agree we use "advisory" as helpful-but-not-sufficient.

I'd say it is more like: helpful-but-not-required by the SC.

Also to note, we've had complaints (leading to objections) for using MUST/SHOULD style language in understanding documents, they were seen as a backdoor way of adding requirements.

On the other hand, there are SCs where we know that the user-need is not (fully) met by just meeting the normative text. That makes me less comfortable with "best practice".

How about trying to focus on the usability of the outcome? E.g.

The location in a smaller viewport may be different than in a larger viewport, which could cause confusion. A consistent location, both visually and programmatically, is generally the most usable.

The key thing is that the understanding doc is clear about what is normatively required, and what is also helpful (or even necessary from the user's point of view). So perhaps when stating the normative requirement we should use 'must' type language?

[bruce-usab]

How about trying to focus on the usability of the outcome...

That works for me! I think @mbgower was hoping we might land on a phrasing which is closer to a copy/paste approach, but I am optimistic that a usability lens can serve for recommended approaches.

So perhaps when stating the normative requirement we should use 'must' type language?

I agree that, per RFC2119, we may do this. We should not because, historically, the churn defeats any utility those four (may/must/should/recommended) words may have provided.

We do not use must in the body of any SC. The word is used in four SC notes (1.4.2, 2.1.2, 2.2.2, 2.3.1) with their references to CR 5.2.5 .2.5 Non-Interference. It then follows that: If we use must when stating the normative requirement — we are paraphrasing. So I don't think must helps even in that context.

[alastc]

So for our various scenarios (meeting SC, going beyond baseline], we can use formulations such as:

• To meet the criterion the content [has a particular attribute, e.g.] would not move the focus when landing on an input.
• [This attribute of content] is generally more usable for people with [x] disability.

To pick on an understanding doc which includes 1 must and 3 shoulds, this:

Information needed to identify controls does not need to be visible all the time. But information needed to identify controls must be visible when the controls are needed without hover interaction or keyboard focus.

Could be:

"Information needed to identify controls does not need to be visible all the time. However, to meet this criterion information needed to identify controls must be visible when the controls are needed without hover interaction or keyboard focus."

And this:

For a video player, activating the video image should launch the video (sometimes in a new window), at which point more video player controls, including controls displayed previously on hover, should be visible.

Could be: "For a video player where the video image launches the video (sometimes in a new window), at which point the controls, including controls displayed previously on hover, need to be visible." (I'm assuming this is part of the SC requirement, I think it is.)

[fstrr]

@mbgower Can this issue be closed? It seems to relate a branch from January 2022 that is just about updating Consistent Help. If this can be closed, please do that and delete the branch as well. Thanks!