Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider using 'should' instead of 'must' in help text for best practices #1491

Closed
mfairchild365 opened this issue Apr 10, 2019 · 8 comments
Closed
Labels
rule metadata Issues in the rule metadata code (lib/rules)
Milestone

Comments

@mfairchild365
Copy link
Contributor

I’d like to propose changing “must” to “should” in best practice rule help text. For example “Document must have one main landmark” would be “Document should have one main landmark”.

Motivation: This would better align with actual WCAG conformance requirements, the way Deque University refers to best practices, and RFC 2119.

@WilcoFiers
Copy link
Contributor

@mfairchild365 I think that's a good suggestion. I'm meeting with Melanie, Glenda and Sujasree to discuss aligning the descriptions of rules with those of the Deque Way. I'll take this on board as input.

@WilcoFiers WilcoFiers added the rule metadata Issues in the rule metadata code (lib/rules) label Apr 11, 2019
@dylanb
Copy link
Contributor

dylanb commented Jun 16, 2019

No, this is a bad suggestion. If you want to meet the best practice you MUST do what it requires. The best practice itself is a SHOULD but if you decide to meet it then the requirements are clear.

@melaniephilipp
Copy link

I was just going to file this same issue but discovered this open issue. As of this time, some axe best practices say must and some say should, so they aren't consistent within axe. Also, in DQU and the DQWay we use the MUST, MAY, SHOULD terminology according to the RFC 2119 standard with respect to WCAG requirements. I realize the axe rules don't capitalize those terms and the analogy isn't perfect, but... the difference in use of "must" and "should" between axe and DQU and DQWay and Assure and WCAG is confusing to say the least.

@WilcoFiers
Copy link
Contributor

There are inconsistencies in these messages. In my opinion, the correct word to use in these messages is "must" for the reason Dylan said. If you want the issue to be resolved, you must resolve the thing.

@melaniephilipp
Copy link

@goodwitch looping you in on this issue to get your thoughts.

@goodwitch
Copy link
Contributor

Sounds like we need to add this to the Jedi Council agenda. @paulbohman needs to be included too. See the DQU usages of MUST and SHOULD here https://dequeuniversity.com/checklist

@WilcoFiers WilcoFiers added this to the axe-core 4.2 milestone Jan 20, 2021
@WilcoFiers
Copy link
Contributor

OK so RFC 2119 has nothing to do with this ticket. I agree with Dylan that if we treat these as requirements, they are a must. I dug into this with Glenda and Melanie this week, and what I found much more of a compelling reason to change this is to consider the MuSCoW prioritisation method. Best practices issues are not things that should block a release, whereas WCAG A and AA issues should do. Therefore it make sense for WCAG rules to not use the word "should" and for BPs to not use the word "must".

@padmavemulapati
Copy link

Verified with the latest axe-core develop branch code with the fix version:
observed the following rules with "best-practice" tag, using should instead must in the respective help text.
Accesskeys
aria-allowed-role
aria-dialog-name
aria-treeitem-name
empty-heading
form-field-multiple-labels
frame-tested
frame-title-unique
landmark-banner-is-top-level
landmark-complimentary-is-top-level
landmark-contentinfo-is-top-level
landmark-main-is-top-level
landmark-no-duplicate-banner
landmark-no-duplicate-contentinfo
landmark-no-duplicate-main
landmark-one-main
landmark-unique
meta-viewport
page-has-heading-one
region
scrollable-region-focusable-matches
table-fake-caption

for example: (replicated with 4.0.2 and fix verification with 4.1.1
image

@straker straker closed this as completed Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule metadata Issues in the rule metadata code (lib/rules)
Projects
None yet
Development

No branches or pull requests

7 participants