E-mail List Archives
Thread: Expected behavior for focus events when using screenreader arrow navigation
Number of posts in this thread: 8 (In chronological order)
From: cb
Date: Wed, Jun 26 2019 1:03PM
Subject: Expected behavior for focus events when using screenreader arrow navigation
No previous message | Next message →
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
From: Steve Green
Date: Wed, Jun 26 2019 2:04PM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | Next message →
I would expect screen readers to do what JAWS is doing i.e. it reads the link text but does not trigger the focus event.
If the link has a destination, you obviously can't trigger the focus event and reveal the flyout by operating the link. The solution would depend on the nature and size of the flyout's content. If it is very small, it might be appropriate to concatenate it with the link text, in which case screen reader users don't need to trigger the focus event.
If the flyout content is larger, you might want screen readers to read it before and separately from the link text regardless of whether the flyout is open or not.
It's difficult to say for sure without seeing the link and flyout in context.
Steve Green
Managing Director
Test Partners Ltd
From: Sailesh Panchang
Date: Wed, Jun 26 2019 3:02PM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | Next message →
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 ADDRESS 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
> > > > >
From: Birkir R. Gunnarsson
Date: Wed, Jun 26 2019 7:34PM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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.
From: Brandon Keith Biggs
Date: Thu, Jun 27 2019 12:02AM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
> > > > >
From: Isabel Holdsworth
Date: Thu, Jun 27 2019 5:09AM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
>> >> >> >> >>
> > > > >
From: Birkir R. Gunnarsson
Date: Thu, Jun 27 2019 5:21AM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
From: Mallory
Date: Thu, Jun 27 2019 7:02AM
Subject: Re: Expected behavior for focus events when using screenreader arrow navigation
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
> > > > >