WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Expected behavior for focus events when using screenreader arrow navigation

for

From: Brandon Keith Biggs
Date: Jun 27, 2019 12:02AM

Hello,
I agree. Can you please give me one circumstance when an accordion menu
would not work for any semantic interface?
I run into the problem that visual designers don't think in classifying
menus. So they think that a menu that looks like a set of drawers that
slide out when you click on them should be a custom menu for screen reader
users, rather than the accordion it is.
Thanks,


Brandon Keith Biggs <http://brandonkeithbiggs.com/>;


On Wed, Jun 26, 2019 at 6:34 PM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> There is more to this.
> If a screen reader is in browse mode and the user is using the arrow
> keys to explore the page it is pretty much the equivalent of someone
> looking at the screen.
> Therefore, in my opinion, a screen reader should not generate any
> events in this state, the user is just reading it. Jaws seems to adopt
> this philosophy while NVDA has more of a hybrid approach.
> Either way, a page should not automatically generate a menu on focus,
> it is going to cause problems.
> Keep it simple and use accordion style menus (you have to click the
> trigger element to display the menu and again to close it, you can
> have the menu close automatically when user moves focus out of it).
> Make sure the trigger has aria-expanded attribute that communicates
> the visible state of the menu.
> Regrding the dual purpose link, the trick as far as a screen reader is
> concerned is that unless the user is in forms/application mode where
> keystrokes are passed thorugh directly to the webpage the screen
> reader will intercept all arrow key presses and act on them (going to
> next/previous line or next/previous character for up/down right/left
> arrows respectively).
> You can circumvent this by putting role="application" on the element
> around the menu (including the trigger), then you can code the enter
> key and arrow keys to do different things, but it would be creating a
> lot of complexity and there is no guarantee the users will figure it
> out.
> I started out recommending and even creating all sorts of fancy menus
> like this, but the more websites I work on, the more I lean towards
> simply creating accordion style menus with links, less JavaScript,
> less work, less ARIA, less confusion.
>
>
>
> On 6/26/19, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> > See if the note in ARIA Authoring Practice 1.1 for Menus / Menubars
> > (3.15) helps your particular situation:
> > The note is under Keyboard Interaction:
> > Although it is recommended that authors avoid doing so, some
> > implementations of navigation menubars may have menuitem elements that
> > both perform a function and open a submenu. In such implementations,
> > enter and Space perform a navigation function, e.g., load new content,
> > while Down Arrow, in a horizontal menubar, opens the submenu
> > associated with that same menuitem.
> > https://www.w3.org/TR/wai-aria-practices-1.1/
> >
> > --
> > Sailesh Panchang
> > Principal Accessibility Consultant
> > Deque Systems Inc
> > 381 Elden Street, Suite 2000, Herndon, VA 20170
> > Mobile: 571-344-1765
> >
> >
> > On 6/26/19, cb < <EMAIL REMOVED> > wrote:
> >> What is the expected or optimal result when a screenreader user is using
> >> arrow navigation and comes across a focusable element that has a focus
> >> event?
> >>
> >> For example, let's say there is a link that has a flyout of some sort
> >> that
> >> activates on hover and on focus. When using tab navigation, I'd expect
> >> that
> >> the focus event would be triggered and the flyout would appear. (I'd
> also
> >> expect that it would be coded in an accessible way so that the
> >> screenreader
> >> user would know what had happened and would be able to access the
> content
> >> of the flyout! But that's not the focus of this question.) What should
> >> happen when you encounter the same element using arrow navigation? Right
> >> now it looks like NVDA triggers the focus event, but Jaws does not. Not
> >> sure about VoiceOver.
> >>
> >> To add complexity: If the link has a destination, and if the
> screenreader
> >> does not trigger the focus event, how can a screenreader user activate
> >> the
> >> flyout without activating the link and moving off the page?
> >>
> >> Thanks
> >>
> >> Caroline
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >