Meeting minutes
New Issue Triage
spectranaut_: a few from pkra that are editorial
pkra: technicalities; we can talk in the editors meeting
spectranaut_: another editorial for aria#2462
pkra: this is for editors
spectranaut_: aria#2461
Rahim: would be valuable to see how mappings are implemented
… and see where they’re actually declared in the source code
spectranaut_: should we schedule a meeting for this?
Rahim: yes, please
spectranaut_: aria#2460
… conflict for common use of <label> radio buttons
… the relevant HTML is the first example
… should we agenda thia?
pkra: seems like a misunderstanding
… please assign to me; I’ll ask for clarification
spectranaut_: okay, and feel free to agenda it
Rahim: Scott raised an issue last year about grouping non-contiguous radio buttons, this seems related
spectranaut_: please link that issue if it’s relevant
New PR Triage
spectranaut_: new PR from PDF-AAM
… aria#2466
… we have reviewers assigned already
… should we also agenda this to discuss?
zakk: yes, please
… this is the initial import for each AAM mapping
… this is an export from our Google spreadsheet
spectranaut_: let’s let the reviewers get to it
spectranaut_: aria#2464, from pkra
pkra: mostly for editors
… our CI isn’t working as expected
… this is also a warning to anyone with an open PR
… I’ll finish this and update all the open PRs
… but the older ones will be difficult because of merge conflicts
… let’s merge this one, and then I’ll rebase others
<scott> fyi - james craig is running late today, and may not be able to attend. i'm also not really here. bye
pkra: a couple minor changes to other specs because prettier is running on them, so we need to talk about it on the editors side
spectranaut_: I’ll review this
WPT Open PRs
spectranaut_: wpt#51107
Rahim: at the beginning of the year, the Interop gropu had to roll back some tests
… to prevent them from being counted in 2024
… so this is just reverting those back in
… this specific one has to do with the multiple aria-labelledby spellings
… so I’ll review
spectranaut_: and then we can merge
Deep Dive planning
spectranaut_: SVG is scheduled for week after this
… I’ll make an event for that
… also, heads-up that an accname whitepsace deep dive we had scheduled for Dec will be rescheduled for either March or early April
… keep an eye out
giacomo-petri: the cards deep dive can be removed from this list
pkra: can we close the issue?
giacomo-petri: yes, I think so
spectranaut_: I’ll close it (aria#2162)
spectranaut_: would you like to talk about any of these others?
giacomo-petri: html-aam#562 is about browser heuristics with tables
… but not ready to discuss yet
Daylight Savings starts 9 March in the U.S. For Europeans, that means meetings will be an hour earlier until the 30th.
😭
<giacomo-petri> better for EU people
<giacomo-petri> :D
spectranaut_: meetings will be an hour earlier until the 30th
Resolution to move DPUB to PR now that w3c/aria#2459 has been merged?
spectranaut_: a few weeks ago we discussed this issue from giacomo-petri
… there’s a normative change, so not fully editorial
Daniel: yes, a name from author change
… I’ll argue for editorial, but chances are we’ll need to go back to a candidate review snapshot
… giacomo-petri also raised some other issues
giacomo-petri: the other ones should be editorial
… but I think I found a separate mistake related to doc page break
… the examples disagree with the actual requirement
Daniel: okay, we should wait on this
spectranaut_: for the minutes, does everyone agree that this is editorial?
… or should we resolve these outstanding issues first?
pkra: is this in the spec, or something that ARIA JS is causing?
… the other issues, I mean, like page breaks
… in the spec itself, or maybe a problem with ARIA JS, JSON, child stuff that populates some of the inherited properties from the main spec
Daniel: not sure, will need to check
pkra: if the latter, then the problem is with the automation, and we’ll need to fix that rather than the spec
spectranaut_: Daniel, is there a chance we could still move to PR if the WG agrees that the changes are editorial?
Daniel: just this PR that just landed?
spectranaut_: yes
<spectranaut_> this PR: w3c/
Daniel: we have a high risk that if we send this to PR that it will be rejected for not being editorial
spectranaut_: do people agree to try for PR?
<pkra> +1
<hdv> 0
spectranaut_: any objections?
Daniel: if it gets rejected, then it will be delayed by another ~6 months
pkra: I did just confirm that the valuenow issue giacomo-petri discovered *is* an automation issue; not a spec issue
spectranaut_: no objections, so please do go ahead with proposal to move to PR
RESOLUTION: Move DPUB to PR as the group considers adding the superclass role as an editorial change
Cancel next weeks meeting due to CSUN?
spectranaut_: we don’t need to cancel
… since many of us won’t be attending CSUN
ARIA IDL updates: convert eligible attributes to enumerated, new ARIA IDL guidance and examples
spectranaut_: Rahim, you brought this PR back
Rahim: this was a draft PR, and now it’s ready for review
Aligning HTML spec with ARIA's style of DOMString? reflection
Rahim: at TPAC, we discussed ways of improving IDL
… for ARIA attribute reflection
… what motivated this work is that attributes have 2 aspects:
… the content attribute
… and the IDL attribute, formerly known as the DOM property
… those are accessors on JS objects
… correlating to DOM nodes
… every node gets a JS wrapper
… IDL comes into play when we want the JS representation to synchronize with the underlying C++ implementations
… always synced, always aligned
… we call that “reflection”
… aria-expanded ~= foo.ariaExpanded
… ensures the API types make sense for that they are
… boolean attributes are true/false
… nullable strings, non-nullable strings, etc.
… there should be no difference between reflected attributes
… this specific PR has to do with nullable DOM string
… as part of the getter, when the browser gets the value, it no longer checks to make sure the attribute is enumerated
… previously there was a check
… this issue loosened that getter
… so we have plenty of attributes that aren’t enumerated
… that we want to reflect as nullable DOM strings
… so that we can determine the absence of the string
… tl;dr we now have the ability to align with the HTML spec
spectranaut_: this is really great
… been an outstanding issue for a while
… is this issue closeable when we land the PR?
Rahim: the PR has landed on the HTML side
… and approved by HTML editors
… no implementation work is required
… really just a spec bug that was fixed
… we can close the ARIA issue now
… this was the easy one
ARIA IDL updates: convert eligible attributes to enumerated, new ARIA IDL guidance and examples
Rahim: going back to this PR
… after that TPAC discussion
… we talked about improving IDL
… there was consensus that the ARIA WG should really start treating more attributes as enumerated
… enumerated attrs have a very specific definition in the HTML spec
… treated in a distinct way
… for example, the `type` attribute for <input>
… there are a finite number of states
… when missing or invalid, it defaults to `type=text`
… this aligns well many ARIA attributes
… so this PR re-defines many attributes as enumerated
… the same way HTML attributes are treated
… you can review them all in the PR
… I also updated values table
… specified missing values
… clarified undefined
… and also allows us to update our values schema
… now we can have enumerated values that will really capture how things are handled on the HTML side
sarah: I saw aria-valuemin and arai-valuemax and aria-valuenow are all in there
… is that intentional?
… those stood out to me as ones that should accept any numerical value
Rahim: I think you’re right, those should be reflected as numeric values
… but there’s no role-specific reflection for those
… no, those won’t be enumerated
spectranaut_: let’s get some more reviewers, it’s a big change
… and normative
Rahim: jcraig should definitely be a reviewer
… I’d like keithamus’ review as well
keithamus: sure thing
Rahim: this will need some implementor changes
… on the Webkit side, we can remove some custom code and just use the IDL engine
… there’s custom logic we can remove/simplify
keithamus: very likely that the other browsers will have a similar situation
… custom C++ that can be removed
Rahim: on the Chromium side, reflect is not part of the HTML spec
… it’s an “extended” attribute, so technically not part of spec
… but on the Chromium side there’s reflectInvalid and reflectMissing, which is novel
spectranaut_: do we need more browser people to take a look at this?
Rahim: maybe doesn’t need implementor eyes on it yet, just that the ARIA WG is satisfied with the PR
Rahim: on the HTML side, there’s an IDL block for every interface
… wasn’t sure if we wanted to do that in ARIA
spectranaut_: let’s do these reviews offline
… I’ll also review
Aligning HTML spec with ARIA's style of DOMString? reflection
Does aria-atomic have real-world use cases?
Aaron: when ARIA was first being conceived
… how are we going to deal with content changing on the screen
… and we invented live regions
… and then “what if one node changes in a region?”
… we didn’t know the answer
… so we created aria-atomic
… so that people can control it
… but when I see it in markup, it’s usually the author didn’t know what it was for
… and recently TalkBack started to improve web support
… and they asked “is aria-atomic important?”
… if use cases are only theoretical, then I’ll tell them to de-prioritize it
sarah: I have had cases where I wanted to use it in the past but didn’t because of the lack of support
… not worth doing with partial support
… inconsistency is worse than nothing at all
… usually when there are surgical DOM changes like that, I’ve just found that custom visually hidden live regions is a better use case
… and will be handled even better by ariaNotify
<hdv> +1 to Sarah's point
hdv: I’ve also been thinking about use cases
… and came up empty for this
Aaron: can we keep it in the spec but deprecate it?
… add a note that it’s not consistently supported now
sarah: we might want to poll people who work on smaller things with less infrastructure than the big enterprise applications I work on
Aaron: let’s say you have a word processor with a status bar showing the row and column your cursor is on
… I think the idea was that you could have a label in front of it
… you could put aria-atomic around the value that the label is pointing to
sarah: yeah, that’s similar to things I’ve encountered in the past
<hdv> +1 to deprecate aria-atomic
spectranaut_: is anyone against deprecating
… no
RESOLUTION: deprecate `aria-atomic` in the spec