Content suggestion: Generalized ARIA support banner

[ericwbailey]

What is the new suggestion?

This suggestion came from a conversation in https://github.com/mdn/content/pull/10892#pullrequestreview-829681208 with @estelle. Many parts of ARIA have varying levels of support, or complete lack of support, depending on the combination of operating system, browser, and assistive technology being utilized.

I am wondering if we can have a generic, templated banner that communicates this across all ARIA pages.

Why is it important or useful?

I think developers are used to thinking about a technology presented in the MDN as a sort of binary working/not working way, unless specifically noted. ARIA, unlike many other web technologies, has shades of support. I worry that without this type of messaging a developer may find ARIA that matches their use case, and not think to test on a robust suite of assistive technologies.

An info banner may help communicate the nuance around support, which may help with using ARIA with discretion and care.

[Malvoz]

I think this is relevant: https://github.com/mdn/yari/issues/4454.

[Josh-Cena]

This is now tracked in https://github.com/mdn/mdn/issues/389

[Josh-Cena]

See also the discussion in https://github.com/mdn/mdn/issues/389; in general I'm against a banner that makes claims or generalizations not substantiated by actual data, but I'm happy to hear others' thoughts.

[ericwbailey]

I would like to unpack some of the nuance surfaced in https://github.com/mdn/mdn/issues/389 here.

I believe my tenure predates yours, @Josh-Cena. For context, I am the original author of the MDN's accessibility concerns subsections, and a former editor of the HTML section of the docs. I am voicing this this to communicate both my good faith intentions and also my knowledge of this space.

Mostly, I am attempting to balance bias to action with ensuring the perception of MDN's authority does not contribute towards increasing access barriers on the web.

To help center the issue I am driving at I would like to quote a11ysupport.io itself:

Important: This website does not attempt to establish a standard for how assistive technologies (such as screen readers) must behave or dictate how assistive technologies must provide support (no such standard exists). It should not be used as the only source for determining if something is supported. Instead, it is meant to help visitors get a head start in understanding behaviors, general expectations, and support.

a11ysupport.io, and other contemporary resources like it, are opinion. They are assertions based on informed ideas of how screen readers and other assistive technology should behave. This behavior is not static, either. It is a window of a certain moment in time, and that support can, and does change by design.

Behavior can be supported, not supported, be supported and regress. In addition, the perception of behavior being supported can occur. This is the part I am most concerned with, especially for people who are less familiar with assistive technology's nuance.

Behavior can also be impacted by:

• The assistive technology,
• Its version.
• The browser,
• Its version,
• The operating system, and
• Its version.

This is different than how most people think about support for web-related content, but important to communicate for full knowledge of the problem space.

For your comment in 389:

If the goal is to educate them that ARIA has bugs, we should do it in one place instead of everywhere (we don't repeat ourselves). If the goal is to inform them about the state of things, we need to give them the information.

This is again why I am advocating for more generic message. The state of things in web accessibility is complicated, highly variable, and far less mature and stable than other parts of web development. Because of this we should be encouraging caution and not over-indexing on applying ARIA.

Again, I am incredibly cognizant of MDN's influence on web development. This is why I am attempting to help steer things in a direction that will ultimately help people who rely on assistive technology to get what they need.

[Josh-Cena]

I'm not discrediting your professionality and I am fully aware of your knowledge and good faith in this area. I'm just saying that:

1. From the perspective of a reader, this note is not actionable because it's telling them neither the what nor the how. It leaves them confused, worried, and afraid.
2. This problem is not unique to ARIA. As you already quoted, CSS features and HTML elements can also have a11y implications and a11y bugs. Does that mean we need this note on every page, or should we simply faithfully document actual bugs that people have reported?
3. I am not married to one data source. A11ysupport happens to be one of the few projects in this area and often gets quoted, which is why everyone brings it up as an example, but we have our own data source with well-maintained testing infrastructure. We are assessing all possible solutions, including the capacity to self-host the data.

4. This proposal can be fully subsumed by that proposal, because there can only be three outcomes:

   • We include compatibility tables on each page (with the promise to keep it correct and up to date, assuming that is possible). There's no need for a generalized banner since developers can get more precise information.
   • We don't include compatibility tables because it's not feasible. Therefore we just add this note as a fallback, saying support is unknown and you need to do your own test. This is also a possible solution to that proposal.
   • We keep it in the status quo because we think developers are aware of the situation, we don't want repeated verbiage on every page, and we don't want to maintain the data.

   The acceptance and implementation of compat tables automatically implements the spirit of this note, and under no circumstance will we have both, which is why I think having two separate proposals is not productive as it diverges conversations.