-
Notifications
You must be signed in to change notification settings - Fork 83
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
[BUG]: Accessibility scanner flagging new violations that the in-browser scan does not find #2065
Comments
Slack comment from IBM Docs admin Kerry Landis:
We are hoping this flag can either be ignored by default in the WFM scans or downgraded from violation to "Needs review" |
slack discussion thread: https://ibm-studios.slack.com/archives/C036P1CTN/p1727885751674519 |
Here's where I see them in our dev (test) environment. They are not flagged in our production documentation because the issues only appeared yesterday https://wfm.dcs.ibm.com/product/SSCT62_dev/reports/accessibility/2c8b5966edf93792462d2433eee1d525 |
I'm seeing these on links that aren't generated parent topic ones. Eg both the following links result in the error: We also have a lot of generated parent topic links that aren't causing errors, so not sure what the pattern is. My in-browser IBM Equal Access accessibility checker (set to use the 7.3 rulest) also doesn't raise these errors, either on the bare html file or in IBM Docs. |
Slack comment from IBM Docs admin Kerry Landis:
@dmuelle commented
As Tom explained in the #accessibility-at-ibm thread,
So from the Checker perspective, the scanner is working as designed and there's nothing to fix in the Checker tooling or rules. The fix would need to be in the DCS WFM process and usage of the Checker. |
Today @tombrunet and I meet to discuss this issue. There is a lot confusion around this so I hope this clears it up.
WFM is not in the business of understanding what is and what is not an accessibility violation. That is not the point of our tool. @philljenkins - Thus, with what I stated above, your comment is never going to happen:
In other words, this is NOT apples to apples. ACheck is not scanning the same file from the WFM scan that shows up on the live website.
rwlp_jaxrs2.0_atom_wfm_scanned.html.zip
|
@nfernho That example triggers a needs review, not a violation, so, still not entirely clear what's firing a violation. That said, I see some things in that example that shouldn't be flagging. We can look to fix that, but, not sure if it'll fix the violation scenario since that's not showing on our end in that page. |
Triage: waiting for more information to investigate what exactly happened. Also, we need to fix the issue of the target size overlapping. |
Earlier, I said "My in-browser IBM Equal Access accessibility checker (set to use the 7.3 ruleset) also doesn't raise these errors, either on the bare html file or in IBM Docs." However, I've found that sometimes it does, and sometimes it doesn't. Eg here are 2 files that were both listed by the batch checker (results in WFM) as having the error (twice in the case of the second file): I downloaded both of these files from COS and ran the Chrome browser checker on them. The first topic didn't show the error, the second one showed only the 2nd instance of the error (compared to the WFM report). So compared to the batch checker, which I believe is running on these same files, 2 errors are not reported. This suggests that the two forms of the checker aren't producing the same results? The structure of the relevant html looks the same to me in both files. For the file that has 2 instances of the error, I can't see why the first instance is even a problem. There's nothing that's close to the link (it's the links at the bottom of the file that are causing the errors). In any case, what's the actual problem? The rule that's supposedly being violated is to ensure that "controls are easier to activate with a mouse or by touch" by not being too close together. But the only clickable thing here is a link. It might be close to an icon (it's not clear whether that's the trigger though) but it's not close to another control so why is this error being thrown at all? First file:
Second file:
|
Fundamentally, accessibility scanning files without CSS applied is incomplete and may not be a valid scan in all cases. Isn't there a way to apply the Doc's CSS before/during the WFM process so that the Checker scans a more complete and valid page of content that better reflects what the end user will receive? |
Project
accessibility-checker-engine
Browser
Chrome
Operating system
MacOS
Description
When I ran the DCS accessibility scan after the update to the IBM Accessibility Requirement v7.3 ruleset, I saw many violations flagged
target_spacing_sufficient
, all for files that have not been modified since the last scan. These are flagged as actual violations, not "needs review".The flags are attached to autogenerated "Parent topic:" links that are created as part of the IBM Docs build process. The parts of the HTML file that are being flagged are added by the doc build and are not present in the DITA source files.
But the in-browser IBM Accessibility checker for Chrome does not find these violations. They are only showing up in the batch scan.
Steps to reproduce
For example- this is one of the errors in the scan: Undersized target "a" does not have sufficient spacing of 12 CSS pixels from another target "a"
This is the page in IBM Docs: JAX-RS 2.0 integration with Atom. The flag is coming from the atuogenerated Parent topic: Deploying JAX-RS 2.0 applications to Liberty link at the bottom of the page. If you hover over the link, it pulls up the text you see in the error report.
All of the instances I've found are for similar "Parent topic" links.
Here is a link to a recent report with similar flags
https://wfm.dcs.ibm.com/product/SSAW57_liberty_test/reports/accessibility/53064bda8c82f705eb91c2ba8a48d723
Since these flags are not drawn by anything in our source files, I'm trying to determine whether the flags can be ignored, or theres a problem with the scanner, or a problem with the IBM docs framework.
The text was updated successfully, but these errors were encountered: