W3C

– DRAFT –
ARIA Deep Dive - Name traversal

03 November 2022

Attendees

Present
Adam_Page, jamesn, scottono
Regrets
-
Chair
-
Scribe
jamesn

Meeting minutes

BGaraventa: Issue for some years where browsers have chosen on their own which roles etc need to be traversed

https://github.com/w3c/aria/issues/1821

BGaraventa: first determine which roles should/should not be traversed

scottono: example https://github.com/w3c/aria/issues/1821#issuecomment-1267695450

<Zakim> jamesn, you wanted to ask is this not error correction at this point?

BGaraventa: some browsers could weigh on the side of including everything

jcraig: +1 in support of jamesn language - there are opportunities for authors to get that interop to fix the issues

jcraig: allowing the engines to account for it in a flexible way allows engines to account for something which are both performant and innvative

<Zakim> jamesn, you wanted to ask if we think authors should be able to do this

BGaraventa: in principle I agree but the person who suffers is the AT user

scottono: I agree that in principle this should not be allowed

scottono: but in HTML it is allowed and this is a real thing that is happening

scottono: the rules for how name should be calculated are far more recent

<Zakim> jamesn, you wanted to react to scottono

jamesn: why can't we do that

Jamie: overriding of content only happens for cases links where they do allow name from content but name from author is also allowed

Jamie: a bunch of conversations - a bigger conflation - I don't think focusability matters much if we traverse into something

Jamie: when the root node allows name from content

Jamie: group doesn't allow Name from content - but when it is a child it will get traversed

Jamie: this focusability should get name from content but only when focusable

Jamie: this would only apply for things that allow name from content

Jamie: for roles that allow name from content there is a list of things which allow traversal

<Zakim> jcraig, you wanted to say re: "allowed" MAY or SHOULD? and to and to address the innerText comment (speccing that would not allow a better sub-set of innerText)

jcraig: perhaps should would be better

jcraig: BGaraventa sounded like you wanted to put InnerText in the spec - would be good to start with.... but wouldn't allow useragents to do a better job

jcraig: there could be better ways including using text size etc, to allow user agents to do a better job

BGaraventa: the problem is when you omit info you are determining that someone may not need to know what X is - maybe the disclaimer is important and it is smaller

jcraig: agree would be a problem. with VO you can interact - if others are suppressing that then could be a problem

Jamie: have no issue with UA using ML etc. to work something out - need to mark it such that it is a guess

Jamie: think we had this conversation at TPAC and think V. important that the user knows it is a guess

+1 to Jamie

<scottono> +1

<jcraig> VO has precedent for speaking "possibly <text>" or "probably <text>"

BGaraventa: I like Jamie idea about traversing - but not specced out clearly

<jcraig> Jamie: fine with that, but the spec should make it clear that the guess should not be the same API property as the label

<Zakim> jcraig, you wanted to throw a <table> in <button> wrench

jcraig: link is less concerning.... button leaf nodes would be suppressed. We could make this an author error - unless content is exposed in other ways

aaronlev_: good simple example is Emphasis.... we have a list of the roles in chrome

https://docs.google.com/spreadsheets/d/1iLk-KTX2PZvqIhdhQzM9vfMI3za3RlWQCRNx1e6m2VM/edit#gid=1453515990

Jamie: to try to write up a proposal

Minutes manually created (not a transcript), formatted by scribe.perl version 196 (Thu Oct 27 17:06:44 2022 UTC).

Diagnostics

Succeeded: s/jcraig: group/Jamie: group/

No scribenick or scribe found. Guessed: jamesn

Maybe present: aaronlev_, BGaraventa, Jamie, jcraig

All speakers: aaronlev_, BGaraventa, jamesn, Jamie, jcraig, scottono

Active on IRC: aaronlev_, Adam_Page, jamesn, Jamie, jcraig, scottono