w3c
Expose implicit ARIA semantics (browser-defaults and ElementInternals)
Description of bug or feature request
Accessibility testing frameworks currently have no way to query the ARIA semantics applied through ElementInternals within custom elements. This results in false positives and undetected issues across a growing ecosystem of web components that use ElementInternals to set accessibility roles and properties. Automated accessibility testing is typically performed by JavaScript libraries (e.g., axe-core) that run directly in the page context or in CI systems, and therefore must be able to query all author-provided accessibility information via standard DOM APIs.
This limitation has been raised in several issues, including aria#2656, aria#2655, and whatwg#11040. Proposals to address this at the ElementInternals level (e.g., relaxing encapsulation) have been discussed, but were met with valid concerns around encapsulation and design.
The goal of this issue is to gather thoughts from the ARIA WG about the feasibility of a proposed solution, and/or brainstorm about other solutions.
Proposal: Introduce a new get-only API surface (tentatively named implicitAria) to expose browser-default (or author-modified browser-default) accessibility semantics for DOM elements, including those defined via ElementInternals. Unlike standard ARIA reflection (which exposes explicitly set aria-* attributes), implicitAria would expose the implicit or default semantics the browser applies. This would be ideal for accessibility testing libraries such as axe-core.
Here are examples to demonstrate the idea:
- Native
<button id="b1">Save</button>
<script>
const b1 = document.getElementById('b1');
// ARIA reflection (explicit only): no role attribute present
console.log(b1.role); // undefined
// Proposed implicit semantics:
console.log(b1.implicitAria.role); // "button" (from native semantics)
</script>
- Custom element that sets role via ElementInternals
<script>
class CustomButton extends HTMLElement {
constructor() {
super();
this._internals = this.attachInternals();
this._internals.role = 'button'; // author-provided implicit role
}
}
customElements.define('custom-button', CustomButton);
</script>
<custom-button id="b2"></custom-button>
<script>
const b2 = document.getElementById('b2');
// No explicit role attribute on the host:
console.log(b2.role); // undefined
// Proposed implicit semantics reflect ElementInternals:
console.log(b2.implicitAria.role); // "button" (from ElementInternals)
</script>
- Native
<button id="b3" role="checkbox">Toggle</button>
<script>
const b3 = document.getElementById('b3');
// ARIA reflection exposes exactly what the author set:
console.log(b3.role); // "checkbox"
// Proposed implicit semantics still show the native default:
console.log(b3.implicitAria.role); // "button"
</script>
This solution doesn't require the browser to build the accessibility tree, it works similarly to how ARIA reflections work but for default values. I believe it stays clear from the privacy and performance issues we once discussed around AOM and the AccessibleNode proposal. It wouldn't leak the accessibility needs of a specific user, and is reasonably scoped. We could use a get-only version of the ARIAMixin interface to expose the full set of aria attributes.
Will this require a change to CORE-AAM?
No.
Will this require a change to the ARIA authoring guide?
It shouldn't.
There are a lot of similarities here to the original, abandoned version of accessibleNode. A major problem here is that computing this information is generally handled by a browser's accessibility engine, which isn't always running for performance reasons; e.g. if there are no accessibility clients running on the system. We can't simply return nothing when the accessibility engine isn't running because that would provide a very obvious way to detect whether an AT is running, which violates the web Platform Design Principle 2.11. Don’t reveal that assistive technologies are being used. On the flip side, starting the accessibility engine to answer such a query is a performance concern and the timing involved there could also easily reveal whether a user is using AT.
That said, it is important that we can test computed properties. Thus, it has been proposed that we have a test-only interface for this. This wouldn't be exposed to the web at large, only to automated tests. There is active (albeit slow) development on a WebDriver based solution in https://github.com/WICG/aom/issues/203.
Speaking on behalf of Deque Systems (maintainers of axe-core):
We are strongly in favor of this proposal.
Without this proposal, axe-core has no way to detect implicit ARIA semantics defined using ElementInternals. This prevents accurate accessibility testing of any custom element (even ones that don't use ElementInternals), since axe-core has to guess whether or not ElementInternals might be changing which semantics the element is meant to implement.
Today, axe-core guesses "probably not", which means it reports incorrect results for elements that actually do use ElementInternals. The inaccurate results this causes is already the most highly-upvoted issue on axe-core (by a wide margin). This will only become worse over time; ElementInternals is rapidly gaining adoption among design systems and component libraries (eg, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, ...). Without something like this proposal, a near-future version of axe-core will probably need to start saying "we have no way to tell what ARIA semantics any custom element actually has, so the only way to avoid false-positive scan results is to exclude all custom elements from axe-core scans."
Excluding custom elements from axe-core scans would be a huge blow to the accessibility of the web. It would prevent automated accessibility testing of web components in a massive number of projects and accessibility tools. On NPM alone axe-core is downloaded 20+ million times per week, and there are dozens of other accessibility testing tools built on top of axe-core (including some of Google's and Microsoft's).
This wide variety of projects and tools is the reason we want to join @benbeaudry in pushing for a proposal (like this one) that exposes a DOM API, and not a webextension-specific API or a webdriver-specific API. axe-core is the basis of a huge chunk of the automated accessibility testing ecosystem, and that ecosystem is extremely mixed; some of it is webextensions, some of it is bookmarklets, some of it is webdriver-based testing tools, some of it is CDP-based tools, some of it is embedding or injecting directly in sites. An API that works across all of those environments is the best way to ensure that the whole ecosystem of accessibility testing tools continues to function.
An API that works across all of those environments is the best way to ensure that the whole ecosystem of accessibility testing tools continues to function.
While I understand the concern here, as I explained above, no way has been found yet to create such an API without trivially revealing the absence/presence of AT. That is an unacceptable risk for users and users need to come first. To anticipate an argument, yes, there are other known ways to detect AT, but they are at least somewhat obscure and/or indirect. This would be very trivial and very direct.
@jcsteh Let me be explicit: This is different from the proposal you're familiar with. We wouldn't expose the computed role or attributes, but the default ones. This key difference would allow us (at least in Chromium) to avoid starting the accessibility engine, and avoid leaking to the web platform the accessibility needs of the user.
When I say default roles, I mean the roles implied by native semantics or by author-provided ElementInternals values, before any ARIA attributes or other overrides are applied. In other words, this would surface the same information a browser already knows at parse time — what role it would assign to an element if nothing else changes — not the resolved accessibility tree state.
That distinction keeps the API lightweight, deterministic, and privacy-preserving, while still giving accessibility tooling a reliable way to introspect author intent.
Let me be explicit: This is different from the proposal you're familiar with. We wouldn't expose the computed role or attributes, but the default ones.
That clarification helps; thanks. However:
When I say default roles, I mean the roles implied by native semantics or by author-provided ElementInternals values, before any ARIA attributes or other overrides are applied. In other words, this would surface the same information a browser already knows at parse time — what role it would assign to an element if nothing else changes — not the resolved accessibility tree state.
In theory, I understand what you're saying. In practice, at least in Gecko, pretty much all of that is determined by the accessibility engine. Duplicating all of that logic is going to result in inconsistency and difficult maintenance. Conversely, separating out that logic isn't really feasible because of the complex interactions between various levels of semantics.
To use a simple example, consider something like <section>. That could have a role of generic if there's no accessible name, but if there's an accessible name, it should have a role of region. But whether it has an accessible name is pretty complicated and basically requires you to do the entire name computation algorithm, which requires a lot of accessibility information.
What's the difference here from the issues i raised earlier (#2655, #2656)? They seem to propose the same?
I personally like the "getComputedAria()" method more than an implicitAria getter better (since it matches with existing "getComputedStyle" function). On the other hand, you could optimize reading a single ARIA property better in with the getter than the function.
What's the difference here from the issues i raised earlier (#2655, #2656)? They seem to propose the same?
One significant difference is that this issue proposes default semantics, where the other two propose fully computed semantics. Fully computed semantics absolutely suffer from the concerns I raised in https://github.com/w3c/aria/issues/2663#issuecomment-3423951512. It's being suggested that default semantics don't suffer from this problem, though I'm not convinced of that in practice as I outlined in https://github.com/w3c/aria/issues/2663#issuecomment-3424045166.
I'm definitely on board with saying "it's a requirement that whatever solution we come up with can't leak the presence of AT", and I see your point @jcsteh that it'd be problematic to meet that requirement for cases like <section> and <img> whose implicit roles rely on accessible name calculations.
What if the proposal were scoped more specifically to just custom elements? Do you think that would allow Gecko to reasonably implement it without relying on the accessibility engine?
Just FYI: both #2655 and #2656 were briefly discussed during last week's ARIA WG call https://www.w3.org/2025/10/16-aria-minutes.html#123a
What if the proposal were scoped more specifically to just custom elements?
That is far more likely to be feasible because we're only dealing with a clearly author specified role there, rather than the more complicated HTML-AAM and Core-AAM rules. However, https://github.com/w3c/aria/issues/2663#issue-3533431752 noted:
Proposals to address this at the ElementInternals level (e.g., relaxing encapsulation) have been discussed, but were met with valid concerns around encapsulation and design.
I'm not quite sure what all of those concerns were and whether introducing something specific to ElementInternals would have the same concerns.
There might still be some edge cases here. In particular, if this is described as "custom elements" and not "ElementInternals", #2383 comes to mind, since it can mean that the minimum role for a custom element can be different depending on various factors which would normally be determined by the accessibility engine. There might be others too, but I'd say far less than there are for standard HTML elements and ARIA.
I’m glad to see that we all agree on the problem statement. It also sounds like we’re all aligned on the core goals:
- Avoid revealing whether assistive technology is active.
- Maintain good performance (no accessibility engine startup).
That constraint rules out any solution that depends on the accessibility tree or engine. This narrows the set of solutions and, fortunately, makes the few valid options clearer.
Proposal 1: ElementInternals-scoped solution
This is the solution Dan mentioned earlier.
Expose a read-only reflection of an element’s attached ElementInternals ARIAMixin via something like:
element.internalsAria
If no internals are attached, this would return null.
If present, it would expose a readonly snapshot of the author-provided ARIA attributes set via the ElementInternals ARIAMixin.
This approach:
- Does not require the accessibility engine, maintaining privacy and performance.
- Solves the immediate need for ElementInternals-based custom elements.
- Is super easy to implement for user agents.
My one concern with this approach is that it's ElementInternals-specific. The WHATWG discussion in whatwg#11040 raised valid concerns about revisiting a solution that would "open-up" ElementInternals more, saying it would go against the spirit of encapsulation it was designed with in mind.
One could argue that the problem stems not from the closed encapsulation model of ElementInternals, but rather from the absence of a standardized mechanism for accessibility testing tools to read all author-provided ARIA values. These tools need visibility into what authors explicitly set in order to identify errors. My opinion is that this is a need the ARIAWG should explicitly be in support of.
This brings me to the second proposal.
Proposal 2: General DOM API for implicit semantics
This is the solution I proposed in my original post on this issue.
Expose a new get-only property, e.g.:
element.implicitAria
This API would return the element’s default (pre-computed) ARIA role and attributes — the values known to the browser before any explicit ARIA attributes are applied or the accessibility engine is invoked.
For example, implicitAria.role would return "button" for a native <button> or "button" for a custom element that set that role through ElementInternals, but would not account for later overrides or name computations.
To clarify what I mean by “default” or “implicit,” it’s useful to think of an element’s ARIA state in several conceptual stages, as perceived by a browser implementor: initial, explicit, computed, and exposed.
- At the initial stage, the state reflects the native or ElementInternals-defined defaults known at parse time (if any).
- At the explicit stage, it incorporates values directly set by the author using aria-* attributes.
- At the computed stage, the accessibility engine resolves those values according to the full ARIA and HTML-AAM rules.
- Finally, the exposed stage represents the final accessibility tree after platform mappings are applied.
implicitAria would expose only the initial stage — the author-intended semantics before explicit attributes are applied and before computation.
Not all attributes have defaults, and elements whose defaults require non-trivial computation (such as <section>) should be treated as having no real default and thus return null.
This approach:
- Does not require the accessibility engine, maintaining privacy and performance.
- Solves the problem at a lower level.
- Would require the WG to define what counts as a native/default value where not already specified.
- Might require user agents to refactor their default value definitions outside of the accessibility engine.
- Is scalable beyond custom elements if needed.
@jcsteh, you said:
In practice, at least in Gecko, pretty much all of that is determined by the accessibility engine.
This is also true for Chromium today — our native values live in the accessibility objects only instantiated when we run the accessibility engine. I could definitely see us refactoring those definitions outside of it in a way that avoid duplication or inconsistencies.
I'm not yet sure this solution is fully feasible, or whether my mental model of "implicit" values fully holds — which is why I really appreciate this discussion.
I have a few questions for you, Jamie, and others in the WG:
- Do we agree on the premise that the ARIAWG should support accessibility testing tools in their need to access author-provided ARIA values from a DOM API?
- Should we continue pursuing an ElementInternals-scoped solution instead of a broader ARIA-scoped one? If so, how would you justify it to the WHATWG?
- Are there other possible approaches we haven’t discussed yet?
Slightly offtopic, but is there any documentation on the "accessibility engine"? What's the difference between devtools showing ARIA properties and starting up the accessibility engine? Doesn't every vendor's devtools have an accessibility pane within their devtools? Or show the entire a11y tree?
There's no "formal spec" or standardized documentation for browser accessibility engines, because they're internal implementations tied closely to each browser. They're Chromium, Firefox, and Safari's way of implementing the ARIA spec and making the web accessible.
For chromium, this might be helpful: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/accessibility/readme.md?q=accessibility%2Farchitecture&ss=chromium
Chromium and Firefox are similar in how they implement the accessibility engine, in the sense that we both have it completely turned off unless we detect an assistive technology requesting information through the platform accessibility APIs. This is the default because most users don't need accessibility support. The accessibility engine is a very expensive beast in part because it must copy (and maintain a copy of that data) of each tab into the browser process. I explained it at a high-level at the BlinkOn 18 conference, which you can watch here: Challenges with Chromium Accessibility.
One could argue that the problem stems not from the closed encapsulation model of ElementInternals, but rather from the absence of a standardized mechanism for accessibility testing tools to read all author-provided ARIA values. These tools need visibility into what authors explicitly set in order to identify errors.
The concern I have with your second proposal is that implicit semantics aren't "author-provided ARIA values", nor are they things "authors explicitly set".
This API would return the element’s default (pre-computed) ARIA role and attributes — the values known to the browser before any explicit ARIA attributes are applied or the accessibility engine is invoked. ...
- At the initial stage, the state reflects the native or ElementInternals-defined defaults known at parse time (if any).
That's fine for simple cases like <button> where the role can't be anything else unless ARIA attributes are set. But there are cases that just aren't that simple, where there is no constant, default role and where it is always computed. The <section> example I gave illustrates this. It has a role of region if there is an accessible name or generic otherwise. I guess you could say the default is region in this case, but that's kinda arbitrary. Why shouldn't be the default be generic instead? The author's intent depends entirely on whether there's an accessible name or not; we can't assume with any degree of certainty that the author intended a region if there's no name. We could define an explicit list of default roles for this API, but that's ultimately not going to reflect reality. I'd argue we're potentially lying to consumers of this API if we try to make assumptions here.
- Do we agree on the premise that the ARIAWG should support accessibility testing tools in their need to access author-provided ARIA values from a DOM API?
Honestly, I'd argue that DOM APIs aren't the correct way to do this kind of testing and that this kind of automation should be using WebDriver or similar (or a WebExtension at the very least) instead. But I get that pragmatically, that ship sailed a long time ago and I do understand the importance of these tools. The best I can say is that I agree there is a need to support these tools as best we can.
- Should we continue pursuing an ElementInternals-scoped solution instead of a broader ARIA-scoped one? If so, how would you justify it to the WHATWG?
I'd justify it as above: that there is no valid "default" role for many HTML elements and thus we can't support this for every element without potentially lying to the API consumer.
- Are there other possible approaches we haven’t discussed yet?
I haven't really thought this through, but I wonder if there's some way to have a WebExtension which "enables" a DOM API which is otherwise not exposed to the web? This would only be installed in contexts which run automated accessibility tests. That way, we could use the accessibility engine without fear of breaching user privacy.
I haven't really thought this through, but I wonder if there's some way to have a WebExtension which "enables" a DOM API which is otherwise not exposed to the web?
Or much simpler: a browser flag/hidden pref. We already know this is possible. The question is whether it's acceptable.
Proposal 1 seems fairly reasonable to me. Only ARIA props from ElementInternals, that'd do the trick and seems like it wouldn't be a lot of work.
If WHATWG is so worried about encapsulation that even that doesn't seem acceptable than I can't see how any standardized solution would be. Option 2 easily lets me deduce how ElementInternals was used too. So would a getComputedARIA, and an Accessibility Object Model.
The only way to avoid that would be to only make this information available in some kind of priviliged permissions mode. That could be a JavaScript world with special permissions, some extension / Selenium API, or a feature flag. We could also consider maybe a standard API that's only available when an "Accessibility testing" permission is given, kind of like how browsers can ask permission to use the camera or video. That'd also avoid exposing the presence of assistive tech as in such a mode you could have the accessibility API permanently on. A permission may be a bit unorthodox but it seems like a relatively well established and understood path.
All of the special privilege solutions have the problem though that it just isn't going to work everywhere accessibility testing is done. The reason ANDI is a bookmarklet is because accessibility testing has to be done in environments where you cannot get special privileges. This is an essential tool for certified accessibility testing for the US government. Permissions-based MIGHT work for that, but the other solutions wouldn't.
I came here to say most of what @jcsteh already stated more eloquently above... Also, @alice has explained some of this elsewhere.
I think what I'm seeing and that @jcsteh has also pointed out a few times, is that the implementations, as currently architected, can't really avoid spinning up the accessibility runtime, or else they could but would not be able to return a useful, accurate answer without doing so... Several of the accessibility engine implementors have even discussed moving parts of the accessibility runtime further up into engines, but ultimately abandoned it once we determined how much re-architecture would be required... Some of it may still be possible, but upon investigation, it was much, much more complex that any implementor wanted to commit to at the time. A similar level of complexity was one of the reasons we abandoned the :role() selector I proposed, but that has the added complication of potentially creating a dependency loop prior to style compute.
The above complication is the core of what I'd want to discuss in the meeting new week. One thing that might be useful @benbeaudry, is that if I haven't dissuaded you yet, try creating a draft implementation of what you've proposed, and see if you really can find a good way to bypass the accessibility runtime without completely rearchitecting it, and still provide useful return values. If so, it's certainly worth revisiting.
But I also want to point out that there are test-only APIs available for audit frameworks specifically, as long as the audit developer is open to adopting these rather than utilizing only open web APIs... I pointed this out to contacts at Deque and Level Access around 2019 when Audits were shipped in WebKit. Despite a few blog posts and WWDC talks, what might not have been as clear is that the shipping "Accessibility" audit in the WebKit Inspector isn't intended to be as thorough as one like Deque's Axe-Core. Rather, it's intended to be sample code for audit developers, so they can write and embed their own audit in the shipping engine, or make it a downloadable, installable audit... If audit tool support like Axe-Core is the core of this issue, that path may be the most feasible near-term strategy.
As a web developer, having a parameter you could pass to playwright for example when running unit tests, would be sufficient as well. That way i can test the computed ARIA properties inside the unit tests.
If you consider having this functionality behind a feature flag/cli parameter, would an API like getComputedARIA (or whatever it is called) be acceptable? Or do the "accessibility engine spinups" etc. arguments still apply then as well?
We discussed this in a meeting a while back but I forgot to link the minutes: https://www.w3.org/2025/10/30-aria-minutes.html#c627
Unfortunately, based on the minutes, it doesn't seem like that discussion covered anything that hasn't already been discussed here in the issue. It sounds like there was some discussion about a WebDriver-only or Audit-only approach, but as we've reiterated repeatedly, those simply aren't meaningful solutions for maintaining compatibility with the huge existing ecosystem of tools that aren't based on those technologies.
It looks like @alice implemented the ability to get the computed role of an element via element.computedRole behind a flag in chromium in 2014, which is still available behind the chrome://flags/#enable-experimental-web-platform-features flag today:
- https://chromium.googlesource.com/chromium/src/+/c659df27843e0631319982e18b8ec195cd81100d
- https://issues.chromium.org/issues/41147084
- https://www.w3.org/WAI/PF/Group/track/issues/427
I wonder why it was never enabled by default? Maybe there is a performance concern since it seems to spin up and possibly tear down the accessibility engine within the call to element.computedRole?
The ARIA Working Group just discussed Expose implicit ARIA semantics (browser-defaults and ElementInternals) https://github.com/w3c/aria/issues/2663.
The full IRC log of that discussion
<jamesn> topic: Expose implicit ARIA semantics (browser-defaults and ElementInternals) https://github.com/w3c/aria/issues/2663<jamesn> github: https://github.com/w3c/aria/issues/2663
<pkra> jamesn: wondering where are we lining up on this.
<pkra> ... I'm not sure we have good path forward.
<pkra> ... we had come to 2 approaches.
<spectranaut_> q?
<pkra> ... this seems to be a fundamental blocker for testing tools.
<jamesn> https://github.com/w3c/aria/issues/2663#issuecomment-3433501810
<pkra> giacomo-petri: server side it's not so much a problem
<pkra> jamesn: it's definitely a blocker for axe
<pkra> spectranaut_: I'm not sure how to move this forward.
<pkra> jane: do we need the relevant people on the call?
<pkra> jamesn: I think the arguments are laid out on the issue, e.g. axe and everything that uses it
<pkra> ... I think there's always encapsulation problems
<pkra> ... which get in the way.
<pkra> Jacques: solution 2 looks nicer to me
<jcraig> q+
<pkra> ... to advocate on Ben's behalf
<pkra> jamesn: I suspect in plain JS this will remain a problem. In an extension it's not problem but it remains.
<spectranaut_> ack jcraig
<pkra> jcraig: the way I understand this, it's not technically a web compat issue since it's never been solved via a public web API.
<pkra> ... there's webdriver etc but never a public DOM API
<pkra> ... ... so it feels to say it's breaking axe seems very strong.
<pkra> jamesn: setsInternalElementRole is a relative new feature and it causes this problem, no?
<scott> q+
<pkra> jcraig: I doesn't seem unlike other cases where heuristics were needed.
<pkra> ... but it's a new feature
<scott> q-
<pkra> ... we've had other requests, e.g. opening up the accessibility tree. And there were concerns (performance, security etc).
<pkra> ... so the second part is just not feasible. We cannot let JS in general inspect everything
<pkra> ... but in a test environment, like webdriver or audits, this is possible. And I understand that e.g. axe would like something in plain JS
<pkra> ... I know there are arguments around elements internals that it's problematic in various ways
<front-endian-jane> q+
<jarhar> q+
<pkra> scott: I agree with both James and James. I think it would be useful to determine the role. But we know it's difficult for good reasons. The computed role changing is a problem
<pkra> ... we need to acknowledge this limitation
<jcraig> q?
<jamesn> ack front-endian-jane
<pkra> jane: I agree it's a new feature and thus not breaking anything technically but it seems it would create a lot of work if switching to custom elements cannot be tested properly. This is a problem worth fixing.
<spectranaut_> q+ to ask about proposal 2 specifically -- element.implicitAria
<jamesn> ack jarhar
<pkra> ... but it's unclear how the options will help. I understand that breaking encapsulation is a problem but it seems theoretical with a real impact on accessibility of websites.
<pkra> jarhar: chromium has had computedRole for over a decade. It's interesting that it's so old.
<pkra> jcraig: is this a public API?
<jarhar> https://github.com/w3c/aria/issues/2663#issuecomment-3444944924
<pkra> jarhar: it's behind a flag.
<jarhar> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/element.idl;l=164-166;drc=1b33d126f307fc6442cf8adf370e122cbaa9571f
<jarhar> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/element.cc;l=3491-3500;drc=1b33d126f307fc6442cf8adf370e122cbaa9571f
<pkra> ... it seems heavy but it probably works.
<pkra> Jacques: this requires a flag and restart?
<pkra> jarhar: I think just the flag.
<pkra> ... the flag is "computedAccessibilityInfo"
<pkra> ... it might be very very slow right now, starting/stopping the accessibility engine.
<pkra> cyns: CLI or runtime?
<pkra> Jacques: it's a runtime flag
<pkra> cyns: people who cannot use fancy flags (like locked down browsers) won't be able to use this, right?
<pkra> jcraig: right. Would need an admin.
<pkra> jane: even in those environments exceptions can sometimes be made for testing etc.
<pkra> jcraig: and presumably you can deploy this in CI environments, too.
<jamesn> ack spectranaut_
<Zakim> spectranaut_, you wanted to ask about proposal 2 specifically -- element.implicitAria
<pkra> spectranaut_: I wanted to hear people's thoughts on the implicitAria proposal. It seems more lightweight.
<pkra> ... I wonder what testing people would think
<pkra> ... but there doesn't seem to be feedback on that.
<pkra> scott: I think both approaches would have some benefits at least.
<jcraig> s/I doesn't seem unlike other cases where heuristics were needed./There are other existing scenarios where Axe-Core can't detect the real role... I just want to make sure we're stating the problem accurately. This is not "breaking" Axe-Core. This is a new web feature that can't be tested in client-side code, and client-side testing tool devs want to solve that *new* problem./
<pkra> ... this stems from the allowed-roles in aria-in-html. That's a really good basis. But sometimes setting a rule it breaks something down in the engines and it's really hard to tell where the problem lies.
<jarhar> more context on the code i found: https://chromium.googlesource.com/chromium/src/+/c659df27843e0631319982e18b8ec195cd81100d https://issues.chromium.org/issues/41147084 https://www.w3.org/WAI/PF/Group/track/issues/427
<jamesn> q+
<jamesn> ack me
<pkra> ... knowing the implicit role really helps but even then it probably still only reaches "90% sure".
<pkra> jamesn: any of this would give rules engine a way to write some rules instead of having no idea what role a component has going on.
<jcraig> s/deploy this in CI environments, too./deploy this in CI environments with a command line flag. Looks like perf would not be good, but determinable on a case-by-case basis. That's better than hanging every person's browser to solve a testing use case./
<pkra> giacomo-petri: I think the problem is like not knowing what the explicit role is. If you set role=button on a button, if you know the implicit one is region but the current one is button you can raises an issue but it's not relevant.
<pkra> ... so you can raise it but you don't know if it's accurate.
<pkra> mattking: I think that's a good point. If you knew it's a button, you could raise an error on focus. But if it's a region, you wouldn't catch that.
<pkra> siri: wouldn't the computedRole give the end result?
<pkra> jcraig: assuming it works, yes.
<pkra> mattking: we're talking about the implicit role though
<pkra> jamesn: aren't we focused on custom elements which do not have implicit roles
<pkra> giacomo-petri: yes but if you change the role, you still don't know.
<pkra> jamesn: you're setting it though, right?
<pkra> giacomo-petri: but if you change it later?
<pkra> jamesn: you'd set it the same way and get it back the same way?
<pkra> jcraig: It would be great to have an example.
It looks like @alice implemented the ability to get the computed role of an element via element.computedRole behind a flag in chromium in 2014, which is still available behind the chrome://flags/#enable-experimental-web-platform-features flag today ... I wonder why it was never enabled by default?
I obviously can't speak authoritatively for Chromium, but it was likely never enabled due to the explanation I gave in the first paragraphof https://github.com/w3c/aria/issues/2663#issuecomment-3423951512.
s/I doesn't seem unlike other cases where heuristics were needed./There are other existing scenarios where Axe-Core can't detect the real role... I just want to make sure we're stating the problem accurately. This is not "breaking" Axe-Core. This is a new web feature that can't be tested in client-side code, and client-side testing tool devs want to solve that new problem./
I don't think you're quite right on either point @cookiecrook. Firstly, while there might be some edge cases around closed shadow DOM where axe might not be able to figure everything out, I've never come across one in practice. The only open issue where Axe-core is unable to correctly compute a role is for ElementInternals. Even if that was the case, all that'd mean is that there are more problems to figure out.
On your point about it not breaking anything, I think that's debatable. Axe-core can no longer assume custom elements have no semantics. It currently still does assume this, but this is causing issues. If there is no other way we can solve those issues, then I think it's quite possible that we are going to change axe-core to stop testing custom elements completely. Just whenever it sees one, bail and report nothing. That doesn't mean Deque tools won't be able to test these things. We'll find ways around that. As others have indicated, different platforms have different ways to do that. But that won't work for axe-core, since it is required to run the consistently in all DOM environments.
It isn't quite that "ElementInternals breaks axe-core", rather "Deque might deliberately break axe-core because of ElementInternals". I don't know yet. Maybe using ElementInternals for ARIA dies on the vine and this blows over. Maybe we can convince everyone who wants to do this to use a community protocol, without making their production code behave different from their internal test environments. If there's no DOM API for this, I think those are the three options. The only one I have control over is the first.
This is not "breaking" Axe-Core. This is a new web feature that can't be tested in client-side code, and client-side testing tool devs want to solve that new problem.
I see where folks are coming from with this statement if you only consider "can axe-core accurately test cases that use this new web feature". Where I respectfully disagree, and where think it's fair to characterize this as "breaking" axe-core, is that the addition of this web feature breaks axe-core's ability to accurately test cases that don't use this new web feature. Because axe-core cannot tell whether ElementInternals is in use or not, the addition of ElementInternals means that in order for axe-core to avoid false positives, it's going to have to remove previously-working functionality for testing custom elements, since it can no longer assume accurate knowledge of custom elements' accessibility properties (even for custom elements that don't use the new web feature).
I'd love if we could have some more discussion about "Proposal 1" from @benbeaudry 's comment here. So far, that option seems like the most concrete route forward that realistically avoids the concerns folks are raising about needing to start the accessibility engine. The concerns I've heard about that option have primarily been about not wanting to violate the purity of the ElementInternals enapsulation boundary, but if we can agree that "backwards compatibility of my accessibility testing tools" is a web page author need, I think the priority of constituencies is pretty clear about prioritizing web page author needs above theoretical purity.
@josepharhar
I wonder why it was never enabled by default? Maybe there is a performance concern since it seems to spin up and possibly tear down the accessibility engine within the call to element.computedRole?
Yep, exactly. It was only ever experimental; it probably should have been removed a long time ago. It's largely superseded by the devtools pane and related puppeteer API, and by the WebDriver API.
@benbeaudry
Expose a read-only reflection of an element’s attached ElementInternals ARIAMixin ...
If no internals are attached, this would return null. If present, it would expose a readonly snapshot of the author-provided ARIA attributes set via the ElementInternals ARIAMixin.
Would it be acceptable to have this always return an object, but to just have all the properties be null (or whatever default value makes sense) if no ElementInternals has been attached? I think that would avoid leaking implementation details while also allowing a cheap way to retrieve author-set semantics.
@WilcoFiers wrote:
I don't think you're quite right on either point @cookiecrook. […] The only open issue where Axe-core is unable to correctly compute a role is for ElementInternals.
There are many other scenarios. What's the internal computed role of an orphaned <li> or <div role="cell">? What is the role of a ::before pseudo? What about<div role="switch checkbox">? This last one depends on the browser version.
My point is that AxeCore cannot know these answers, even before we discuss ElementInternals.
WebDriver is the only standard means for getting at these, though each browser has internal hooks to get more through the devtools bridge. Neither of those vectors are available to AxeCore or other client-side libraries. They can only make an educated guess based on heuristics and specs language, but the browsers don't always align with the specs. When we find these misalignments (through WebDriver/WPT), we change the implementations, or the spec, or both, or agree to disagree.
On your point about it not breaking anything, I think that's debatable. Axe-core can no longer assume custom elements have no semantics.
Should AxeCore have ever made that assumption? In any case, adding a new DOM API that AxeCore cannot test isn't the same as breaking something that AxeCore used to be able to do. Testing the real computed role of any element has never been supported in AxeCore, because there was never a DOM API available for this purpose.
@dbjorge wrote:
Where I respectfully disagree, and where think it's fair to characterize this as "breaking" axe-core, is that the addition of this web feature breaks axe-core's ability to accurately test cases that don't use this new web feature.
I guess we're disagreeing on the term. You're using "accurately test cases" to mean, detect many or most common authoring errors, where I'm using it mean detecting real issues affecting end users. For example, there are some authoring errors that are spurious, not causing real harm to users, if the browser can recover the intent. Likewise, there are things no automated checker can guarantee are non-issues.
Because axe-core cannot tell whether ElementInternals is in use or not, the addition of ElementInternals means that in order for axe-core to avoid false positives, it's going to have to remove previously-working functionality for testing custom elements, since it can no longer assume accurate knowledge of custom elements' accessibility properties (even for custom elements that don't use the new web feature).
I concede this well-phrased point, though I would contend that the assumed "accurate knowledge" was not 100% accurate.
I'd love if we could have some more discussion about https://github.com/w3c/aria/issues/2663#issuecomment-3433501810. So far, that option seems like the most concrete route forward that realistically avoids the concerns folks are raising about needing to start the accessibility engine. The concerns I've heard about that option have primarily been about not wanting to violate the purity of the ElementInternals encapsulation boundary, but if we can agree that "backwards compatibility of my accessibility testing tools" is a web page author need, I think the priority of constituencies is pretty clear about prioritizing web page author needs above theoretical purity.
I don't necessarily agree that "backwards compatibility of my accessibility testing tools" is another author need. It would be beneficial, yes. I would agree that the ability for a web author test the accessibility of their web sites and views is critical, yes. And they currently can through in-browser and native testing tools. I wouldn't go as far as to agree that testing a new feature needs a backwards-compatible test API, nor that it needs to be a public DOM API.
You've used the priority of constituencies to argue for authors over others lower in the chain, but the counterpoints above indicate the performance cost of actually computing the role is too great for users.
I think @benbeaudry may be proposing some mid-point where the authors explicitly defined ARIA role is reflected (even if that's not the computed role), I'm less concerned with that, but others may still object on encapsulation grounds.