Meeting minutes
New Issue Triage
spectranaut_: a few related issues about combobox
spectranaut_: mel, should we update the language to match changes in combobox?
melsumner: not the only issue where this needs clarification due to cross-spec changes
spectranaut_: are there others specifically related to combobox?
scotto: this one too w3c/
spectranaut_: melsumner okay to assign to you?
melsumner: yes please
spectranaut_: no milestones in this repo.... will try to do that in the mono repo?
scotto: i don't think the listbox is required, but the prose says it is... returned value matters, not the option... probably just a prose change?
spectranaut_: prose change in accname right, not aria?
scotto: wanted to track that aria and accname conflict... so two trackers
spectranaut_: okay will review (and close?) the aria issue since accname will be handled in w3c/
"HTML AAM: VoiceOver (AXAPI) mapping for optimum, low <meter> attributes"
scotto: will recruit the filer to make the spec change
jcraig: sounds good to me
Allow aria-flowto to have multiple ID references
pkra: alerted the filer to to the fact that flowto updates are shelved for the time being.
spectranaut_: do we need to keep this open?
mario: (phone breaking up) expresses support for improving support of flowto
<melsumner> should we say "needs design" ?
jcraig: this is one step above deprecation because of shortcomings in the design of flowto
mario: mindmaps (and flowcharts) are problematic for SR users
bryan: i agree... we have a UI that cannot be accessible yet
aardrian: CSS WG is working on reading order
<Zakim> jcraig, you wanted to mention flowto is not the right solution for flowcharts or mindmaps... SVG connectors maybe
<aardrian> CSS WG reading order issue: w3c/
<melsumner> flowto doesn't support it _yet_ but it could, it needs design.
<scotto> +1 to the point raised by jcraig that aria-flowto is likely not the best solution for these concepts.
<aardrian> Chrome intent to prototype: https://
<spectranaut_> jcraig: talks about svg connectors
<scotto> especially since being an ARIA only solution, it just means other non-ARIA accessibility solutions would also need to be added which would overlap / cause aria-flowto to be redundant
<spectranaut_> jcraig: and discusses how aria-flow to is not the right solution for the ose problems
<aardrian> CSS WG discussing applying this to tables (with my warning): w3c/
<Zakim> jamesn, you wanted to state that maybe we could use aria-details instead of aria-flowto as that already supports multiple IDrefs - and the implementation shouldn't really be different (not on call so just to provoke discussion)
jcraig: wanted to mention flowto is not the right solution for flowcharts or mindmaps... SVG connectors maybe
jamesn: wanted to state that maybe we could use aria-details instead of aria-flowto as that already supports multiple IDrefs - and the implementation shouldn't really be different (not on call so just to provoke discussion)
<spectranaut_> jcraig: example: if two different elements point to an element, then you get to that element, which one do you go "back" to?
bryan: can go backwards from flowto in JAWS
jcraig: but which do you go back to if there are two references... it's ambiguous
spectranaut_: ???
Matt_King: didn't list this as a priority for 2024 at TPAC
spectranaut_: let's mark this as a deep dive
Data grid example, form field missing accessible name
Matt_King: I transferred form APG, filed by Wilco
common practice fails validators, but there's ambiguity whether common practices should be accepted as a non-failure?
in this case there's a field in a cell... common use case
if there there row/col headers... does the field need a redundant label?
especially b/c html label/for can't have multiple references to every cell in the row or col
<melsumner> wouldn't you need some label for the rotor though?
Matt_King: feels like it needs agenda
scotto: does this belong in ARIA? what about WCAG? the automated tests are defined there...
<aardrian> +1 to Scott's suggestion this may be a WCAG issue, not in scope for ARIA
scotto: [rhetorical] are we trying to pass the validator, or is it more important to make sure the SR users understand this and don't hear redundancy?
Matt_King: or an AT thing.. if unlabeled field in a cell, label from headers.
if you can't code it in plain old semantic HTML, should it be the case that ARIA is required?
scotto: title attr might be the simplest native HTML solution
Matt_King: feel bad punting to WCAG without more thought...
Matt_King: ARIA WG should state an opinion
can this be pushed to AccName, e.g. name from table headers
Matt_King: that should be part of the discussion once agenda-ed
<jamesn> +1 to Matt - not quite as simple as just table headers especially when there are mutliple fields in a cell
`marquee` and `timer` listed as live region roles but have intrinsic `aria-live="off"`
<spectranaut_> jcraig: I think.. in the implementations, in safari, the goal is that something like a timer would be way to chatty. effectively what it was used for, a live-region value off, the screen reader focus is on the timer, you get the notifications
<spectranaut_> jcraig: this was a while ago, I'm not sure if it still this way or how the browsers are doing
Matt_King: I think it's funny b/c there's nothing in the live region spec that defines the "live region but only while you're on it" pattern... this was an artifact of getting ARIA 1.0 out the door.
scotto: confusion around "off" value of "live" since there's not a clear distinction between "off" and "undefined" since there is no "undefined" value
jcraig: also doesn't work with IDL reflection for undefined or invalid values.
jamesn: sounds like a good place for a clarifying note detailing what we expect AT to do with this
Name and description change events clarification
scotto: discrepancy where name changes are announced to SRs etc... diffs b/w Browser and SR implementations
<spectranaut_> jcraig: good issue, from webkit perspective, voiceover tries to keep an eye on the label especially if a user event cause the label to change. this is not well documented
bryan: description too?
scotto: yes, both name and desc
<pkra> I have to drop off early. thanks and talk to you all next week.
bryan: dynamic tooltips would be a good thing to test with desc change events
<spectranaut_> jcraig: ARIA-AT might be interested?
jcraig: what about ARIA-AT tests for name change events?
Matt_King: trying to think if we have test cases. Could be good for the group to test.
giacomo-petri: exc: <a href><img alt=""</a> even if you update the image alt via javascript, chrome did not get the name update for the label.
<giacomo-petri> I've found the ticket I opened, just FYI: https://
Matt_King: would need test case basics
I18N Review: aria-keyshortcuts needs attention?
<spectranaut_> jcraig: Here is the main concern, the assumption of the keyboard matches the language of the content. I proposed this to Aaron. and Aaron convinced me to drop the objection because lets say gmail or google docs -- in different locals, it uses local and languages to change what the keyshortcut is. this is localizable, it is expected that the webapp controls this based on language and locale. There might be a weird keyboard where
<spectranaut_> jcraig: you can't do the keyshortcut. google docs gets around this by having different shortcuts in locale and language.
<spectranaut_> jcraig: the web app business logic should solve it
<spectranaut_> jcraig: not ARIA
<spectranaut_> jcraig: if we are not stating that in the prose of the spec then we should
<spectranaut_> 1?
<spectranaut_> jcraig: maybe we can get one of the google contributors to respond and add some prose
<scotto> just find it a little weird it's coming up now, but this has been in the spec since 1.1