From 31148f9bf2190a6ca08a99bbe50c30c5ba271183 Mon Sep 17 00:00:00 2001 From: Adam Page Date: Tue, 2 Dec 2025 16:30:59 -0800 Subject: [PATCH 01/10] initial suggestions --- .../keyboard-interface/keyboard-interface-practice.html | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 67c2543fcb..e241bed366 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -391,9 +391,8 @@

Note

Focusability of disabled controls

- By default, disabled HTML input elements are removed from the tab sequence. - In most contexts, the normal expectation is that disabled interactive elements are not focusable. - However, there are some contexts where it is common for disabled elements to be focusable, especially inside of composite widgets. + By default, HTML input elements with the disabled attribute are removed from the tab sequence. + However, there are some contexts where it is useful for an element to convey a disabled state while remaining focusable, especially inside of composite widgets. For example, as demonstrated in the menu and menubar pattern, disabled items are focusable when navigating through a menu with the arrow keys. @@ -406,12 +405,12 @@

Focusability of disabled controls

- Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements. + Authors are encouraged to adopt a consistent set of pattern-specific conventions for the focusability of disabled elements. The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.

    -
  1. For elements that are in the tab sequence when enabled, remove them from the tab sequence when disabled.
    2. +
  2. For disabled elements that don’t need to remain discoverable, remove them from the tab sequence.
  3. For the following composite widget elements, keep them focusable when disabled: From 7af15e5d6fde27aeda5b1b0c72cce53286877189 Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 18 Feb 2026 08:14:04 -0800 Subject: [PATCH 02/10] Update content/practices/keyboard-interface/keyboard-interface-practice.html Co-authored-by: Matt King --- .../keyboard-interface/keyboard-interface-practice.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index e241bed366..4b12edc47b 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -391,7 +391,7 @@

    Note

    Focusability of disabled controls

    - By default, HTML input elements with the disabled attribute are removed from the tab sequence. + Browsers remove HTML input elements with the disabled attribute from the tab sequence. However, there are some contexts where it is useful for an element to convey a disabled state while remaining focusable, especially inside of composite widgets. For example, as demonstrated in the menu and menubar pattern, From be655090d7448c99f86167f4856e52a91f94175e Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 18 Feb 2026 08:14:10 -0800 Subject: [PATCH 03/10] Update content/practices/keyboard-interface/keyboard-interface-practice.html Co-authored-by: Matt King --- .../keyboard-interface/keyboard-interface-practice.html | 1 + 1 file changed, 1 insertion(+) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 4b12edc47b..78727235a6 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -393,6 +393,7 @@

    Focusability of disabled controls

    Browsers remove HTML input elements with the disabled attribute from the tab sequence. However, there are some contexts where it is useful for an element to convey a disabled state while remaining focusable, especially inside of composite widgets. + This can be accomplished by applying the state aria-disabled="true". For example, as demonstrated in the menu and menubar pattern, disabled items are focusable when navigating through a menu with the arrow keys. From 781eee7d33f6d36cef0098e236e7b823473c35ae Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 18 Feb 2026 16:45:36 -0800 Subject: [PATCH 04/10] finesse --- .../keyboard-interface-practice.html | 41 +++++++++---------- 1 file changed, 20 insertions(+), 21 deletions(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 78727235a6..23a3119fbe 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -409,14 +409,30 @@

    Focusability of disabled controls

    Authors are encouraged to adopt a consistent set of pattern-specific conventions for the focusability of disabled elements. The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.

    -
      -
    1. For disabled elements that don’t need to remain discoverable, remove them from the tab sequence.
      2. -
    2. - For the following composite widget elements, keep them focusable when disabled: + When a disabled element does not need to remain discoverable, we apply the native disabled attribute so that it will no longer be focusable. + For example: +
        +
      • + The “Previous” and “Next” buttons in the “Scrollable Search Results” example of a Grid, each of which will become respectively disabled when the user has navigated to the start or end of the grid. +
        • +
      • + A toolbar with buttons for moving, removing, and adding items in a list includes buttons for "Up", "Down", "Add", and "Remove". + The "Up" button is disabled and its focusability is removed when the first item in the list is selected. + Given the presence of the "Down" button, discoverability of the "Up" button is not a concern. +
        • +
      +
      3. +
    3. + When a disabled element does need to remain discoverable, we apply aria-disabled="true" so that it remains focusable. For example:
        +
      • + The “Copy”, “Cut”, and “Paste” buttons in the Toolbar. + The discoverability of these features relies on their focusability even when they are not immediately applicable + (i.e., when no text is selected in the editor and/or when the clipboard is empty). +
      • Options in a Listbox
      • Menu items in a Menu or menu bar
      • Tab elements in a set of Tabs
        • @@ -424,23 +440,6 @@

        Focusability of disabled controls

      4. -
    4. - For elements contained in a toolbar, make them focusable if discoverability is a concern. - Here are two examples to aid with this judgment. - -
        -
      1. - A toolbar with buttons for moving, removing, and adding items in a list includes buttons for "Up", "Down", "Add", and "Remove". - The "Up" button is disabled and its focusability is removed when the first item in the list is selected. - Given the presence of the "Down" button, discoverability of the "Up" button is not a concern. -
        2. - -
      2. - A toolbar in an editor contains a set of special smart paste functions that are disabled when the clipboard is empty or when the function is not applicable to the current content of the clipboard. - It could be helpful to keep the disabled buttons focusable if the ability to discover their functionality is primarily via their presence on the toolbar. -
        3. -
      -

    One design technique for mitigating the impact of including disabled elements in the path of keyboard focus is employing appropriate keyboard shortcuts as described in Keyboard Shortcuts.

    From 4d8e23c3b4b62f03ae4a7dd4b76f695e8a29c78b Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 1 Apr 2026 07:26:35 -0700 Subject: [PATCH 05/10] Update content/practices/keyboard-interface/keyboard-interface-practice.html Co-authored-by: Daniel Montalvo <49305434+daniel-montalvo@users.noreply.github.com> --- .../keyboard-interface/keyboard-interface-practice.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 23a3119fbe..22269ca4c0 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -406,7 +406,7 @@

    Focusability of disabled controls

    - Authors are encouraged to adopt a consistent set of pattern-specific conventions for the focusability of disabled elements. +Authors are encouraged to adopt consistent pattern-based conventions for the focusability of disabled elements. The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.

      From 7e041768bfe0dbea28a4335d4b075b2d4027f43f Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 1 Apr 2026 07:29:56 -0700 Subject: [PATCH 06/10] clarify lack of discoverability --- .../keyboard-interface/keyboard-interface-practice.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 22269ca4c0..1ac0ed5b7e 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -402,7 +402,7 @@

      Focusability of disabled controls

      Removing focusability from disabled elements can offer users both advantages and disadvantages. Allowing keyboard users to skip disabled elements usually reduces the number of key presses required to complete a task. - However, preventing focus from moving to disabled elements can hide their presence from screen reader users who "see" by moving the focus. + However, screen reader users are far less likely to discover disabled elements that are not focusable because moving focus is one of their primary methods of discovery.

      From 6bc6028b52a04f56b239d37f2b23c7325c954f0f Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 1 Apr 2026 08:07:07 -0700 Subject: [PATCH 07/10] =?UTF-8?q?rewrite=20=E2=80=9Cwe=E2=80=9D=20statemen?= =?UTF-8?q?ts?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../keyboard-interface/keyboard-interface-practice.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 1ac0ed5b7e..945d8a41e4 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -411,7 +411,7 @@

      Focusability of disabled controls

      1. - When a disabled element does not need to remain discoverable, we apply the native disabled attribute so that it will no longer be focusable. + When a disabled element does not need to remain discoverable, the native disabled attribute is applied so that it will no longer be focusable. For example:
        • @@ -426,7 +426,7 @@

          Focusability of disabled controls

        • - When a disabled element does need to remain discoverable, we apply aria-disabled="true" so that it remains focusable. For example: + When a disabled element does need to remain discoverable, aria-disabled="true" is applied so that it will remain focusable. For example:
          • The “Copy”, “Cut”, and “Paste” buttons in the Toolbar. From 010fbd99d860d5e7a1a9f4ce217a7105f000f781 Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 1 Apr 2026 08:16:18 -0700 Subject: [PATCH 08/10] clarify case where users can infer a disabled element --- .../keyboard-interface-practice.html | 29 +++++++++++-------- 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 945d8a41e4..a0952e41d2 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -411,18 +411,23 @@

            Focusability of disabled controls

            1. - When a disabled element does not need to remain discoverable, the native disabled attribute is applied so that it will no longer be focusable. - For example: -
                -
              • - The “Previous” and “Next” buttons in the “Scrollable Search Results” example of a Grid, each of which will become respectively disabled when the user has navigated to the start or end of the grid. -
                • -
              • - A toolbar with buttons for moving, removing, and adding items in a list includes buttons for "Up", "Down", "Add", and "Remove". - The "Up" button is disabled and its focusability is removed when the first item in the list is selected. - Given the presence of the "Down" button, discoverability of the "Up" button is not a concern. -
                • -
              + When users can reasonably infer a disabled element from nearby + focusable elements, it can be removed from the keyboard focus order + using the HTML disabled attribute. For example: +
                +
              • + In the “Scrollable + Search Results” grid example, when the grid is showing the + first page and the “Next” button receives focus, users can infer + that the “Previous” button is disabled. +
                • +
              • + A toolbar with buttons for moving, removing, and adding items in a list includes buttons for "Up", "Down", "Add", and "Remove". + The "Up" button is disabled and its focusability is removed when the first item in the list is selected. + Given the presence of the "Down" button, discoverability of the "Up" button is not a concern. +
                • +
            2. From 082cd032ba476bcad4f3e3dde68b105630bae7db Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 15 Apr 2026 07:40:30 -0700 Subject: [PATCH 09/10] Update content/practices/keyboard-interface/keyboard-interface-practice.html Co-authored-by: Matt King --- .../keyboard-interface/keyboard-interface-practice.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index a0952e41d2..95f6274663 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -411,7 +411,7 @@

              Focusability of disabled controls

              1. - When users can reasonably infer a disabled element from nearby + When users can reasonably infer the presence of a disabled element from nearby focusable elements, it can be removed from the keyboard focus order using the HTML disabled attribute. For example:
                  From 0e263eb53982bb3ef6fb64fc36edec7ca74c89eb Mon Sep 17 00:00:00 2001 From: Adam Page Date: Wed, 15 Apr 2026 07:40:43 -0700 Subject: [PATCH 10/10] Update content/practices/keyboard-interface/keyboard-interface-practice.html Co-authored-by: Matt King --- .../keyboard-interface/keyboard-interface-practice.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/practices/keyboard-interface/keyboard-interface-practice.html b/content/practices/keyboard-interface/keyboard-interface-practice.html index 95f6274663..d0f7255598 100644 --- a/content/practices/keyboard-interface/keyboard-interface-practice.html +++ b/content/practices/keyboard-interface/keyboard-interface-practice.html @@ -412,7 +412,7 @@

                  Focusability of disabled controls

                  1. When users can reasonably infer the presence of a disabled element from nearby - focusable elements, it can be removed from the keyboard focus order + focusable elements, it is removed from the keyboard focus order using the HTML disabled attribute. For example: