skip-link rule not able to find link when scanning a logged-in WordPress page
Product
axe-core
Product Version
4.10.0
Latest Version
- [X] I have tested the issue with the latest version of the product
Issue Description
Expectation
The skip-link rule should find a valid skip link on the page and check it.
Actual
The skip-link rule returns inapplicable as it is unable to determine the correct skip link on the page.
How to Reproduce
A default WordPress site scanned as a logged in user creates the scenario that causes this.
Additional context
When a user is logged in on a WordPress site generally markup for an Admin Bar is added to the page which produces links that are the first page links. I understand that this breaks expectation of where a skip link should appear in the page but I can't control the placement or markup of that admin bar.
I do have the admin bar excluded in the context however the skip link heuristics do not consider the excludes context when finding the first link on the page.
Thank you for reporting this @pattonwebz. I'm not sure there is anything we can do about this. In order to avoid failing things that aren't real issues (aka false positives), axe-core can only test things if its sure about what it's testing. An internal link that's not at the top of the page may be a skip link, or it may not be. We can't say for sure, and if we can't be sure we can't test it without false positives.
That's the tradeoff axe has to make to be as accurate as it is, it sometimes has to ignore things that could be issues, because we're not confident enough that it will be.
@WilcoFiers I understand that the default rules should be using certainty and avoiding false positives. However if the heuristics for this was updated to take into account the context.exclude[] values then for WordPress sites it could be made to be reliable by simply excluding the admin bar ID.
That's not really going to work. It would create a situation where if you excluded a part of the page axe would suddenly find more then if you didn't exclude it. That's going to be confusing.
What might work though is if we explicitly ignored the wordpress admin bar for this particular rule. We don't generally code site-specific exceptions into axe-core. That's kind of a losing battle, but we do have a couple for very common sites like YouTube. I don't know that we'd prioritize it, but if someone wanted to open a pull request to do this that should be fine.
Talked this over with the team. We believe that this is a real best practice issue. WordPress ideally should have a way to skip over its admin panel. There are good reasons to want to do that. I'm going to close this issue and encourage anyone who has this issue to raise it with WordPress.