1

Let's say you have a web app with 3 sections. A left nav menu, a toolbar/settings section, and a main application area. Most of the time, the user will be engaging directly with the application, and their document's focus will be potentially somewhere deep inside of the application's "hierarchy", meaning that tabbing into/out of the application to place focus on the left nav or toolbar will be a pain.

Is adding a shortcut (and making the shortcut's keystrokes visible next to that section maybe?) to change focus to the left navigation menu or the toolbar a good idea generally? Otherwise they may have to do a lot of tabbing or use some other method of interacting with that part of the site, which we'd like to avoid. Bonus points if anyone knows how this aligns with WCAG a11y requirements.

EDIT, update with wireframes:

rough application wireframes

Let's say we've got an application with a left nav, a toolbar, and an application (the "meaty" part of the application). The application focuses on the application section first, labelled "SOME APPLICATION" in the wireframes, and has many nested sections that might make it difficult to get out of using focus. Is it appropriate to allow the user to shift focus to, let's say, the first relevant link or button in each of the sections using a shortcut? (I used some contrived examples of shortcuts for the image, but you can imagine some that may be more appropriate perhaps)

  • I think your question to wide. Could you post your wireframe or a sketch of your idea? Then we can discuss looking at your work. And point on the image your doubts and alternatives that you already tried. – BraDev Sep 25 at 11:30
  • Hello z0d14c, welcome to UXSE! As stated by BraDev, could you potentially show us any designs to see your thought process. That way we can look at something tangible and help guide you through your thinking. Personally I don't think this is too broad, just need a little more to understand what you're trying to achieve. – Majo0od Sep 26 at 12:00
  • Ok, I added a super quick update/edit with a very rough example. – z0d14c Sep 27 at 0:15
1

Keyboard navigation is a great thing in the right circumstances, and often it is 'invisible' to anyone who doesn't want to use it, so there's little downside to adding it.

"Right circumstances" might include any or all of:

  • Experienced, regular users: Casual users of an app generally won't remember the keyboard shortcuts (or even consider that keyboard navigation is a possibility). Keyboard navigation is generally for long-term power users.
  • Devices with keyboards: Obviously keyboard shortcuts are only good if you have a keyboard. If the function the key provides is critical, and/or you have a lot of users on phones/tablets, you might want to look at solving it a different way, or providing an alternate path for touch devices (gestures, additional controls, etc)
  • Compatible with the OS: Probably goes without saying that you shouldn't get in the way of standard keyboard shortcuts on the user's operating system or browser. These do vary - keep that in mind when producing help content, for example.

As for accessibility guidelines, see Success Criterion 2.1.4: Character Key Shortcuts. Specifically this relates to shortcuts that are single character keypresses, so if you're using [ctrl]+ or [cmd+] shortcuts, that should be fine. I would implement shortcuts as triggering link elements which point to the element you want to set focus to (rather than just the key setting the focus directly) - this is likely to be compatible with most assistive tech, as they can all deal with plain links and anchors. This maps nicely with your idea of displaying the short-cut as a prompt to the user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.