Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<spectranaut_> scribe?
spectranaut_ I'm already scribing :)
<spectranaut_> oh ty!!
spectranaut_: Let's do PR triage
… pr 2853 from kate
… editorial.
… reviewers added.
… next pr 2852. svg-aam change.
… has reviewers
… next: pr 2851 from tannal
… mathml-aam editorial.
… I'll review
… next pr 2850. dependabot.
daniel: I'll review
spectranaut_: thanks. next pr 2849 from pkra
… next another build actions PR
daniel: I'd like another person to take a look
spectranaut_: reviewers assigned.
… next pr 2845 for aria-actions. We discussed it last week and has reviewers.
sarah: It's on the agenda.
spectranaut_: it's last on the agenda today. Should we take it out?
jcraig: can wait until sarah can respond.
sarah: I used it because it's used in the spec.
jcraig: maybe then we'll need an editorial change later / there
Limiting drawing to direct children of <canvas> limits possibilities for accessibility agendabot]
philip: we spoke about html canvas a couple of months ago. There have been API changes and one has accessibility considerations.
… to recap: html-canvas allows html elements underneath canvas and an API to draw them into the canvas.
… e.g. apply webgl effects to an element.
… two pieces for today: drawable attribute for children to opt into drawing and JS function drawElementImage.
… the question we had: what should the default accessibility visibility be for something that's drawable but not drawn.
… in the screenshare, two children drawable but only one drawn.
… use case: developer puts attribute on everything and draws everything. Then we put bunch of things into the accessibility tree.
… use case: off-screen. You don't want to draw them but have them in the accessibility tree.
… use case: 3D scene. They may be move behind something (e.g. cube), then maybe you want them in the accessibility tree.
… we're hoping for important use cases for accessibility.
aardrian: so initially they are not exposed at all?
philip: some cases yes. E.g. display:none.
<jcraig> One of the related issues to the current topic: WICG/
philip: but scrolled off-screen elements might not be visible. Should that be visible? The platform seems clear that that should be.
<HaTheo> +1 to Giacomo, I could see(and imagine this will be used in Docs/slides/ect.) and I think keeping things exposed is safer.
Matt_King: my intuition is there's a difference between on-screen, scrollable-into-screen and not available to get into the screen.
… I don't understand how canvas and html work together.
… if you know it's drawable but not on screen, what do we know about the drawn state.
philip: we're wondering how likely it is that an author will make it drawable but not draw it.
… so we're not sure what they want then.
… we know if they've called the JS api or not.
Stefan: it's bad form to make it drawable but not drawn maybe but we think it's a case that we'll run into.
… we thought maybe it's a bit like CSS content visibility
… and the idea if content is semantically relevant.
thanks you dgrogan
… if it can be scrolled into the screen at any time, that's fairly clean.
… with this API we might not know.
… if it's not drawn, is it semantically relevant.
Matt_King: could AT see if it's drawable and test if it's drawn?
Stefan: if it has geometry, it should have been drawn.
philip: I tried voiceover and that might work
Matt_King: if the default is to include stuff, but if AT can test the info, then you could include it but AT could trim it.
Stefan: when we have semantically relevant content that's not display, we mark it as off screen in the accessibility tree.
… our plan was that we'd mark such as off screen.
… not sure how widely off-screen is established.
<spectranaut_> pkra: I was thinking are we even sure that if somehting is drawn we want it exposed. like a clip card, for a learning application. OR a book reading app, that has fancy page turns. Things drawn that aren't really visible. If you are just sliding something into view.. do we want to expose everything that is barely visible?
philip: we were hoping to use platform primitives to get things to work but maybe we need something extra.
stefan: but we might need to lean into visibility hidden or things like that.
front-endian-jane: if it's not in the accessibility tree, would focusable elements also not be upon focus?
philip: great question. I'd say keeping things in sync seems natural.
front-endian-jane: we have apis to hide things from the accessibility tree. But we don't have a way to expose children.
… how could we get there?
philip: we were looking at sr-only styles.
… that's not ergonomic.
stefan: we also presented drawable not as boolean but with multiple values.
… we hope to not add too many ways but lean on existing primitives.
<aardrian> had to drop, so following the chat, but sr-only styles is a cudgel for _supposedly_ addressing screen readers while having a potentially unintended impact on voice, other users.
front-endian-jane: right. I'm leaning towards giacomo-petri's suggestion, exposing everything by default. Authors have aria-hidden etc. It's established and effective.
<HaTheo> +1 with Jane/Giacomo, I think it's way cleaner to include it and apply a way of hiding it.
front-endian-jane: but if developers forget to do so, then no information is lost.
spectranaut_: long queue. Let's think about continuing.
philip: maybe next week?
<fantasai> WICG/
spectranaut_: sounds good. Let's have an issue for this maybe.
philip: let's add a separate?
fantasai: I suspect it might be hard without the whole.
philip: I made a doc to explain it and I'll include it on the issue.
fantasai: the starting point was to draw more than just the top element.
<spectranaut_> Document describing issue: https://
<Zakim> jcraig, you wanted to ask about giacomo's question re: CSS rendering in the unrendered subtree and to follow on with Matt's comment about whether you've considered (not intending to to explode the API — just curious) expanding the API to associate any of the drawing methods (dozens) with an object, and track the changed pixels with that representative element... and to trash :-) the sr-only styles idea... drawable attr would be better
fantasai: we had different ideas. E.g. an attribute with multiple values, a Boolean attribute
spectranaut_: let's weigh in on the issue and continue next week!
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: I made several new tests. jcraig, Rahim heads up.
jcraig: great. That'll go back to the first issues in 23
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: we have a deep dive next week.
… on listbox etc.
… anything we want to set up?
TPAC registration open
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
spectranaut_: please register for TPAC in Dublin.
jamesn: early bird for first 4 from any given org
Daniel: IEs can apply for waivers.
pkra: support for IEs is open until end of month
Draft Charter Review
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
daniel: charter refinement will trigger signal to various committees.
… I've put together a rough draft of what we've been discussing.
… in various groups.
… main points: I've moved some items into tentative section since we're currently not making too much progress on them.
… some new ones: css-aam as we've discussed at last TPAC and webengine hackfest. Also AT-Driver spec, to get discussion in the group going
… AT-Drive was with the browser testing tools WG. They've dropped it. We think ARIA WG could be a good place for it.
spectranaut_: any comments?
Matt_King: thank you Daniel!
<pkra> +1
spectranaut_: what's next? read and comment? +1?
Daniel: go through it. Most important would be any objections.
Add explicit language and direction metadata to AriaNotificationOptions
spectranaut_: did we have communications?
Daniel: they had a meeting. They seem to suggest for aria-notify to directly address it. If the WG feels strongly that this is the way to go,
… then we might need to have a meeting with the i18n group
spectranaut_: I'm struggling to understand their use case.
Daniel: Right. I hope we can resolve it in a conversation.
spectranaut_: right let's try to set something up.
pkra: isn't the underlying problem that this won't work without non-web-stack changes?
Daniel: right.
jcraig: maybe it helps to think about other attributes that are not rendered in the same context. E.g. title attribute.
… maybe there's a use case in the APIs docs.
… but I agree with pkra that it seems unlikely we ever want to break away from the element.
spectranaut_: their example is translations
jcraig: right. I had filed the issue for that.
spectranaut_: ok we have next steps. Let's get all relevant people together.
jcraig: I was a bit vague in the new issue. I hope we can work that out together.
Daniel: it would be great to move things forward for them to look at.