Meeting minutes
New Issue Triage
spectranaut_: I'll take this
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
jamesn: sounds like editorial
jamesn: but lets discuss it in a meeting anyway
jamesn: looks non controversial
giacomo-petri: I can do this
New PR Triage
spectranaut_: I'll review
jamesn: and also we have james craigs, so that is good
WPT Open PRs
<jamesn> https://
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