Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disable specific rules for specific locators in axe-core scan #4417

Open
ling1726 opened this issue Apr 16, 2024 · 2 comments
Open

Disable specific rules for specific locators in axe-core scan #4417

ling1726 opened this issue Apr 16, 2024 · 2 comments

Comments

@ling1726
Copy link

Product: playwright

Expectation: Disable rules for a specific selector in an axe scan

Actual: Can either disable

  • All rules for one locator and its descendants
  • One rule for the entire scan

Motivation: Even if the scanned element has an invalid rule inside one of its subtrees. It's still worth running other rules for that its subtree.

Let's take this example

<div id="to-test">
  <button id="duplicate-id">
    <i class="send-icon"><i>
  </button>

  <button id="duplicate"><i class="delete-icon"></i></button>
</div>

There are two rules that are being violated here:

  1. button does not have accessible name
  2. ids are not unique

If I test the entire UI markup here, there's no way for me ignore a specific rule for one of the problematic buttons (if they happen to be an exception). In fact, it's possible to mistakenly exclude one of the problematic buttons or rules and get a less accurate result from the scan.


axe-core version: 4.9.0
@axe-core/playwright: 4.9.0

- Node version: 20
- Platform:  Mac, Linux, Windows
@straker
Copy link
Contributor

straker commented Apr 18, 2024

Thanks for the issue. Axe-core would be in charge of something like this so I'm going to move this ticket over there.

@straker straker transferred this issue from dequelabs/axe-core-npm Apr 18, 2024
@dbjorge
Copy link
Contributor

dbjorge commented Apr 19, 2024

Today, the easiest way to achieve this is by post-processing the results from axe-core before writing your test assertions. Playwright's Accessibility Testing docs has a section suggesting one option for how to do that.

Longer-term, we do agree that this is a feature that would make sense to add to axe-core. We don't currently have engineering cycles to prioritize for it, but it's something we'd be happy to accept a contribution for.

We did discuss some different options for it; if someone did want to try a contribution for this, we're leaning towards something along these lines:

  • Using a similar "inline suppression" concept to what other dev tools use for one-off issue suppression (eg, // prettier-ignore or // eslint-disable-next-line rule-name)
  • ...by adding support for putting an inline suppression attribute on elements, something along the lines of <div data-axe-skip="color-contrast">.
  • We might want different syntax to represent "skip for just this element" vs "skip for this element and its descendants".
  • We don't think we'd want to completely remove those results from the final result object - we think it'd probably make more sense to instead list them out in a new skipped array on the result objects, which would be a sibling of the existing violations/incomplete/etc arrays.

We also considered adding properties to the axe.run Options or Context types to represent elements that should be skipped, but we think we'd prefer the inline option, at least to start with; we think it would be less complex to make that work consistently across all the languages and products that we maintain axe integrations for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants