axe extension in chrome causing disruptive behavior for syntax highlighting with eleventy-plugin-syntaxhighlight
See original GitHub issueHello dequelabs team!
This issue is in reference to Major issue with syntax-highlight plugin for multi-line code blocks within eleventy-plugin-syntaxhighlight.
I wanted to inform you that when I have the chrome extension axe - Web Accessibility Testing
enabled, it causes disruptive behavior to eleventy-plugin-syntaxhighlight for highlighting fenced code blocks with Prism.
It causes multi-line fenced code blocks to become single line and disregards the white-space: pre
style in the Prism stylesheet. It looks like its causing white-space: pre
to be white-space: nowrap
where everything is in a single line. (Not sure if this is the exact cause but thats what it looks like)
Expectation: Expect the accessibility testing extension not to cause disruptive behavior to the syntax highlighting that is handled by Prism.js within eleventy-plugin-syntaxhighlight
.
Actual: Having the axe - Web Accessibility Testing
extension enabled with access to “all sites” causes multi-line code blocks that are highlighted with eleventy-plugin-syntaxhighlight
to have their styling messed up causing everything to be in a single line ignoring the CSS that should create line breaks.
Screenshot of a multi-line code block that is forced to be single line when the accessibility extension is enabled with “site access: all sites”
Screenshot of axe extension site access details
Motivation: I want the behavior to be changed so I can continue to use the axe - Web Accessibility Testing extension alongside eleventy-plugin-syntaxhighlight
without having to configure any non-default behavior.
Currently as a workaround, @5t3ph pointed out that having the extension enabled with site access: on click
is one way to avoid the issue I’ve stated above.
axe-core version: 4.6.2
Browser and Assistive Technology versions
For Tooling issues:
- Node version: v11.0.0
- Platform: MacOS
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (2 by maintainers)
Top GitHub Comments
Closing this issue in favor of #2686. Please continue discussion there.
Same issue as in #2686