Meeting minutes
<spectranaut_> scribe?
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_: I'm sure that the WG has discussed the issue discussed in Issue 2836 before, comments added to it already with some context
Tyler Wilcock: I want to talk about this one as I've seen related things for images
@spectranaut_: core-aam issue #266, I can take a look at it
James Craig: It may be worth ping Aaron Levanthal since he worked on something similar in Chrome.
James Craig: core-aam issue 265, this may end up being an implementation detail but Sarah and I found some inconsistency with what gets translated, but adding a note may be enough and then we can call it an implementation detail
@spectranaut_: Because i18n is pretty interested in ARIA notify now, someone should probably pick this up.
James Craig: You can assign it to me.
@spectranaut_: svg-aam issue 53, any SVG folks on this call who can take a look at it?
Cynthia: I can take a look
@spectranaut_: mathml-aam issue 41, I am going to ask our intern at Igalia if they are interested in taking this on since they are working on MathML
@spectranaut_: html-aam issue 608, any html-aam editors or people who want to work on this change? It should be easy for anyone who wants to start work on AAMs.
@spectranaut_: Asking Rahim if we can assign it to them.
<lola> I can
<lola> Apologies I'm not live atm
@spectranaut_: Thank you lola!
@spectranaut_: ARIA issue 2842, has anyone looked at this?
@Daniel: O
@Daniel: I've looked at this, it is more a screen reader issue rather than something we can do, but I'm open to hearing from others.
@spectranaut_: if others could look at this and comment by next week, that would be good
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Deep Dive/TPAC
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<Daniel> Registrants list
@spectranaut_: Reminder that TPAC is coming up, we also had a deep dive on listboxes this morning which there is a recording of if anyone wants to watch it.
Charter is going through!
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
@spectranaut_: No comment from anyone about the charter from last week, so it is going through.
@Daniel: We are in the refinement phase, with 6 months ahead people can make comments, but I'll continue to move forward.
Quick check in on: aria-actions: handling focus when actions are synthetically triggered
@spectranaut_: Sarah is not on the call, but James Craig left a bunch of comments. Any movement since then?/
James Craig: I have not caught up on this yet.
@spectranaut_: Should we ping Jamie on this?
James Craig: He was in the discussion we had, Sarah made the changes discussed, and this PR is the output of that discussion. We are reviewing it.
Canvas Accessibility -- continuing the convo from last week
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Philip Rogers: Continuing conversation from last week, we made some changes and I wanted to review them with the group.
Philip Rogers: To review, we are looking into adding a new attribute "drawable" which can be added to elements inside a canvas tag, which uses can draw using the drawElementImage() function. The question is whether things should be rendered or not by default.
Philip Rogers: I am wondering if we should default to exposing everything to the accessibility tree, including the things not marked as drawable, which would help with things like labels for drawable things, we don't have a way to add things to the accessibility tree that have been removed.
<spectranaut_> front-endian-jane: we have aria-hidden to hide things, seems like it should be there by default, if you are doing this you already have a javascript heavy application, adding aria-hidden doesn't seem alike a big lift
We also don't have a way to do the reverse of aria-hidden, and just because something is rendered doesn't mean it is visible to the user (it could be blurred, in the background, covered, etc)
@Jacques: It could be helpful to have a palette of things that could be rendered. It seems like everything being rendered at once could be a foot gun in that needing to hide things isn't something that would be immediately obvious to people and could result in a lot of excess elements being read to users.
Philip Rogers: There is a similar problem in existing websites of people not hiding things that should be, and yes, this is a real downside, but the upside is we wouldn't miss things.
@Jacques: It feels like a pretty big "foot gun" to have things all this exposed. Where in my flow do I think about what should be shown/hidden? It is a problem that exists elsewhere, I am not against this, but this is a serious issue.
Philip Rogers: A big reason for this feature is accessibility, and we looked into things like developer warnings, but there was a good suggestion to document all the good accessibility patterns in the spec explicitly
<Zakim> jcraig, you wanted to speculate if authors will expect CSS and @hidden to "work" inside the unrendered subtree and to ask whether you've considered (not intending 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 follow along on cyns @inert idea....
@cyns: I think that confusing chattiness is probably better than accidentally missing content.
James Craig: First, I want to make it clear that I like this feature. People will expect CSS to just work, so have y'all looked into what it would take to make that work. One of the main way that people hide stuff from the accessibility tree is via CSS, not ARIA. We've worked out ways to get labels and things associated across hidden content. It's not clear to me that aria-hidden should be used, versus the normal HTML hidden state.
James Craig: I liked what Cynthia said about marking these as inert rather than hidden. That could be a forcing function to force authors to do the right thing.
James Craig: I don't want to blow up the API but have you considered whether you an associate these elements with the different drawing elements to determine what is rendered on screen at the time? That sounds like a challenging math problem to me but maybe it could be solved.
Philip Rogers: Capturing what was actually drawn would be the ideal, and we tried, but it we were unable to make it work due to a lot of technical reasons.
Philip Rogers: The idea of marking thing as inert and then blocking people from drawing things that are inert is an interesting idea. Do you mean things would default to inert?
James Crag: I was thinking we could use it instead of hidden or aria-hidden, block drawing things that are inert, and we could use it as a way to remind web authors to do the right thing.
Philip Rogers: I worry about special casing this. Maybe people want to draw content that isn't clickable. Inert content are rendered currently, so it feels weird to not allow drawing them.
Philip Rogers: The great thing about inert is that it allows things to not work for everyone.
Philip Rogers: I'll followup separately.
@Matt_King: I agree with the idea in general, but not about using aria-hidden. the author is responsible for using any aria attribute it is a recipe for disaster. We need a way to make it work for everyone, like with hidden or inert.
@giacomo-petri: I agree with Jane and others that the responsibility should be on developers to do this. Everything should be exposed by default and hidden, CSS, or aria-hidden used to hide things. What if there was a way to link drawable to hidden, and force the author to change the author to expose to all users.
Philip Rogers: We started with this idea and had pieces of it, but one place it would fall down is if you only draw part of something (like an image figure relationship and only the image is drawn). By exposing things as off screen we can let ATs figure out what to present too.
<Zakim> spectranaut_, you wanted to discuss a basic question about "drawable"
<Zakim> lola, you wanted to talk about working closely with documenters and to advise against going against current web dev heuristics, i.e. echoing Jane, as TAG would likely raise it as an issue
@spectranaut_: I am concerned that things could become not visible on the canvas, but still drawn. It feels easier to communicate to developers that they have to manage both things on/off screen.
@lola: I wanted to raise that I agree that having this rendered into the accessibility tree by default as the web normally works like that elsewhere, regardless of which direction we go though, this could be confusing for developers. This is an accessibility feature, and more devs don't know about accessibility.
@lola: The key thing here is working with documenters in the docs CG group and elsewhere to make sure that devs are educated about this.
<Matt_King> +1
<front-endian-jane> +1
<giacomo-petri> +1 interested
<jcraig> +1
<lola> +1
Philip Rogers: I will add comments from this conversation to the issue.
@spectranaut_: I will make a deep dive for this next week before the WG meeting.
<dgrogan> WICG/
<Zakim> jcraig, you wanted to discuss offscreen further and to understand when the css is parsed and rendered on subtree elements before they are drawn into the canvas