Input May 2025

guidelines/groups/input-operation.json

@@ -1,11 +1,11 @@
 {
   "children": [
+    "keyboard-interface-input",
+    "physical-or-cognitive-effort-when-using-keyboard",
+    "pointer-input",
+    "speech-and-voice-input",
     "input-operation",
-    "content-changes",
-    "target-size",
-    "keyboard-operation",
-    "gestures",
-    "motion-input"
+    "authentication"
   ],
   "title": "Input / operation"
 }

guidelines/groups/input-operation/authentication.md

@@ -0,0 +1,7 @@
+---
+children:
+  - biometric-identification
+  - voice-identification
+---
+
+Provide alternatives to authentication for those who cannot use some authentication methods usable by people without disabilities.

guidelines/groups/input-operation/authentication/biometric-identification.md

@@ -0,0 +1,6 @@
+---
+status: developing
+type: foundational
+---
+
+Use of a biometric is not the only way to identify or authenticate.

guidelines/groups/input-operation/authentication/voice-identification.md

@@ -0,0 +1,6 @@
+---
+status: developing
+type: foundational
+---
+
+Voice is not the only way to identify or authenticate.

guidelines/groups/input-operation/input-operation.md

@@ -1,8 +1,10 @@
 ---
 children:
-  - concurrent-inputs
-  - hover-information
-  - input-control
+  - change-keyboard-focus-with-pointer-device
+  - content-on-hover-or-keyboard-focus
+  - gesture-alternative
+  - input-method-flexibility
+  - use-without-body-movement
 ---
 
-Users can use different input techniques and combinations and switch between them.
+Users have the option to use different input techniques and combinations and switch between them.

guidelines/groups/input-operation/input-operation/change-keyboard-focus-with-pointer-device.md

@@ -0,0 +1,10 @@
+---
+status: developing
+type: foundational
+---
+
+If content interferes with pointer or keyboard focus behavior of the :term[user agent], then selecting anything on the :term[view] with a :term[pointer] moves the keyboard focus to that interactive element, even if the user drags off the element (so as to not activate it).
+
+:::note
+An example of this is: a user scrolls a document down six screens, then clicks on a paragraph with their :term[pointer]. The user then presses the <kbd>tab</kbd> key, which moves the focus to the first interactive component after the position on the screen that was clicked, rather than from the previous position, six screens up the document.
+:::

guidelines/groups/input-operation/input-operation/content-on-hover-or-keyboard-focus.md

@@ -0,0 +1,30 @@
+---
+status: developing
+type: foundational
+---
+
+When receiving and then removing :term[pointer] hover or keyboard focus triggers additional content to become visible and then hidden, and the visual presentation of the additional content is controlled by the author and not by the :term[user agent], all of the following are true:
+
+Dismissible
+
+:  A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content does not obscure or replace other content;
+
+Hoverable
+
+: If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;</dd>
+
+Persistent
+
+: The additional content remains visible until the hover or keyboard focus trigger is removed, the user dismisses it, or its information is no longer valid.
+
+:::note
+Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML <code class="language-html">title</code> attribute.
+:::
+
+:::note
+Custom tooltips, sub-menus, and other non-modal popups that display on hover and keyboard focus are examples of additional content covered by this criterion.
+:::
+
+:::note
+This applies to content that appears in addition to the triggering interactive element itself. Since hidden interactive elements that are made visible on keyboard focus (such as links used to skip to another part of a :term[view]) do not present additional content they are not covered by this requirement.
+:::

guidelines/groups/input-operation/input-operation/gesture-alternative.md

@@ -0,0 +1,6 @@
+---
+status: developing
+type: foundational
+---
+
+Gestures are not the only way of achieving any functionality, except where a :term[gesture] is essential to the functionality.

guidelines/groups/input-operation/input-operation/input-method-flexibility.md

@@ -0,0 +1,10 @@
+---
+status: developing
+type: foundational
+---
+
+Where functionality, including input or navigation, are achievable using different input methods, users have the option to switch between those input methods at any time.
+
+:::note
+This does not mean that all input technologies (pointer, keyboard, voice, gesture) need to be supported in one's content, but if an input modality is supported, it is supported everywhere in the content except where a particular input method is essential to the functionality.
+:::

guidelines/groups/input-operation/input-operation/use-without-body-movement.md

@@ -0,0 +1,10 @@
+---
+status: developing
+type: foundational
+---
+
+Full or gross body movement is not the only way of achieving any functionality, except where full or gross body movement is essential to the functionality.
+
+:::note
+This includes both detection of body movement and actions to the device (e.g., shaking) that require body movement.
+:::

guidelines/groups/input-operation/keyboard-interface-input.md

@@ -0,0 +1,13 @@
+---
+children:
+  - all-elements-keyboard-actionable
+  - all-content-keyboard-accessible
+  - bidirectional-navigation
+  - conflicting-keyboard-commands
+  - keyboard-navigable-if-responsive
+  - no-keyboard-trap
+  - user-control-of-keyboard-focus
+  - relevant-tab-order-keyboard-focus
+---
+
+Users can navigate and operate content using only the keyboard.

guidelines/groups/input-operation/keyboard-interface-input/all-content-keyboard-accessible.md

@@ -0,0 +1,22 @@
+---
+status: developing
+type: foundational
+---
+
+All :term[content] that can be accessed by other input modalities can be accessed using :term[keyboard interface] only.
+
+:::note
+All content includes content made available via hovers, right clicks, etc.
+:::
+
+:::note
+Other input modalities include :term[pointing devices], voice and speech recognition, :term[gesture], camera input, and any other other means of input or control.
+:::
+
+:::note
+The [All Elements Keyboard-Actionable requirement](#all-elements-keyboard-actionable) allows you to navigate to all actionable elements but if the next element is 5 screens down - you also need to be able to access all the content. Also if the content is in expanding sections - you need to not just open them but also access all of the content - not just its actionable elements.
+:::
+
+:::note
+A menu that opens and closes is an interactive group that consists of an icon or label (which opens and closes the menu - and is therefore an interactive element) and a group of interactive elements inside.
+:::

guidelines/groups/input-operation/keyboard-interface-input/all-elements-keyboard-actionable.md

@@ -0,0 +1,10 @@
+---
+status: developing
+type: foundational
+---
+
+All elements that can be controlled or activated by :term[pointer], audio (voice or other), gesture, camera input, or other means can be controlled or activated from the :term[keyboard interface].
+
+:::note
+Here, and throughout this section, "camera input" refers to user control using a camera as a motion sensor to detect gestures of any type, for example "in the air" gestures. It does not include, for example, a static QR code image on a web page.
+:::

guidelines/groups/input-operation/keyboard-interface-input/bidirectional-navigation.md

@@ -0,0 +1,10 @@
+---
+status: developing
+type: foundational
+---
+
+It is always possible to move forward and backward at each point using keyboard navigation.
+
+:::ednote
+We are considering making this require that the navigation be symmetrical (ie., if you navigate forward and then backward you always end up back in the same place) but are interested in comments on this.
+:::

guidelines/groups/input-operation/keyboard-interface-input/conflicting-keyboard-commands.md

@@ -0,0 +1,6 @@
+---
+status: developing
+type: foundational
+---
+
+Author generated keyboard commands do not conflict with :term[standard platform keyboard commands] or they can be remapped.

guidelines/groups/input-operation/keyboard-interface-input/keyboard-navigable-if-responsive.md

@@ -0,0 +1,6 @@
+---
+status: developing
+type: foundational
+---
+
+If the :term[page] / :term[view] uses responsive design, the :term[page] / :term[view] remains fully keyboard navigable.

guidelines/groups/input-operation/keyboard-interface-input/no-keyboard-trap.md

@@ -0,0 +1,6 @@
+---
+status: developing
+type: foundational
+---
+
+It is always possible to navigate away from an element after navigating to, entering, or activating the element by using a :term[common keyboard navigation technique], or by using a technique for exiting is described on the :term[page] / :term[view] or on a :term[page] / :term[view] earlier in the :term[process] where it is used.

guidelines/groups/input-operation/keyboard-interface-input/relevant-tab-order-keyboard-focus.md

@@ -0,0 +1,14 @@
+---
+status: developing
+type: foundational
+---
+
+Except for skip links and other elements that are hidden but specifically added to aid keyboard navigation, tabbing does not move the keyboard focus into content that was not visible before the <kbd>Tab</kbd> (or <kbd><kbd>Shift</kbd> + <kbd>Tab</kbd></kbd>) key was entered.
+
+:::note
+Accordions, dropdown menus, and [ARIA tab panels](https://www.w3.org/WAI/ARIA/apg/patterns/tabs/) are examples of expandable content. According to this requirement, these would not expand simply because they include an element in the tab-order contained in them. They would either not expand or would not have any tab-order elements in them.
+:::
+
+:::note
+For example, a menu that expands when you tab to it, but then uses arrow keys to navigate in it would pass. But a menu that expands and then requires you to tab through all the newly-visible elements to navigate past it would fail.
+:::

guidelines/groups/input-operation/keyboard-interface-input/user-control-of-keyboard-focus.md

@@ -0,0 +1,16 @@
+---
+status: developing
+type: foundational
+---
+
+When the keyboard focus is moved, one of the following is true:
+- The focus was moved under direct user control;
+- A new :term[view] such as a dialog is introduced and focus is moved to that view;
+- The user is informed of the potential keyboard focus move before it happens and given the chance to avoid the move;
+- The keyboard focus moves to the next item in keyboard navigation order automatically on completion of some user action.
+
+:::note
+Examples of where it may be useful to "jump the user to some other location" (after of course asking the user if they want to move there) would be:
+- a form message that says "If you answer no, you can skip questions 8 through 15, would you like to skip to question 16"; and
+- when a form error is detected on submit and a message says "There is an error on the page, would you like to jump to it" (especially if it also provided information on what the error was).
+:::