bug(aria/combobox): Focus management and a11y regressions: Combobox missing readonly, Select disabled is focusable

[rudzikdawid]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

21.2.12

Description

There are two critical accessibility (WCAG) and focus management regressions in the @angular/aria package regarding how readonly and disabled states are handled across Combobox and Select components.

Issue 1: Combobox missing readonly support

In PR #33206, the readonly support seems to have been removed from the combobox implementation, leaving only the disabled state. This removes critical WCAG/a11y functionality needed to build accessible, single-selection dropdowns using the ARIA Combobox pattern.

According to WCAG, a combobox can be "Select-only" (non-editable). For this pattern to be fully accessible, the control must support readonly:

• disabled: The control is completely deactivated and removed from the tab order. It is not focusable, meaning screen reader users navigating via keyboard will bypass it completely.
• readonly: The control remains focusable but non-editable. This is the exact requirement for a "Select-only" dropdown. When a user focuses a readonly combobox, assistive technologies (like VoiceOver) will properly read its label and current value, while preventing the user from typing arbitrary text.

By removing readonly, developers are forced to choose between a fully editable input or a completely disabled control.

Documentation mismatch (Combobox Example 7):
In the current docs: [Combobox - Example 7 (Readonly mode)](https://angular.dev/guide/aria/combobox#readonly-mode https://angular.dev/guide/aria/combobox#example-7), the description explicitly states it is a "readonly combobox". However, the code lacks the readonly attribute, and the input acts as a fully editable control (it accepts arbitrary typing, the menu opens/closes while typing), which completely contradicts the concept of a "Readonly" select mode.

---

Issue 2: Select disabled state is focusable

Conversely, the @angular/aria/select component incorrectly manages the disabled state.

According to standard accessibility practices and native HTML <select disabled> behavior, a disabled control must be strictly unfocusable and removed from the document's tab order.

Documentation mismatch (Disabled Select):
If you go to Select - Disabled Select and navigate using the Tab key, you will notice that the disabled select control actually receives keyboard focus. This is a direct violation of expected disabled semantics.

Summary

The distinction between readonly (focusable, non-editable) and disabled (unfocusable, non-editable) has been lost. The Combobox is missing the former, and the Select incorrectly implements the latter.

Reproduction

StackBlitz link:
Both issues are reproducible directly in the official Angular documentation:

1. Combobox (readonly issue): https://angular.dev/guide/aria/combobox#readonly-mode https://angular.dev/guide/aria/combobox#example-7
2. Select (disabled issue): https://angular.dev/guide/aria/select#disabled-select

Steps to reproduce:

BUG 1: Combobox missing readonly support

1. Go to https://angular.dev/guide/aria/combobox#example-7 (Readonly mode example).
2. Focus the combobox input.
3. Try typing any random arbitrary text using your keyboard.
4. Notice that the input allows free typing and editing, despite being explicitly described as a "readonly combobox" for a "single-selection dropdown".
5. Look at the library source code (after PR feat(aria/combobox): migrate simple-combobox directly into primary entrypoints #33206) - readonly support was removed entirely, making it impossible to implement a true Select-only WCAG pattern.

BUG 2: Select disabled state is focusable

1. Go to https://angular.dev/guide/aria/select#disabled-select
2. Use the Tab key to navigate through the page.
3. Notice that the "disabled" select control actually receives keyboard focus.
4. This violates standard accessibility practices and native HTML behavior, where disabled controls must be removed from the tab order and be unfocusable.

Expected Behavior

1. The @angular/aria/combobox should restore support for the readonly state. This is required to build focusable, non-editable, and screen-reader-friendly single-selection dropdowns according to WCAG. Example 7 in the docs should properly implement this state and prevent arbitrary typing.
2. The @angular/aria/select, when in a disabled state, should be completely removed from the tab order and strictly unfocusable, aligning with native HTML <select disabled> behavior.
3. The distinction between readonly (focusable, non-editable) and disabled (unfocusable, non-editable) must be clearly maintained across all @angular/aria components.

Actual Behavior

1. Combobox: The combobox control currently lacks readonly support. As seen in the official "Readonly mode" example, the input remains fully editable, allowing users to freely type arbitrary text instead of restricting them to listbox selections.
2. Select: A disabled select control currently receives keyboard focus when navigating via the Tab key, instead of being properly removed from the document's tab order.

Environment

• Angular: 22.0.0
• Angular/aria 22.0.0.
• CDK/Material: 22.0.0
• Browser(s): Google Chrome 149
• Operating System (e.g. Windows, macOS, Ubuntu): Fedora

[rudzikdawid]

cc @tjshiu
Hi! I'm tagging you since you worked on PR #33206. It looks like the readonly state was dropped there, which breaks the non-editable combobox pattern. Could you take a look when you have a moment and let us know if this omission was intentional?