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

Decorative images should be ignored by the region rule #4145

Closed
professorplumb opened this issue Sep 1, 2023 · 5 comments · Fixed by #4412
Closed

Decorative images should be ignored by the region rule #4145

professorplumb opened this issue Sep 1, 2023 · 5 comments · Fixed by #4412
Assignees
Labels
fix Bug fixes rules Issue or false result from an axe-core rule support

Comments

@professorplumb
Copy link

Product

axe-core

Question

Like many website operators, we use "marketing pixels" to track page hits and conversions. These are usually img tags with a height and width of 1 and a src URL which points to a marketing partner's site and through which affiliate metrics are tracked.

These might look something like

<img src="https://marketing.partner.com/path/to/tracking/script/123456789/?identifier=gobbledygook&amp;random=1594174352357287200&amp;url=https://my-page.url/&amp;other-identifier=asdfjkl" height="1" width="1" alt="" />

Since they're often created by a third-party script, the script usually auto-appends them to the body tag. Because they're not inside a landmark region, they're called out by axe-core's region rule.

My question is: is there any way to get axe-core to ignore these pixels being outside a landmark region? The purpose of the rule - to have all consumable content inside landmark regions for screen reader navigation - doesn't apply, since these pixels aren't intended to be viewed by any users at all. (Most have alt="" to cause screen readers to ignore them.)

I could see a few ways to update axe-core to accommodate this:

  1. Exclude any images with height="1" width="1" (or with alt="", or both) from the region rule.
  2. Allow users to pass "ignorable" rule/element pairings to axe-core: the above could be ignored by something like ignoreIfMatches: [{ rule: 'region', elementRegex: '/img src.*height="1" width="1".*\/>/' }].

I'm aware that we can also fix these violations by appending the pixel to e.g. the end of the main element instead of the body. We don't always control the script which adds them, though, and we'd love to be able to ignore these in our accessibility audits.

@professorplumb professorplumb added question ungroomed Ticket needs a maintainer to prioritize and label labels Sep 1, 2023
@sorin-davidoi
Copy link
Contributor

Allow users to pass "ignorable" rule/element pairings to axe-core:

Doesn't the exclude context property work for your use-case? https://github.com/dequelabs/axe-core/blob/develop/doc/context.md#exclude-elements-from-test

@straker
Copy link
Contributor

straker commented Sep 6, 2023

@professorplumb Unfortunately there is no way to tell axe-core to ignore a specific violation, nor is there a good way for axe-core to detect the purpose of these tracking pixels from the markup alone to know to exclude them from the rule itself.

But as @sorin-davidoi has suggested, one way you can have axe-core not report the issue is to use the exclude property of the context object and that will ignore the element completely from the run.

@straker straker removed the ungroomed Ticket needs a maintainer to prioritize and label label Sep 6, 2023
@WilcoFiers
Copy link
Contributor

You shouldn't have to exclude these elements. Axe-core is in error in failing these under the region rule. I think the real issue here is that decorative images aren't ignored by the region rule.

@WilcoFiers WilcoFiers changed the title Is it possible to instruct axe-core to ignore a specific violation? Decorative images should be ignored by the region rule Sep 7, 2023
@WilcoFiers WilcoFiers added fix Bug fixes rules Issue or false result from an axe-core rule and removed question labels Sep 7, 2023
@professorplumb
Copy link
Author

Thanks @WilcoFiers - having the region rule ignore alt="" images (or perhaps, more generally, anything which is not part of the accessibility tree) outside of landmarks sounds like a good idea.

@straker @sorin-davidoi appreciate the reference to the exclude property. I'm aware of it, but AFAICT it can only exclude an element and its subtree from all rules, not a specific rule. The latter is what I was asking for, and it looks like axe doesn't currently support it. The fix @WilcoFiers is proposing will solve the problem which prompted this ticket though.

@dbjorge dbjorge added the support label Apr 4, 2024
@dbjorge
Copy link
Contributor

dbjorge commented Apr 4, 2024

We received a new +1 of this issue in a customer support ticket today

gaiety-deque added a commit that referenced this issue Apr 16, 2024
added isPresentationGraphic check which currently only handles alt='' and ignores them for the region rule
svg I believe is handled differently already
role='presentation' test added as well, use-case already handled

fix: #4145
gaiety-deque added a commit that referenced this issue Apr 16, 2024
my IDE was adding tabs ew, replaced with spaces

Refs: #4145
gaiety-deque added a commit that referenced this issue May 3, 2024
Issue was around [decorative
images](https://www.w3.org/WAI/tutorials/images/decorative/),
specifically 1 pixel wide/tall marketing tracking images, that get added
outside of regions failing the region rule. An easy and fairly robust
solution [the issue opener agreed
with](#4145 (comment))
was ignoring images with `alt=''` and so that's what this PR implements.

Dev notes:

- Added `isPresentationGraphic/1` check which currently only handles
`alt=''` and ignores them for the region rule
- role='presentation' test added as well, but this already worked
previously prior to this code change
- svg I believe is handled differently already, there's a test called
`treats svg elements as regions` so the new function doesn't check for
svg's

fix: #4145
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix Bug fixes rules Issue or false result from an axe-core rule support
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants