Meeting minutes
Setup and Review Agenda
https://
Matt_King: Any requests for change to agenda?
Adam_Page: I had a couple small things to add
Adam_Page: While updating one of the PRs listed in the agenda, I discovered a couple broken links. I opened a pull request with those fixes, and I was hoping to get that merged quickly
Matt_King: Ah yes. I can review that, so we probably don't need to dedicate meeting time (or an agenda item) for it
<Adam_Page> w3c/
<Adam_Page> w3c/
Adam_Page: Another issue to add (link above). Valerie made a suggestion for ARIA
Adam_Page: And still another one (link also shared above) concerns feedback from James Craig on Tab Actions
Matt_King: Could you add the "agenda" label to those issues?
Adam_Page: Sure
Matt_King: Next meeting: April 15
Publication planning
Matt_King: There are four pull requests that I want to check in on.
PR 2991: Add Practice Page for Supporting Color Contrast Settings by mcking65
github: w3c/
Matt_King: jongund_ do you want to implement this feedback, or should I?
jongund_: I can take care of it
Matt_King: Thank you! I think most of this feedback is pretty straightfoward
Matt_King: One part concerns the whole structure. Thanks to JoeLamyman for bringing a holistic perspective
Matt_King: That is a clear and well-thought-out suggestion, so I think it's worth incorporating
PR 3387: Developing a Keyboard Interface Practice: Clarify guidance for “Focusability of disabled controls” by adampage
github: w3c/
Adam_Page: I've incorporated all feedback to date... As of half an hour ago
Matt_King: Great! I'll give this another read. We may be really close on this one.
PR 3400: Revise Content for New Experimental Example of Scrollable Listbox with Actions on Options by mcking65
github: w3c/
Matt_King: Curt isn't present today, so I don't know if we can advance it right now
PR 3418: Landmark Practice: Update alignment between HTML aside element and ARIA complementary role by NakajimaTakuya
github: w3c/
Matt_King: jongund_ commented on this pull request, but it belongs to someone else
jongund_: Aside only generates complimentary roles if it's in the scope of the body element, the main element, or the header or footer element
jongund_: But I also noticed that if you're using role=navigation or role=region, then that seems to impact the behavior
Matt_King: The purpose of the AAM update was to limit it. It was supposed to be only complimentary if it was in the scope of body or main
Matt_King: The fact that it's doing it inside of header or footer seems to be a bug. Those should be getting ignored (not complimentary)
jongund_: Chrome and Firefox are not ignoring under those circumstances
Matt_King: That seems like a bug to me
Matt_King: Is the text of the pull request correctly reflecting what the guidance should be? Or are you saying that the text in the pull request needs to be updated?
jongund_: I saw the links to the AAM, but I didn't recognize that there was text to be reviewed. I will take a look offline
Daniel: There are places where you need to create a complimentary within an aside. I was worried that we were enforcing a restriction across the board. But if the restriction only applies when it doesn't have a name, then I think that's fine
Matt_King: I think that's what the HTML AAM language says
Matt_King: This pull request in the APG isn't to say what should happen, of course. It's just to reflect what the specifications tell people
Matt_King: So I want to make sure the language in the APG is aligned with the specification
Matt_King: For what it's worth, I'm aligned with you. Just like with the section element--when it's named, then it will get revealed as a landmark
jongund_: I filed an issue for the HTML and ARIA spec to say that it isn't aligned with AAM
Daniel: One of the reasons it hasn't been addressed yet is because we're trying to publish what we're calling a "revised recommendation" to include the changes that have been made since 2021
Daniel: And this is making me think we may want to hold off on publishing that until we've resolved this issue
Matt_King: If the AAM says that unnamed asides should only be complimentary when in body or main, then I think somebody needs to raise some bugs against Firefox and Chrome
Matt_King: In any case, the goal here is to align the APG with the AAM
PR 3421: AlertDialog Pattern: Add guidance about use of aria-modal
github: w3c/
Matt_King: This is a pretty straightforward pull request related to the alert-dialog pattern
Matt_King: We didn't include aria-modal. We do point people to the modal-dialog pattern, but this change is to pull some of the content about modal directly into the alert dialog
Matt_King: It seemed like a good change to me
Matt_King: I'd like someone else to take a look at the pull request also and see if you agree
JoeLamyman: I can review as well
Matt_King: Thank you!
Accordion keyboard issues
Matt_King: There are a mix of older and newer issues
Matt_King: I thought it would be useful to look at a couple of these together
Matt_King: We'll start with issue #3406 and reference our discussion from #357 if we find that it is relevant
github: w3c/
Matt_King: The person who raised the issue is representing that a conflict between the scrolling with arrow keys and moving between accordion header is a blocking problem
Matt_King: We have a lot of composite widgets that use the up and down arrow keys (e.g. menus, vertical tabs, list boxes, grids, etc.)
Matt_King: The up and down arrow keys perform the function of navigating within the composite widget rather than scrolling the page. Generally, the way to handle that is to remove the focus from the widget
Matt_King: But the accordion isn't a composite widget. It's a collection of independent headings that aren't truly connected to one another
Matt_King: I guess that because of that, this accordion thing has always been kind of contrived
Matt_King: But there are still things within Open-UI about making accordions. There seem to be some general conventions that say that accordion is an entity out there in the world and that people want some way to design and build them
Matt_King: So in my head as I review this issue, I wonder if there should be any guidance at all regarding moving from one accordion to another
Matt_King: I think if we answer these questions, we will also address the related issue #357
jongund_: Our example doesn't use those keys
Matt_King: That's right. They are optional. There was a time where we implemented support for them, but we simplified it a lot. I believe Sarah removed them
jongund_: There are so many other things that people need to think about. If we don't implement them... Are there ones out there in the world that actually use these keys?
jongund_: There is no role that says "I am an accordion". If I don't know that I'm in an accordion, I'm never going to use those keys, anyway! I would just take them out
jongund_: This seems like an easy one to dispense with because in my opinion, we have higher-priority things to be working on
arigilmore: I think my company has a different accordion implementation that may need to be updated according to these guidelines
arigilmore: But we haven't come across these issues before
Matt_King: The expand/collapse functionality of the accordion is sort of intended to help people get from one header to the next. If you want to move quickly between them with the keyboard, you just collapse the header, and the next one is usually just one or two tab stops away
Matt_King: Way, way back (and I mean way back before we re-did the accordion pattern), the original accordion pattern that was never published in APG (circa 2014), there was an idea that the accordion headers were tabs. We scrapped that whole approach because there was no way to do the tab panel (or the "accordion pattern).
Matt_King: This might just be a legacy of that original design
Matt_King: So jongund_'s recommendation is to remove these keys
Matt_King: The issue suggests assigning a different key, but that would still have the discoverability problem that jongund_ mentioned
Matt_King: Is there any objection to removing the keys as jongund_ has recommended?
Matt_King: I'm not hearing any objections
Matt_King: Adam_Page we discussed accordions in open-ui at TPAC. Is there anything related to this there?
Adam_Page: I don't think so, but I may double-check
Matt_King: It seems like it wouldn't be particularly disruptive if we eliminated the suggestion.
jongund_: The headers are there for navigation, so if you're using a screen reader, you can just use the "h" key to navigate to the next heading
Matt_King: Right. (It's still sort of stunning to me that browsers don't have built-in methodologies for things like that.)
Matt_King: I'm looking at issue #357, now. That was about getting from inside the panel to the header.
Matt_King: We don't have a key for collapsing the panel from inside the panel
Matt_King: Going back to jongund_'s original point: it's not really a composite. It's more like a disclosure.
Matt_King: I think the answer here is the same. We removed it because there wasn't any real way of making it clear to people that that key is available. It's not a common thing; it's just something that was sort of made up to solve a problem. In practice, though, it doesn't actually solve the problem because there is no precedent (e.g. in native desktop implementations)
jongund_: I think it would be the same issue for the disclosure button. If you just had a disclosure button, you had some keyboard command to take you to that button
Matt_King: I guess it's a little bit related to popover in a sense, but none of the popovers push stuff down. They always overlay
Adam_Page: Exactly. Popovers are overlay by definition, as far as I'm concerned
Matt_King: Right, so in that case, when you have overlay, that's a visual clue that, "hey, I might be able to Escape out of this"
Matt_King: A lot of time when you have expanded or collapsed content, once you enter expanded content, you don't even realize that it's collapse-able
Matt_King: Issue #3406 can't be closed without a patch because it will actually require us to remove that text from the pattern
Matt_King: I will draft a pull request for that
Matt_King: I've assigned myself to this issue
Issue 3391 : Questions about accordions when implemented with HTML 'name' attribute
github: w3c/
Matt_King: Prior to this, I didn't even know you could use the name attribute to help with the accordion implementation!
Adam_Page: That's new within the past two years or so
Matt_King: If you use details summary to make accordion sections, the summaries aren't used as headers (neither in the expanded nor collapsed state)
Matt_King: I found a kludgey workaround, but no one should ever actually use that
Matt_King: There was some Open-UI work related to this, somehow. I wish that someone would figure out some way to make a summary into a heading.
Matt_King: I thought that Aaron had taken that feedback and done something with it, but this was over a year ago, so I don't remember...
Daniel: We do have details. Within the details, there's a summary. And within the summary there's a heading.
Daniel: I remember this was an issue with JAWS because it got rid of the semantics within the summary, but I think it works, now
Daniel: Basically, you put a regular heading within the summary
<Daniel> https://
Matt_King: I thought HTML did not allow that
Daniel: I'll have to check, but I wouldn't be surprised if we fail HTML validation
Daniel: I shared a link above
Matt_King: This is one of those really good examples where, if we have a pure-HTML way to make an accordion example, it would be really good for us to do that. We could add it as a parallel example
Matt_King: The questions in this issue are related to if you do this in HTML, can it be considered a fully-accessible accordion
Matt_King: The issue is treating the APG as normative guidance
Matt_King: The key thing that I wanted to highlight here is that this name attribute thing leaves out the heading aspect
Matt_King: Ah, but this is strange. The summary creates a button, and you can't have a heading inside a button. If the browser is switching it to a button inside a heading...
Daniel: This is something we should double-check
Matt_King: It sounds like there may be some potential for making the APG's accordion without any JavaScript at all
Matt_King: This might be raising the prospect of another pull request!