Meeting minutes
scribe pkra
New Issue Triage
spectranaut_: aria 1947 on focusgroup
scotto: openUI meeting this morning spoke about focusgroup.
… want to move it into specs
… focusgroup provides a standardized way for roving tabindex / arrow key navigation
… but it goes way beyond those
… there are bound to be accessibility considerations
… list of links could be a case. at high level nice, but testing with AT today, there are potential problems
… filed it in ARIA instead of html-aam because it could be more widely relevant.
… e.g., people who can't use focusgroup but want something similar.
spectranaut_: let's add it to the agenda
jamesn: maybe deep dive, too.
scotto: main takeaway: this needs to go along with focus group. We should pay attention.
spectranaut_: aria 1946
arigilmore: came from another issue where switched none/presentation in the spec.
… jcraig spotted a detail that could use clarification
spectranaut_: 1 line change?
arigilmore: there might be more
spectranaut_: 1.3 as editorial
New PR Triage
Recommendation Status
daniel: we need a record that we're aware that we're ready to move ARIA to REC.
<dmontalvo> DRAFT RESOLUTION: Group agrees to request advancement of ARIA 1.2 to REC
<spectranaut_> +1
daniel: we should put out a resolution that the group agrees to move 1.2 to REC
+1
… then we have the record to show the WG agrees.
… no objections.
… thank you very much!
… target is June 6
<jamesn> +1
<scotto> +1
<Adam_Page> +1
<myasonik> +1
<jcraig> +1
<arigilmore> +1
<spectranaut_> bryan says +1 in the meeting
RESOLUTION: Group agrees to request advancement of ARIA 1.2 to REC
spectranaut_: thank you, daniel, for getting it published!
Exposure of HTML elements mapped to generic
spectranaut_: james teh had filed it. scotto had responded. the spec doesn't specify but generics can be ignored by browsers.
scotto: my idea was that the concept of generic being pruned from the accessibility tree is not outlined in the spec at all.
… my understanding how we defined generic was that nobody wanted to prohibit pruning generics
… UAs should be allowed to prune them.
… so I felt this should be handled in ARIA
… otherwise it would have to be slotted into the minimal role proposal
… but it would add complexity that I don't think we need
jcraig: I generally agree. We can adjust WPT tests to take empty string, null or something else. It shouldn't be too hard and makes sense.
… I can review a PR
scotto: I'll make a PR
jcraig: I'll file a WPT issue
spectranaut_: any other concerns?
Update from PR #1018 for nameFrom: heading
spectranaut_: when is this ready to merge?
… when we drafted new PR strategy at last TPAC, we set 1 implementation + 1 commitment
… we have webkit. but no other browsers.
jcraig: I believe we heard no objections from others in the past, so I think it's more a formal issue.
spectranaut_: should we already merge?
jcraig: I'd say let's get Jamie or Aaron to respond. But maybe don't wait for implementation.
… WPT comes into play
… making it testable
… then there's a related accName PR to add the steps there.
… I would take it but I'm blocked a bit so happy to see someone else take it.
bryan: I'll take a look
<jcraig> w3c/
spectranaut_: ok, then next step is feedback from Jamie and Aaron.
… then automated tests.
scotto: I was speaking to Aaron. He was hoping to see a list of things from 1.3 so that the team can get to implementations.
… last changelog is from 2020 though.
… there's probably a bunch of things that could be better surfaced if they are in the spec and changelog.
… a chicken/egg situation where people don't see what's waiting in PR.
… not sure what to do about it.
… but 1.3 is still not representative of a living standard.
spectranaut_: I think the new strategy can help improve it. PRs + issues on the browser side.
scotto: that's good but I'd love to have a changelog to just point to.
jamesn: I'll take some blame.
<jamesn> https://
jamesn: but e.g. CSS specs are doing things differently
… we now have some tests.
… CSS has this "support" section, pulled from caniuse.
… gives info on which browsers implemented it.
… gives both readers and implementors info.
… could we have something like this? From which source?
jcraig: I have a couple of links...
jcraig: this is the current list of results of the accessibility related WPT tests.
… if we can add feature specific labels, maybe even sub-feature level.
… maybe we can get a query that only shows the numbers of this view.
… I'd imagine WPT has some metadata that could be useful, at least in the source
… there's a metadata project in WPT
… we could make a precedent for leveraging this .
jamesn: would be not just "accname supported" but "part 1 of step x is supported"
jcraig: yes, if you dig into the tests, each of the subfiles could have labels that we could then use.
jamesn: for css, bikeshed grabs a fragment from caniuse.
… author puts in the snippet
jcraig: and caniuse is updated by browser evangelists.
… but I like the idea of using WPT tests.
… and more people might be interested in this.
jamesn: we should talk to respec as well.
… maybe a tpac conversation
… and FYI tpac. Our schedule was originally Thursday and Friday but all other groups we might want to meet are also those days.
… so we've moved to Monday + Tuesday morning.
<StefanS> +1 to moving
jamesn: I hope it's not a problem for anybody.
daniel: we just need to decide what time to do on Friday.
jamesn: or just hang out with other groups
spectranaut_: I'd reserve some time just in case.
jamesn: sounds good.
spectranaut_: any other business?
StefanS: I have one. we tend to run into validators complaining about IDs missing for performance reasons.
… if we try to workaround it, then some props might be missing or incomplete
… what does the group think?
jamesn: I think the spec would say: if an ID doesn't match anything, it would be ignored. If the attribute is required, it would be an error. If not, it doesn't matter.
StefanS: combobox controls
scotto: it's required. But it doesn't expect it to be in the DOM
StefanS: so the validators are overeager.
scotto: the spec could be clearer.
jamesn: I think if the spec requires it, it seems questionable since the technology just doesn't work that way.
… so if you find something, we should try and fix it.
… why do we have this requirement anyway?
StefanS: I think it stems from AT association
scotto: I think Sarah might have some experience from testing.
jamesn: that'd be good to know. otherwise, we should drop it.
… it makes comboboxes really hard
scotto: maybe we could be more explicit at indicating when there's a MUST to point to an ID, it's more about "when the elements is in the dom, it has to be there"
… also goes for active descendant.
jamesn: please file an issue