Meeting minutes
New Issue Triage
spectranaut_: aria 2086 nested headings
jamesc: from a live website. they have different levels, one native, one aria heading. We just didn't know what to do.
spectranaut_: sounds like we should agenda it
jamesc: I wasn't even sure it's an author error.
jamesn: it should be.
scotto: html won't flag it because it won't take aria roles into account.
spectranaut_: milestone for 2024?
jamesc: more than editorial. jawsTest mentioned that nested elements are not allowed so we could match that.
scotto: I think both authoring guidance and if ARIA more overtly stated what it means now, then aria-in-html could drop the less normative section around this kind of thing
jamesn: can we salvage some of that then?
scotto: yeah. 2024.
spectranaut_: let's agenda it. any takers?
scotto: will take a look.
spectranaut_: aria 2085.
… customize announcement of state
scotto: in openUI has been a proposal for a switch element.
… competing proposal to HTML
… what they keep on trying to do: a switch with states on both sides (day / night or dark/light).
… so I go to the designers and say "you'll need a label where it's clear what on/off does"
… push back from designers that that's not natural for, e.g., a.m./p.m.
… I'm not actually sure we should do it.
jamesn: we have opened the path towards a switch. This sounds like a radio button.
scotto: yeah, but that leads to similar discussions
jamesc: not clear if the proposal is about customizable state or a string that represents the current state of the control.
… I can see jamesn's point for just a label.
<Marcelo_Paiva> comment: switch with two states = a checkbox, but what if the switch has 3 states (on | unselected | off)?
jamesc: iOS and Mac have an API that would fit.
spectranaut_: if it's just about explaining why we don't do this, then 2024 milestone sounds good.
giacomo: just on jamesn radios. This might be due to the inconsistencies around operation.
New PR Triage
spectranaut_: 2 PRs on html-aam.
… on text edit
… seems like those have reviewers
… this is all around the discussion about fieldset maxlength
… then there's 2 PRs on DPUB ARIA.
… around deprecated roles.
… seems they are in a good place
jamesc: I'll get to the other one as well. Seems almost editorial.
WPT Open PRs
<spectranaut_> web-platform-tests/
spectranaut_: 42769 seems in a good place.
jamesc: yes, waiting for changes
describe grouping (and naming of the group) for exclusive accordions <details name>
scotto: this is due to the HTML update to allow details elements to accept name attribute
… which adds functionality where only one details element will be displayed at a time.
… nothing has been done to make this new functionality clear as far as accessibility APIs are concerned.
… some suggestions were to imply a grouping and give that a name
… but in aria it's not possible without an explicit grouping
… I'm not sure naming is always necessary or even helpful.
… Steve F has also taken a look and suggested it might be good if the browsers could update the mappings for summary to enumerate them.
… that would avoid adding a new groupings attribute. Instead of additional groupings (section, fieldset etc).
… people seem to agree they want an "x of y" announcement.
… implying that if you interact with one, something will happen to the others.
… and of course this just adds to the existing problems around summary/details.
Rahim: this issue impacts [zoom connection problem at scribe]
scotto: there can always be groups of related controls that don't fall into clear groups. E.g., related buttons like a toolbar. There's no way to provide an "x of y" announcement (unless you use a list and have a platform that yields such output)
<Rahim> the issue impacts multiple user demographics, but conveying position within set as Scott recommended makes sense
scotto: maybe that opens up the can of worms where buttons and controls could be given position-in-set aria semantics so that they could be allowed to expose thos values.
(thank you, Rahim.)
CoryJoseph: how would naming the grouping be different from encapsulating a section and naming that section?
scotto: I think it comes down to what you want the container be exposed as.
… they want a named group.
… in HTML that would be fieldset.
… the only way in HTML. (except the voldemort attribute)
… there's a note "needs to be grouped for accessibility". Then section would have to be named but then that's a landmark and that seems questionable.
CoryJoseph: and you'd lose the "x of y" aspect.
scotto: right. there was discussion around this. It ends up being a redundancy that you don't really need
CoryJoseph: groups all the way down.
scotto: some consensus that it wasn't always necessary.
giacomo: the idea of having this list of elements does not resolve the key point that something unexpected for the users, i.e., something unrelated collapsing.
… two different implementations leads to the same announcements. Say, a list of buttons. But one of them would do something unexpected.
scotto: I think they wouldn't announce the same way.
… i.e., button in list item would be announced differently from summary in list item
… but I want to acknowledge that this doesn't solve the whole problem. Maybe there's more that we can do and I'm happy if we want to do that here, but it's a problem that exists everywhere.
… for any collapsing items, e.g., tabpanel.
… there's an implicit assumption that switching closes the panel but that's not explicit anywhere.
Rahim: what would be the best user experience for this?
giacomo: I think I'd like to hear something that tells me the other elements will be collapsed.
… the relationship is important but collapse too
Rahim: when entering the group or activating the item?
giacomo: when entering the group
<Marcelo_Paiva> https://
Marcelo_Paiva: US design system has an accordeon compent. This has an option for keeping them open or closing them on activation of another
… we have good success with that.
spectranaut_: there seems to be some interest in making "x of y" counting work.
scotto: if an aria-controls relationship was made between all elements, then perhaps AT could do something with that.
jamesn: but what would it do useful?
scotto: but as Giacomo said, we don't have any parity. Getting beyond "x of y" would be much more than what I had wanted. hard if no platform decided to do that.
Marcelo_Paiva: seconding Scott. Some use cases from my end: helps users with cognitive disability to collapse all, avoiding walls of text. We then also have "open/collapse all" functionality to help further
spectranaut_: is this an HTML-AAM only change?
scotto: I was hoping for implementer interest to see if this has a chance of getting done.
spectranaut_: we'd have to describe what to expose though
scotto: I'd start with calculating setsize and position.
… we have that but it's scoped to certain elements.
… I assume we could update the platforms to expose it.
<Rahim> Will defer to James C. who is calling the shots, I'm just here for moral support :)
jamesc: I was somewhat surprised by some of the reactions. I don't have a preference how we expose this. Was there a specific proposal to consider?
scotto: I was looking for confirmation that there's interest. If html-aam exposes the name, then browsers would have to calculate setsize and pos-in-set. Can this property be exposed on an element that wasn't originally spec'ed to expose that.
jamesc: that seems possible for WebKit and I'd assume other engines are similar here.
… AT should also be able to deal with that.
… I wonder if non-sequential elements will be weird, producing effects across the document.
scotto: it wasn't discussed much. More thought of an 80/20 rule.
… so treating it as not a validation problem even if it's not used well.
jamesc: I'd phrase it as HTML flexibility.
scotto: there was also discussion around keyboard control for this but that would fall outside html-aam.
jamesc: we already have some similar controls.
scotto: yeah, how to move between them
jamesc: right. that sounds outside the initial implementations.
… but I can see how something styled like an accordion would make users expect arrow keys.
… if it's more a traditional summary/details, then I wouldn't expect arrow keys
scotto: agree
… I'll start with a change for html-aam, indicate potential places needed to change
Consider a mechanism to associate controls without an explicit grouping
spectranaut_: ties into previous item
scotto: gets more into the part we discussed around radio buttons earlier
… in HTML you push things inside radio groups. ARIA is a bit less clear there
… I do see a use case to be able to have, e.g., controls in a toolbar, can be grouped even though they're not explicitly done.
spectranaut_: are there cases where the browser can do the work already?
scotto: e.g., the radio button example I think would require guess work from browser to know they're related.
… for the toolbar, arguably anything in the toolbar would be given "x of y"
… but do we always want that or do authors decide?
CoryJoseph: is there really a situation where we don't think authors would want that?
scotto: fair point. I don't know. Anecdotally, some like it and some don't.
CoryJoseph: but that shoulds like something left for AT
jamesc: don't think there's anything that prevents AT from calling out the numbering.
… doesn't feel like a browser specific change
jamesn: but we don't expose this right now in the APIs so they don't calculate that.
jamesc: maybe misunderstanding. If there are five items in the toolbar, they could do that.
jamesn: but do they do the extra work?
… for, say, menus. AAM says that browser should calculate pos-in-set etc and expose that. Should we want AT to expose more than what's exposed? Should they really look through the tree and calculate that?
jamesc: where the default positioning is efficient, it shouldn't need anything extra.
<spectranaut_> menuitem: https://
jamesn: but isn't the browser exposing those properties instead of letting AT infer it from tree?
jamesc: I don't think so.
<pkra> s/jamesc: but/jamesn: but/
spectranaut_: I don't think we expose it.
<jamesn> https://
scotto: from internal discussions, people felt like they'd need to update how the API works.
jamesn: [recites spec from link]
jamesc: we can hopefully make that testable in WPT eventually. I don't think it's a real problem for AT.
jamesn: I just don't know how they all work to say
scotto: thinking specifically about toolbar. it's less clear than say menu or list.
jamesn: and then you might have radio buttons in a toolbar.
jamesc: way back when, there was discussions around toolbar. major UI difference between windows, mac, linux.
spectranaut_: at the hour. let's continue