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 27, 2019 5:21AM

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.