W3C

– DRAFT –
ARIA WG

09 May 2024

Attendees

Present
aardrian, CoryJoseph, CurtBellew, Dniel, Francis_Storr, giacomo-petri, HaTheo, jamesn, katez, knights, Mario_B, Matt_King, melsumner, Rahim, ray-schwartz, sarah, scotto, spectranaut_, StefanS, Summer
Regrets
-
Chair
-
Scribe
spectranaut_

Meeting minutes

New Issue Triage

w3c/aria#2178

spectranaut_: I'll take this

w3c/aria#2177

aardrian: related to the linked PR, we talked about it couple weeks ago

jamesn: agenda it

jamesn: might be strictly editorial, but agenda for now

w3c/aria#2176

jamesn: sounds like editorial

jamesn: but lets discuss it in a meeting anyway

w3c/aria#2175

jamesn: looks non controversial

giacomo-petri: I can do this

New PR Triage

w3c/core-aam#230

spectranaut_: I'll review

jamesn: and also we have james craigs, so that is good

WPT Open PRs

<jamesn> https://bit.ly/wpt_a11y

Deep Dive planning

jamesn: we have a deep dive planed for the 23rd of May on ARIA notify

jamesn: now shipped behind a flag in chromium in nightly

jamesn: does anyone want to schedule a deep dive for 16th?

jamesn: seems like there is a number of people out, lets skip next week

ARIA Monorepo

jamesn: this is for your information, we are planning on trying to move ARIA specs to a mono repo. we have a few folks working on that on the week of the 20th.

jamesn: you may notice a bunch of activity in the repos, do not be alarmed

spectranaut_: please weigh in if you have any concerns/ideas/preferences

spectranaut_: see the link in the wiki, feel free to edit with thoughts

ARIA should clarify distinction between “contents exposed as descendant text nodes” vs “name from contents” (Was: listitem should include name from Contents or name prohibited) and -> td, th naming doesn't align with ARIA

jamesn: (reads issue)

<melsumner> should it be name from author anyway? shouldn't it just be name from content??

scotto: the issue as I understand it is that listitem are only specified as getting name from author, so they wouldn't receive their name from content. I'm coming into this from the other end, which is why do we even let these things get name from author. so there is like one screen reader that allows teh name from author to get exposed and only if it is focused by tab key

scotto: similar to paragraph, which can't be name from author

scotto: we should clarify this, either list items get name from content, or, come to some decision of why list items are allowed to have name from author if it doesn't work anywhere

scotto: makes sense if there is a long list item, but if you want a short name for it

scotto: but if it doesn't work, what is the point

jamesn: I possibly have changed my opinion (from supporting it)

scotto: there was was a shift over time that I never really fully ack'd that in the ax tree, the text of the element is often promoted to it's accessible name

scotto: but that is just the CONTENT, it's not an accessible name

scotto: this always felt like... that makes sense to someone, but it never made sense to me

scotto: these two things (name from content and content) seem a bit conflated

sarah: I was going to say that another use case (good or bad) , because we don't have interactive list role, people use list and list item, and in that scenario name from author gets important

jamesn: what I'm hearing from that, is that we can't use it because people are using it practice

scotto: just because people are using it doesn't mean it works

scotto: only a few instances did the name from author get read

sarah: when the author name is used, there is secondary actions in there

jamesn: would secondary actions help?

sarah: I think more relevant would be interactive list?

jamesn: but once we have a secondary action.... we could do no?

sarah: no, we had a deep dive on this

sarah: we need a new role

aardrian: sarah was outlining.. not a valid use of name from author, but maybe an invalid use of list roles. maybe there is a value in a single access grid like role. I'm on board conceptionally

jamesn: how do we move that forwar

jamesn: in order to resolve list items should be named

jamesn: do we need to do things before we prohibit name from author??

jamesn: should this be deprecated

scotto: for what its worth, I think we should pause on this for right now, we need james to weigh in, and I'm hesitant to make any changes until we decide are we going to create a iterative list item

jamesn: lets pause on list item, and wait until james craig is back to discuss the larger issue

Question: time can have a name from author?

jamesn: no idea why time can have a name from author, right scott?

scotto: yeah

jamesn: anyone know why we allow time to be named by author

scotto: I have no memory of discussing this

jamesn: anyone reject from removing name from author from time

<aardrian> To adjust how I was minuted above, "...single _axis_ grid like role. I'm on board..."

jamesn: we can put it in the obsolete list

<melsumner> +1 for obsolete list

jamesn: should we deprecate the role....?

jamesn: no just kidding

jamesn: does anyone want to do this

spectranaut_: does it have implementation follow up?

scotto: nope

scotto: only author

jamesn: so its a small issue

ray-schwartz: I'll take it!

Trim whitespace from computed accessible name/description

jamesn: does anyone know what the none breaking space thing is

mel: we did have some discussion, we decided ot use CSS spec author's white space definition

mel: I'm pretty sure we decided not to provide our own definition

jamesn: some places in the acc name spec we say that we trim whitespace, in this case we do not say it

jamesn: the specific issue is that when we look at the name and description computation, for example, when you have aria label -- you trim the white space when it is only white space

jamesn: after it's returned, do we trim the front and back or not?

mel: whats the impact of this on a user

jamesn: impact on the testing more than user?

spectranaut_: if all the browsers are triming it, and it doesn't cause problems, then we should spec it

jamesn: joanie thinks we should trim

jamesn: but she says at the end of the calculation we should trim it

scotto: I've seen this being important for users, keeping white space when trying to string together aria-labelledby strings

scotto: otherwise it will take the first and last words and make a garbage word

scotto: if acc name or the aria spec should even call out, if you are stringing together multiple sources, put a space between them

<melsumner> isn't that what space separated provides? I think we can just make ACCNAME consistent.

jamesn: when you have multiple labelbys, the spec says you should add a space between them

scotto: how new is that?

jamesn: is there any use case where we want the spaces to remain? the final things returned by the accname calc, do you ever want spaces at the start or end of that

aardrian: if you have a compound accessible name that is pulling in accessible names, then there might be a use case where you want there to be spaces between each of the entries of the compound accessible name

jamesn: I'm wonder if there is other places in the algorithm that take care of that

aardrian: at least in firefox, idk from chrome, if you have two label elements, they are concated with no space in between

jamesn: the last time we talked about, there were 9 open white space issues.. this will be the 10th

jamesn: maybe we need to work out all the ackname white spaces issues, and tackle them all together

<aardrian> That feels deep-divey?

melsumner: there hasn't been progress on this, i'll try to get it worked out in the next couple of weeks

jamesn: lets deep dive after that

CORE-AAM has "user agents must not expose non-global, not support attributes on roles", but there is no related author error in ARIA?

spectranaut_: talks about the spec

spectranaut_: this makes non supported like prohibited

spectranaut_: from an author/validator point of view -- is there a reason they are treated different?

jamesn: stating this explictly seems fine

jamesn: I'm pretty sure validators produce an error for this?

spectranaut_: inconsistently

scotto: if I put aria-expanded on a paragraph, axe will throw an error

jamesn: pretty sure validators don't have an issue

jamesn: I think it's "editorial" because this implied

scotto: since we have validators throwing the error

jamesn: any one object ot this

eloisa: would this be considered a good first issue?

jamesn: yes!

eloisa: I'll take it

giacomo-petri: there is no rule for this right now, but I can bring it up at the next ACT meeting to make sure there is a rule for this

prevent use of aria-hidden=true on document root elements

scotto: this is ... yeah

jamesn: aaron has concerns and wants consensus

scotto: this issue about whether or not this role holds true for document or html element of an iframe

scotto: my point is that it should be forbidden there too

scotto: if someone is pulling in a document in an iframe, and aria-hidden is true, then the iframe will contain nothing but be exposed. if you wanted to expose the iframe --- putting hidden inside the iframe is not solving the problem

scotto: I won't say what the iframe should do

jamesn: so how do we convince aaron?

scotto: I think I just need to remind him to look at the issue

cynthia: I'm happen to talk to aaron abou tit

jamesn: people used to hide iframes all the time, in the bad old days, I don't think it's something we do before

Trim whitespace from computed accessible name/description

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

Diagnostics

Maybe present: cynthia, eloisa, mel

All speakers: aardrian, cynthia, eloisa, giacomo-petri, jamesn, mel, melsumner, ray-schwartz, sarah, scotto, spectranaut_

Active on IRC: aardrian, dmontalvo, Francis_Storr, giacomo-petri, jamesn, katez, knights, melsumner, ray-schwartz, sarah, scotto, spectranaut_, Summer