Hello Telerik Team,
We’ve received feedback from one of our customers regarding accessibility concerns with the RadMenu control. While we understand that the current RadMenu supports WCAG 2.1, the customer is aiming for full compliance with the WCAG 2.2 standard and has identified some gaps in that regard.
Specifically, they are requesting support for a scenario where a menu item both opens a new page and includes sub-menu items. They would like the behavior to follow the example described in this accessibility article:
https://hub.accessible360.com/kb/articles/529
Could you please advise:
- If there is any workaround we can implement using the current RadMenu to meet this requirement?
- Whether there is an estimated timeline for when the RadMenu will support WCAG 2.2 natively?
We appreciate any guidance or recommendations you can provide to help us support our customer’s accessibility goals.
Judy Wang
Hi Telerik Team,
I asked ChatGPT about a menu item that both opens a new page and contains sub-menu items. Here is its response for WCAG 2.1 AA
Under WCAG 2.1 AA, if a menu item is both a link and also has sub-menu items, there are specific accessibility considerations to meet the standards. Here’s a summary of the relevant success criteria and best practices:
✅ Relevant WCAG 2.1 AA Criteria:
2.1.1 Keyboard
Users should be able to navigate to the menu, open submenus, and activate the link using only the keyboard (e.g., Tab, Enter, Arrow keys).
2.4.4 Link Purpose (In Context)
The menu item’s text must clearly describe its destination, especially if it leads to a page and opens a submenu.
2.4.7 Focus Visible
The focused menu item should have a clear visual indicator.
1.3.1 Info and Relationships
Use proper semantic markup (e.g.,
<ul>
,<li>
, ARIA roles) so screen readers understand the menu structure.4.1.2 Name, Role, Value
For interactive menu items, especially if using ARIA (e.g.,
aria-haspopup
,aria-expanded
), these must reflect the current state.⚠️ Key Design Decision: Clickable + Expandable Menu Items
If a menu item:
Navigates to a page (e.g., Home, Services)
Also opens a submenu
This dual function can be confusing for users, especially those using keyboard or screen readers.
🔧 Recommended Best Practices:
Option 1: Separate the actions
Have the top-level menu item only expand/collapse the submenu (not a link).
Add a submenu item inside the dropdown that links to the main page.
Example:
<li> <button aria-haspopup="true" aria-expanded="false">Services</button> <ul> <li><a href="/services">All Services</a></li> <li><a href="/services/consulting">Consulting</a></li> </ul> </li>
Option 2: Provide a clear distinction
If the top-level item must be both a link and expandable:
Ensure keyboard and screen reader users can activate the submenu separately from the link.
Use a split button UI:
One part is the link.
The other is a button to expand submenu.
✅ Summary of What You Need to Do:
menu
,menuitem
,aria-haspopup
,aria-expanded
Here's for WCAG 2.2 AA.
Under WCAG 2.2 AA, if a menu item is both a link and also has sub-menu items, the standards extend upon WCAG 2.1 AA with additional emphasis on focus visibility, timing of controls, and ease of interaction, particularly for keyboard and assistive technology users.
Here’s a breakdown of what WCAG 2.2 AA requires and recommends for this kind of menu structure:
✅ Core Requirements from WCAG 2.2 AA (Building on 2.1 AA)
1. 2.1.1 Keyboard Accessible
Users must be able to:
Tab to the menu item
Activate the link (usually Enter or Space)
Navigate into the submenu using arrow keys or another intuitive method
2. 2.4.3 Focus Order
Focus should move in a logical and predictable order through the menu and submenu.
3. 2.4.7 Focus Visible
The menu item must show a visible focus indicator when selected via keyboard.
4. 2.4.11 Focus Not Obscured (Minimum) 🆕
The focused element (e.g., the menu item or a submenu item) must not be obscured by overlays, sticky headers, or animations.
5. 2.4.12 Focus Not Obscured (Enhanced) (AAA but good practice)
6. 2.4.13 Focus Appearance 🆕
The focus indicator must be clearly visible (e.g., solid 2px outline with sufficient contrast).
Default browser outlines may not be sufficient if overridden.
7. 1.3.1 Info and Relationships
Use semantic HTML (
<nav>
,<ul>
,<li>
,<a>
) or appropriate ARIA roles to make the structure clear to assistive tech.8. 4.1.2 Name, Role, Value
If using ARIA (
aria-haspopup
,aria-expanded
), these must be correctly implemented and dynamically updated when the submenu opens/closes.⚠️ Accessibility Risk: Dual Function Menu Items
If a menu item is:
A link (navigates to a page), and
A submenu trigger (reveals more links)
This can confuse:
Keyboard users (what happens on Enter?)
Screen reader users (is it a page link, menu, or both?)
🔧 Best Practices to Meet WCAG 2.2 AA
aria-haspopup="true"
and togglearia-expanded="true/false"
when submenu is opened/closed✅ Split Button Example (Preferred Pattern):
<li class="menu-item"> <a href="/services">Services</a> <button aria-haspopup="true" aria-expanded="false" aria-controls="submenu-services"> ▼ </button> <ul id="submenu-services" hidden> <li><a href="/services/consulting">Consulting</a></li> <li><a href="/services/support">Support</a></li> </ul> </li>
OR
✅ Submenu Only with “View All” as Child Item:
<li> <button aria-haspopup="true" aria-expanded="false">Services</button> <ul> <li><a href="/services">View All Services</a></li> <li><a href="/services/design">Design</a></li> </ul> </li>
✅ Summary: WCAG 2.2 AA Checklist for Menus
Is there any way we can use Split Button pattern to solve the issue, please?
Split Button Example (Preferred Pattern):
<li class="menu-item"> <a href="/services">Services</a> <button aria-haspopup="true" aria-expanded="false" aria-controls="submenu-services"> ▼ </button> <ul id="submenu-services" hidden> <li><a href="/services/consulting">Consulting</a></li> <li><a href="/services/support">Support</a></li> </ul> </li>