Meeting minutes
New Issue Triage
jamesn: core-aam/#215
… this is probably for the Apple folks?
Rahim: yep, there’s internal discussion — I’ll update it
jamesn: aria/#2089
pkra: this is mine
jamesn: everything is meant to inherit global states and properties, so this is a bug
pkra: I’ll take assignment and fix it
jamesn: dpub-aria/#62
… no need for us to discuss, let’s just leave this
jamesn: aria/#2087
pkra: spillover from editors meeting
… let’s discuss it more in the next editors meeting
New PR Triage
jamesn: aria/#2090
scotto: needs jcraig’s review
jamesn: added jcraig and James Teh
… other reviewers welcome
jamesn: aria/#2088
… please review and comment
… it’s still draft though
jamesn: aria/#214
… editorial, so doesn’t need wide review
shigley: I worked on this, I’ll review it
jamesn: I’ll review as well
ACT Rule Review
jamesn: Wilco asked us a month ago to look at 3 ACT rules
… please review and comment
… they’re creating rulesets that different automated checkers can use in a more standardized way
… ARIA errors won’t necessarily be a WCAG failure
… these are all 1.2 based, so 1.3 might introduce some new failures until ACT is updated
scotto: I reviewed and approved all three
dmontalvo: we should just focus on ARIA rules and whether they disagree with the ARIA spec
jamesn: please review and thumbs-up or comment
<melsumner> These are some lint checks we've put into Ember's linter so it's great to see these at a broader scale. :thumbsup:
dmontalvo: we’re trying to publish these by the end of next week
Consider a mechanism to associate controls without an explicit grouping
jamesn: why did we leave this on the agenda?
scotto: we mainly discussed `details/summary`
… seemed a little weird that buttons and other controls could have aria-posinset when they‘re descendants of toolbar
… wonder if we’d want to call that out
jamesn: I don’t see any reason why you’d need posinset for toolbars
… you never need to fetch more things
MattKing: we use it on tabs
jamesn: why?
… sometimes we do because the browser doesn’t calculate correctly
MattKing: my question on this is how do you label the group if you don’t have a grouping mechanism?
jamesn: yes, while HTML supports some of these — like radio buttons — is it a good idea to have discontiguous things belong to a group?
… isn’t the whole concept confusing?
MattKing: discontiguous?
jamesn: radio buttons separated with text elements, for example
scotto: you could have a single-selection grid right now and you use radio buttons to allow selection of a row
jamesn: and that works until you have any other thing focusable in that grid
MattKing: why use radios in that scenario?
scotto: because they’re the simplest way to do single selection
sarah: when you have a control inside a grid cell that changes the selection of that cell‘s row, what control would you use?
MattKing: you could probably use any toggle-able control
<melsumner> I'd allow checkboxes but probably not radio buttons. :Shrug:
scotto: the reason I’d advise someone to use radio is because of desktop support and iOS row focus behavior
<melsumner> wait I think about tables and grids as different things and I'm hearing us interchange the terms
Mario_Batusic: if you use radios in a grid, or textbox between radios, then you disturb the normal keyboard expectations
jamesn: agree
sarah: if you need this to work in mobile, there’s no choice but to use radio
… cards are another example, where they can be single- or multi-select
… keyboard behavior is handled manually for those
… and so far, that’s not been a problem — it’s semantics and selection communication that has been difficult
… so I think this will be helpful for app-like contexts
MattKing: this is why I want listbox to support both single- and multi-select
sarah: on mobile, gridcells are not selectable
MattKing: there are certainly interop issues, but that shouldn’t necessarily influence the spec
sarah: but those interop issues are unlikely to be resolved
MattKing: when AT users encounter a radio group, they have an expectation to traverse them all to discover what the options are
… this changes the fundamental purpose of the radio pattern
jamesn: I’m still concerned about the keyboard interaction
… radio feels like a non-starter for these scenarios
… live regions can be a workaround for poor AT support for conveying selected states, not ideal but possible
scotto: let’s table this part and finalize the first part
… about posinset with toolbars
MattKing: is there any appetite in this group for adding a single- and mult-select grid example in APG for first half of 2024?
scotto: I think that’s a great idea
handling multi-selection / selection confirmation of action for menus
scotto: listboxes right now have poor multi-select support
… we talked about this with combo boxes being able to open up menus
… there are use cases where you might want to select multiple things within a menu
… like rich text editor
… like a menu that exposes bold, italic, etc. and you want to be able to activate multiples of them without the menu closing
… i.e., just keep the menu open until the user is done
MattKing: we distinguish between space and enter — space just activated, and enter activated-and-closed
… but got feedback that it wasn’t discoverable
… and from Apple, not feasible
… the problem is there’s no affordance for the user “being done”
… a good example is the assignee UI in GitHub
… seems like many of these should actually be non-modal dialogs
Rahim: what’s the mouse and voice control experience, to know whether something supports multi-selection, and how to close
… so like MattKing said, this is really about having dedicated controls for each function
MattKing: the GitHub assignee UI does not need to be a menu; it’s really just a disclosure
keithamus: we’re actually changing this GitHub UI to a dialog
… and there will be a dedicated OK button
… and mouse users won’t be able to dismiss by clicking outside
… it will be a modal dialog
scotto: I understand all this, and I still think there’s merit for menus to not *always* close upon selection of a menuitem
jamesn: any more to say on this?
scotto: not urgent, but please offer other ideas
<melsumner> If folks aren't willing to refactor their broken widgets idk if that's something this group should be taking on TBQH. Sometimes implementations are incorrect and have to be remediated, that's just part of the job of web development.
sarah: this seems like a very straightforward improvement we can make for menus without diving into comboboxes and dialogs
MattKing: we still need a way to convey to users how the dismissal will work
… keyboard experience, voice experience, etc.
… that will need to be documented
scotto: that’s fair