design-system-components icon indicating copy to clipboard operation
design-system-components copied to clipboard

Main Navigation - Screen Reader Mobile view

Open HerinHentry opened this issue 5 years ago • 13 comments

Component: https://designsystem.gov.au/components/main-nav/

Being a responsive menu, the toggle feature expands and collapses the menu. Does this feature need aria-expanded and aria-haspopup?

Screen reader mobile content does not read the status change of the menu. Can you please review this? The expectation is, as it expands on 'enter key' it announces 'expanded' and 'collapsed'.

HerinHentry avatar Dec 14 '18 01:12 HerinHentry

Thanks Herin we will review this in the new year. Thanks for bringing it up :)

alex-page avatar Dec 14 '18 07:12 alex-page

Totally agree with you @HerinHentry. Adding aria-expanded and aria-haspopup would follow the ARIA design pattern for menu button.

@alex-page I noticed that DTA website and DTA marketplace have implemented the mobile menu as an accordion rather than a flyout as per the design system. This would be good to talk though before the update as it could have some bearing on whether we use aria-haspopup or not.

sarahpulis avatar Jan 16 '19 23:01 sarahpulis

I agree with aria-expanded, however, do not include aria-haspopup. I recommend adding aria-controls.

‘Authors MUST ensure that the role of the element that serves as the container for the popup content is menu, listbox, tree, grid, or dialog’.

I also recommend wrapping the menu expand/collapse buttons in a div with a role of heading and aria-level. Recent discussions with a blind screen reader user who is also an accessibility developer found ‘If role heading and aria-level is implemented, expanding the subsection it is a clear indicator that the section starts at a particular point, so the heading is helpful for that plus the user can quickly jump between them using the H and Shift+H keys with or without the sections being expanded, and even use the rotor on iOS to swipe between headings using single swipe up/down gestures.

There are major issues using. VoiceOver on IOS. When trying to navigate the expanded menu on mobile the expanded menu cannot be accessed. VoiceOver moves through the background page and not the expanded menu—which is inaccessible.

https://www.w3.org/TR/wai-aria-1.1/#aria-haspopup

LaurenceRLewis avatar Mar 05 '19 20:03 LaurenceRLewis

Hi @Decrepidos thanks for sharing, I tried out the main nav on voiceover IOS and you are right. Despite there being an 'overlay' div with a high z-index, VoiceOver is still able to access elements behind the slide out menu. Is there a work around for this?

I'll start working on a new implementation with the new mark up.

sukhrajghuman avatar Jul 17 '19 05:07 sukhrajghuman

@sukhrajghuman I will try and review the code tomorrow to find a solution for the menu.

LaurenceRLewis avatar Jul 17 '19 08:07 LaurenceRLewis

@sukhrajghuman

A solution is to hide the background for AT users when the menu is open:

add aria-hidden="true" to the background when the menu is expanded and the overlay is visible.

$('.au-main-nav__toggle au-main-nav__toggle--closed').on('click',function(){ $('.page-wrapper').attr('aria-hidden', 'true'); }; $('.au-main-nav__toggle au-main-nav__toggle--open').on('click',function(){ $('.page-wrapper').removeAttr('aria-hidden'); };

This effectively does the same as the overlay which hides the background elements for visual users.

Other issues identified during current testing

The 'Australian Government official website' disclosure widget, when expanded, the next swipe moves me to the MENU button.

I believe this is caused by the method used to collapse / expand by changing the CSS height from 0 to auto; which seems to be tied into the display block / none somehow. If this CSS is turned off the disclosure breaks.

.js .au-accordion__body.au-accordion--closed { display: none; height: 0; } .js .au-accordion__body.au-accordion--open { display: block; height: auto; } I cannot find the script that runs this to offer a fix. I recommend changing this a using the method for a disclosure widget described by the ARIA Authoring Practices 1.1 https://www.w3.org/TR/wai-aria-practices/examples/disclosure/disclosure-faq.html

Implementation of aria-controls

The following does not do anything and can (should) be removed because a <div> cannot control anything so aria-controls is invalid.

<div aria-controls="au-main-nav-99" class="au-main-nav__overlay" style=""></div>

The TAB component HTML | REACT

The unselected tab is missing the aria-selected attribute. aria-selected must be set to false on the unselected tabs.

Hope this helps

Cheers Laurence

LaurenceRLewis avatar Jul 18 '19 03:07 LaurenceRLewis

Thanks @Decrepidos for all of this. We really appreciate it.

I will try your method to see if this solves our issues with main-nav.


The following does not do anything and can (should) be removed because a

cannot control anything so aria-controls is invalid.

I agree. Will change this.

The 'Australian Government official website' disclosure widget, when expanded, the next swipe moves me to the MENU button.

This is interesting I have opened up another ticket to investigate this.

The unselected tab is missing the aria-selected attribute. aria-selected must be set to false on the unselected tabs.

Yep nice pick up, have opened a ticket for this.

sukhrajghuman avatar Jul 18 '19 04:07 sukhrajghuman

@sukhrajghuman you are welcome. If you need anything tested at anytime; please let me know. Happy to contribute.

LaurenceRLewis avatar Jul 18 '19 04:07 LaurenceRLewis

@sukhrajghuman This was one of the issues I was gong to share with SM site ally findings. Good to see it already resolved.

AtamDhillon avatar Apr 26 '21 02:04 AtamDhillon

hey @AtamDhillon, The IOS bug where screen readers are able to view elements behind the main nav is still an open issue. I haven't been working on this project for a while so I wasn't able to get around to this.

The only fix that has been applied is adding aria-expanded to the the open/close button

sukhrajghuman avatar Apr 26 '21 22:04 sukhrajghuman

Hi All Don’t know if this helps. I was looking into modal dialog accessibility and created a test CodePen.

https://codepen.io/Deafinitive/pen/GRNZKxG

LaurenceRLewis avatar Apr 27 '21 00:04 LaurenceRLewis

@rossmullen @adrian-yee @monicagee99

sukhrajghuman avatar Apr 27 '21 04:04 sukhrajghuman

hey @AtamDhillon, The IOS bug where screen readers are able to view elements behind the main nav is still an open issue. I haven't been working on this project for a while so I wasn't able to get around to this.

The only fix that has been applied is adding aria-expanded to the the open/close button

Hi Raj, I was away yesterday, a quick resolve may be adding "aria-hidden = true" with open of dialog and remove when closed using js to the elements behind the dialog. It may require multiple elements including main region without restructuring the whole page architecture.

AtamDhillon avatar Apr 28 '21 07:04 AtamDhillon