Consider adding an accessibility disclaimer to the Baseline badge

[captainbrosset]

Summary

The context for this issue comes from web-platform-dx/web-features#498.

Sorry, this is a long issue to read, but I think the gist of it can be understood by reading these comments:

1. Is accessibility support included? web-platform-dx/web-features#498 (comment)
2. Is accessibility support included? web-platform-dx/web-features#498 (comment)
3. Is accessibility support included? web-platform-dx/web-features#498 (comment)
4. Is accessibility support included? web-platform-dx/web-features#498 (comment)

In short, the web-features repo does not currently have a clear guideline around accessibility that's used to decide the Baseline status of a feature. We're discussing ways to change this, but it was suggested in the linked issue above that, in the meantime, it would be good for MDN to add a disclaimer to the Baseline badge.

See web-platform-dx/web-features#498 (comment) for an example of the proposal. Once expanded, the badge could have something like

 There is no guarantee this feature is
 <a href="https://www.w3.org/TR/WCAG22/#dfn-accessibility-supported">
  accessibility supported
 </a>, however, so support testing is recommended.

Because the UI rendering of the Baseline data is owned by MDN, I'm opening this issue for the MDN team to discuss and consider if they want to change the UI and add a note about accessibility.

URL

N/A

Reproduction steps

N/A

Expected behavior

Accessibility should either be included in the baseline status for the feature, or a disclaimer that it's not should be present in the badge.

Actual behavior

N/A

Device

Desktop

Browser

Chrome

Browser version

Stable

Operating system

Android

Screenshot

No response

Anything else?

No response

Validations

• I have read the Community Participation Guidelines.
• I have verified that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• I have checked that this is a concrete bug. For Q&A open a GitHub Discussion.

[LeoMcA]

I don't think this is a good idea, for a number of reasons:

First, I reckon it'll fail to achieve what it sets out to do: people likely won't see this disclaimer, currently very few people actually open the Baseline banner: our metrics show between 2-3% of pageviews with a Baseline banner shown also have that Baseline banner toggled open.

Second, a11y support isn't the only non-goal of Baseline, do we add disclaimers for all those others in the banner as well? This will get rather overwhelming rather quickly, and fail on the aim of Baseline to be easily digestible.

Indeed, Baseline doesn't override general web development best practices: you should still test your code, regardless of what the compatibility data suggests. Perhaps some kind of "how to use Baseline" document would be a better place for a disclaimer of this type, along with the other non-goals.

[foolip]

Accessibility isn't a non-goal of Baseline, the delineation that was made in web-platform-dx/web-features#519 is that if the browser does the wrong thing we consider that a user-affecting bug like any other, and it might lead to the feature not being considered ready. It's bugs outside of the browser, in the ATs, that we're not tracking.

[ddbeck]

Indeed, Baseline doesn't override general web development best practices: you should still test your code, regardless of what the compatibility data suggests. Perhaps some kind of "how to use Baseline" document would be a better place for a disclaimer of this type, along with the other non-goals.

I would like to echo this sentiment. Perhaps the Baseline glossary page is the right place to cover some of this stuff. That Extra considerations section could use some attention, along the lines of: don't forget to do accessibility, usability, performance, and other testing, or you'll be sorry whether or not there was a blue or green mark.

[caugner]

I would like to echo this sentiment. Perhaps the Baseline glossary page is the right place to cover some of this stuff. That Extra considerations section could use some attention, along the lines of: don't forget to do accessibility, usability, performance, and other testing, or you'll be sorry whether or not there was a blue or green mark.

We discussed this internally and support Daniel's proposal to reflect this on the Baseline glossary page. 👍

[ddbeck]

I opened a PR for this in content: mdn/content#33515