Meeting minutes
<jamesn> i'll add it
New Issue Triage
spectranaut_: for aria #2313, can you introduce this Scott?
scott: working on HTML-related stuff; idea of having to specify that aria-hidden is used to make an SVG decorative is a "prickly" subject. Made me realize there's no good way to do this with SVGs (e.g., alt for <img>). No need to talk now, can agenda+
spectranaut_: after moving to monorepo, no good way to tag PRs so please weigh in if you have an opinion
spectranaut_: aria #2310 was already discussed, James to tackle
New PR Triage
jcraig: for wpt #47608, associationlist is included in test even though it's been moved from editor's draft. Aaron saw a problem with how name prohibited is enforced; pretty straightforward but a bit bigger due to ancillary issues I discovered as part of fixing WPT issue
spectranaut_: Aaron can you take a look?
jcraig: Chris or Simon can add you to the (a11y) interop team so you can review it as reviewer
… one reviewer is all that's needed for WPT but since this is related to 2 or 3 ARIA issues, good to have a few people from ARIA WG review it. If I recall correctly, it shows accname reviewers (and Val/James). Feel free to remove anyone that doesn't want it but nice to have other reviewers
<OliverH> Was there a message about it?
spectranaut_: I can take a look
… (and Melanie)
WPT Open PRs
TPAC
spectranaut_: previously we had issue for accname #95 as a potential F2F candidate but Melanie will not be at TPAC; there was a suggestion to move to deep dive unless Bryan prefers it at TPAC? Can also keep it at TPAC
… will keep this as a deep dive otpic
… anything else on TPAC topics? Just a reminder that TPAC is happening in a month and next week, James and I will start to make a draft agenda and share with the group. If you have topics, add the "F2FCandidate" tag and write something in the discussion board
Clay: we've talked about aria-notify breakout session; is there docs for how to put together an effective one for review?
spectranaut_: no, sessions are up to whoever is running it. Only guidance is there should be clear goals/guidance that should come out of the discussion but can talk more offline if you want more guidance than that
aaronlev: if you have complicated stuff, might be good to socialize with smaller group to gather feelings/thoughts so it's smoother when brought to larger group. It's been somewhat successful before to start with something that won't be hard to agree on, then have a list of 5/6 things you want to go through towards resolution. Hopefully won't need to start from the beginning and explain everything
jamesn: having something written beforehand is also very handy
9.3 Presentational Roles Conflict Resolution does not consider custom element use cases
spectranaut_: this is Aaron's issue that we briefly discussed but Aaron wasn't present. Seems like there's more to discuss
aaronlev: what I learned from last week is that there are more people that are seeing this in multiple places; i.e., not that people put role="none" on it. Most folks don't understand engine internals for a11y
… could recommend something in the long run (e.g., shadow DOM delegate). Role="none" always means take something out of the tree, then later it was raised (as philosophical issue), what happens if someone puts role="none" and there's an important property there
… people didn't see harm there, and browsers would ignore it. Now, when people implement custom elements, there's no quick and easy way to fix that. It came up for me when working on rules that prevent Chrome's UI which has HTML in it (and broke things like elements that have name prohibited)
… by allowing role="none" on custom elements, don't think we're breaking anything, and doesn't preclude more elegant solutions but I think it's a small change that would help me right now
jamesn: are you saying that the custom elements that you want this to work from are handling aria-label and doing something with it, or are moving all other attributes to the target element?
aaronlev: sometimes it could be aria-label, aria-description
jamesn: are they specifically targeting those? (Aaron says no)
… danger of doing this is that there are lots of authors using custom elements who end up adding aria-label to a custom element and shouldn't be doing it, and the aria-label isn't getting passed anywhere else
<spectranaut_> spectranaut_: I think Aaron said they are targeting aria-label and aria-description, rather than blanket copying
aaronlev: not saying custom elements get a default role of none; I'm saying that the custom element knows to copy the appropriate attributes
jamesn: if a custom element does this, and the author unintentionally is setting ARIA on it, now that aria-label is not getting reflected properly
… (correction***: ARIA generally, not just aria-label)
… we don't generally allow people to put ARIA on custom elements because of this problem; you don't allow someone to do that if you're going to copy those properties somewhere else. Shouldn't this problem surface as part of testing?
aaronlev: we have testing, but doesn't test every environment and feature (that should be thorough). You're saying that people at Adobe should be able to set aria-label/role="none" on custom element?
jamesn: when someone has set aria-label on this thing (custom element), I'm concerned this will be a breaking change and things are not ignoring that aria-label so it ends up creating a group; then, the author is getting this behavior (although not intended) and now it's broken
aaronlev: could I convince you that we're giving people a tool to get more things to work; your case is theoretical and my case seems more real
jamesn: I would like to talk more people who have experience creating custom elements; this discussion should go to those people rather than us (ARIA WG) making a decision
scott: I did reach out to some of the people at Microsoft who build custom elements/components; one of the things they struggle with is what Aaron has brought up; i.e., authors are used to putting attributes on custom element wrapper and then have it passed down to element's internals. ARIA has been the exception (and there's been pushback) and we've had people change their code but not for all the frameworks' custom elements
… one of the developers I reached out to commented on the issue
aaronlev: not just changing implementation of custom element, would have to change everything that uses it (easier to change in one place rather than many)
aardrian: do we raw data of what's being used in the wild? Scott gave some from Microsoft, and Aaron from Google; more data could help make more informed decision
jamesn: rather than using role=none as the internal, should there be something else you specify as an alternative approach? (e.g., a new role?)
<Zakim> melsumner, you wanted to say +1 to the idea of having something else to specify instead of `role="none"`
aaronlev: we should go with Adrian's suggestion of getting more data; don't need more roles
<scott> absolutely do not want this to be a role
Matt_King: instead of a new role; instead of declaring none, but also declaring a secondary role that represents the custom element? e.g., role="none tree" or "none button" as a way of distinguishing it
aaronlev: let's not make it harder and just follow the markup of what someone put
scott: adding context to opposition to addition of new role: custom elements are being used as Aaron mentioned; and using them as funnily-named divs. If they have a generic role by default and if we made a role, valid argument for why this isn't the default role for custom elements. If the whole point is to pass attribute to element internals, it would break custom elements that already use the global ARIA attributes (e.g., passing aria-live
down to element internal)
keithamus: is this solved by the referencetarget proposal, and work around these issues? is it easier to have the conversation when that proposal ships
aaronlev: no; e.g., referencetarget lets you use a relation so you can point to something going inside the custom element, e.g.., set aria-controls and point it to something inside. In this case, it's not necessarily a relation
spectranaut_: I want to see the pros/cons of making this change, some speculative. I've heard multiple cons but difficult to process from just this discussion. From the perspective of making ARIA easier to learn, does it help that role=none works one way on one element and another?
jamesn: author doesn't set role=none here, it's the component (but author could set it?)
… this could also encourage authors to start setting aria-label on custom elements (in a willy nilly way); this is the reason we encourage people to not use the ARIA attributes on the custom element itself
aaronlev: any alternate solutions?
keithamus: how many people try to do this? When I've done this, I've removed the attribute on the custom element
aaronlev: problem is that custom element has onattributechange event handlers
spectranaut_: not hearing hard "no" either, what are next steps?
<melsumner> It seems like we need a way to gather user feedback since there's an uptick in anecdotal evidence, yeah?
jamesn: want to talk to our internal folks to learn more
aaronlev: the reason I'm pushing on this is because I'm trying to implement an experiment anyone can play with and play with name prohibited elements (and move that content to description)
… right now, what I'd have to do is have an exception for my experiment (but in order to make it work, need to change behavior of custom elements). This proposal gives me a way to fix it in a single place
… for the content I'm specifically worrying about, it's the stuff that's part of Chrome's UI which is written in HTML
… I basically have to carve out an exception for the name prohibited, allowing names on custom elements or provide some way for people to work around it
spectranaut_: otherwise the role would be none? (Aaron says it should be generic so name is prohibited)
<Zakim> melsumner, you wanted to ask if we have considered "Stages" like they do with TC39 so we have ways to experiment?
melsumner: experimentation would be really useful; we are getting stuck because the "horse is out the barn's door", but implementators are stuck as well
spectranaut_: maybe you can make an issue and agenda+ it
<StefanS> *
jcraig: I don't have a strong an opinion on this issue; one of the things I want to call out is that Aaron is moving away from what other browsers are currently doing. E.g., for <dt>, <dd>, Gecko/WebKit still pass the label through despite it being an author error. You're (to Aaron) enforcing an author error as use behavior may be problematic in terms of priority of constituencies. This is part of the reason we don't have a user agent
requirement
aaronlev: I'm putting this behind a flag so people can play with it (and moves the content behind description). We've been working with AT vendors to support description on anything (e.g., virtual buffer mode, tabbing though a form), helps authors supply a plain text representation and have it rendered/announed. When I looked at aria-label on generic elements, sometimes it's being used as duplicate text, and sometimes something additional to
have spoken
jcraig: how does it apply to generics?
aaronlev: if there's an interesting ARIA property on a generic, it gets exposed in the a11y tree
jcraig: are you using aria-label for example to description as well for role=generic?
aaronlev: that's what the experiment does; not all screen readers can handle having text in a container (get confused when you have text from a name and inner text)
(i.e., inner text = descendant objects/elements that have their own accessible name)
Matt_King: this discussion is getting concerning around forcing users of screen readers to hear stuff that should be by design to be ignored (i.e., the extra information). The reason we have name prohibited on certain things is partly because of this noise factor where you have authors doing this and labelling things where it creates more problems than it solves. It feels like there's an inconsistency that we don't stuff named, but it can be
named; don't care what it's called, it's still a problem
aaronlev: none of the browsers remove the information from the tree so you get different experiences across ATs/browsers
Matt_King: wondering if we're not doing the job we need to do to prevent authors from doing things that are detrimental to users (which is why we have name prohibited)
aaronlev: extra verbosity might be better than to remove something
Matt_King: if something is vital information, and if the tooling isn't doing what it needs to do (you just put vital information and expressed it in a bad way), authors should realize this vital information isn't getting rendered properly
Brett-Lewis: we do have problem with verbosity; I like moving this information to description and reading description afterwards (and giving user easy way to ignore them). I like what Aaron is talking about which is rendering all available information about an element
Matt_King: example we've trying to tell authors is that aria-label overrides content inside link. But if we expose both the link text and aria-label??
Brett-Lewis: I get the difficulty and challenge here and I agree with Aaron's sentiment that we should say too much rather than remove stuff
aaronlev: which is why I created this experiment so you can try it
spectranaut_: next steps are James N. will talk to others, any other next steps?
aaronlev: we need to reach out to Westbrook and ask their opinion on ARIA on custom elements that get duplicated?
keithamus: I can do that