It really is disturbing how many people can't even code the HTML for a menu properly, crapping pointless "DIV for NOTHING" all over the place, omitting lists... and then when they get to the layout and design it all reeks of utter and complete ignorance of the most basic of accessibility minimum.
I mean seriously, white text on yellow and lime-green? REALLY?
That said, don't think that aria role trash does ANYTHING of value. If he had the proper semantics, it's a menu. Concepts like "expanded" and "controls" is pointless, redundant, and to be frank border on saying what things look like or how they behave, NEITHER of which is any of HTML's business. Neither of those do anything that the NAV tag and proper UL/LI wouldn't provide... especially the mentally enfeebled "aria-expanded" nonsense as if a screen reader, braille reader, or search engine gives a flying purple fish about whether something is open or not. In most cases, that isn't even a thing that matters for them!
But what do I know? I don't even use JavaScript for menus that open and close. And no I don't use BUTTON for that either. It's called hash links, the :target pseudo-state, anchors, and ID's.
The best part being that for non-visual UA's the anchors for closure are "hidden" si they don't exist, they're empty so even if they did exist they wouldn't show, and for ones like modals where we want the link to do something, it's just a hash link on-page so it still navigates to those sections. No extra semantics, aria nonsense, JavaScript, and so forth needed!
Fun stuff. So much of the stuff people waste JS on aren't even JS' job.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
A comment worthy of being one of my accessibility rants! 🤣
The problem with the :target method is the fact you have to change the URL (which affects the back button obviously) in order to perform actions that should not update the URL.
I am quite a fan of using it as a no-JS fallback but overall it is better to use minimal JS to move focus to the close button on an open menu (and even more importantly to return focus to the button that opened the menu in the first place) and prevent the URL updating so you don't clutter the browser history.
(for example in the demo of yours when I open the menu the focus is not on the close button so I have no focus indicator and then when I close it my focus is not on an active item so I have no focus indicator, I can also tab out of the menu without it closing and also tab to items within the menu when it is closed etc.). Also you still need JS to close the modal with Esc so you can't avoid it entirely!
As for aria-controls and aria-expanded they are useful for complex SAAS applications, but it is certainly food for thought on whether they should be used on simple websites as the focus management aspects are more than sufficient!
Interesting one to think about as sometimes it is easy to follow "best practices" without questioning whether they actually are!
Certainly one I will be exploring in a series I have planned for this year "Ultimate-UI" (which will be a great one for you to rant on if you think I get things wrong as it is meant to be "perfect" UI elements! So I would love feedback when those come out!).
Also while I am self-plugging things that I think you might enjoy ultimatemotherfuckingwebsite.com/ will hopefully make you semantically happy and smile at me poking fun at idiocy all at the same time!
Great rant, wish I could give you a unicorn but a ❤ and a thanks for the smile will have to do!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It really is disturbing how many people can't even code the HTML for a menu properly, crapping pointless "DIV for NOTHING" all over the place, omitting lists... and then when they get to the layout and design it all reeks of utter and complete ignorance of the most basic of accessibility minimum.
I mean seriously, white text on yellow and lime-green? REALLY?
That said, don't think that aria role trash does ANYTHING of value. If he had the proper semantics, it's a menu. Concepts like "expanded" and "controls" is pointless, redundant, and to be frank border on saying what things look like or how they behave, NEITHER of which is any of HTML's business. Neither of those do anything that the NAV tag and proper UL/LI wouldn't provide... especially the mentally enfeebled "aria-expanded" nonsense as if a screen reader, braille reader, or search engine gives a flying purple fish about whether something is open or not. In most cases, that isn't even a thing that matters for them!
But what do I know? I don't even use JavaScript for menus that open and close. And no I don't use BUTTON for that either. It's called hash links, the :target pseudo-state, anchors, and ID's.
See my article "Semantic UI Doesn't Even Use Semantic Markup"
If you go into the demo:
cutcodedown.com/for_others/medium_...
There's not a single line of JavaScript involved, there is NO reason to add Aria roles to any of it.
The hash technique being so powerful, you can even use it to make modal driven sites with little to no JS... which I wrote about in this article:
levelup.gitconnected.com/modal-dia...
The best part being that for non-visual UA's the anchors for closure are "hidden" si they don't exist, they're empty so even if they did exist they wouldn't show, and for ones like modals where we want the link to do something, it's just a hash link on-page so it still navigates to those sections. No extra semantics, aria nonsense, JavaScript, and so forth needed!
Fun stuff. So much of the stuff people waste JS on aren't even JS' job.
Sorry to my limited knowledge, I will invest some more time to get better on accessibility, thanks for the feedback.
A comment worthy of being one of my accessibility rants! 🤣
The problem with the
:targetmethod is the fact you have to change the URL (which affects the back button obviously) in order to perform actions that should not update the URL.I am quite a fan of using it as a no-JS fallback but overall it is better to use minimal JS to move focus to the close button on an open menu (and even more importantly to return focus to the button that opened the menu in the first place) and prevent the URL updating so you don't clutter the browser history.
(for example in the demo of yours when I open the menu the focus is not on the close button so I have no focus indicator and then when I close it my focus is not on an active item so I have no focus indicator, I can also tab out of the menu without it closing and also tab to items within the menu when it is closed etc.). Also you still need JS to close the modal with Esc so you can't avoid it entirely!
As for
aria-controlsandaria-expandedthey are useful for complex SAAS applications, but it is certainly food for thought on whether they should be used on simple websites as the focus management aspects are more than sufficient!Interesting one to think about as sometimes it is easy to follow "best practices" without questioning whether they actually are!
Certainly one I will be exploring in a series I have planned for this year "Ultimate-UI" (which will be a great one for you to rant on if you think I get things wrong as it is meant to be "perfect" UI elements! So I would love feedback when those come out!).
As for the rant on semantic UI - Mwwwaaahhh (chefs kiss noise) it is similar to my rant on "Headless-UI "Fully Accessible" - it's not your fault you believe the 💩 BS 💩" as there is no consequence for these companies making false claims!
Also while I am self-plugging things that I think you might enjoy ultimatemotherfuckingwebsite.com/ will hopefully make you semantically happy and smile at me poking fun at idiocy all at the same time!
Great rant, wish I could give you a unicorn but a ❤ and a thanks for the smile will have to do!