Keyboard Experience on the Form
- Dominant language
- TypeScript
- Stars
- 38
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Description
From https://github.com/getodk/web-forms/issues/86
**WCAG 2.1 Four Main Guiding Principles:**
[Perceivable](https://www.w3.org/TR/WCAG21/#perceivable): Users must be able to perceive the information being presented
[Operable](https://www.w3.org/TR/WCAG21/#operable): Interface forms, controls, and navigation are operable
[Understandable](https://www.w3.org/TR/WCAG21/#understandable): Information and the operation of user interface must be understandable to all users
[Robust](https://www.w3.org/TR/WCAG21/#robust): Users must be able to access the content as technologies advance
## Navigation structure
We want to ensure the keyboard navigation order is logical and intuitive. This navigation order (and also the reading order for screen readers) is determined by the web page's source code. The accessibility guides suggest to structure your underlying source code so that the reading/navigation order is correct. Then, if necessary, use CSS to control the visual presentation of the elements on your page.
> Given I'm about to fill out my form using a keyboard
when I start, I will begin with the header first,
then content of the form, send
and then “Powered by ODK” at the bottom
## Focus indicators
We don't want to auto-advance focus from one field to the next. This makes it difficult for keyboard-only users to navigate and correct mistakes.
> Given I want to select an option and I'm using my keyboard
when I tab through the different options
then I will see a light grey container to indicate which question
The following table includes many of the most common online interactions and the [standard keystrokes](https://webaim.org/techniques/keyboard/) for interacting with controls.
Interaction | Keystrokes | Notes
-- | -- | --
Navigate to interactive elements | Tab - navigate forwardShift + Tab - navigate backward | Keyboard focus indicators must be present.Navigation order should be logical and intuitive.
Link | Enter - activate the link |
Button | Enter or Spacebar - activate the button | Ensure elements with ARIA role="button" can be activated with both key commands.
Checkbox | Spacebar - check/uncheck a checkbox | Users can typically select zero, one, or multiple options from group of checkboxes.
Radio buttons | Spacebar - select the focused option (if not selected)↑/↓ or ←/→ - navigate between optionsTab - leave the group of radio buttons | Users can select only one option from a group of radio buttons.
Select (dropdown) menu | ↑/↓ - navigate between optionsSpacebar - expandEnter/Esc - select option and collapse | You can also filter or jump to options in the menu as you type letters.
Autocomplete | Type to begin filtering↑/↓ - navigate to an optionEnter - select an option |
Dialog | Esc - close | Modal dialogs should maintain keyboard focus.Non-modal dialogs should close automatically when they lose focus.When a dialog closes, focus should usually return to the element that opened the dialog.
Slider | ↑/↓ or ←/→ - increase or decrease slider valueHome/End - beginning or end | For double-headed sliders (to set a range), Tab/Shift + Tab should toggle between each end.In some sliders PageUp/PageDown can move by a larger increment (e.g., by 10%).
Menu bar | ↑/↓ - previous/next menu optionEnter - expand the menu (optional) and select an option.←/→ - expand/collapse submenu | A menu bar dynamically changes content within an application. Links that utilize Tab/Enter are NOT menu bars. |
Scroll | ↑/↓ - scroll vertically←/→ - scroll horizontallySpacebar/Shift + Spacebar - scroll by page | The space bar will, by default, scroll the page, but only if an interactive control that allows space bar input is not focused. Horizontal scrolling within the page should be minimized.
Multi select dropdown | Control/Command or Shift + click to select multiple items | Multi selects are not ideal for keyboards. A group of checkboxes provides similar functionality in a more accessible way, but we don’t have control over this.
Contributor guide
No contributing guide indexed for this repository
Research direction
The issue does not name any files, tests, or entry points. Start by locating the form layout and interactive controls, then inspect existing keyboard focus behavior against the stated navigation and WCAG requirements. Done means the form has logical keyboard order, visible focus indicators, and the documented standard interactions without automatic focus advancement.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- accessibility, frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100