Meeting minutes
New Issue Triage
New PR Triage
spectranaut_: I think these are all monorepo PRs or from us
spectranaut_: we'll talk about the monorepo soon
spectranaut_: one aria-hidden PR from scott
scott: this is trying to resolve the expectation around aria-hidden and focusable items. So if you have a container with aria-hidden and a button within. Talking with Aaron on this, and trying to get this closed
spectranaut_: any other reviewers?
scott: this is closing the issue I opened, but also related to work Melanie and Aaron were trying to do with the giant aria-hidden PR. I went in a bit of a different direction, but it's all based off the same ideas
Adam_Page: I'm interested, could also do WPT coverage
Rahim: I believe this is testable, maybe we could create a separate issue? I can follow up
WPT Open PRs
spectranaut_: nothing new, moving on
Deep Dive planning
spectranaut_: this morning, had ariaNotify deep dive. Would be good to share the slides
<giacomo-petri> https://
spectranaut_: I don't think we have anything planned upcoming. Anything we want to plan?
(silence)
spectranaut_: moving on
Monorepo status
spectranaut_: monorepo work is in progress. There are a lot of PRs on ARIA, these are PRs that are moving the history of the individual specs into the ARIA repo.
spectranaut_: there are PRs by Peter that are moving the PRs from the old specs to the ARIA branch. We are doing those one by one, I think Peter might do all of them for us.
pkra: I cannot do those where branches are not in the repository. Well, I'd rather not. Those are not a lot, I think the only one on the call is Sarah
spectranaut_: we're planning on finishing this work by next week on tuesday. If everyone can hold off on doing new work till then, it will make it easier to finish. On tuesday we won't be merging the PRs, because they're in various states. The editors of all the specs should decide how they want to handle the description of these individual PRs
spectranaut_: more to come
spectranaut_: any questions, or James and Peter is there anything else to talk about?
pkra: if you want to make a PR to the ARIA spec, that won't cause any issues. If you do one to other ones, we might miss them
keithamus: are there any guidelines to making a PR like the core AAM one?
spectranaut_: the goal is to have one PR for cross-spec changes
pkra: you can do it yourself, but you'd need to wait until the Core AAM spec is moved over
spectranaut_: we will have a PR preview. It's not the same bot so the diff option won't be available. It's using Netlify.
spectranaut_: we have a long list of follow-up tasks that we will convert to issues so other folks can see what needs to be done still. Feel free to provide feedback on the process in the future
Consider loosening 'requirements' for naming certain container elements
scott: this came out of the editors meaning we had, and was brought up in previous ARIA meetings. I filed this issue per the conversation in the WCAG group where giacomo-petri asked if it was a WCAG failure if a table or dialog is not named if using the native HTML elements that don't require names vs. the ARIA ones that do require them.
scott: the line between what is an ARIA requirement and what is a WCAG requirement can confuse people. So that was the setup for this. By making this a requirement, we are saying that even in instances where naming these things could be redundant to other ways of identifying the containers -- a radiogroup could have radios that are fully
understandable by themselves, same for headings before tables and dialogs
scott: e.g. in a dialog that has a heading that is auto-read, having it be the name can be redundant. So we have a failure that doesn't always lead to a negative user experience. My suggestion here is the requirement should be changed. I think it's usually a good idea to name these things, but I don't agree with having a requirement that 100% they
should all be named
scott: it sounded like in the editor's meeting people might've kind of agreed with me
giacomo-petri: that's perfect, and I'm also working on an ACT rule that's checking these. I've removed all the elements with an implicit role from the rule.
giacomo-petri: then, as Scott said, if we set this as a requirement for implicit roles, this means that all tables, forms, need an explicit name regardless of if it's implicit role, which is not always necessary
scott: it's not always a compliance failure if they don't have a name. If it is, it would be caught by one of the existing WCAG rules.
scott: I've been taking that approach and slowly updating ARIA in HTML to be less strict, because not all the rules in there need to be as strict as they are. Some of those were done before conformance checkers being as robust as they are now
scott: one of Steve's goals was that the spec was made to ensure that ARIA and HTML would play well together. some of the rules were about not using ARIA, just use native HTML. Now that things have evolved, that is not really a problem anymore and where issues can pop up, there is already a WCAG requirement for it
CoryJoseph: I agree with everything you're saying, but I can't think of an example where a dialog would be acceptable without a name. I agree we shouldn't be more stringent than wcag, so if wcag doesn't say a dialog has to have a name, then OK. Is there a situation where a dialog could be acceptable without a name?
scott: a standard confirmation dialog in many native apps doesn't have a name. Taking that same concept to the web, a sign-in dialog where the first heading is "sign in", does that dialog also need to be named sign in, when the heading is right there that's going to be the first thing a screen reader reads?
CoryJoseph: I guess from my perspective, I'm thinking if you have the heading there, why wouldn't you say the heading is the name of the dialog? I see your line of thinking, I think there should be name for dialogs
scott: we do also have the effort of trying to implicitly name things from headings, including article and dialog. If that were the case, if they grabbed the first heading and made it the name, then it would be named. THen also, screen readers could put in their logic to not repeat the name.
scott: so depending on how someone gets to the dialog, they might hear the name, and then the heading immediately.
Rahim: quick question on if this has any impact on authoring practices, the APG guide. There's language for a lot of components like radiogroup, dialog where they say if there's a visible title use aria-labelledby and otherwise use aria-label. There's no indication that it's not required, should there be any crossover to updating that guidance?
scott: there should probably be something there to call out that these are ARIA requirements and not WCAG requirements
Rahim: APG has that section on keyboard operability, so some of those are optional, but other places like the ARIA table does not have any indication that they're optional
siri: I think there are cases where the dialog name is requirement, for example if you send any feedback like thumbs up, if there's a dialog that requires more information on why you sent the feedback. In that case, if the dialog doesn't have a good label, then users don't get the same information as visual users
siri: why do we not want a dialog name when we have aria-labelledby and have it map to the heading?
scott: whether it's aria-label or aria-labelledby is not what we're talking about right now. It's whether all dialogs, radiogroups, tables, grids don't always require a name. I'm not arguing that there aren't cases where things do need names, the issue is that this is a pass/fail boolean right now, and we're saying that these always need a name and
that's not true
scott: just want to be absolutely clear that I'm not saying dialogs don't require names, that would be a misunderstanding. I still agree that in most cases, it would be good, and people should provide names to these things. I think it's an overreach to say they're always required
giacomo-petri: I think we can go further in which roles we exclude from the requirement. For example, we have a search form, with a form input inside, with label search, and so with a screen reader, you 'd find search landmark, search form, search input,
giacomo-petri: I'm not saying we never need the name on specific elements. We could even determine which elements might or might need the accname, but I think the example with the search is pretty self-explanatory
spectranaut_: just wanted to say that I agree with this change, I feel like if we want them to be requirements we should agree with WCAG. I think there are some scenarios where the context is enough for the names of some of these elements, and we should allow for that. I just wanted to voice support.
spectranaut_: there's a little bit of pushback from Cory, but is there any other feelings on this?
aardrian: I also support this for the reasons scott outlined. This isn't wcag, I"m good with this
CoryJoseph: just a follow up on my statements, I think aligning with not being more strict than WCAG, I would support it
<siri> +1 as optional
spectranaut_: no other pushback or disagreement? I think we should open a PR and discuss individual elements
scott: jamesn I want to pick on you
scott: you had the strongest arguments against this, if there's an argument to continue to require this, I'm happy to to reconsider
jamesn: I've heard enough, I no longer hold that opinion
spectranaut_: next steps, someone want to volunteer?
scott: I'll do it once the repo's calmed down.
jamesn: PRs on the ARIA spec are fine, since it's the one that isn't moving, right pkra?
pkra: last we decided, yes
Why does <slot> not allow role?
spectranaut_: keithamus, why does slot not require role? This is an issue on HTML AAM
keithamus: so, you can't put role on slot which feels weird because it's often interleaved with other things that have roles. We made a mistake with a package we were workign on because we changed a div to a slot, and then we noticed the issue and had to do a larger refactor around that
keithamus: the only things that don't allow a role are things that go in the head which feels right, but slot feels weird with that
spectranaut_: should we start off with the context from scott from last time? Though you can see from the issue that slot isn't supposed to be exposed to the user at all, so this would change things
sarah: is it currently exposed in the layout tree right now?
keithamus: you can override the display: contents and make it part of the layout tree if you want it to be
scott
scott: for all the opposition when we brought this up, I actually don't care. Just when I brought this up, I was told no. If opinions have changed and HTML editors are supportive of this then fine. I don't see us making this change without getting wider support
scott: to give this a role is kind of going against what the element is defined by. Even per the example that you can add styles to it, you can do that to head content too but that doesn't mean you should. I don't know that that's a strong enough argument there
keithamus: I guess the next step then is to take this to whatwg, which I'm happy to do and prod them a bit until someone tells me a firm no
keithamus: if I do get a no, I can have a good followup action to add words to the spec about how this is a weird case where you can't add a role
scott: right now I have to show a thread from a validator to show the explanation I was given
jamesn: I understand there was a time when mistakenly a role got applied to a slot in some real code at some point, but was this a complex workaround to not do this? I'm struggling to see the benefit of moving that way
keithamus: I think in this situation, we had a div role=tablist which can only have direct children. I don't think slot counts, but we had some difficulty, and I think ultimately we used javascript to apply the role depending on whether or not the element is slotted, so not a wonderful workaround
keithamus: the more I get told probably no, I think I need a definitely no
jamesn: it isn't something I've heard from our web component folks, but maybe they just haven't raised it
keithamus: I'm just in a weird position where I know enough to be dangerous, and here we are
scott: some of the contextual role stuff that's going on -- in Firefox specifically, I know that if slot is exposed in their tree as a generic, then right now, and I think this a bug they need to fix, but right now if a slot is in a <ul> and exposed as generic, then that means all the li elements see that generic as their parent and then think
they're not inside a list and turn into generics. So that's a situation where slot being exposed as a role breaks the accessibility of the list
scott: so that's a place where if slot was role=none, or no role, this wouldn't have happened
sarah: would the new change where you can have generics between tablist and tab, so even if slot had a display it would be OK. Would that have helped your use case?
keithamus: I need to think about it more, maybe
jamesn: I wasn't aware you could change the display, maybe that should change things?
keithamus: scott's argument was that you can also do that for script elements
<scott> script, link, title, head, style... anything that is essentially display none by default
keithamus: dunno if I want to open the floodgates on all of these, my thoughts are that slots are interleaved between other elements, so it can be difficult to massage the nodes
aardrian: was going to parrot what keithamus said, where people do display the code, the script and style block. My thought was that those are edge cases and we don't need to panic about those. I would like to think that we don't need to worry about putting a display on a slot, but I could see a developer doing that. I don't know if that means we
need to allow role on it
keithamus: I think that depending on the conclusion from someone telling me no, I think I'll ask chrome to put a big warning on putting a role on a slot, because we did make this change, and shipped it, and didn't notice until getting an axe warning
spectranaut_: I think that sounds like a good resolution unless anyone doesn't want keith to do that, let's move on
CSS: handing the a11y of anchor positioning
spectranaut_: another one from scott, he left
spectranaut_: anyone else have context on this issue?
pkra: and it's very future looking still, anchor positioning isn't widely available, is it?
spectranaut_: I wouldn't mind ending early, any parting comments or should we just run away?
<elguerrero> Going to drop off -- bye!