E-mail List Archives
Thread: Query on button navigation
Number of posts in this thread: 2 (In chronological order)
From: Vemaarapu Venkatesh
Date: Wed, May 03 2017 4:38AM
Subject: Query on button navigation
No previous message | Next message →
Hi all, Greetings
While testing with Voice Over in MAC I observed few buttons in the app are
not navigable with tab key but able to access them with VO+right/ left
arrow keys. I filed this as bug because I feel that every action element
should be in tab order though VO+right/ left arrow keys are primary
navigation keys in MAC. But this is not accepted as bug as these buttons
are navigable with VO+arrow keys. Is it really not a bug?
I have one more query on button navigation in general not in MAC. The
context is, I have a navigation tree view and all these tree view items are
buttons where I can arrow up/ down through the tree view. "Selected/ not
selected" states are assigned to these buttons in the tree view.
1. I feel that buttons should be navigable with tab key but not with arrow
keys. So role should not be button for these tree view items. Is it fine or
it's OK if buttons are navigable with only arrow keys instead of tab.
2. I didnt feel great seeing selected/ not selected states on buttons. Is
it recommendable to use these states on buttons? I think pressed/ not
pressed are only applicable states for buttons.
The above context is seen with JAWS and NVDA in a desktop app.
Need your expertise on these and thanks for the knowledge share in advance.
Thanks,
Venkatesh
From: Jonathan Cohn
Date: Thu, May 04 2017 8:41PM
Subject: Re: Query on button navigation
← Previous message | No next message
Some of your questions can only be answered with it depends. When there are 100's of buttons then having all of them reachable by tab actually significantly reduces accessibility. To expand /collapse a tree view, I would have thought the role should be collapsed / expanded for a tree view that as buttons to hide some of the contents. I can't recall off-hand if there is a better role than button for use with tree views. But generally tree views should be navigated with up / down to go to next / prior item and left / right keys to collapse / expand children views. If on a leaf or collapsed parent, and left button is clicked than I believe the standard behavior is to move to the parent of the current node.
Just thought of an interesting question: In right to left languages would the behaviors of left and right arrow keys in a tree view be reversed?
In terms of ARIA states, there is a W3C document that lists valid states for most if not all ARIA roles.
Best wishes,
Jonathan Cohn
> On May 3, 2017, at 6:38 AM, Vemaarapu Venkatesh < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi all, Greetings
>
> While testing with Voice Over in MAC I observed few buttons in the app are
> not navigable with tab key but able to access them with VO+right/ left
> arrow keys. I filed this as bug because I feel that every action element
> should be in tab order though VO+right/ left arrow keys are primary
> navigation keys in MAC. But this is not accepted as bug as these buttons
> are navigable with VO+arrow keys. Is it really not a bug?
>
> I have one more query on button navigation in general not in MAC. The
> context is, I have a navigation tree view and all these tree view items are
> buttons where I can arrow up/ down through the tree view. "Selected/ not
> selected" states are assigned to these buttons in the tree view.
> 1. I feel that buttons should be navigable with tab key but not with arrow
> keys. So role should not be button for these tree view items. Is it fine or
> it's OK if buttons are navigable with only arrow keys instead of tab.
> 2. I didnt feel great seeing selected/ not selected states on buttons. Is
> it recommendable to use these states on buttons? I think pressed/ not
> pressed are only applicable states for buttons.
>
> The above context is seen with JAWS and NVDA in a desktop app.
> Need your expertise on these and thanks for the knowledge share in advance.
>
> Thanks,
> Venkatesh
> > > >