Meeting minutes
New Issue Triage
spectranaut_: aria#2162
giacomo-petri: many websites with complex dashboards, multiple tabs — when interacting with a single card, only that card’s content is affected
… wondering if it makes sense to enable users to recognize these kinds of widgets
spectranaut_: MarioBatusic proposed something related to this: aria#1944
… please review, and then put agenda label on it for follow-up
spectranaut_: aria#2161
… directory deprecation should be normative
scotto: some editorial work could be done here
spectranaut_: let’s ask Jocelyn if she’d like to make this change
… unless someone else wants it ;-)
spectranaut_: core-aam#227
… do we mark things as deprecated in aam?
… we keep mappings if they exist, right?
scotto: yes. I don’t disagree with this. We can just add a “deprecated” note to the existing mapping to be clear
spectranaut_: aria#2160
… listitem should include `nameFrom: contents`, right?
cookiecrook: tests assume this, but spec doesn‘t actually state it
… we could either make it name prohibited, or change it to allowed from author and content
… there may be more elements, but listitem was the first that came up
… the downside for name prohibited is that there could be some scenarios where we want to allow authors to name
… even if uncommon
… there’s an odd distinction in the spec
… what’s the distinction between a heading’s computed label and a heading‘s concatenated _contents_?
… might be worth agenda'ing
spectranaut_: yes
… adding for future
spectranaut_: aria#2158
… allow posinset/setsize for toolbars
… follow-up from discussion about mechanism to relate controls without explicit grouping
scotto: yep, we can talk about it more, or we can just get to work
spectranaut_: yes, I believe there was consensus already
sarah: implicit indexing could be difficult/impossible
… browser people will be needed for the implicit indexing part
aardrian: I think this makes sense
… I’ll take assignment of this
aardrian: will this have any relationship to the core-aam spec?
spectranaut_: probably not, but reach out for help
scotto: I’m available too
spectranaut_: aria#2157
… sounds editorial
pkra: I looked into this and think it’s not exported
spectranaut_: let’s leave as is then, hopefully annek will come through
spectranaut_: aria#2156
<sarah> small correction on the minuting -- I wasn't being negative on the aria-posinset + toolbar thing, just wanted to suggest splitting the issue into the easy part (allowing the attrs on the roles), and the hard part (potential implicit index calculations for toolbar items)
spectranaut_: this sounds like a straightforward editorial change
… will see if Rahim would like to draft a PR
cookiecrook: I’ll also sync up with Rahim about this to clarify use of undefined
spectranaut_: html-aam#543
scotto: this is similar to the listitem one
<sarah> related issue: w3c/
scotto: aria#2160
spectranaut_: html-aam#541
… clarify contextual roles and accessibility parents
scotto: yes, I already started work on this
… this is a follow-on to another issue related to li role mapping
… this example is interesting because the parser actually error corrects
spectranaut_: okay, we’ll leave this one with you
spectranaut_: mathml-aam#33
… already discussed
New PR Triage
spectranaut_: html-aam#544
… scotto already reviewed
spectranaut_: aria#2163
pkra: no need for another review
spectranaut_: let’s merge both
spectranaut_: aria#2159
… note to expand radiogroup content 'allowances'
scotto: should there be a way to allow association elements outside of grouping them
… e.g., in HTML, you can put radio buttons wherever you want and relate them with the `name` attr
… but ARIA isn’t permissive in the same way
… so this PR gives more freedom to authors
cookiecrook: I’ll review
… we can already have an ARIA radio group that points to disparate radio buttons
… it’s kind of a junk element, but comparable to host language radio group
scotto: the issue I see with that is with aria-owns, the a11y tree will reflect the element structure/adjacency differently than the DOM
sarah: I’ll review this too
spectranaut_: html-aam#540
… clarify li role mapping
scotto: if an li element is used in some arbitrary location, then it should resolve to `generic`
… and if a `generic` intervenes between it and a `list`, then it should still legitimately be a `listitem`
cookiecrook: this aligns with bullet rendering in most browsers too
… I’ll also review
spectranaut_: anyone else?
sarah: I’ll review this too
WPT Open PRs
cookiecrook: I reviewed all these yesteday
… for scotto and Adam_Page, if you’ve committed changes based on my feedback, please request re-review
spectranaut_: zakim, next item
Deep Dive planning
spectranaut_: possible topic: should form fields in cells have names from table headers
aardrian: yes, I want to do this but haven’t begun
spectranaut_: please ping when you’re ready
aardrian: should I file the deep dive prep as a new issue?
spectranaut_: nah, just add a comment to aria#2148
… we should schedule the deep dive once we have the explainer
… can revisit scheduling it in the weekly call next week
TPAC 2024
spectranaut_: TPAC is starting to get planned
<aardrian> Considering attending, but cannot commit yet.
spectranaut_: it’s in the LA area at the end of September
<jcraig> I plan to attend.
<melsumner> I still have to figure it out but I'll make every effort to attend
bummed that I already know I can’t attend in-person, and possibly not even virtually — I’ve got a work conflict
MattKing: I’ll be at TPAC
<CoryJoseph> Planning to attend TPAC
cyns: 95% likely
<CurtBellew> likely to attend
<sarah> Need to confirm, but I plan to attend
<giacomo-petri> Planning to attend
<keithamus> Unlikely due to budgets.
spectranaut_: terrific, thanks
Deprecation of aria-invalid as a Global property and proposed Introduction of aria-MarkedType/aria-markType & Issue: CSS Highlights Not Clearly Documented in AAM
spectranaut_: this is a two-issue topic
spectranaut_: aria#2155 — introduction of aria-MarkedType
DougGeoffey: I’ll ping Theo to see if he’s available to discuss
spectranaut_: next topic
… 3 issues
… live regions
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 , -> Clarification of when a role="alert" should
spectranaut_: 3 issues with live regions
… clarification for when live regions are meant to be announced
MattKing: being discussed right now
Adam_Page: about injection of live regions into DOM after load being already rendered on load
MattKing: this is not addressed by `atomic`?
cookiecrook: correct, it’s not
spectranaut_: well-researched issue explaining the lack of clarity
… the first question is: what *is* our intention
jcraig: the implementations would like to settle on this
jcraig: let’s determine what implementations and AT+browser combos currently do, and then codify that
… agree with Patrick that this is under-specified
… and difficult to do automated testing
keithamus: interested in picking this up
… and testing for it as well
… I volunteered to write spec for aria-notify
… so there’s a strong intersection
jcraig: are you involved in interop meetings?
… I’m gonna ask Simon Pieters to add you to that
spectranaut_: back to the queue
sarah: is there any intent to change the core-aam mappings?
… browsers are kind of following the spec if you interpret it just so
… is part of the purpose to use the spec to *change* what browsers are doing? or just clarification?
spectranaut_: my reading is just clarification
keithamus: I agree, and Patrick and I have discussed this
keithamus: the point is to clarify this in the spec, and hopefully aria-notify will be the ultimate improvement
sarah: I’m skeptical that live regions will go away
spectranaut_: sarah, are you suggesting a change?
sarah: no, just wanting to point out that what we have now may not make a lot of sense but will also be fragile to change
scotto: I agree with jcraig that a lot of implementers are following this pattern, but they do that because of screaming from the a11y community via lots of testing to determine what works and recommend a technique
… to sarah’s point, if we codify that, I do think that‘s a good thing, but role="alert" is the one odd duck out
… role="alert" is actually better at announcing on page load, whereas other live regions are not nearly as good
… so we can call that out in the spec
… there was probably a reason
… but that’s an important detail
jcraig: thanks for that clarification, I do recall that alert nuance
<sarah> These are my tests from last year, if it's at all helpful: https://
jcraig: we should fix this, and we should create manual tests, and automated tests in chromium, gecko, webkit
… don’t want to get too far outside the scope of live regions until we have WPT coverage
… but yes, it should be resolved and clarified
<scotto> 1+ douggeoffray
MattKing: is it actually intended that role="alert" is somehow different from an equivalently coded live region that doesn’t have role="alert" on it?
… because they don’t behave the same across today’s browsers
… but that is not intentional, correct?
jcraig: there were enough ambiguities 10-12 years ago, it’s hard to say whether it was intentional
MattKing: alert was meant to be a shorthand synonym
… but indicate to the OS that it could do something additional, like make a sound
… if we’re just codifying behavior, I would want to resolve that ambiguity and ensure that we don’t *need* to use role="alert" to get the same SR response
jcraig: the difference is in the a11y APIs
… and their pre-existing features
… all other live regions do work the same, alert is the only exception
sarah: I would like to propose one specific change
… keep the alert event for all APIs, but for role="status" add the wording to announce on insertion
… and then to clarify for both only announce on insertion if it is *not empty*
… to prevent breaking changes
MattKing: one thing from ARIA-AT, we are averse to treating alert differently — it has lost all its distinction
… saying the word "alert", for example, is now being treated as a bug
… there’s a lot of user blowback on this, especially for something like a chatbot, where the user hears "alert" way too often
spectranaut_: let’s discuss TheoHale’s issue next week
douggeoffray: I wanted to add, this just came up in Windows, NVDA/JAWS didn’t announce a live region when Narrator did
<sarah> I think part of the benefit to spec'ing adding role=status as also announcing on insertion would be to (hopefully) cut down on authors using alerts for announcements that are not semantically alerts, but which they want to announce immediately when inserted
douggeoffray: in Chromium today, we found out that UI implementation, it will fire on creation
… and we filed a bug for that
… so that it will only announce on text insertion and not creation
jcraig: that sounds dangerous
douggeoffray: we were seeing inconsistent results in testing
<jcraig> ss/it sounds dangerous to make the change in one engine, where other engines have aligned on a different behavior, and live regions are not yet testable in WPT. there's a real risk here of making the existing problems even worse across browser and screenreader combinations./it sounds dangerous to make the change in one engine, where other engine have aligned on a different behavior/
spectranaut_: think we need to keep discussing this
<Zakim> jcraig, you wanted to ask sarah why status is different from log and to ask why Matt why we would not fire the engine event; JAWS could ignore it or change their UI if they so choose.
jcraig: leaving a note for sarah and MattKing to consider
… I think we would still want fire the creation event
… and align the spec
… and JAWS could choose to ignore if they think it’s irrelevant
<scotto> one thing that can be a problem is when alert is given an accname (becuase it can be named LOL) and should that count as an auto announcement, or should that be ignored until content is inserted into the alert?
<Doug> JAWS/NVDA monitor live regions on text insertion, not on creation. We have cases where live regions are being created with the intended text to be spoken and JAWS/NVDA are not speaking that text but Chromium through UIA was firing a live region causing Narrator (based solely on UIA) to speak the content on creation. This caused a very different
<Doug> interaction based on the screen reader. After conversion with Mick from NV Access he explained the intent was to only speak on text insertion (which is what they do) and agreed that the UIA implementation was inconsistent with that intent.
<jcraig> Note for the minutes that several substitutions (scribe corrections) are listed in the minutes as "Succeeded" but the changes did not actually make it into the minutes... I'm not sure why. Please review the IRC log needed.