W3C

– DRAFT –
ARIA WG

07 March 2024

Attendees

Present
aardrian, Adam_Page, CurtBellew, Daniel, Francis_Storr, giacomo-petri, katez, keithamus, pkra, Rahim, sarah, scotto, StefanS
Regrets
-
Chair
-
Scribe
spectranaut

Meeting minutes

New Issue Triage

jamesn: 2140 on aria

w3c/aria#2140

jamesn: any comments on this...?

jcraig: this sounds editorial. its allowed in other areas, I think its a bug in that one sentence

aardrian: I could do this

jamesn: w3c/aria#2137

jcraig: we are going to remove "orphan" role tests to some tests to a tentative file... this is not something that is actually speced in ARIA

jcraig: orphan tests are gridcells that are not in a row or table

jcraig: though these are author errors, we do not make clear what the user agent should return in these scenarios

jcraig: should it be left to implementation detail? there are differences in the implementations

jcraig: the aria working group should decide what to do. this might have html-aam downstream work

jamesn: should we agenda for further discussion?

jcraig: probably also a deep dive candidate

jamesn: w3c/core-aam#223

<scotto> was only going to comment on the fact that i agree. html aam work. there are already some instances of contextual roles exactly about orphaned content

jamesn: should we leave this going in discussion between scott and james teh?

scotto: one of the reasons this is coming up because we keep punting association list down the road

jamesn: yeah... ok... well.. should we talk about again?

scotto: doesn't need a deep dive. I think last we talked about it, detailed lists should just be lists. whether we do role description, I'm unsure. but we should finish discussion

jamesn: agenda'd

jamesn: w3c/aria#2135

jamesn: should we agenda?

jcraig: yeah I think so

jcraig: dominic should be there for the discussion

jamesn: w3c/html-aam#535

scotto: I filled this for myself

scotto: to see if anything needs to be mentioned in the naming steps.. finally putting together wpt for minimal role stuff

scotto: then I saw this should statement

scotto: how is naming handled for things that have draggable attribute?

adam: does putting draggable make it focusable?

jcraig: no, it doesn't even make it draggable

jcraig: complications with that are why we dropped the aria properties

jamesn: w3c/html-aam#534

scotto: val assigned her self to make platform bugs, we should do any more work on this until those things land

New PR Triage

jamesn: w3c/aria#2134

jamesn: two approving PRs, I think we can merge

WPT Open PRs

jcraig: I'm working with anne on: web-platform-tests/wpt#44971

Adam_Page: this one is still draft: web-platform-tests/wpt#44965

<scotto> did i do something wrong for web-platform-tests/wpt#44934 to not show up in this list?

jcraig: I'll review this one and merge web-platform-tests/wpt#44600

jcraig: unless the removed tests should be put in tentative

jamesn: they look fine to remove to me

Deep Dive planning

jamesn: nothing to schedule for next week or following week

Daylight savings time

jamesn: if you are outside of the US and canada, the meeting time will shift

for the time for the next week, if you don't have daylight savings time

Add `nameFrom: heading` steps to computation after spec addition ARIA PR #1860 is reviewed.

to discuss this comment: w3c/accname#182 (comment)

jcraig: to describe briefly, tthe first heading is expected to contribute to the name from authors probably

jcraig: but depth first search will slow down name computation

jcraig: I think the user would notice on all of these roles

jcraig: there is another search, iterative deepening first search

jcraig: this will work most of the time, but there are examples which really don't make sense

jcraig: see scott's examples

jcraig: this may or may not be an edge case

jcraig: we need consensus from wg and implementers because of the performance hit

scotto: the issue is that I understand what james is saying, I don't want a performance hit, but I can't say these are edge cases, I see these patterns everywhere

scotto: I found three sites that would have unexpected headings for the name of the article

scotto: they are using the mark up pattern that html says they should use

jcraig: they are using the hgroup?

scotto: some people are using the hgroup

jcraig: on a lot of sites there are lots of extraneous divs

scotto: I would expect divs without roles to be ignored

scotto: but what about div tab index -1?

jcraig: I would need verify but I don't think that would improve the performance

jcraig: deep vs breadth is the critical part, parsing the nodes and ignoring them won't help

jcraig: the critical blockers, we need to hear from chromium and gecko

jcraig: if they come back and say "eh it's not much of a problem", then I'll dig deeper into webkit and get some numbers

jamesn: it seems like the alternative proposal has too many weird consequences... with unexpected names occurring frequently. didn't apple already implement something similar for articles?

jcraig: I filled the orig bug a few years ago, but i said the spec should be more permissive in the way we choose the name. voiceover was naming things based on what it knew was a heading inside. webkit obscured some extraneous divs. voiceover's search was fast enough

jcraig: sounds like something you don't want, iterative deepening, so maybe this is a choice between standard depth first search or scrapping name from heading?

jamesn: you are doing something with html according to specification, and you will get something unexpected

jcraig: I'll change the PR to use deep first search, and then it will unblock implementaitons

jcraig: then we can investigate the performance cost

jcraig: unless the web engines are conscious about potential perf costs, the change can include a way to measure the change

jamesn: I'm curious about.. aren't we calculating the accname for all the elements anyway?

jcraig: we don't compute the name until we land on it

jamesn: is that why it takes so long for the acc tree to come up?

jcraig: in the dev tools, it takes a while because it's spinning up the acc tree and doing additional calls

jcraig: when you land on a article, you have to go through the WHOLE subtree to rule out name from heading

jcraig: if there is no heading that will take a while

scotto: contextual roles for header/footer/aside, etc

scotto: talking to aaron lev, aaron was saying that if we spec this to be based on the acc tree rather than the dom nodes, it would be more performant

scotto: that is where I was coming from, if this calculated in the acc tree instead of the dom tree

jcraig: that is a good idea, but because we don't have a standard accessibility tree between browsers it might lead to difference. I don't think we could implement it yet reliably

jcraig: if you are talking to him can you post the comment?

scotto: I'll saw what I remembered, and I'll cc him in

jamesn: I know this is something that might not want to do because it is hard to explain, seems like 99% of our use case or more would be covered if we did depth first search of only 2 deep?

jcraig: maybe 75%

jcraig: and you add an extra div and it suddenly doesn't work

scotto: and what happens with shadow dom???

Deep Dive planning

ARIAMixin has many integer attributes with string types and uses DOMString? incorrectly

jamesn: is this something we are ever going to do something about?

keithamus: some of the types don't match up.. I'm not sure the risk to make them match up

keithamus: I plan to chip away at this over the next month or so, if we align to the html spec, it would require changes in the browser implementation, which is fine except for compatibility issue. There are certain patterns where developers do feature detection...

keithamus: for anything that isn't enumerated, if you can set it and read it and see whether it is a supported value

keithamus: this needs some careful teasing apart

jcraig: this will break existing web pages, its not editorial

jcraig: there is a web compat risk

jcraig: I handed this off to anne and others because this is a broad discussion

jcraig: we reflected all of these as strings for a few years now... and think.. last year gecko implemented to match. we even have wpt tests for it...? I will have to verify

jcraig: to get these changes in, we will break a lot

jcraig: I don't think we don't have usage information about whether anything will break

keithamus: that is what I was going to div into

keithamus: we incorrectly says "domstring?", there is an editorial change to change from "domstring?" to "domstring"

jcraig: the "?" means nullable?

keithamus: yeah, and "domstring?" must be limited to known values, for eample

keithamus: so we need to tweak it for that. but each one needs to be analyzed

keithamus: this is worth weighing up each change

jcraig: probably it's fine if we change from a nullable to empty string

keithamus: (something about salesforce I didn't catch)

jcraig: I'm fine with domstring? to domstring

jamesn: sounds like you are working on this and I really appreciate, this is an area the group has been lacking in expertise

<keithamus> Salesforce (Nolan Lawson) are concerned about changes to this due to their polyfill, and we don't want to break that.

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/he first heading will be the first to contribute to the name/the first heading is expected to contribute to the name from authors probably/

Maybe present: adam, jamesn, jcraig

All speakers: aardrian, adam, Adam_Page, jamesn, jcraig, keithamus, scotto

Active on IRC: aardrian, Adam_Page, CurtBellew, dmontalvo, Francis_Storr, giacomo-petri, jamesn, katez, keithamus, pkra, Rahim, sarah, scotto, spectranaut_, StefanS