Meeting minutes
Agenda Review & Announcements
<matatk> JenStrickland: There was a review of the HTML CSS inert attribute work, I think it's worth looking at. Tagged PaulG so maybe he could look at it before we do. There are some layers of complexity that we should discuss. Some smart people within CSS are raising concerns.
<matatk> *we add it to the agenda for next week*
TPAC 2025
<matatk> janina: As you heard last week, we have been busy and filing requests for meetings with other groups.
<matatk> ... Are there any additional things we need to know? W3C requires them by Friday. As usual, we have a list of issues and groups we want to meet at TPAC.
<matatk> Roy_Ruoxi: I have created a placeholder for APA WG. If we got a resolution we can update that.
<Roy_Ruoxi> w3c/
New on TR
<matatk> Roy_Ruoxi: Nothing new this week.
Charter review requests
[wg/social] Social Web Working Group new charter
<matatk> w3c/
<matatk> janina: No concerns; can sign off
[wg/apa] Accessible Platform Architectures Group Charter
<matatk> w3c/
<Roy_Ruoxi> w3c/
<matatk> Roy_Ruoxi: Comment raises several process questions.
<matatk> janina: Can we address in next planning call?
<matatk> Roy_Ruoxi: OK
Spec review requests
Audio Session
<matatk> w3c/
<matatk> Due: 2025-04-24
<chiace> +present
<matatk> matatk: Great positive answer (and take up of offer of ACs section) from Marcos - but I am still unclear as to where in the spec it actually makes it clear that hints are being passed to the OS - should we ask them to make it clearer?
<matatk> janina: It's an early stage document, so yes.
<matatk> JenStrickland: Agree. Important to raise awareness of accessibility amongst designers and developers.
<JenStrickland> matatk I'm happy to review anything for co-authoring the accessibility considerations.
Web Neural Network API
<matatk> w3c/
<matatk> Due: 2025-06-20
<matatk> APA reviewers' thread: w3c/
<matatk> matatk: Chiara has done additional research on these. We agreed on most of them but didn't have suggestions on some.
<matatk> Chiara: 2.2.5 Background Blur - latency can cause issues. Added a requirement to have user-controllable background blur. The toggle should be keyboard operable. Consider latency - 150ms seems to be an important threshold.
<matatk> ... 6.2: At the moment the author only can provide power/performance hints. Allowing option for the UA to override them, controlled by the user, would help. Users from different socioeconomic backgrounds particularly affected.
<matatk> ... 7.1 to 7.3 no change needed, but maybe helpful to clarify that they're targeted at implementer, not accessibility specific.
<matatk> ... Example 9 uses an ASCII diagram. SVG may be more accessible.
<matatk> ... Last point: we need an ACs section. Let's introduce one to summarize the accessibility concerns.
<matatk> ... including confidence, and other issues raised above - and reference appropriate docs.
<matatk> ... What do you think?
<matatk> Dr_Keith: +1 Chiara. If we are going to have ACs sections for all documents going forward, do we have a specific structure we'd like folks to use moving forward?
<matatk> Dr_Keith: Or do we do it case-by-case?
<matatk> janina: We have in the past considered a template; still under advisement for us to do; easier if you have a starting point, but it doesn't exist yet.
<matatk> Dr_Keith: Is that something we could do now?
<matatk> janina: We'd be more effective if we had it.
<matatk> janina: We shouldn't let it get in the way of a specific review; that's where we've tripped up - figuring out the specific parts vs generic ones.
<matatk> Chiara: I think the main point of ACs section is having a consistent structure across the documents; maybe we can have simple overview with key points; user control, performance impacts; fallbacks; AT; privacy; in this case.
<matatk> ... I'm new so looking for input - maybe investigate the key documentation you produce and refine them into a structure.
<PaulG> matak: I don't think 7.1-7.3 isn't really needed since there are no changes needed
<PaulG> ...dev docs usually end up on MDN
<PaulG> ...as to a stock accessibility section: anything that can help us review is helpful, but maybe what we need more is a list of things for the reviewers to think about to ensure that they include the relevant sections
<PaulG> ...the compute pressure API had some really good examples of this
<PaulG> ...it's just so variable across technology and audience it's hard to prescribe a template across all documents
<matatk> PaulG: Going back to the document itself. One of the things we can do is help other groups with awareness of ATs. They have noise suppression and speech recognition. In between those is audio description. It could be added here as a use case. It's often something that's missing,a s it takes a human to identify what the sound is, and put it into
<matatk> text.
<matatk> ... There's another technology there; VTT. Here's an opportunity for us to add use cases they may be unware of.
<matatk> janina: We have consensus
Comment review requests
Add a way to indicate the semantics of ruby annotations
<matatk> source: w3c/html-ruby#24
<matatk> tracking: w3c/
<PaulG> matak: Ruby elements seem like a good approach for symbols but it's not being used what it's meant to be used for which is why i18n isn't in favor of this approach
<PaulG> ...the proposal adds a type attribute to ruby that would distinguish this new use case
<PaulG> ...the ADAPT task force would be in favor. If anyone wants to look into it, comment on the tracking issue in the a11y-review repository
<PaulG> ...if you comment on the actual issue (linked from the review issue), it would be from you, not APA
<PaulG> (yeah that)
<PaulG> https://
Pointer animations
https://
PaulG: This set off alarm bells for me. Needs strongly-worded considerations.
PaulG: What about eye gaze etc? This will be a problem for a lot of people. I commented that this *must* have an ACs section, and they may need help with writing that.
… If anyone's interested in the overlap between animation and something that messes withthe pointer's visibility, let me know! I may not have bandwidth for it.
janina: We should put CSS higher up next time!