Is accessibility support included? #498
Comments
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? |
So no verification of claims nor validation of support is performed here, it's essentially an aggregator?
Here are two:
In addition, accessibility practitioners publish support notes regularly across their blogs, company sites, social media, and so on. |
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. |
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.
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. |
|
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 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. |
|
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. |
Any content page with an accessibility considerations subsection.
I am unsure. It will likely need to be manually done. |
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
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. |
|
Ah poop, Eric responded while I was typing. |
|
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. |
|
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. |
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. |
|
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? 
|
|
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: 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):
When you bring this to MDN I encourage you to suggest they revise that. |
|
I think the most straightforward way to handle this is to treat accessibility issues like other bugs, and use In web-features, when a feature includes some BCD feature with 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 :) |
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? |
Agreed, though the team performing the review:
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.
See my two bullets above.
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):
Neither of those were acted on and are still open. I filed a related PR at Can I Use (which was merged):
But then the browser's rep came through and filed a new PR at Can I Use to undo the change, which was merged ():
This may relate to my unwillingness to trust self-reported support from browser vendors. As another example, let's look at
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
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:
Let's consider those first three issues. From an editorial perspective, would Web Platform Baseline consider For that last issue, MDN considers both 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 This is a case where WHATWG HTML was updated to allow 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. |
|
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 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™. |
|
Thanks for the examples, @aardrian! web-features doesn't have We do have entries for both Flexbox and Grid, and the situation reminds me of I can't find WebKit bugs about the problem of Flexbox and Grid on a I don't know if attempting to use Flexbox or Grid on We don't have web-features entries for 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? |
Which is why I suggested a disclaimer (and proposed some text). 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!).
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 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).
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.
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? |
|
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:
|
This adds an item to non-goals to clarify that support in assistive tools that may be used along a browser is not (yet?) covered by Baseline. See discussion in #498
I prepared #519 so that we can discuss concrete text.
I see you initiated a discussion with BCD in mdn/browser-compat-data#21847. |
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.
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. |
|
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 |
|
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. |
|
Hey James, yes we do have regular meetings. Here's the calendar for the CG: https://www.w3.org/groups/cg/webdx/calendar/ |
|
Issue discussed in last week's WebDX baseline meeting An attempt to summarize the discussion:
|
I filed an issue on the MDN/yari repo about this: mdn/yari#10350 |
|
@cookiecrook Yes, you're welcome to join Feb 29 call. We'll add that to the second half of the agenda! |
|
Sorry. Trying to make this work. I got called away last week and just found the invitation in spam. Replying offline. |
This adds an item to non-goals to clarify that support in assistive tools that may be used along a browser is not (yet?) covered by Baseline. See discussion in #498 Co-authored-by: Daniel D. Beck <[email protected]> Co-authored-by: Philip Jägenstedt <[email protected]>
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:
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.
The text was updated successfully, but these errors were encountered: