Meeting minutes
New Issue Triage
spectranaut_: aria #2440 from scott
scott: we can discuss it a bit more during the agenda's related issu
… this was dropped during aria 1.2. We have something similar open now.
… so re-opening
… can be agenda'd some other time.
spectranaut_: next aria #2439. I'll move it to core-aam
… core-aam #247
… alice was trying to work out how activedescendant works.
… I'll take a look
New PR Triage
spectranaut_: no new PRs
WPT Open PRs
spectranaut_: wpt #50679. an interop issue.
… jcraig not here. let's follow up later.
Deep Dive planning
giacomo-petri: spoke with pkra this week.
<spectranaut_> w3c/
giacomo-petri: we want to try to get traction on this.
… output for end user is very different, depending on tech involved.
… we need a conversation with browser people. Work out what we need to do.
… we want to present concerns and difficulties, work out how to approach them together.
spectranaut_: is there a time you had in mind?
giacomo-petri: depends a lot on james, aaron, maybe firefox
spectranaut_: is this ready or does it need more work beforehand?
giacomo-petri: I think we can start with this issue - svg being exposed differently. Leads into differences between "simple" and complex images. Not sure that's where we want to start.
pkra: we think this is a good entry point. If we can only solve the immediate issue, that's good. If we can get from there to the various issues filed in recent years, that would be great. But either way, we need vendors at least.
spectranaut_: ok. tricky scheduling with all of them. Let's wait until we have some on the call. Maybe an email thread.
giacomo-petri: yes, next month would be fine
Remove name required from alertdialog, dialog, form, grid, radiogroup, table
spectranaut_: this has been open for a while, though not too long.
pkra: there was recent push back from the community. But this has been reviewed. Unless we revisit it, what's missing to merge.
scott: right. We wanted to weaken the requirements to match HTML and WCAG.
… last time, we had agreed that sometimes a name is not needed - even though it usually is.
… recent push back reiterated this discussion once again.
… right now, if a group doesn't need a name from a WCAG perspective, then it's really a false positive. Most checkers ignore this. So aligning with this reality seems good.
… I don't mind either way. I find it problematic that after a decision this discussion starts once again.
spectranaut_: reading it today, it looks like the push back is about radio group. So maybe we just remove that.
aardrian: I feel the same. Other than that, we could fix an issue with axe. If they say we don't do this, we can point that out to users.
scott: but we did. and they said that. it's linked and everything.
… still here we are.
aardrian: thank you.
siri: two question. how does a use know that they're grouped together, if the name is removed? How is focus change dealt with?
… feels like radiogroup more than dialog.
scott: to reiterate. We're not saying that most need a name. It's only that we acknowledge that in rare situations, name is not necessary. And an absolute statement where missing names are flagged but effectively false positives, is not helping people.
spectranaut_: so the question: can an author create an example where a name is not required. And htat seems to be the case.
<aardrian> Because I missed the axe issue referenced in the issue at hand: dequelabs/
bryan: I can see use cases for this. Large areas where toggles switch visibility of parts. So I'm in favor of changing it to SHOULD.
<pkra> +1
spectranaut_: ok, so there seems to be continued consensus. Can we merge?
<Adam_Page> +1 generally, and also +1 to including `radiogroup`
pkra: do we need to do something before merging?
scott: the only change I'm aware of is filing an issue against IBM's checkers that it's changing from MUST to SHOULD.
… afaik they're the only one who calls this out.
spectranaut_: that sounds great.
<giacomo-petri> we do too
<aardrian> +1
spectranaut_: then there's MDN / APG. Do we need something for APG?
pkra: could we just file one on APG?
Adam_Page: I think they need a slight change.
spectranaut_: ah, thanks for checking. Could you file an issue?
… ok let's merge and check in on follow ups.
A generic element (with aria-live) intervening with the parent/descendant relationship.
giacomo-petri: when we have required parent/child, a generic intervening is allowed. But if properties like aria-live are set on the generic, then the generic is exposed.
… this can lead to problems. In the example, it maybe become a/the list item.
… it seems unclear what should happen.
… but it's not clear to me what we want to happen.
spectranaut_: one issue is to be clearer in the spec that more than generic is allowed?
scott: I assume the idea to allow intervening generics was that browser would ignore them, so parent/child would be fine.
… but since browsers don't always treat them as ignored, then the generic role is exposed and intervening.
… so either browsers should ignore generics even when they're exposed this way. Or the spec should say that it only means generics that are ignored (or role=none)
sarah: IIRC when we built test cases, it was working ok. It would be great if we didn't have to change the spec.
… rewriting it seems tricky to me.
… e.g., group.
spectranaut_: +1 to needing browser input.
… the difference between role and generics is always a bit murky
scott: none removes them. generics works for various elements and text nodes. If it doesn't have anything browser detect, they prune them. But if anything relevant (tabindex, aria-live) is used, they do show up.
… for none we have global properties resolution. But it will then revert.
aardrian: so none is also theoretically mutable.
sarah: about list. It seems to have the most issues. The others are a bit better.
… looks like a lot is suddenly lost. VO is problematic. Maybe it could be made to work.
… menu and listbox seems more manageable.
… but browser people need to weigh in.
… it feels like some quirks could go away
… I can link my old test case.
spectranaut_: and this worked for menu but not regular lists?
sarah: yes. also jaws, nvda, not narrator.
… on safari, role=list goes away in a way that sounds like browser mapping more than screenreader.
spectranaut_: then let's follow up when we have some browser people. But let's have more input from people on what they want to see.
<sarah> (I mumbled, narrator is the same as jaws and nvda, largely, in that it does worst with list and OK with listbox and menu)
thanks, sarah.
aaron: I think we undid it because it was causing problems. If we become too draconian in the markup, then users report problems with applications.
scott: the quirks come from aria-live etc triggering role=generic. those seem to trip things up.
aaron: ah, ok. More tests would be good.
sarah: I'll do a more comprehensive thing. Weirdly, list seems to be the worst.
aaron: I don't immediately see a problem with intervening generics that have aria-live, tabindex etc on it.
sarah: great. I'll try to get jcraig to weigh in
aaron: jamie might have different opinions, too.
… if voiceover has a problem with what chrome is exposing, then that's separate of coure.
sarah: safari seems to strip the roles which obviously messes things up
aaron: right. voiceover is sometimes more strict than other AT.
pkra: do we have an assignee?
sarah: I guess I volunteered.
Should the ARIA WG standardize heuristic-based ignoring of ARIA and related features? And if so, how? agendabot]
spectranaut_: this was from jcraig. So let's skip
Group as allowed acc child of role menu if acc child of menuitem
giacomo-petri: I wanted to understand if this is the intended behavior.
… is the example in the issue ok?
… can a group be direct child of a group inside a menu?
aardrian: in a menu you can have separators. Those effectively provide grouping. Not sure why this use case would be useful.
giacomo-petri: I opened it because of allowed children in its table.
… this is not clear from the spec. I just wanted clarification.
pkra: does it work in practice?
giacomo-petri: I think it's announced as expected.
spectranaut_: that's a good argument. but group without a name is a generic, no?
<siri> https://
MarioB: I don't understand the point of the example.
giacomo-petri: right. In HTML you couldn't. But here it seems so. As a tool vendor, I'd like to know.
aardrian: sounds like someone needs to do some testing. Then we can make an editorial change to match?
spectranaut_: yes. any takers?
giacomo-petri: I'll take it on.
spectranaut_: thanks. Then re-agenda it.
Should html aam provide mappings for other user agents?
scott: just to recap. We had an ancient issue for Android mappings. It was incomplete back then. Revisiting this with Rahim, we thought it's worth doing.
… not just Android, but also iOS etc.
… the question is: how far do we go?
… so two questions: How far to go? How do we find people who represent the platform (and are willing to help)?
spectranaut_: +1 from me. I've been asked for both iOS and Android mappings. I had no good answer.
… finding someone is of course a bigger challenge.
aardrian: if we have resources, it should provide enough to make the implementation stick. It might be a good opportunity to reach out to vendors as a way to reach developers.
spectranaut_: did we know something for iOS?
scott: discussed some of this with rahim. We already have differences between MacOS and Windows for various roles.
… even macos and ios might treat elements differently.
<aardrian> +1 to Scott's statement that iOS / macOS present things to users differently from one another.
scott: and I'm aware that Android is different.
aaron: it's a question of resources. If there was another browser engine to work with, that might help
… if there's no tangible result for users, it seems worth it.
spectranaut_: doesn't firefox work on Android?
aaron: I'm not sure they do.
… but that would help.
… the AAM is most helpful when you have multiple browsers.
spectranaut_: so we leave the issue open?
scott: well, the old one is from 2018. And it didn't go anywhere.
… if it's not a priority for browser, then I don't see why we'd keep it open.
aaron: fwiw, we have very good tests in chromium. That would get you a basic version. But it probably has gaps and missing nuances.
spectranaut_: right. But it's really about finding a champion.
pkra: we should match the "needs champion" label.
spectranaut_: should we move it to the aria tracker. It touches at least core-aam.