Keyboard navigation in lists

repeater-widget

#1

How do we implement keyboard navigation?
In a list, users should be able to scroll by using up/down arrow keys, and then expand/collapse a list item by using right/left arrow keys. The expanded area includes some buttons which should be accessed by using TAB/Enter.
Then there are the additional states needed for this; Focus + Selected.
Please advise.

This is an accessibility success criterion (WCAG 2.1.1) and also very useful for all users. Proper support for this in Axure would be very much appreciated.


#2

Items in an Axure mockup will generally work with keyboard tab navigation, but this will follow the order of items in the outline (second pane in the lefthand navigation bar). This can be very, very difficult to keep consistent, especially if you’re grouping items and doing anything with dynamic panels/repeaters/popups etc. You can also fake some arrow key/return key interactions by having ‘KeyUp’ interactions which monitor for those keys being pressed and take specific actions.

In general though, Axure is a mockup tool, not for creating accessible web applications - an Axure mockup would fail any automated WCAG testing by definition, as it is not really properly structured semantic HTML/CSS. You shouldn’t really be doing any sort of accessibility testing on a mockup, as screen readers, automated tests and users with specific accessibility needs won’t be able to effectively test anything, since it is not a real webpage with structured relationships between elements.


#3

Thanks for taking the time to comment. I’m aware of most of what you’re saying, including the fact that Axure is only a mockup tool. What I’m requesting is a way to simulate keyboard navigation, not creating an actual accessible prototype/mockup.
I hope there will be support for this in the future, the same way Axure supports simulations of lots of other interaction metaphors. But in the meantime, I was hoping that someone had an improvised way of simulating keyboard navigation.


#4

There’s no standardised way aside from using a combination of element order (dictated by the outline) for tab key focus changes (I use this pretty reasonably in forms and tables) and key press monitoring, which is laborious.

HTML elements like droplists etc will respond as they normally would to keyboard navigation, but I don’t think tables etc will. You’d have to use interactions to listen for arrow key presses and then move focus manually.


#5

I’m afraid you’re right :neutral_face: But thanks anyway.


#6

Hi Frank, try this examplenavigacee.rp (49.6 KB)


#7

Sorry for late respons. Extremely busy these days. But thanks, this was the best solution to my problem. Thanks again!


closed #8

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.