Meeting minutes
Happy New Year 🎉
New Issue Triage 🐜
associationlist and related roles have tediously long names https://github.com/w3c/aria/issues/1662
Requesting extended review period of ARIA 1.2 CR2 https://
previous already addressed
Listitem in a list as a possible aria-activedescendant ID reference target for combo box role https://github.com/w3c/aria/issues/1668
jamesn: Scott?
Scott: need to talk through this with Stefan
sarah_higley: seems similar to secondary actions
jamesn: Sarah, will you follow up in issue?
sarah_higley: will do
jamesn: leaving unmilestoned
A role specifically for pagination https://github.com/w3c/aria/issues/1669
Scott: argument from the WICG discourse is for consistency and i18n...
jamesn: from thread, this could be an attribute rather than a role
Scott: someone thought HTML should implement... type=something for navigation?
jamesn: can we push this back? convo has stalled... role="navigation" aria-label="pagination" may do enough already unless more specific suggestion provided
Scott to comment in issue
New role for splitbuttons https://github.com/w3c/aria/issues/1670
jamesn: no opposition... can be grouped buttons, but maybe not necessary
sarah_higley: Microsoft moving away from grouping buttons as a single tab stop
jcraig: Mac never has combined grouped button (Segmented Controls) as a single tab stop unless it's used as a mutually exclusive selection like radio group or tabgroup
jamesn: milestoned to 1.4 for further discussion
<sohara> potentially related to secondary actions rather than needing a new role
New PR Triage 🎁
New PR Triage 🎁 https://
abstract roles remove 'name from' https://github.com/w3c/aria/pull/1667
Scott: noticed inconsistencies
jamesn: do folks approve? care?
Scott: alternative I saw would be to match what inherits those, but that's not always a 1:1 match, like nameform:author
jamesn: currently I recall nameFrom defined on all (even if defined as prohibited or n/a)
jamesn: joanie any problem with removing? this seems editorial. No objections. Will remove after Peter and I review.
add note to aria-roledescription https://github.com/w3c/aria/pull/1666
jamesn: needs reviewers, jcraig and sarah_higley
jamesn: next two editorial. done... Will merge
Deep Dive planning 🤿📆
Deep Dive planning 🤿📆](https://
<jamesn> https://
jcraig: Is this related to User Actions https://
sarah_higley: a little different. would expose visible buttons
Clarify usage of aria-haspopup 🥤🆙
[Clarify usage of aria-haspopup 🥤🆙](https://
Scott: come up recently b/c of related work in OpenUI
in those cases, any sort of thing could "pop up" but the value set is limited
IA2 mappings are awkward... why do we need the limited value set? do we need to specify what type of thing may popup? if it's almost but not quite a menu or dialog, does ARIA need to be the bottleneck, or can the author just aria-haspopup="bikeshed" (some unspecified)
Scott: people are using this in new ways... authors are confused, for excample list of links is not a menu
<sarah_higley> from experience, sighted users don't even understand the difference between a menu popup and listbox popup after having seen them and interacted with them
aaronlev: historically ARIA had values mapped to the MSAA values, may no longer be necessary
spreading (unnecessarily?) this legacy complexity to HTML element proposal
sarah_higley: In theory, I'm not opposed to generalizing the use case, but what is the effect if we "lose" existing AT behavior popup menu?
Scott: baggage values: true, false, menu, other?
sarah_higley: would change long-standing AT experience
<sarah_higley> the "oh no we effed up, start over" approach 😄
could deprecate aria-haspopup in favor of a new similar aria-popup=true? (still would have author confusion but allow legacy behavior)
sarah_higley: I increasingly like the idea to deprecate and start over
James Craig: ackno self
<jcraig> s/ackno self /fully acknowledges self doubt on this suggestion/
Scott: problem, any aria-haspopup value now makes it into a menu button (jc: I this limited to Windows AT?)
[scribe missed some quick chatter]
sarah_higley: not just an forms mode issue, also it's a menu button
Sarah: preserve only the menu mapping, and changing mappings for other values to not map to menu button
aaronlev: could include aria-controls to the element type in the DOM
jamesn: the controlled "popup" may not be in the DOM yet
next steps?
Scott: need to talk some more before proposal
Inconsistency between native and ARIA listboxes when implicit aria-selected is provided 🕵🏻
[Inconsistency between native and ARIA listboxes when implicit aria-selected is provided 🕵🏻](https://
<jamesn> If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false.
joanie: as long as the user is interacting with a listbox, AT can use internal selection, but if user not interacting, that no longer applies
Scott: text was added due to awkwardness of allowing list boxes to have aria-checked=true
Sarah: @@@
Scott: purposeful divergence
sarah_higley: default selection on focus already existed though
adjourned
<sarah_higley> me: we were trying to have a difference in default behavior of checked vs. selected, and write text for selected that matched the already-existing behavior in browsers for selection in ARIA listboxes