Marijke LuttekesEdit 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.
Hanneke@mahryekuh I kinda like css to write greenfield, but after that I completely lose track and I cannot process it 😬
@h5e Huge CSS files are a maze!
The quickest way to find something in such files, when I don't know the exact selector, is to use the browser inspector. The inspector usually points at a filename and line for a specific selector.
I used partials to split up CSS back in my SCSS days, but I quit SCSS.
Luckily, we now have CSS layers, which you can import separately to split your styles across many files.
(Which, of course, only works if you have a logical system for splitting, or you will still lose track of all your stuff.)
@mahryekuh yeah, and the html tree changes often in applications. It’s hard to keep track, especially with multiple people making changes over time. It’s easy to create a chaos. It’s really powerful though, I certainly agree with that.
@h5e ADHD-moment: Ik moet nu denken aan "Ravensburger Doolhof" 😂
Bradley@mahryekuh thanks for sharing
Curtis Wilcox@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.
@cwilcox808 Thanks for the feedback. I removed the checkbox, and the navigation items are now always visible again.
Bas Wijnen@mahryekuh Yes, very cool. I have been making tabbed interfaces without JS for a while, using radiobuttons. But the part I don't like is that (I think) I need to use CSS rules for every tab (input#thistab:not(:checked) ~ div#thispage { display: none; })
Do you know of a way this can be achieved in a way that does not need new CSS rules when new tabs are added? Is that even possible?
@mahryekuh Ok, I have just answered my own question by reading your post; it works using has().
I still seem to need this for the tab style though (to show which tab is currently active, so to which tab the currently visible page belongs). What I would want for that, is a CSS rule that can "follow" the htmlFor member of the Label (which is not a descendant in the DOM tree). I suppose I could use has() there as well, but then I'd need to say "has id equal to this element's for". Is that a thing?
@wijnen I haven't fully read your post as it's too much info for me right now, but…
Tabs need JS anyway, so you can simplify CSS using attribute selectors.
If you use the pattern described below, than you can probably apply your desired styling on `[aria-selected]`, or a sibling/descendent of that element.
@mahryekuh I don't do much with the web; I hadn't looked accessibility before. But of course I want that and it seems that aria-selected can indeed not be generated without JS.
And you are also correct that once that is generated, it is trivial to get style on the tab based on it. 😃
So thanks, this makes it much better!