Edit 4 days later: Deleted the contents of this toot, but keeping it for replies.
The original example code was inaccessible and has now been removed.
Edit 4 days later: Deleted the contents of this toot, but keeping it for replies.
The original example code was inaccessible and has now been removed.
@mahryekuh
When you can't see the menu links they *should* be removed from the accessibility tree. Also, the links will still be in the focus order when the menu is not visible. For a sighted keyboard user, focus will disappear until they Tab through all the links.
I don't know what the checkbox is named but "checked" is not the state that conveys to a screen reader user that a menu is open, "expanded" is. You can get this without JS by using a <button> with a popover though because mobile menus often cover all usable space, I think having them in a <dialog> opened by `command="show-modal"` is better.
@cwilcox808 This functionality is only for sighted users; the checkbox and its label are set to aria-hidden, which is why I kept the menu items in the tab order at all times.
I should add `:focus-within` to account for sighted users tabbing around, though, good point.
Addendum: The menu of this particular site actually features a dropdown with aria-expanded and all the other features you mentioned; the "checked" thing is something else, though. It's easier to see on the website itself.
@mahryekuh
Most screen reader users have some vision, the visual and non-visual experiences should correspond. `:focus-within` would help the non-screen reader keyboard users but a screen reader's virtual cursor will not trigger it.
CSS checkbox hacks have existed for a long time but have always had the same accessibility issues; what `:has()` enabled is freedom for where the checkbox is in the DOM relative to what it reveals.