W3C

– DRAFT –
ARIA WG

02 April 2026

Attendees

Present
aardrian, Adam_Page, benbeaudry, Daniel, filippo-zorzi, Francis_Storr, giacomo-petri, jcraig, markrogers, Rahim, scott, Siri, Stefan
Regrets
-
Chair
-
Scribe
Jacques, Jacques5, keithamus

Meeting minutes

<Siri> prsent+

New PR Triage

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

New Issue Triage

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

spectranaut_: can we close as duplicate?

jamesn: can we merge these two?

Rahim: I had a question, is this a semantic issue, or is this presentational? The thermometer example threw me off.

apologies, I had a forced update..

back.

Matt_King: aria orientation doesn't tell you the direction, only the orientation.

jamesn: but in rtl languages and writing modes, increasing/decreasing is flipped.

<aardrian> I found the conversation and a specific comment related to `aria-orientation`: w3c/aria#113 (comment)

<aardrian> I am not sure it applies here?

spectranaut_: do we need to discuss the implementation role mapping for svg elements?

cyns: we are working on it.

jcraig: right now svg-aam is blocking wpt tests as well, but this feels like a good close to first step so we can begin testing.

cyns: we are looking at how the different browsers are making their descisions.

markrogers: one thing that would be useful would be finding out where in webkit the code for computing svg roles is. I want to summarize and compare the different engines.

WPT Open PRs

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

Deep Dive planning

<github-bot> I can't comment on that because it doesn't look like a github issue to me.

html-in-canvas feedback

<spectranaut_> Philip is presenting the explainer: WICG/html-in-canvas

Philip: This is a new API that allows you to draw HTML into canvas, designed with accessibility in mind.
… wanted to share this with the group to make sure our assumptions are right.

Philip: to draw html in canvas, you put the html directly into the canvas element, "Canvas customized renderering"
… <shows a "jelly" slider> this is simply being exposed as an input slider to accessibility.
… all of the browser features continue to work as they would today.

jcraig: I'm excited about this proposal after talking to foolip at TPAC 2025. The ARIA and AOM folks proposed what was called a "canvas shadow dom" before "shadow dom" a long time ago, but what we got wrong was the accessibility-only nature of the propsal. This uses a lot of the same ideas, but gives a mainstream benefit to web devs, not just limited to use cases for accessibility, so it should be a better API overall.
… this will make canvas much more usable for developers, even if you are handling all of the rendering yourself, this will take some load off of the developer to make things accessible, keyboard-operable, etc.

aardrian: At a high level, is the idea that an author who is using html/css can just author html, put it into canvas, and then another developer can do the "fancy" rendering?

Philip: Canvas based rendering is quite popular on the web, with many productivity tools using canvas today.
… all of these tools are re-inventing accessibility; we want them to be able to just use the DOM
… to your point, one use case would be to have one person/team write the HTML, and another person/team do the scripting for the canvas rendering.

jcraig: to follow up on that question, it can allow people to use canvas as a background if they want.
… there hasn't been a way to have standard controls and canvas in the same view before.
… this could make it easier for devs to get all of your standard renderings (focus, contrast, etc) when you want to use these new types of use cases.
… developers today often ignore accessibility for these situations.

Philip: to use these APIs correctly, to get hit-testing work for example, then you make accessibility work in the process.

cyns: I am happy to see this moving forward.

jcraig: Having this be a mainstream path removes the downside of making this a method to detect accessiiblity users.

<Zakim> Adam_Page, you wanted to ask a naive question about keyboard operability of the tongue slider

Adam_Page: focus is not visible in the example, but it seems like this might need extra work compared to what you would normally do in CSSS.

Philip: In this example, we are completely replacing the rendering, and we neglected to show the focus. If you are rendering HTML directly in canvas, focus rings are shown as you would expect.

<spectranaut_> link to slider under discussion: https://wicg.github.io/html-in-canvas/Examples/webgpu-jelly-slider/

Matt_King: two questions, google slides in particular: is the reason the screen show presentation due to canvas limitations, and would this API make the "real" text content be rendered?
… other question: things like system colors, forced colors, high contrast, in canvas, does this all need to be done manually? Or does some of that get inherited?

Philip: First, google slides is written in svg, so that won't change with this. But google docs is using canvas, so they might be a candidate.
… they might want to integrate this peicemeal, this API allows them to start to adopt the feature slowly, but you would need a significant amount of refactoring to be able to fully adopt.
… For the second question, for high contrast mode, we would draw that into the canvas.
… We don't want to fingerprint/show more information, but we felt that this information was "worth" it to expose.
… Since high contrast mode is already detectable in js, we felt it was appropriate to expose.
… to the other colors, we have an approach to where we would draw focus ring colors, but will use the default system color.

giacomo-petri: I'm excited as well, canvas is often used in educational settings.
… What happens when accessibility technologies are running, and when they want to show focus rectangles?

Philip: We have a similar problem for other kinds of browser features, such as tooltip.
… likewise rectangles from assistive technologies will draw on top rather than into the canvas.
… as long as the DOM position is kept in sync with the drawn position, we can draw these in the right place.

cyns: We would need some WCAG points around this. Would like to see a demo that uses high contrast.

<Zakim> jcraig, you wanted to confirm the repaint interval relies on author adoption, and to ask about practical introspection of font size by canvas authors

jcraig: You may be able to update your demo to use the css media feature for `prefers-contrast:more`
… The author still has to listen to a repaint notification to apply the pixels to the canvas at the right time?

Philip: We are bringing the js developer into the loop, they have a hook to draw, and they update where they drew it. They get a callback any time the children of the canvas changed their rendering, and another callback where they get the transform.

jcraig: At the time that the backing element gets its native focus ring they will get a notification that happened.
… That should include partially opaque pixels as well.
… the second question I had was font size.
… some media features that use responsive layout or command+/- to change font size
… would the developer be notified that the element that used to occupy a smaller bounds now occupies a larger area of the canvas?

Philip: we need to let the developer know about all of these changes.
… high contrast mode, zoom, etc.
… The API tells the developer to update their rendering and report the new position.

<spectranaut_> Jacques5: my question is, about high contrast mode, for forced colors mode, and the custom rendering -- would authors be able to customize the colors of the custom rendered based on high contrast mode or prefered colors?

<spectranaut_> Philip: yes

scott: in many cases of custom canvas apps, or canvas-adjecent apps:
… many of these apps allow for user authoring, e.g. drag/drop onto the canvas.
… if people can drop anything in in any order, what does this look like? Has this been concidered?

Philip: this would work however this works in the DOM today.
… I can follow-up more after via email.

jcraig: My final question for later review is about the input courier, such as for accented characters or non-western characters, would it be an overlay over even custom controls on the canvas?

<jcraig> lot of the same ideas, but gives a mainstream benefit to web devs, not just limited to use cases for accessibility, so it should be a better API overall./

<jcraig> s/At the time that the backing element gets or loses its native focus ring they will get a notification that happened, which indicates the author should repaint the canvas or redraw teh custom control with the new state applied./

Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

Diagnostics

Succeeded: s/This is something I'm excited about. We've been wanting something like this for a long time, but makes something that we imagined as an accessibility only API have a mainstream benefit./I'm excited about this proposal after talking to foolip at TPAC 2025. The ARIA and AOM folks proposed what was called a "canvas shadow dom" before "shadow dom" a long time ago, but what we got wrong was the accessibility-only nature of the propsal. This uses a

Succeeded: s/nature of the propsal. This uses a/nature of the propsal. This uses a lot of the same ideas, but gives a mainstream benefit to web devs, not just limited to use cases for accessibility, so it should be a better API overall./

Succeeded: s/the rest off of the developer./some load off of the developer to make things accessible, keyboard-operable, etc./

Succeeded: s/this makes it easier for you to get all of your standard renderings when you want to use these new types of use./this could make it easier for devs to get all of your standard renderings (focus, contrast, etc) when you want to use these new types of use cases./

Succeeded: s/the css media feature should work here./You may be able to update your demo to use the css media feature for `prefers-contrast:more`/

Failed: s/At the time that the backing element gets or loses its native focus ring they will get a notification that happened, which indicates the author should repaint the canvas or redraw teh custom control with the new state applied./

Succeeded: s/would the developer be notified that thse changes occured?/would the developer be notified that the element that used to occupy a smaller bounds now occupies a larger area of the canvas?/

Succeeded: s/The input courior, there can be a renderered popup over the text field, where would that be placed?/My final question for later review is about the input courier, such as for accented characters or non-western characters, would it be an overlay over even custom controls on the canvas?/

Maybe present: cyns, jamesn, Matt_King, Philip, spectranaut_

All speakers: aardrian, Adam_Page, cyns, giacomo-petri, jamesn, jcraig, markrogers, Matt_King, Philip, Rahim, scott, spectranaut_

Active on IRC: aardrian, Adam_Page, benbeaudry, cyns, filippo-zorzi, Francis_Storr, giacomo-petri, Jacques, Jacques5, jamesn, jcraig, keithamus, markrogers, Matt_King, Rahim, scott, Siri, spectranaut_