James Teh

Ah, thank you. I think the language in ARIA-in-HTML (a spec I keep forgetting about for some reason) clears this up. That said, it does suggest that ARIA roles should...

> Although in Firefox 142 the selection box was drawn over the `user-select: none` element when using the VoiceOver text selection command (VO+Return). For the record, [this should be fixed...

Thanks for the report. I am aware of this. There are two issues here: 1. ReaKontrol doesn't yet support some of the features of the new Mk3 firmware; e.g. control...

For the most part, ReaKontrol mirrors the controls used by Ableton Live. See the M32 manual for details on those mappings.

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

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

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

> What's the difference here from the issues i raised earlier ([#2655](https://github.com/w3c/aria/issues/2655), [#2656](https://github.com/w3c/aria/issues/2656))? They seem to propose the same? One significant difference is that this issue proposes default semantics, where...

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

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