Developing a Keyboard Interface Practice: Clarify guidance for “Focusability of disabled controls”

[adampage]

Makes small clarifications in the “Focusability of disabled controls” section.

Closes #2318.

Preview

Preview the revised keyboard practice page in the compare branch

---

WAI Preview Link (Last built on Wed, 01 Apr 2026 15:20:47 GMT).

[mcking65]

made a couple of suggestions and ran out of steam ... struggling with GitHub changes.

[adampage]

Thanks, @mcking65 — committed. 👍🏻

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed PR 3387: Clarify guidance for Focusability of disabled controls.

The full IRC log of that discussion

<jugglinmike> Topic: PR 3387: Clarify guidance for Focusability of disabled controls
<jugglinmike> github: https://github.com//pull/3387
<jugglinmike> Matt_King: This is Adam_Page's pull request
<jugglinmike> Matt_King: I'm in the middle of reviewing it
<jugglinmike> Matt_King: I've already made a couple suggestions in the pull request. I hope they're good! It was kind of hard for me to review my own suggestions in the GitHub UI following some recent changes on that site
<jugglinmike> Matt_King: I was trying to soften up some of the language a bit more, and I have an idea for one more suggestion along those lines
<jugglinmike> Matt_King: It would be nice to get some other perspective on this pull request
<jugglinmike> Adam_Page: I've read your feedback, and I agree with all of it. I committed all the changes you suggested
<Daniel> q+
<jugglinmike> Matt_King: There's a paragraph that reads, "In the APG, our examples have adopted the following" with a list of two items (the second having a bunch of sub-list items). Those two list items are worded in a definitive way. I'm thinking of aligning the wording of those list items with the wording of the text that precedes them
<Daniel> q?
<jugglinmike> Jem_: I appreciate the directness of that wording
<jugglinmike> Matt_King: But the feedback is that we want to make sure the optionality is clear to readers
<jugglinmike> Adam_Page: I understand what you're getting at. There's an important rhetorical difference between "we did this" and "the reader should do this", and this change kind of mixes those two stances
<jugglinmike> Adam_Page: I'll take another pass with that in mind
<jugglinmike> Zakim, end the meeting

[adampage]

Heya @mcking65, how about this latest commit? Here’s a direct preview link.

[cgatian]

👋 An outsider that happened to come across this issue while researching mui/base-ui#4174

The improved docs help clarify the use cases, but didn't mention the expected behavior for a disabled radio within a radio group. I'm assuming using disabled on a radio is the correct pattern because the user doesn't need to know this is a selectable option.

But then I reading this:

discoverability of these features relies on their focusability even when they are not immediately applicable

It made me think, "it depends"? Is there any clarification you could provide?

Thank you!

[mcking65]

@adampage

Thank you for the revisions and direct link. I'm not going to battle the new GitHub accessibility problems in the diff viewer today. Instead, I will just quote content here to give feedback.

Editorial style note: "We" (the task force) avoid use of personal pronouns, especially first and second person. There are two instances of "we".(irony intended 😄 )

I think we may leave readers scratching their heads a bit wondering why some elements needs to be discoverable and others do not. The text only partially conveys a rationale in the cut/copy/paste example. For the others, there is no explanation.

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. For example:

What about something like:

1. When users could reasonably infer the presence of a disabled element based on the nature of surrounding non-disabled elements that are focusable, disabled elements are removed from the keyboard focus order. To achieve this, the example conveys the disabled state by using the HTML disabled attribute. For example:

Then:

In the example of a scrollable grid with previous and next buttons for scrolling, users can infer the presence of the disabled "previous" button when the grid is showing the first page of content and the "Next" button receives focus.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed PR 3387: Clarify guidance for Focusability of disabled controls.

The full IRC log of that discussion

<jugglinmike> Topic: PR 3387: Clarify guidance for Focusability of disabled controls
<jugglinmike> github: https://github.com//pull/3387
<jugglinmike> Matt_King: Adam_Page couldn't make it today
<jugglinmike> Matt_King: I've added some feedback
<jugglinmike> Daniel: I've written up some suggestions, but I haven't been able to post them yet due to technical difficulties with the GitHub UI
<jugglinmike> Matt_King: I wonder if your comments are similar to my comments. I added a comment rather than trying to mess with the "diff" viewer itself. I quoted the text that I think should change and I added my suggestions there
<jugglinmike> Matt_King: (I'm finding the new "diff" viewer for GitHub pull requests almost impossible to use.)
<jugglinmike> Matt_King: It looks like I'm the only person who has been formally designated as a reviewer. If anyone else wants to add feedback, now is the time!
<jugglinmike> Matt_King: But if Daniel is also reviewing, I think that will be sufficient because this is strictly an editorial change

[daniel-montalvo]

Couple comments

[daniel-montalvo]

@adampage Link checker is failing here, I think it's because of https://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/

We may want to update that link with https://vispero.com/resources/using-wai-aria-landmark-roles/, which seems to be the most up-to-date version they have.

[adampage]

Hi @mcking65, I’ve just finished incorporate your and @daniel-montalvo’s suggestions. Please check out the latest deploy preview and let me know what you think?

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed PR 3387: Developing a Keyboard Interface Practice: Clarify guidance for “Focusability of disabled controls” by adampage.

The full IRC log of that discussion

<jugglinmike> subtopic: PR 3387: Developing a Keyboard Interface Practice: Clarify guidance for “Focusability of disabled controls” by adampage
<jugglinmike> github: https://github.com//pull/3387
<jugglinmike> Adam_Page: I've incorporated all feedback to date... As of half an hour ago
<jugglinmike> Matt_King: Great! I'll give this another read. We may be really close on this one.