BUGFIX: template-no-unsupported-role-attributes — honor aria-query attribute constraints#9
Closed
johanrd wants to merge 3 commits into
Closed
BUGFIX: template-no-unsupported-role-attributes — honor aria-query attribute constraints#9johanrd wants to merge 3 commits into
johanrd wants to merge 3 commits into
Conversation
…ute constraints in implicit-role lookup
The old getImplicitRole picked the first elementRoles entry whose name
matched the tag. For <input> it tried a type-attribute match but
ignored the rest of aria-query's constraint annotations.
Concrete consequences of the old logic:
- <input type="text"> without a `list` attribute returned "combobox"
(because aria-query's {type=text, list=set}→combobox entry appears
before {type=text, list=undefined}→textbox). Correct implicit role is
textbox.
- <input type="email|tel|url"> behaved the same way.
- <input type="password"> isn't mapped by aria-query; the fallback
branch returned the first input entry — "button".
The new implementation walks every elementRoles key whose tag matches,
checks each attribute spec (honoring `constraints: ["set"]` and
`constraints: ["undefined"]` as well as required values), and picks the
entry with the most attribute constraints satisfied.
Behavioral impact:
- Text-like inputs without a list attribute now correctly resolve to
textbox and accept aria-required / aria-readonly / aria-placeholder.
- <input type="password"> now resolves to no implicit role, so global
ARIA attrs don't trip the rule (matching jsx-a11y's treatment).
- One existing test updated: <input type="email"> now maps to textbox
in the error message; added a sibling case with `list="x"` to cover
the combobox path.
- Eight new valid tests cover the textbox/password paths.
🏎️ Benchmark Comparison
Full mitata output |
…peer cases Translates 33 cases from peer-plugin rules: - jsx-a11y role-supports-aria-props - lit-a11y role-supports-aria-attr - vuejs-accessibility (no direct equivalent; divergence noted) The fixture documents where our rule now matches jsx-a11y (notably <input type="email"> without `list` mapping to "textbox" per the aria-query attribute constraints) plus the sibling `list=…` case mapping to "combobox".
Owner
Author
|
Moved upstream to ember-cli#2726. See that PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
aria-query'selementRolesmap encodes element → implicit-role pairings that depend on attribute state. Each entry lists attributes that must beset,undefined, or match a specificvalue.getImplicitRolehelper returned the first entry whose tag name matched, ignoring the attribute constraints on subsequent entries.Concrete consequences of the old logic:
<input type="text">(nolist)<input type="email|tel|url">(nolist)<input type="password">The first two block valid usages involving attributes that
textboxsupports butcomboboxdoes not — notablyaria-placeholder(covered by the new tests) andaria-multiline. Bothtextboxandcomboboxlistaria-requiredin aria-query 5.3.2, so that attribute is not the concern here. The third row is arbitrarily wrong — there's no reason a password input should ever be treated as a button.<input type="password">is intentionally left unmapped because aria-query gives it no role; this diverges from HTML-AAM, which maps it totextbox.Fix: walk every
elementRolesentry whose name matches the tag; evaluate each attribute spec (checkingconstraints: ["set"],constraints: ["undefined"], and required values); pick the entry with the most attribute constraints satisfied.Eight new valid tests cover the textbox/password paths. One existing test updated:
<input type="email" aria-level={{this.level}} />now maps to textbox in the error message; a sibling case withlist="x"covers the combobox path.Prior art
role-supports-aria-propsviagetImplicitRole+ per-element implicit-role files undersrc/util/implicitRoles/.a.jschecks forhrefbefore returning "link".role-supports-aria-attrrole=attribute; does not compute an implicit role from the element + attribute state, so this false positive does not arise there.Upstream
ember-template-lint@7.9.3has the same mis-roling.