Search code examples
htmlcssaccessibilitywcagwcag2.0

Accessibility and absolute positioning?

We have a hamburger that looks like

bbq button

and when you click it, a popup will show (the class "open" is added to a div).

popup

This is accomplished with fixed positioning. However, it seems like accessibility programs reacts on that kind of positioning elements. We try out SortSite 5.

Is that really good stuff for the purpose?

Actually, it calls the positioning "absolute" although it is "fixed". The same thing probably, because the reason would be that screen readers have problems with those elements.

We really want to have the menu like a popup this way and when you click the bbq-button, the document should not grow in a strange way. For instance, ugliness happened when we tried to float the popup instead.

  • How do I made those programs happy?
  • Should I try to use a screen reader myself instead?
  • Should I have a <nav>-element?

html

<div id="drawer">
  <table role="presentation" class="buttons" style="width: 100%">
    <tr>
       <td class="bbq-parent">
         <div class="bbq"></div>
       </td>
       <td class="logo-parent">
         <div class="logo"
           onclick="javascript:location='.'; event.stopPropagation();"
           onkeypress="javascript:location='.'; event.stopPropagation();"
           tabindex="0"></div>
       </td>
     </tr>
   </table>
   <ul>
     <li><a href="item1.html">item 1</a></li>
     <li><a href="item2.html">item 2</a></li>
     <li><a href="item3.html">item 3</a></li>
     <li><a href="item4.html">item 4</a></li>
   </ul>
</div>

css

#drawer
{
  position: fixed;
  z-index: 1;
  top: 5px;
  left: 5px;
}

#drawer ul
{
  padding-left: 0;
  display: none;
  list-style: none;
  margin-top: -10px;
}

#drawer.open ul
{
  display: block;
}

#drawer .bbq
{
    background: url("Images/bbq.svg") no-repeat;
    background-size: 100% auto;
    width: 23px;
    height: 25px;
    cursor: pointer;
}
Solution

  • The button should have a button role, or (preferably) it should be a proper <button> element (which gives you that tabindex and basic keyboard operation 'for free'), although you may need to remove some user-agent styles to keep the appearance you have now.

    You should also add aria-haspopup="true" to the button, because it opens a popup menu. It would be useful to add aria-expanded="true" when the menu is open as well, and remove it again when the the menu is closed. Assistive tech understands these attributes, and uses them to communicate the state of the button. You can also use them in attribute selectors to change the style. This is much better than using custom class names such as open, because it kills two birds with one stone.

    There's another ARIA attribute, which is intended to connect a control to the thing it controls. It has a number of conceptual and implementation issues which make it inadvisable. More details about the failures of aria-controls are available from heydonworks.

    Given that aria-controls has so many problems, the menu should immediately follow the button that opens it in the source order, which will establish a connection between the two. This pattern has surprisingly good support from assistive tech. but I am not sure if that will play well with your presentational table.

    BTW you can get table-layout without using <table> via CSS display values. There's table, table-row, table-cell, flex, grid etc. All of these are preferable to using table markup for presentation these days. flex is probably the easiest to work with.

    The button must have an accessible name (i.e. a text label). This does not have to be visible. The 'hamburger icon' idiom is well established for menu buttons. An invisible label can be achieved with something like aria-label="toggle menu" or whatever expresses what the button does.

    And yes, if this is a navigation menu, definitely do wrap it in a <nav> element, or use role="navigation" on the <ul>. This provides assistive tech with alternative mechanisms for accessing the links, although I would consider hiding the closed menu by moving it offscreen to negative coordinates, instead of using display:none; so that these mechanisms work even when the menu button is not being used.

    I would support Jonas Carlbaum' recommendation to look at the w3 aria practices page. They have an example of a navigation menu, using many of the suggestions mentioned here, and with appropriate focus handling which you can get inspired by.