Is accessibility support included?

[aardrian]

What steps is Baseline taking to ensure that when it affirms "this feature works across the latest devices and browser versions" a developer can confidently take the feature and deploy it without the risk of creating barriers for users (or legal risk, depending on jurisdiction)?

Background

I see nothing in the Baseline documentation nor goals about how to test, track, nor report whether or not something is (at least) accessibility supported (nor what level of support across versions and assistive technology / browser combinations).

This is absent from all the other platforms Baseline intends to supplement / borrow from, so the data will generally not come from them.

The only mention of "accessibility" I found in any existing open or closed issues was from a comment in May and not thoroughly addressed in followup conversation. A pull request comment in February lays out the concern as well, but the follow-up issue does not address it.

For example, I am struggling to find guidance on:

• What features have any accessibility vetting;
• What versions of assistive technology (AT) are considered for support (2 major releases?);
• What platform accessibility features are supported with these features;
• Bugs that trigger something to be inaccessible despite claims (see years of Safari breaking tables with display properties);
• etc.

Without accessibility as a pillar of the support charts, including testing details, this cannot be relied on by developers. This feels counter to improving the developer experience.

If I am simply terrible at finding it in the repo, please point me to it.

[tidoust]

This is absent from all the other platforms Baseline intends to supplement / borrow from, so the data will generally not come from them.

The web-features project agglomerates support data from other sources. For support in core web browsers, web-features currently builds on BCD, which in turn builds on sources such as browser release notes and more generally speaking has close ties with core browser vendors. The core browser set in the baseline definition is also a pragmatic one, as in "browsers for which we can find support data".

Are there reliable sources that web-features could build upon to assess feature support in assistive tools?

[aardrian]

The web-features project agglomerates support data from other sources.

So no verification of claims nor validation of support is performed here, it's essentially an aggregator?

Are there reliable sources that web-features could build upon to assess feature support in assistive tools?

Here are two:

• https://a11ysupport.io/, which has robust tests but is community supported and can always use people to help test; and
• ARIA and Assistive Technologies Community Group, though it only tracks screen readers and only cares about ARIA.

In addition, accessibility practitioners publish support notes regularly across their blogs, company sites, social media, and so on.

[tidoust]

So no verification of claims nor validation of support is performed here, it's essentially an aggregator?

If the web-features project can leverage data produced elsewhere, that's great!

The project is also community supported. Feature support in browsers gets reviewed before a baseline status gets set, but that's best effort, based on the expertise and knowledge within the web-features community. That community has a good overlap of participants with the BCD community, on purpose, to create a virtuous circle between BCD and the baseline information in this project, which hopefully benefits everyone and leads to more accurate results.

A similar setting would be needed to integrate accessibility support, I think, both because we likely don't have the right expertise in the group today (at least, I don't!), and because assessing support for features in assistive tools seems too large a task for the group right now.

Thanks for the pointers, that seems like a good start. The features being considered in a11y support seem finer grained than the coarser grouping that web-features defines. This makes me wonder about integration in BCD (and MDN) as a starting point.

From a web-features perspective, documentation could be updated to make explicit that the baseline status today is restricted to support in core web browsers and does not consider the combination of browsers and assistive tools.

[aardrian]

…because assessing support for features in assistive tools seems too large a task for the group right now.

Calling this out because much of the accessibility support can be confirmed without assistive technology. It does require some combination of knowledge of testing, WCAG, dev tools, and platform APIs so I do not doubt that is a large task.

From a web-features perspective, documentation could be updated to make explicit that the baseline status today is restricted to support in core web browsers and does not consider the combination of browsers and assistive tools.

I think that is a good start. I would go further, however, and state that "Baseline today is restricted to support as reported by browsers and the accessibility of these features is not assessed as part of this."

I offer this because browsers often self-report incorrectly (happy to provide links, but don't want to beat up specific engines) or unknowingly introduce regressions.

Since in my world baseline user agent feature support must consider accessibility (for legal and contract compliance), I will have to protect clients by qualifying that Baseline (as a resource) does not represent true baseline support. That is not me being snarky, that is my (legal) obligation. Having an appropriate disclaimer puts my clients less at risk of a footgun before they are my clients.

[ericwbailey]

I'd like to offer some bottom-up, in-the-trenches perspective here:

Of the many, many misunderstandings about web accessibility is the notion that semantics are intrinsically accessible. Oftentimes "semantics" translates to "I used HTML, so I should be good."

Unfortunately, there are many gaps in support and regressions on the browser layer, which assistive technology can have difficulty parsing, including straight-up not doing so.

Two notable, concrete examples here are the title attribute and display: contents. The former is a long-standing, well-established and documented problem. The other is a more recent, more volatile concern. There are many more examples of both of these types of issues out there (as well as plenty that live in the middle area between them), as well.

Resources like Can I use are helpful here, in that it can, and does link to community documentation of these issues. This is helpful as an accessibility practitioner when I have to leverage external authority to help communicate the nuance of why we need to avoid using these approaches.

Baseline, to my knowledge, does not communicate this nuance with its design. This can lead to a situation where my authority as a domain specialist is overridden, in that the case I'm attempting to build runs into "Well, the browsers all show a green checkmark so it should work."

Here, the cross-browser support messaging does not communicate the full picture. However, the perceived authority of the logos are about as deep as the inquiry into the problem space goes. This leads to chilling effects on our ability to move the work forward.

Another lens to consider is many of these concerns represent concrete access barriers which limit people's ability to accomplish things on the web, and not abstract concerns that have a viable fallback. So, "support" is a bit of wiggly term in that it is not a binary through every lens it can be viewed through.

The flip of a problem is an opportunity, however. Accessibility is used to being an afterthought, but imagine if Baseline was used as a tool to reflect the reality of the situation when it comes to platform-level accessibility bugs.

It would make folks feel the pain some in the short-term, but I am thinking those yellow and red status lights might serve as a motivational factor. It could lead to traction on some of the more longstanding community-identified issues, and in doing so help reinforce some very public commitments.

I am literally the reason MDN has an accessibility support subsection on many of its content pages—I say this with no ego. My idea here was to meet these people where they already are. Your average developer does not read W3C specs or preaching-to-the-choir accessibility blog posts.

The hope is that bubbling up these considerations in this way might translate to those who do read up on the technology having at least a nominal chance of gaining awareness about these sorts of concerns. It is also not lost on me that MDN programmatically fuels a ton of documentation for many different features and build systems, so the hope that this information would also be amplified in some small way in these areas.

To me, Baseline represents a way to take that approach and make it even more effective.

[dfabulich]

I'm not familiar with the accessibility support subsection in MDN. Can you link to an example?

Is the data for the accessibility support subsection in https://github.com/mdn/browser-compat-data ? If BCD has accessibility data there, it should be relatively straightforward to add it to the definition of Baseline.

[ericwbailey]

I'm not familiar with the accessibility support subsection in MDN. Can you link to an example?

Any content page with an accessibility considerations subsection.

If BCD has accessibility data there, it should be relatively straightforward to add it to the definition of Baseline.

I am unsure. It will likely need to be manually done.

[aardrian]

I'm not familiar with the accessibility support subsection in MDN. Can you link to an example?

I think this question is for @ericwbailey ? Though he may be talking about the accessibility notes on pages like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog#accessibility_considerations

Is the data for the accessibility support subsection in https://github.com/mdn/browser-compat-data ?

The browser compat data has no carve out for accessibility API support, the people who know it aren't necessarily the ones who can add it (the process is not exactly accessible), and when issues are filed about browser accessibility bugs they tend to sit.

[aardrian]

Ah poop, Eric responded while I was typing.

[dfabulich]

Ah, I see, that's an "accessibility considerations section," not an "accessibility support section." It provides advice to developers on how to ensure accessibility, not data on whether the feature is or isn't accessible.

In light of that, I agree with @tidoust that probably the best path would be for someone to connect the data from https://a11ysupport.io/ to https://github.com/mdn/browser-compat-data. This would presumably allow MDN to have an accessibility support section, showing on which browsers/versions a feature is/isn't accessible.

[ericwbailey]

Little note that a11ysupport.io is, as far as I know, run by a sole individual in their free time so even that content may only be as good as the last time it was manually evaluated. Better than nothing, in my opinion, but also trying to better explain the nuance of the status quo here.

[aardrian]

@dfabulich

In light of that, I agree with @tidoust that probably the best path would be for someone to connect the data from https://a11ysupport.io/ to https://github.com/mdn/browser-compat-data. This would presumably allow MDN to have an accessibility support section, showing on which browsers/versions a feature is/isn't accessible.

I the meantime, can you add a disclaimer as I outlined above?

Partly because a disclaimer will be much faster than taking the data from the two sources I listed above and figuring out how to add that.

[dfabulich]

Surprisingly, we have no direct control over the presentation of Baseline on MDN or Caniuse. This project provides the data to MDN on which features are and aren't Baseline; they control the presentation of the banner. (But, we talk to them, and can offer them advice.)

Just so I understand, where are you imagining putting an accessibility disclaimer? In the collapsed version? In the expanded version? In the "Browser compatibility" table, which you'll scroll down to with the "See full compatibility" link?

[aardrian]

The disclaimer is probably best in the expanded version (though a simplified version could live alongside the table). A variation on what is there now, with my poor copywriting skills contributing a new sentence at the end:

<p>
 Since<!-- --> <!-- -->March 2022<!-- -->,
 this feature works across the latest devices
 and browser versions. This feature might
 not work in older devices or browsers.

 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.
</p>

Part of the reason it should not go in the disclosure trigger is because it is already incredibly verbose. For the example you shared, this is how it announces using NVDA with Firefox (no pauses or breaks):

Baseline Check graphic Baseline 2022 heading level 2 NEWLY AVAILABLE Chrome check graphic Edge check graphic Firefox check graphic Safari check button collapsed

When you bring this to MDN I encourage you to suggest they revise that.

[foolip]

I think the most straightforward way to handle this is to treat accessibility issues like other bugs, and use partial_support in BCD when there is a serious accessibility issue.

In web-features, when a feature includes some BCD feature with partial_support, we'd need to make an editorial judgment about whether to withhold the Baseline status or not.

We'll also need notes to explain such situations.

Finally, I can't find any existing notes in BCD about accessibility, so the path I'm suggesting has no precedent. That makes me less confident it's the right idea :)