====== Keyboard Navigation and Visible Focus ======

The ability to navigate a site using only the keyboard is important for screen reader users as well as sighted people with mobility impairments. [[https://accessibility.digital.gov/ux/tab-order/|Understanding tab order]] is essential. Keyboard users will navigate every focusable item on the screen, in sequential order, unless skip links and [[accessibility:aria:landmarks|ARIA landmarks]] are provided. Using the tab and arrow keys, users should reach each element on the page in the same order it appears visually.

Avoid setting the tabindex attribute to a positive value if you can help it. The browser determines the tabbing order automatically based on the sequence of elements in the markup.

Click actions must be available to people using keyboards as well as mice. [[accessibility:links|Use <button> instead of <a>]] for triggering actions that do not reload the page, so that click events will include keyboard support automatically.

Avoid attaching essential actions to hover events. These will be unavailable to both keyboard and touchscreen users.

===== Visible Focus =====

Sighted people using keyboards for navigation need to see which page element has focus. Most native HTML controls have focus indicators; it’s important to avoid turning these off. Custom components may need to have focus styles set explicitly. The focus color should have a 3:1 contrast ratio with the background (using the [[https://webaim.org/resources/contrastchecker/|WebAIM contrast checker]]).

In CSS, `:focus` will create an outline that is visible when an element has focus via keyboard navigation and mouse clicks, while [[https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible|`:focus-visible` behaves differently depending on the mode of input]]. You can use `:focus-visible` to avoid visible focus rings on clicked buttons and links (but do some user testing first to make sure the rings are not helpful).

In modal windows, [[https://hidde.blog/using-javascript-to-trap-focus-in-an-element/|focus must be trapped in the modal until it is dismissed]], and there must be a way to dismiss the modal using the keyboard.

===== References =====

  * [[https://www.accessguide.io/guide/focus-indicator|Ensure that focus indicator is visible, Access Guide]]
  * [[https://www.digitala11y.com/focus-visible-understanding-sc-2-4-7/|Understanding SC 2.4.7 Focus Visible, DigitalA11y]]
  * [[https://www.sarasoueidan.com/blog/focus-indicators/|A guide to designing accessible, WCAG-compliant focus indicators, Sara Soueidan]]
  * [[https://adrianroselli.com/2023/08/where-to-put-focus-when-deleting-a-thing.html|Where to Put Focus When Deleting a Thing, Adrian Roselli]]
  * [[https://www.yanandcoffee.com/2020/06/06/accessible-modals-part-2/|Accessible Modals, Part 2 - Focus Trap! Key Events!]]
  * [[https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#keyboardnavigationinsidecomponents#kbd_shortcuts_assignments_assistivetech_conflicts|Avoiding conflicts when creating custom keyboard shortcuts (hotkeys)]]
  * [[https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-keyshortcuts|aria-keyshortcuts attributes]]