refactor: extract isComponentInvocation util (fix native-HTML-tag misclassification)#31
Closed
refactor: extract isComponentInvocation util (fix native-HTML-tag misclassification)#31
Conversation
…g discrimination
Several accessibility rules lowercase `node.tag` and compare it against
a set of native HTML tag names. That misclassifies PascalCase Ember
component invocations whose names happen to match a native HTML element
(e.g. `<Article>`, `<Form>`, `<Main>`, `<Nav>`, `<Ul>`, `<Li>`,
`<Aside>`, `<Section>`, `<Table>`), producing false positives.
Concrete false positives confirmed in the Phase 3 audit:
- B5: `<Article role="button">` flagged as non-interactive-to-interactive-role.
- B8: `<Article tabindex={{0}}>` flagged as non-interactive-tabindex.
Extract the existing inline guard from `template-no-invalid-interactive`
and `template-no-empty-headings` into a single shared util,
`lib/utils/is-component-invocation.js`. The util recognises PascalCase,
named-arg (`<@x>`), this-path (`<this.x>`), dot-path (`<a.b>`), and
named-block (`<Foo::Bar>`) invocations.
This refactor is behaviour-neutral for these two rules; their test
suites are unchanged and still pass.
Follow-up: five more rules also need to adopt this util —
- template-no-aria-hidden-on-focusable
- template-no-interactive-element-to-noninteractive-role
- template-no-noninteractive-element-to-interactive-role
- template-no-role-presentation-on-focusable
- template-no-noninteractive-tabindex
Those rules currently live on open PR branches (#19, #20, #21, #22, #24)
and will adopt the util in separate follow-up PRs once each feature PR
merges.
Ref: audit tracking PR #28 item F2.
🏎️ Benchmark Comparison
Full mitata output |
johanrd
added a commit
that referenced
this pull request
Apr 21, 2026
Migrate template-no-aria-hidden-on-focusable to the shared utility helpers introduced by PR #31 (isComponentInvocation) and PR #37 (isNativeInteractive): - isFocusable() now delegates the native-focusable-tag check to isNativeInteractive(node, getTextAttrValue). The local INHERENTLY_FOCUSABLE_TAGS set and the inline a[href] branch are removed. - hasFocusableDescendant()'s opaque-tag skip (added in G5.1) now uses isComponentInvocation(child) in place of the inline isOpaqueTag predicate; the local isOpaqueTag helper is removed. Behavior delta (spec-correct FN fix): - Previously <video controls> and <audio controls> were absent from the local INHERENTLY_FOCUSABLE_TAGS, so <div aria-hidden="true"><video controls></video></div> was VALID. - isNativeInteractive returns true for audio[controls] / video[controls] (browsers only render focusable media UI when controls is present). Such patterns are now FLAGGED under noAriaHiddenOnAncestorOfFocusable, and the element directly (<video controls aria-hidden="true">) is FLAGGED under noAriaHiddenOnFocusable. - Audio/video without controls remain VALID (no native focusable UI). Tests: new invalid cases for audio/video with controls directly aria-hidden and as descendants of aria-hidden wrappers, in both gts and hbs suites. New valid cases for audio/video without controls to pin the conditional behavior.
johanrd
added a commit
that referenced
this pull request
Apr 21, 2026
Replace the rule's inline INHERENTLY_FOCUSABLE_TAGS set and ad-hoc tag checks with the two shared utils: - lib/utils/is-component-invocation.js (from PR #31) - lib/utils/native-interactive-elements.js (from PR #37) Both files (and their tests) are copied bit-identically from their source branches so parity is preserved while those PRs remain open. Behavior deltas introduced by the util swap ------------------------------------------- The prior inline set was {button, details, embed, iframe, input, select, summary, textarea}. The shared util covers the same set plus several additional native-interactive tags that were previously false negatives: - option, datalist, object, canvas — now recognized as native-interactive - area[href] — now recognized (symmetric with a[href]) - audio[controls], video[controls] — now recognized (per HTML-AAM / browser reality; keyboard-operable transport controls) Net effect: `role="presentation"` / `role="none"` on any of the above is now flagged where it wasn't before. All of these are spec-correct FN fixes (WAI-ARIA 1.2 §4.6 conflict resolution applies the same way once the element is acknowledged as focusable). Tests added for representative new cases: - <video controls role="presentation"> — flags (gts + hbs) - <audio controls role="none"> — flags (gts) - <area href="/x" role="presentation"> — flags (gts) - <video role="presentation"> (no controls) — valid (still not focusable) No deltas for <label>: it was not in the prior INHERENTLY_FOCUSABLE_TAGS set and it is not in the shared util either, so behavior is unchanged. Component-invocation handling is now an explicit early-return via isComponentInvocation(node), which also excludes named-arg (<@slot>), this-path (<this.widget>), and dot-path (<foo.bar>) invocations that were previously only excluded incidentally by the tag-lowercase lookup.
This was referenced Apr 21, 2026
Owner
Author
|
Moved upstream to ember-cli#2724. See that PR for ongoing review. |
johanrd
added a commit
that referenced
this pull request
Apr 26, 2026
Migrate template-no-aria-hidden-on-focusable to the shared utility helpers introduced by PR #31 (isComponentInvocation) and PR #37 (isNativeInteractive): - isFocusable() now delegates the native-focusable-tag check to isNativeInteractive(node, getTextAttrValue). The local INHERENTLY_FOCUSABLE_TAGS set and the inline a[href] branch are removed. - hasFocusableDescendant()'s opaque-tag skip (added in G5.1) now uses isComponentInvocation(child) in place of the inline isOpaqueTag predicate; the local isOpaqueTag helper is removed. Behavior delta (spec-correct FN fix): - Previously <video controls> and <audio controls> were absent from the local INHERENTLY_FOCUSABLE_TAGS, so <div aria-hidden="true"><video controls></video></div> was VALID. - isNativeInteractive returns true for audio[controls] / video[controls] (browsers only render focusable media UI when controls is present). Such patterns are now FLAGGED under noAriaHiddenOnAncestorOfFocusable, and the element directly (<video controls aria-hidden="true">) is FLAGGED under noAriaHiddenOnFocusable. - Audio/video without controls remain VALID (no native focusable UI). Tests: new invalid cases for audio/video with controls directly aria-hidden and as descendants of aria-hidden wrappers, in both gts and hbs suites. New valid cases for audio/video without controls to pin the conditional behavior.
johanrd
added a commit
that referenced
this pull request
Apr 26, 2026
Replace the rule's inline INHERENTLY_FOCUSABLE_TAGS set and ad-hoc tag checks with the two shared utils: - lib/utils/is-component-invocation.js (from PR #31) - lib/utils/native-interactive-elements.js (from PR #37) Both files (and their tests) are copied bit-identically from their source branches so parity is preserved while those PRs remain open. Behavior deltas introduced by the util swap ------------------------------------------- The prior inline set was {button, details, embed, iframe, input, select, summary, textarea}. The shared util covers the same set plus several additional native-interactive tags that were previously false negatives: - option, datalist, object, canvas — now recognized as native-interactive - area[href] — now recognized (symmetric with a[href]) - audio[controls], video[controls] — now recognized (per HTML-AAM / browser reality; keyboard-operable transport controls) Net effect: `role="presentation"` / `role="none"` on any of the above is now flagged where it wasn't before. All of these are spec-correct FN fixes (WAI-ARIA 1.2 §4.6 conflict resolution applies the same way once the element is acknowledged as focusable). Tests added for representative new cases: - <video controls role="presentation"> — flags (gts + hbs) - <audio controls role="none"> — flags (gts) - <area href="/x" role="presentation"> — flags (gts) - <video role="presentation"> (no controls) — valid (still not focusable) No deltas for <label>: it was not in the prior INHERENTLY_FOCUSABLE_TAGS set and it is not in the shared util either, so behavior is unchanged. Component-invocation handling is now an explicit early-return via isComponentInvocation(node), which also excludes named-arg (<@slot>), this-path (<this.widget>), and dot-path (<foo.bar>) invocations that were previously only excluded incidentally by the tag-lowercase lookup.
johanrd
added a commit
that referenced
this pull request
Apr 27, 2026
Migrate template-no-aria-hidden-on-focusable to the shared utility helpers introduced by PR #31 (isComponentInvocation) and PR #37 (isNativeInteractive): - isFocusable() now delegates the native-focusable-tag check to isNativeInteractive(node, getTextAttrValue). The local INHERENTLY_FOCUSABLE_TAGS set and the inline a[href] branch are removed. - hasFocusableDescendant()'s opaque-tag skip (added in G5.1) now uses isComponentInvocation(child) in place of the inline isOpaqueTag predicate; the local isOpaqueTag helper is removed. Behavior delta (spec-correct FN fix): - Previously <video controls> and <audio controls> were absent from the local INHERENTLY_FOCUSABLE_TAGS, so <div aria-hidden="true"><video controls></video></div> was VALID. - isNativeInteractive returns true for audio[controls] / video[controls] (browsers only render focusable media UI when controls is present). Such patterns are now FLAGGED under noAriaHiddenOnAncestorOfFocusable, and the element directly (<video controls aria-hidden="true">) is FLAGGED under noAriaHiddenOnFocusable. - Audio/video without controls remain VALID (no native focusable UI). Tests: new invalid cases for audio/video with controls directly aria-hidden and as descendants of aria-hidden wrappers, in both gts and hbs suites. New valid cases for audio/video without controls to pin the conditional behavior.
johanrd
added a commit
that referenced
this pull request
Apr 27, 2026
Replace the rule's inline INHERENTLY_FOCUSABLE_TAGS set and ad-hoc tag checks with the two shared utils: - lib/utils/is-component-invocation.js (from PR #31) - lib/utils/native-interactive-elements.js (from PR #37) Both files (and their tests) are copied bit-identically from their source branches so parity is preserved while those PRs remain open. Behavior deltas introduced by the util swap ------------------------------------------- The prior inline set was {button, details, embed, iframe, input, select, summary, textarea}. The shared util covers the same set plus several additional native-interactive tags that were previously false negatives: - option, datalist, object, canvas — now recognized as native-interactive - area[href] — now recognized (symmetric with a[href]) - audio[controls], video[controls] — now recognized (per HTML-AAM / browser reality; keyboard-operable transport controls) Net effect: `role="presentation"` / `role="none"` on any of the above is now flagged where it wasn't before. All of these are spec-correct FN fixes (WAI-ARIA 1.2 §4.6 conflict resolution applies the same way once the element is acknowledged as focusable). Tests added for representative new cases: - <video controls role="presentation"> — flags (gts + hbs) - <audio controls role="none"> — flags (gts) - <area href="/x" role="presentation"> — flags (gts) - <video role="presentation"> (no controls) — valid (still not focusable) No deltas for <label>: it was not in the prior INHERENTLY_FOCUSABLE_TAGS set and it is not in the shared util either, so behavior is unchanged. Component-invocation handling is now an explicit early-return via isComponentInvocation(node), which also excludes named-arg (<@slot>), this-path (<this.widget>), and dot-path (<foo.bar>) invocations that were previously only excluded incidentally by the tag-lowercase lookup.
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.
<Article>,<Form>). Rules that donode.tag.toLowerCase()and compare to a set of native HTML tag names misclassify these.<Article role="button">flagged as non-interactive→interactive-role (audit B5);<Article tabindex={{0}}>flagged as non-interactive tabindex (audit B8).Fix: extract the existing inline guard (from
template-no-invalid-interactiveandtemplate-no-empty-headings) into a shared util. No behavior change in those two rules.Follow-up: 5 rules on open PR branches (#19, #20, #21, #22, #24) also need to adopt this util. Tracked separately — those adoptions will land when each PR merges.
Ref: audit tracking PR #28 item F2.