Meeting minutes
New Issue Triage
jcraig: summarizing... nathan from gecko, and tyler from webkit interop, raised these as troublesome from implementation. after we found the html one, nathan did implement a feature in gecko, but tyler brought up other concerns -- see the bulleted list
jcraig: brings us to the question of whether or not this is critical to keep as a requirement in the specs
jcraig: a listitem outside of the list context. whether or not it is problematic to say that it is a listitem, the AT can figure out whether or not the containment is valid. At only does this when user request get to that item.
jcraig: this puts more work on the engine to constantly do this work
jcraig: just now, because of implementation, we are questioning whether or not this is necessary
jamesn: should this be moved to core-aam
jcraig: I think it is in html-aam too?
scotto: this is true for in html for role list item, but I thought that html was mapped to generic for the last 12 years
jcraig: nathan didn't say this is a performance problem
jcraig: but what about the other cases?
jamesn: does this need agenda-ing?
<scotto> note: not "thought" for the <li> element, when used incorrectly, it _has_ been mapped to generic in firefox for the past 12 years
jcraig: if people agree... what I'm hoping for is that people agree should we pull the tests from 2024
jamesn: probably the right people to make the decision are in the issue
jamesn: I'll put deep dive so we keep an eye on it
New role for audio transcripts
jamesn: any opinions?
<scotto> agree HTML first. otherwise just creating more roles with no native equivalent
<aardrian> also agree HTML first
pkra: reporter also raised other structural role proposals
<Theo> just making sure we don't lose track of the issue we were not able to get to last week. w3c/
pkra: should discuss with HTML too?
Matt: kind attr?
aardrian: e.g. <track> element in <video>/<audio>
aardrian: no expectation how AT would treat it differently.
jamesn: any volunteers to write a response?
jcraig: I wanted to point out an example
https://
look at the transcript tab
matt: list of timecoded captions...
jcraig: basically yes. generated from the same source as captions. results in a functional list of links that jumps to video timecode. this could be a new control type aligned with this issue's "transcript" role proposal.
<Theo> similar UI exists in MS Stream to these timecoded captions.
aardrian: transcript is not always a plain text representation of what was said
aardrian: i will ask if she is tying this req to functionality or to a simple container with role description
New PR Triage
aria-actions! w3c/
sarah: need aleventhal to review
jamesn: accname follow on https://
sarah: those interested in actions or accname and perf please look
BGaraventa: please add me as a reviewer
jamesn: thanks sarah for the hard work
WPT Open PRs
jcraig: all these are getting reviewed, I'd like to take this time to look at the recent issue list
https://
jcraig: there are a few to discuss
web-platform-tests/
jcraig: melanie and bryan, can you review
jcraig: there has been a lot of discussion about this, and I want a final review
jcraig: now that there are accessibility interop tests, I don't want them to fix something that is actually wrong, so I want it reviewed. it's just 40 lines of code. if there is any question I'd like to pull them out now
bryan: I'll look at it
Deep Dive planning
aardrian: 2148 may be ready for a deep dive
jamesn: if you can run the meeting it's ready... pick a date
Should form field in cells have name computed from table/grid headers (Was: Data grid example, form field missing accessible name)
jamesn: how about next week?
spectranaut_: scheduling
Deprecation of aria-invalid as a Global property and proposed Introduction of aria-MarkedType/aria-markType & Issue: CSS Highlights Not Clearly Documented in AAM
Theo: noticed 3 issues here
Theo: first has been identified by aleventhal. lack of browser support for aria-invalid... wasn't clear what that mean for developers... and no working alternative...
Theo: issue 1 confusion re: "deprecation" can note be updated to say its still okay to use?
StefanS: the "deprecation" listing should be handled generally, not just limited to invalid
Theo: agreed, please list related problem areas
Theo: issue 2. with plain HTML, should be a way to mark things as invalid... as with CSS highlights
Theo: aria-marktype
Theo: idea is on a <mark> element or other element, have a way to communicate the intended semantic
Matt: logistical question: editors draft of ARIA, i thought we used to have the value of token types expressed.. are those gone?
jamesn: sounds like a Respec error perhaps?
jamesn: I see them in the editors draft... values table after chars table
Theo: in summary, issue 2 is about providing a similar native use case for aria-invalid
Theo: used in google docs and elsewhere... if kept for form elements, would allow similar functionality
jamesn: summarizes issues 1 and 2 of 3
1 aria-marketype
2 native equivalent
Theo: other types of filters like inclusive language of disability-first language, could be marked as such.
Theo: issue 3 is that the CSS highlights did work to make sure it's available assistive tech.
could be a good topic to include in proposed CSS-AAM
Theo: i can help with (but not own) a new CSS-AAM spec
jcraig: I can too. I initially didn't consider CSS-AAM necessary (~5 years ago) but there have been several use cases since that (including this one) that warrant it
jamesn: please speak up if you can own this... we can discuss with editors
jcraig: link this to the old CSS-AAM or spawn a new one?
Theo: re-reading "deprecation" note… mostly developers saw this and moved away from using it... could be linked across to other possibilities
jamesn: also weird to deprecate w/o alternatives
matt: question about intent of deprecation scope.. .deprecated as global attr
can still use those grammar/spelling/etc value in input
Matt_King: should we use this new attr of anything that is not a bad input
Matt: so maybe we should consider making aria-invalid boolean only
Matt_King: and use this new aria-marktype attr to differentiate both invalid fields and other uses of marking
scotto: when it was deprecated from global, we kep on form control to use that scope
scotto: i don't believe you can use multiple values currently in aria-invalid (jamesn: correct, it's TOKEN not TOKENLIST)
matt: screen readers do announce "spelling" error for example.
scotto: didn't make sense to add multiple tokens
scotto: so maybe it makes sense to use this other attr to handle those other types
jamesn: we have a direction to move forward: associate this as one of several justifications for a new CSS-AAM
Theo: browsers have their own mark functionality and pass along to APIs
How to continue the conversation: Clarification of when live regions are meant to be announced by AT , Clarification of when a role="alert" should be announced by AT / fire an alert event , ->
jcraig: to summarize what I put in the issue... it looks like the was some confusion back to a shared convo of what the expected behavior is. with aaron and ben and dominic and scott and sarah that the role of alert will continue to fire the alert notification, the recent webkit change brings it back in line with mozilla and chromium behavior. so we don't have a new divergence . there is more work to be done to make sure it works in all
places.
jcraig: ben did follow up with the chromium issue.... it seems like after 10 years of aria there is a consistent live region behavior
jcraig: maybe we should close this issue (immediately retracted)
jamesn: is there anything that should be added to ARIA?
jcraig: yes, we need to add prose describing the consistency across browsers
jamesn: does someone who understands the issue can take this assignment
sarah: I'm interested, but it depends how soon you want it done
jamesn: if all the browsers agree it's not urgent
jcraig: I could help with any clarifications of behavior and PR review. it's not high priority
Matt_King: I'm trying to understand the scope of your comment... about the alert only?
jcraig: doug made a statement last meeting which i interpreted to mean browsers would soon lose live region interoperability (which is in the meeting minutes from last meeting)
<Doug3> Yeah, sorry, I wasn't clear on the role="alert" part. The non-alert versions were inconsistent with the UIA implementation.
jcraig: (to scribe summarize -- we thought there was a difference last meeting, it turns out the browsers are still aligned, which is a relief)
sarah: it's specified in core-aam, not ARIA
sarah: alert role is different event that live regions
sarah: aria-live has a link to the changes section below, which are different events
sarah: it's obscure, so it wouldn't hurt to have it in aria
Matt_King: I have an old draft PR in aria-practices who will help get a live region in aria-practices. this whole topic of being able to insert an element vs change an elements, this is critical to authors. if anyone here is happy to adopt this PR
sarah: as long as this is what you were thinking, I wanted to do extra tests with toggling display on the area
jcraig: test dev browser builds, since a few bug fixes have been very recent
Matt_King: a question, if you have a div that is live, and you toggle hidden on that div, nothing should happen. but if you toggle hidden on a child of that div, something should happen
sarah: that is my read of the spec. I have tested this before and I don't remember the result off hand. but you when you get to edge case differences in some specifics
Matt_King: if there are screen reader dependencies, all of your test case should be put in ARIA-AT