WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Isabel Holdsworth
Date: Jun 27, 2019 5:09AM

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.
>> >> >> >> >>
> > > > >