crates/biome_html_analyze/src/lint/a11y/no_aria_hidden_on_focusable.rs (2)

171-180: ⚠️ Potential issue | 🟠 Major

Treat empty/missing contenteditable value as truthy.

At Line 175-179, has_contenteditable_true misses <div contenteditable ...> and <div contenteditable="" ...>, which should both be treated as editable in HTML. This creates false negatives.

Proposed patch

 fn has_contenteditable_true(element: &AnyHtmlElement) -> bool {
     element
         .find_attribute_by_name("contenteditable")
-        .is_some_and(|attr| {
-            attr.value().is_some_and(|value| {
-                let trimmed = value.trim();
-                !trimmed.is_empty() && !trimmed.eq_ignore_ascii_case("false")
-            })
-        })
+        .is_some_and(|attr| match attr.value() {
+            None => true,
+            Some(value) => {
+                let trimmed = value.trim();
+                trimmed.is_empty() || !trimmed.eq_ignore_ascii_case("false")
+            }
+        })
 }

Per HTML spec, what state does contenteditable have when present without a value, or with an empty string value?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_html_analyze/src/lint/a11y/no_aria_hidden_on_focusable.rs`
around lines 171 - 180, The function has_contenteditable_true incorrectly treats
elements like <div contenteditable> and <div contenteditable=""> as
non-editable; update has_contenteditable_true to treat presence of the
contenteditable attribute with no value or an empty string as truthy per the
HTML spec by returning true when the attribute exists and its value is either
missing or empty, and only return false when the attribute value is explicitly
"false" (case-insensitive); locate has_contenteditable_true and adjust the
attribute value check to consider attr.value() being None or Some("") as true
while still treating "false" as false.

---

155-164: ⚠️ Potential issue | 🟠 Major

Exclude hidden inputs from native-focusable detection.

Line 157 currently treats all <input> elements as focusable. That includes type="hidden", which should not trigger this rule, so this can raise false positives. Also add a fixture for <input type="hidden" aria-hidden="true"> to lock this down.

Proposed patch

-        if name_matches("button")
-            || name_matches("input")
-            || name_matches("select")
+        if name_matches("button")
+            || name_matches("select")
             || name_matches("textarea")
             || name_matches("details")
             || name_matches("summary")
         {
             return true;
         }
+
+        if name_matches("input") {
+            let is_hidden_input = element
+                .find_attribute_by_name("type")
+                .and_then(|attr| attr.value())
+                .is_some_and(|value| value.trim().eq_ignore_ascii_case("hidden"));
+            return !is_hidden_input;
+        }

In the HTML Standard, is <input type="hidden"> part of sequential keyboard focus navigation (tab order)?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@crates/biome_html_analyze/src/lint/a11y/no_aria_hidden_on_focusable.rs`
around lines 155 - 164, The current native-focusable check treats all inputs as
focusable (the name_matches("input") branch) which incorrectly includes <input
type="hidden">; update the logic so the input case explicitly excludes inputs
where the type attribute is "hidden" (e.g., check the element's "type" attribute
or add an is_hidden_input helper and use it in the early-return condition), and
add a fixture/test for <input type="hidden" aria-hidden="true"> to verify it no
longer triggers the rule; ensure you update the same function containing the
name_matches("input") check so hidden inputs are not considered focusable.

crates/biome_html_analyze/tests/specs/a11y/noAriaHiddenOnFocusable/valid.html (1)

13-13: Consider adding an invalid contenteditable value test case.

Per the HTML spec, invalid values like contenteditable="banana" fall back to the Inherit state (not an editing host). Adding a case like <div contenteditable="banana" aria-hidden="true"> would document this edge case behaviour.

Suggested addition

 <div contenteditable="false" aria-hidden="true">not editable</div>
+<div contenteditable="banana" aria-hidden="true">invalid value inherits</div>
 <BUTTON aria-hidden="true" tabindex="-1"></BUTTON>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@crates/biome_html_analyze/tests/specs/a11y/noAriaHiddenOnFocusable/valid.html`
at line 13, Add a test case showing the invalid contenteditable value behavior
by including an element like <div contenteditable="banana"
aria-hidden="true">not editable</div> in the valid.html tests for
noAriaHiddenOnFocusable; this documents that invalid values fall back to Inherit
(not an editing host) so aria-hidden on that element is acceptable.