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

Feature request: If CSS display:none causes failure, pull it into code snip. #598

Open
DavidMacDonald opened this issue Nov 2, 2017 · 5 comments
Labels
feat New feature or enhancement help wanted We welcome PRs or discussions for issues marked as help wanted rules Issue or false result from an axe-core rule
Milestone

Comments

@DavidMacDonald
Copy link

The now closed issue #597 shows that this feature would save a lot of trouble.

@marcysutton
Copy link
Contributor

marcysutton commented Nov 2, 2017

To capture what we just discussed as a team: I like this idea, however it isn't straight-forward to do. The CSS can come from anywhere, and the accessible name calculation code is pretty complicated. Passing the CSS isn't as simple for other scenarios as it might be for this one. So we'd have to do a lot of API work or rewriting of code to make this possible. But I agree that it would have helped in this scenario.

@DavidMacDonald
Copy link
Author

DavidMacDonald commented Nov 3, 2017

Perhaps in the interim, add to the list of things to check at the bottom, a text message that CSS display:none may be hiding the label.

@WilcoFiers
Copy link
Contributor

@marcysutton I've been thinking about this one a bit. How about we do the same thing with the "fail" and "pass" messages that we did with the "incomplete": allow them to be objects with multiple messages. You can set one of them from the check. That doesn't just help us with consistency and with better messages, it also solves our message templating problem. Since by doing this we no longer need to put in conditional statements in the messages. Simple string replacements can put the variables in the right place, and that's all we need.

@WilcoFiers WilcoFiers added feat New feature or enhancement help wanted We welcome PRs or discussions for issues marked as help wanted rules Issue or false result from an axe-core rule labels Apr 17, 2018
@dylanb
Copy link
Contributor

dylanb commented Mar 12, 2021

@WilcoFiers close?

@WilcoFiers WilcoFiers added this to the Axe-core 4.5 milestone Jan 26, 2022
@WilcoFiers
Copy link
Contributor

I'm looking at this with fresh eyes. I think there is value in us recording for each node we return whether it's visible or not. We can do that on DqElement. We'd need to consider if we want to track how an element is hidden, there are different ways. I'm going to keep this open for now.

@WilcoFiers WilcoFiers modified the milestones: Axe-core 4.5, Axe-core 4.6 May 20, 2022
@WilcoFiers WilcoFiers modified the milestones: Axe-core 4.6, Axe-core 4.7 Nov 2, 2022
@WilcoFiers WilcoFiers modified the milestones: Axe-core 4.8, Axe-core 4.9 Jun 27, 2023
mrtnvh pushed a commit to mrtnvh/axe-core that referenced this issue Nov 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat New feature or enhancement help wanted We welcome PRs or discussions for issues marked as help wanted rules Issue or false result from an axe-core rule
Projects
None yet
Development

No branches or pull requests

4 participants