WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Mallory
Date: Jun 27, 2019 7:02AM

I definitely dislike menus where the top menu items show the subs on hover/focus but clicking them goes to another page-- I've solved this in the past by having the hover/focus bit also happen on click, and have the link that would have been the main menu item be the first item in the new;y shown content.

This can be progressively enhanced from a menu where all the top menu items are just regular clickable links, assuming the destination pages offer ways to get to whatever is offered in any submenus.

Overloaded controls suck (controls that do multiple things based on how you interact with them). I tolerate the tap versus tab-and-hold on mobile (one activates a link/button, the other opens a context menu) but the hover/focus/click ones frustrate me. Like how do I easily make that new content appear with speech rec?

cheers,
_mallory



On Thu, Jun 27, 2019, at 1:22 PM, Birkir R. Gunnarsson wrote:
> Move the link inside the accordion, the trigger should not serve both
> as a trigger and as a link.
> You can make it do both if you ue the menu/menuitem construct or the
> application role to takve over keyboard control from the screen
> reader, but it will require a good deal of Javascript and testing.
>
>
> On 6/27/19, Isabel Holdsworth < <EMAIL REMOVED> > wrote:
> > I don't think the scenario described by the original poster would work
> > as an accordion. As I understand it, when the focus event is fired on
> > a link, something that was previously hidden is revealed, but if the
> > click event is fired, a different page is displayed. So how could the
> > accordion be opened and closed?
> >
> > On 27/06/2019, Brandon Keith Biggs < <EMAIL REMOVED> > wrote:
> >> 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.
> >>> > >>> > >>> > >>> > >>>
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >