WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Birkir R. Gunnarsson
Date: Jun 26, 2019 7:34PM

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.