Popout menu caveats about 30-seconds-of-css HOT 3 CLOSED

I, too, think this is something that has some space for improvement. tabindex and :focus sound like a really good starting point for this.

from 30-seconds-of-css.

There are actually quite a few caveats with accurately conveying a "popout menu" component to screen readers, let alone sighted keyboard users, that just can not be done with CSS alone.

1. A button should really be the element that is the trigger for such a component. If going the route of using a div and adding a tabindex, an ARIA role="button" would need to be set to the div and JavaScript would need to listen for keypress of space or enter for keyboard press. Which brings me to point 2...
2. Focusing on the trigger alone would be insufficient for the component, as when focus was removed from the trigger, the revealed content would become hidden again. The component can continue to use :hover for mouse users, but should have JavaScript allowing the trigger to be pressed/toggle the state of the popout container. e.g.

   <div class="reference">
   <!-- 
     JS would control the state of the button, toggling between true/false 
     for the aria-expanded attribute.  This could be utilized as the CSS 
     selector to effectively show/hide the popout-menu 
   -->
    <button type="button" aria-expanded="true/false" aria-controls="pop_menu">
         Trigger Name
    </button>
    <div id="pop_menu" class="popout-menu">
         ...
    </div>
   </div>

   button[aria-expanded="false"] + .popout-menu { visibility: hidden; }  
   button[aria-expanded="true"] + .popout-menu { visibility: visible; }

3. Do not allow focus of content within the popout menu if the popout menu is not purposefully opened. This is not a present behavior, but more of a preemptive warning, in case one was thinking they might be able to circumvent the previous requirements by utilizing :focus-within to mitigate the fact the popout content would disappear once focus left the trigger. Mouse users have the luxury of scanning a page and hovering over / revealing content they want to, while ignoring the rest. Keyboard users (sighted or not) typically must traverse the DOM sequentially. Coming to an element that should allow them the ability to show/hide related content, they should have the same choice as mouse users as to whether they want to engage with that content or not. Forcing them to engage with the hidden content, regardless of their preference, is a poor user experience.

If you made it this far, I appreciate you reading my short primer on the accessibility considerations for components such as this :)

from 30-seconds-of-css.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from 30-seconds-of-css.