Since the modern websites are rich in the look wise, it is important to provide the same rich experience to the assistive technology users too. Unfortunately, there are no HTML semantics for the few of the rich controls such as menu, menubar, tab, tree and so on.. usually, authors bring such rich visual look by using CSS design patterns. Let me talk more on menus and menubar in this post. Since there are no HtML semantics for menus and menubar, authors may have to use CSS for the either anchor element or custom container to get the visual appearance of the menu or menubar. When they do so then control might be visually appearing as menu or menubar but assistive technologies do not interpret the same. When assistive technologies do not interpret the way how sighted person perceives the control then it is high chance that assistive technology users would not be aware of the complete functionality of the control. For example, if menu is announced as link by screen reader then it is not the identical experience to the screen reader users. in addition, menu and link might not have the same functionality. In order to provide the semantics for such rich controls, aria introduced menu, menubar, and menuitem roles.
Menu role
When we go to restaurant then what is the first thing that we look for. Obviously, we look for the menu. What does it contain? Usually, menu contains the list of the choices that we need to have for the food. On the similar lines, aria menu role is nothing but A type of widget that offers a list of choices to the user. A menu is often a list of common actions or functions that the user can invoke. One thing that we need to remember here is that those list of the options are displayed only when user invokes the menu widget but those list of the options are not visible by default.
The menu role(role=”menu”) is appropriate when a list of menu items is presented in a manner similar to a menu on a desktop application. In aria1.1, aria-orientation=”vertical” has been added as The default implicit value for menu role. The child or required own elements for menu role are menuitem, menuitemcheckbox, menuitemradio.
Menubar role
Menubar role is also kind of the similar concept as menu role. When the list of the choices/options are visually persistent then it is called as menubar. In a simple words, the list of choices are always visible on the screen by default then that complete bar is called as menubar. Most of the people would think that menu is the child of menubar but it is not true. Even though, The menu and menubar are at the same level from the hierarchy wise but they are different in nature. Let me tell you the difference clearly. The list of the choices are displayed when user invokes menu widget for the menu whereas the list of the choices are always visible on the screen by default for the menubar. That is difference between both of them. The child or required own elements roles for the menu and menubar are same and they are menuitem, menuitemcheckbox, menuitemradio.
The menubar role(role=”menubar”) is used to create a menu bar similar to those found in Windows, Mac, and Gnome desktop applications. A menu bar is used to create a consistent set of frequently used commands. Authors should ensure that menubar interaction is similar to the typical menu bar interaction in a desktop graphical user interface. In aria1.1, aria-orientation=”horizontal” has been added as The default implicit value for menubar role and Menubar is usually presented horizontally.
Menuitem role
Menuitem is nothing but An option in a set of choices contained by a menu or menubar. A Menuitem(role=”menuitem”) may or may not contain sub menu. If the menu item has its aria-haspopup attribute set to true, it indicates that the menu item may be used to launch a sub-level menu, and authors SHOULD display a new sub-level menu when the menu item is activated. Authors MUST ensure that menu items are owned by an element with role menu or menubar in order to identify that they are related widgets. Authors MAY disable a menu item with the aria-disabled attribute.
Sample code snippet
<ul role=”menubar” id=”appmenu”>
<li role=”menuitem” aria-haspopup=”true”>
Edit
<ul role=”menu”>
<li role=”menuitem”>Undo</li>
<li role=”menuitem”>Redo</li>
<li role=”separator”></li>
<li role=”menuitem”>Cut</li>
<li role=”menuitem”>Copy</li>
<li role=”menuitem”>Paste</li>
</ul>
</li>
</ul>
References
- Aria1.1 specification-menu role
- Aria1.1 specification-menubar role
- Aria1.1 specification-menuitem role
- WAI aria1.1 authoring practices-navigation menubar example
Thanks for sharing your knowledge it is very useful.
Thank you Chandana!
Loved the simplistic way of explaining screen reader user experience with Aria attributes
Thank you for that
very useful