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 :)

[foolip]

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?

Simplified support information is not reviewed and we've found a lot of things in need of fixing in BCD in the process, because we double check implausible data.

There's also the possibility of editorial override if summarizing BCD gives a misleading picture.

Are there features we should change the Baseline status of based on their accessibility support?

[aardrian]

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. [...] we'd need to make an editorial judgment about whether to withhold the Baseline status or not.

Agreed, though the team performing the review:

1. must be comfortable with testing accessibility issues, and
2. must be consistent in assigning severity.

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 :)

Or, that lack of existing notes confirms that accessibility continues to be an afterthought and that huge gap in all these efforts validates the existence of a11ySupport.io and the ARIA-AT CG.

There's also the possibility of editorial override if summarizing BCD gives a misleading picture.

See my two bullets above.

Are there features we should change the Baseline status of based on their accessibility support?

Yes. I am going to add them, but because I accidentally hit "submit" this comment was posted prematurely and I want to state some are coming before anyone responds...

Here are two BCD issues I filed related to years-old bugs (which the browser finally fixed in a recent release, partly as a function of me constantly pushing for it):

• #17776 css.properties.display - Safari (thru 16) flex, grid, contents problems 13 September 2022
• #19994 Safari Table Support - CSS Display Properties Break Tables., 30 May 2023

Neither of those were acted on and are still open.

I filed a related PR at Can I Use (which was merged):

• #6451 Safari 16 (release version) still broken, 13 September 2022

But then the browser's rep came through and filed a new PR at Can I Use to undo the change, which was merged ():

• #6458 Clarifications regarding accessibility and display: contents, 15 September 2022

This may relate to my unwillingness to trust self-reported support from browser vendors.

As another example, let's look at <datalist>:

• Chrome 20+ lists full support, yet: Issue 1322462: Form control validation errors don’t change zoom when zooming in/out on the page (CMD +/- on MacOS), open since 4 May 2022 with no action other than lowering its priority a year later (after threatening to close it)
• Safari 12.1+ lists full support, yet: Bug 240077 – AX: Default field validation messages do not zoom with page, open since 4 May 2022 with no action
• Firefox 4+ lists partial support (options do not appear on input types date, time, range, and color), yet does not mention: Bug 1756203: Users need a way to increase the size of overlays/menus that come from web content but are styled as browser UI (e.g. datetime-picker, text-input datalist, alert(), prompt(), tooltip), open since 18 February 2022 with no activity in 5 months and none pending.

Those are maybe not so critical. Something like native browser forms validation, however, can be critical for users who are maybe banking. As an example of one factor in field validation, MDN says the support for pattern is good.

• 1322462: The form control error message doesn’t zoom while zooming in on the page (CMD +/- on MacOS), 4 May 2022 with only a call to close and then a priority reduction
• Users need a way to increase the size of overlays/menus that come from web content but are styled as browser UI (e.g. datetime-picker, text-input datalist, alert(), prompt(), tooltip) (this should look familiar since it is listed above as well)
• 240077: AX: Default field validation messages do not zoom with page, 4 May 2022 with no action
• 1322670: Default field validation messages self-dismiss when they should persist, 4 May 2022 still open though it may be fixed

Of course, all the browser support is moot if there are bugs in the assistive technology (AT) that a disabled user relies on to use the web. Which means this effort would also need to consider bugs from those tools that have open bug trackers (they don't all do that).

Here are examples from the JAWS (a Windows screen reader) public bug reporting repo:

• #783 Row headers with labels announce as 'blank' with table navigation
• #601 JAWS announces wrong column header info after spanned cell
• #791 Unable to navigate nested tables in JAWS (fixed in latest release)
• #668 Expose superscript and subscript text

Let's consider those first three issues. From an editorial perspective, would Web Platform Baseline consider <table> to be fully supported? I assume sure, because the browser exposes it and JAWS has the bugs. However, these bugs mean a JAWS user runs into real, potentially critical, barriers. Which means in a practical sense, the goal of providing "clear information about which web platform features are safe to use" is not accurate.

For that last issue, MDN considers both <sup> and <sub> to be fully supported. It just happens to not be programmatically exposed to all users. They both have AAPI mappings (sub and sup in HTML-AAM), so as long as browsers are following it, this is an AT issue.

But does Web Platform Baseline care? Should it? And if not, how practical is it as a resource? And if so, who here trusts the browsers to self report and the reviewers to have the deep experience necessary to evaluate it?

Edited again to add... I filed an issue against MDN browser compat: #21648 html.elements.hr - Its standardized use in <select> is not widely supported

This is a case where WHATWG HTML was updated to allow <hr> in <select>, but no browser supports that fully, which (IMO) means the "full support" entry in the table is wrong.

Which means in addition to monitoring everything else I noted, this effort may need to monitor the versionless "living standard" of WHATWG HTML to note when existing features are modified and new features are added.

[extra808]

I think trying to account for everything that can play a part in some people's experience would be letting the perfect be the enemy of the good. Whether or not the core browsers do what they should do in ways that affect accessibility should be in-scope; visuals not getting bigger when browser zoom is used is in-scope, element roles or states not being reflected in their accessibility tree is in-scope, focus order not being updated as focusable elements become available or not, etc. Problems due to assistive technologies or devices failing to make use of what browsers provide should be out of scope, it's just too much and there's often not even good data sources to reference.

When it comes to accessibility issues with browsers, adding bug reports in BCD and using the Partial support label is also the approach I thought of. That is, Baseline is clearly meant to be a simplification of the data it's based on and a primary source, BCD, should do more to represent whether features work with more than just the most obvious modes and interaction methods.

If BCD ends up with more bug reports leading to more Partial support labels, that raises the prospect of browser regressions leading to a feature's Baseline status being reduced. This is different than the hr case where the spec expanded how something can be used, at minimum time can be allowed for implementations to come.

The point of something like Baseline is to be simple, to not provide a nuanced answer. Otherwise, the label for almost everything would be It Depends™.

[foolip]

Thanks for the examples, @aardrian!

web-features doesn't have display: contents as a feature yet, but if mdn/browser-compat-data#17776 is fixed I think we'd see a note when adding one.

We do have entries for both Flexbox and Grid, and the situation reminds me of position: sticky on <table> elements. In BCD we made that its own feature:

https://github.com/mdn/browser-compat-data/blob/e90b87e2eb0f47cab97d458918c58fa93ff87bd0/css/properties/position.json#L123-L161

I can't find WebKit bugs about the problem of Flexbox and Grid on a <table> element, but notes on some BCD entries or possibly a new BCD entry seems like possible options. I'd defer review of such changes to someone on the WebKit team.

I don't know if attempting to use Flexbox or Grid on <table> is common, but my hunch is that it's not common enough for us to say that those features aren't Baseline, just like position: sticky was broadly usable before the bugs with <table> were fixed.

We don't have web-features entries for <datalist> or the pattern attribute yet.

I think the opportunity here is guidelines for how to evaluate accessibility when adding new features to web-features and when deciding on the Baseline status. Is searching https://a11ysupport.io/ for the name of the feature a good start?

[aardrian]

@extra808

I think trying to account for everything that can play a part in some people's experience would be letting the perfect be the enemy of the good.

Which is why I suggested a disclaimer (and proposed some text).

@foolip

Those were intended as examples, not to kick off a discussion on each (issue or web platform feature). Those can be done in the issues (though I appreciate one I filed over a year ago finally getting some attention!).

I can't find WebKit bugs about the problem of Flexbox and Grid on a <table> element, but notes on some BCD entries or possibly a new BCD entry seems like possible options.

Here's one (and the issues often manifest on the required children, so a cursory search might not get the results you want): mdn/browser-compat-data#19994 (linked from the other year-plus-old entry)

I'd defer review of such changes to someone on the WebKit team.

I would not. WebKit has been consistently wrong for years (I linked examples of that above). Which comes back to one of my opening concerns — browser makers sometimes mis-report support (I am not suggesting intent).

I don't know if attempting to use Flexbox or Grid on <table> is common, but my hunch is that it's not common enough for us to say that those features aren't Baseline [...]

The issues often manifest on the required children. It is common enough that I kept running into it with banking clients (I think one or two libraries incorporated it). Hence, me trying for years to get this fixed.

But again, this issue is not the place to litigate specific open issues on web platform features.

I think the opportunity here is guidelines for how to evaluate accessibility when adding new features to web-features and when deciding on the Baseline status. Is searching https://a11ysupport.io/ for the name of the feature a good start?

Yes, but as I (and Eric) noted above, it is maintained by a single person and is not always current. Throwing some Web Platform Baseline or BCD resources its way would be ideal.

Can BCD commit to contributing to a11ySupport?

[aardrian]

I know this conversation petered out just before solstice and then the Gregorian new year came along and folks are just picking up email and task lists and wow is that a pile of messages to get through.

But I had two outstanding questions above and I would love to get some resolution:

1. Can you add a disclaimer Is accessibility support included? #498 (comment)?
2. Can BCD commit to contributing to a11ySupport?

[tidoust]

Can you add a disclaimer #498 (comment)?

I prepared #519 so that we can discuss concrete text.

Can BCD commit to contributing to a11ySupport?

I see you initiated a discussion with BCD in mdn/browser-compat-data#21847.

[aardrian]

I prepared #519 so that we can discuss concrete text.

I left notes on the two bullets you added (actually, I suggested rewrites). Obviously I cannot identify what the scope of Baseline really is, only what has been outlined here, so I tried to stay within that.

I see you initiated a discussion with BCD in mdn/browser-compat-data#21847.

Not quite. I filed an issue with BCD data on MDN, which was closed because BCD does not track that information. It then turned into an explainer to me about the overlap between Baseline and BCD. Less a discussion and more two people trying to explain the demarcations to me.

[cookiecrook]

Hopefully you all are aware of the webcompat work going on in the interop-accessibility project, which includes investigations into new potential WebDriver features that will hopefully allow more testability going forward...

Some dashboard-like functionality you're talking above could possibly come from those results... We're discussing adding some WPT integration to ReSpec for the ARIA spec.. See https://github.com/w3c/respec/issues/4633

[cookiecrook]

If you'd like, I share a progress update on the Interop Accessibility project in one of your upcoming meetings. I think there's a lot of incentive for the web-features project contributors to write new WPT tests as part of the effort to discover and document what works and what doesn't.

[atopal]

Hey James, yes we do have regular meetings. Here's the calendar for the CG: https://www.w3.org/groups/cg/webdx/calendar/

[tidoust]

Issue discussed in last week's WebDX baseline meeting

An attempt to summarize the discussion:

1. There are ongoing efforts to converge on an accessibility tree definition, which in turn will make it easier to automate testing and generate useful support data. That's still some time in the future. @cookierook, you're certainly welcome to share progress on the Interop Accessibility project!
2. The association browser + assistive tool is out of scope of BCD for the time being, and thus of web-features.
3. The baseline definition would benefit from making that explicit. See Clarify that Baseline does not cover assistive technology #519 for some proposed wording. On to the owners group to agree on the update.
4. Main accessibility issues at the browser level are expected to be reported to and flagged in BCD somehow (e.g., as partially implemented with a note). This should be enough for web-features not to report a feature as baseline when it has known accessibility issues in core browsers.
5. Up to MDN to determine whether a disclaimer should be added to the baseline banner displayed on MDN pages. The general feeling in the WebDX CG is that a generic disclaimer on all banners would not be useful.

[captainbrosset]

5. Up to MDN to determine whether a disclaimer should be added to the baseline banner displayed on MDN pages. The general feeling in the WebDX CG is that a generic disclaimer on all banners would not be useful.

I filed an issue on the MDN/yari repo about this: mdn/yari#10350

[cookiecrook]

@atopal @tidoust 8am Pacific conflicts with kid school drop-offs, but I could attend the second half of a general meeting if that'd be helpful. Feb 29 or in March perhaps.

[tidoust]

@cookiecrook Yes, you're welcome to join Feb 29 call. We'll add that to the second half of the agenda!

[cookiecrook]

Sorry. Trying to make this work. I got called away last week and just found the invitation in spam. Replying offline.