How to alter aria attributes on Menu and PanelBar?

[Mike]

Is there a way that I can change attributes on the rendered elements of the Menu and PanelBar components?  I am testing them out of the box with NVDA and JAWS screen readers, and running into issues with how they are read.  I believe part of the issue is how the aria-attributes are being rendered on the controls.

I've been looking at the aria best practices for Menubars (menu equivalent) and TreeViews (PanelBar equivalent), and their recommended approaches for implementation differ from the Telerik component implementations.  For example, on the menu, the the menuitem role is added to an <a> within the <li> tags, and the role of the <li> tags is is set to none.  This seems to work a lot better with NVDA interpreting the component.

The same thing can be said with the PanelBar, setting the <li> role to none when the node contains the <a> element, and the <a> gets a role of treeitem.

Here are the 2 best practices examples I'm referring to:

https://www.w3.org/TR/wai-aria-practices-1.1/examples/treeview/treeview-2/treeview-2a.html

https://www.w3.org/TR/wai-aria-practices-1.1/examples/menubar/menubar-1/menubar-1.html

All that being said, is there some way for me to change these attributes on the component when rendering? I know that there are templates, for me to handle the individual items, and that would take care of the <a>, but I don't see a way to adjust the <ul> and <li> elements rendered automatically by the control.

Also, all of the demos for keyboard support use an ALT-W hotkey.  I can't see where that is set up in the demos, so I could change to a different key if I would like to.  How would I do that?

[Hristian Stefanov]

Hi Mike,

I tested the PanelBar and Menu demos with an enabled NVDA screen reader on my machine. Indeed, thеrе is an actual accessibility issue with the PanelBar.  At this moment, we are not aware of any workarounds for the reported bug.  Additionally, I can confirm the current keyboard support is set by design.

That being said, we have opened a bug report on your behalf on our Public Feedback Portal regarding the Accessibility issue with the enabled NVDA screen reader. The status is set to "Unplanned", which means that this is a confirmed bug, but with no scheduled date for implementation yet. Since we created this bug report on your behalf, you are automatically subscribed to receive email notifications for status updates.  

We prioritize bug reports depending on community interest, and I have added a vote on your behalf to the request to increase the item's popularity.  As a small gesture of gratitude for making this bug public, I added Telerik points to your account.

The Menu, on the other hand, seems to work on my machine with an enabled NVDA screen reader. Can you please provide us with the steps of reproduction for the issues you mentioned with the menu? This will allow me to see the behavior first hand.

Thank you in advance, and I look forward to your reply.

Regards,
Hristian Stefanov
Progress Telerik

[Mike]

Hi Hristian,

While the menu is usable the way it is, it could be better. If you take a look at the example menu in the best practices link that I provided in the original post, you will see what I mean. Some of the differences include the following:

• For any item in your menu that is a link and not a submenu, the item is read by NVDA saying "collapsed" which is unnecessary and could get frustrating to a screen reader user. This doesn't happen with the best practices menu. 
• using the keyboard left and right buttons moves the focus to the next adjacent menu item, but it doesn't set focus to the top menu item and read it. Instead it just says "Menu".  The best practices will focus on the top menu item when moving left or right.
• The escape key isn't being used to cancel out of the dropdown on the menu. A user should be able to click ESC and the menu should close, with focus set back to the parent menu item.  This presents a navigational issue for those submenu items that have further submenus. In order for a user to navigate to an adjacent menu, they need traverse to the left all the way down the submenus before it will move on to the next adjacent top item. With the ESC key, they can move back to the parent item, and then navigate right or left from there.
• Tabbing out of the menu when focus is on the submenu, messes up the tab order, so shift tab doesn't navigate back to the menu.  If the focus is on one of the top menu items, then tabbing out and back works. However, it should set the focus back to the last top menu item that has focus, not the first item. So if the 3rd item had focus, then tabbing out and then shift-tabbing back should set the focus back to the 3rd item, not the first item.  And if you tab out from a submenu item from the 2nd parent item, then shift-tab should bring them back to the 2nd parent item.

Also, circling back to the alt-W hotkey, what happens if I were to add both a top menu, and a panel bar on the same page?  If they are both hard coded with a shortcut of Alt-W how would that work?  There should be some way to specify the hot key for each control.

Thanks,

Mike

[Hristian Stefanov]

Hi Mike,

Thank you once again for the provided steps and additional details.

I was able to reproduce the described behavior on my end. This is why we opened one more bug report on your behalf on our Public Feedback Portal regarding the Accessibility issues with the Menu. Like the previous one, you are automatically subscribed to receive email notifications for status updates.

This future fix would cover the described problems.

For the "alt" + "w" combination, I can confirm that it always focuses on the first element on the page.

If you have any other questions, I would be glad to help.

Regards,
Hristian Stefanov
Progress Telerik