Meeting minutes
New Issue Triage
<jamesn> https://
jamesn: #1950
scotto: probably for ARIA 1.4
jamesn: agenda for next week?
scotto: sure
jamesn: #1948
scotto: supposed to be taken care of by Anne’s PR
juanita_george: I’ll review
jamesn: #194
BGaraventa: is this for background images?
scotto: this is because one can use CSS pseudo elements to concatenate alt text
… but Chromium is allowing that to trump visible text
… this allows some to visually render something and then override the accname with pseudo element content
jamesn: let’s agenda this
jcraig: CSS has had a supported capability to override alt for some time but this developed later
jamesn: #178
… anyone familiar with IA2 who can explain this one?
benb: I’ll take assignment of this one
jamesn: #1947
… this one’s already on the agenda
New PR Triage
jamesn: #1949
… if anyone else wants to review, please do
jamesn: #179
… would be good for spectranaut to review
… I’ll also request aaronlev’s review
Deep Dive planning
jamesn: anyone want a deep dive for the next few weeks?
scotto: maybe we should decide after the next two agenda items
Considerations for focusgroup
scotto: there’s currently no one driving this, but it’s not unimportant
benb: it’s on my team’s active backlog
scotto: in toying around with this, it became clear that — at least in the explainer — there’s no overt mention of how this would work from an accessibility perspective or usability implications
… e.g., no visual indication of focus for the group or guidance for roving tab index
… has implications for ARIA menus, listboxes, etc.
… nothing called out in the docs yet for a sighted keyboard experience
… but when testing out the current implementation in Chromium, this seemed to work quite well for patterns that expected this behavior — menus, toolbars, etc.
… but intermixing elements that would result in JAWS and NVDA switching modes was problematic
… that’s why I wanted to raise this issue here in the WG
… we should take a close look at the explainer and consider commentary
… and arguably this is a good feature
… allow people to quickly navigate large blocks of focusable elements
… we already have roles in place where this behavior is already expected
… what kind of mappings would we need to give to AT — like lists of links, etc., where arrow key navigation should work
jamesn: this seems really useful and that people are already doing in frameworks all the time
… don’t see any issues in terms of exposing this to visual user
… potentially confusing to use different keystrokes in different places, but it’s already highly custom in frameworks
… I support this and want to give it a closer look
Matt_King: I’ll echo that this feature is kind of a shortcut; lets you avoid custom JS when implementing APG patterns
… devs already had a responsibility to implement it correctly to avoid authoring errors
… but I would love to explore whether user agents could do something to visually indicate the focused grouping
… that would be awesome
… and if there are things we can do in the explainer or within the feature itself to avoid some of the mode-switching AT problems scotto described
sirib: how will the user know what the keyboard behaviors will be? I’m concerned for the end user
scotto: another potential feature I can see for focusgroup is — for better or worse — there are people who’ve requested that toolbars, listings of buttons, etc. expose enumeration to AT
… something like this, purposefully including things that should be individual tab stops could cause user confusion
Matt_King: if you’re using toolbar, tab, list, all those things support posinset and setsize
… but we wouldn’t want people applying focusgoup carelessly to divs, etc.
scotto: it will be a global atttribute, so they could do that
Matt_King: so if they did that, what role would we give the div, and/or should that be an authoring error?
… would we respect focusgroup on a generic container?
scotto: I think next step, apart from a deep dive, is: anyone who’s not familiar with this proposal, please read through it and consider commentary
… there is an implementation in Chrome Canary you can try out
… now’s the time to influence the spec
Matt_King: +1 to deep dive
… and put together a small group to create some APG examples using Chrome Canary
jamesn: let‘s use #1947 to collect questions we have, comments on our experiments
… and then we can schedule a deep dive for next week if enough participation happens
… or by the following week
jcraig: I’m out next week, so I’d prefer the following week
jamesn: I’ll pencil in a deep dive for the week after next
<jamesn> w3c/
jamesn: if no one’s put in anything by next week, then we’ll postpone the deep dive
scotto: I’m raising the issue, but I’m not the champion — everyone, please come prepared
[Role Parity] What do we do about summary element?
scotto: accordions are being prototyped right now to use details/summary, and that exposes some gaps
… and the spec allows arbitrary content in the summary
… this has created some problems because nested interactive elements are allowed
… we have disparate mappings for summary across platforms
… but the mapping of the underlying element isn’t necessarily clear right now — it’s like a button, but not quite
… we have the opportunity to either double down that this is a button or we come up with a new role that indicates the element itself is interactive but can also have interactive children
scotto: data has shown that 50% of summary elements in the wild contain interactive children
Matt_King: VO, NVDA, and JAWS all show me button expanded/collapsed for that element
scotto: VO shouldn’t be doing that
… Webkit and macOS VO (notably not iOS VO) in particular are actually demonstrating how this could work, and maybe *should* work
Matt_King: a side comment about accordions
… the other problem we’ve encountered in the APG is handling summaries that need to be headings
Matt_King: I hope we don’t add another role here
… if there’s some movement toward allowing buttons to be composite, that sounds super complicated — and we should have that conversation before this one
… is there urgency to solving this particular summary problem?
jamesn: I want to step back. This is a problem we all see all the time, another example is cards with nested interactives
… and although there are solutions in code, no one seems to want to use those techniques
Matt_King: exactly, let’s solve that higher-level problem first
… it could be the case that we change nothing at all for non-composite buttons and links, but we allow some differentiation for buttons and links that are detected to be composite
… we don’t necessarily have to break legacy
scotto: I agree
… we have another deep dive topic here
… re: your question about urgency, this is something that is happening now
… a PR has been made to allow for details/summary to be used for accordion implementations
… if this gets pushed and implemented in browsers, then this pattern will proliferate
Matt_King: that reinforces to me that we need to address the underlying issue
… could we have a separate session to understand this accordion issue specifically?
scotto: beyond just wonky AT behavior, the underlying mapping issues are significant
jamesn: shall we schedule a deep dive?
scotto: I have a few different proposals in mind
… but I want to hear other perspectives
… I see two routes:
… #1: because this element has a variety of different mappings and is being exposed in different ways, the non-button versions are working quite well — see Safari — there could be a role for this that works
… #2: we do a larger re-evaluation of how buttons work in general and make that all consistent and figure out how to handle nested interactive elements, e.g., secondary actions, then platforms could change their mappings
… it’ll be a big lift either way
Matt_King: for both routes, mapping changes will be necessary
scotto: yes
jamesn: let’s have a follow-up
scotto: yes, let’s do it after July 4th
jamesn: we’ll schedule it next week
ARIA 1.2 is a w3c Recommendation https://www.w3.org/TR/wai-aria/ 🎉
jamesn: thank you to everyone who made this happen!
Matt_King: congratulations!
jamesn: we’ve learned some things about the process to make our next version move faster
scotto: did we resolve all 1.2 issues?
jamesn: there are a few unresolved, but we can push out our first public working draft
Matt_King: the editor’s draft on GH pages right now: is that our first public working draft?
jamesn: probably
… I need to double-check some things there
… we did have stable vs. main, but we’re kind of doing away with stable, which should make editor‘s draft the main