say that LW is checking WCAG 2.1 A & AA but our dashboard only says 2.0:
I was looking for a way to set the level in config or somewhere, but reading that doc, I’m guessing that will not be an option? Thing is, SUNY schools are going to need 2.2 AA…
Also, I’m getting accessibility warnings that I used to not get that don’t make sense because they’re in widget nodes:
The <arg> element has the id "format" that is already in use
<arg id="format">
The <arg> element has the id "height" that is already in use
<arg id="height">
The <arg> element has the id "width" that is already in use
<arg id="width">
The <arg> element has the id "id" that is already in use
<arg id="id">
I’d expect there would be multiple nodes with the same id on a page with multiple widgets - can these be filtered out of the report?
For the <args>, I’ve noticed this too. It seems that the accessibility check sometimes runs on the editor or preprocessed copy of the page, rather than the output copy, producing these false-positives. I tend to confirm this by running the “Refresh report” on the page as the user sees it.
(Personal aside: it would be nice if the report could give a bit more details on the exact element for each item. I’ve seen the “background” and the “landmark” items in the above images somewhat consistently, but having just <p> to go on isn’t too helpful in finding the cause (easily). Perhaps if the report could list the parent elements/classes/ids, similar to a CSS rule, or similar, that could narrow things down more.)
Ah - that’s a good tip. I still wish they didn’t show at all though - since they are spurious they add no value and when you just look at the page details the number isn’t accurate. Refreshing sometimes takes time, and I’d rather just see ‘no problems’ and not have to open anything. I do see your point though, that once you do the refresh it stays that way, at least until the next auto-check, I’m guessing…
We’re going to be doing a lot of accessibility checking before the Title II deadline hits!
We use SiteImprove for our accessibility checking so I don’t pay much attention to what LiveWhale is reporting. But I will add that SiteImprove also occasionally reports issues that look like they are due to preprocessed widget/xphp content. How a third-party crawler would be seeing that content is beyond me, and we’ve never been able to pinpoint the cause. We just rerun the check in SiteImprove and the problem goes away, similar to what Nick suggested in LiveWhale.
Hey guys, thanks for raising these points — we’ve been discussing these a lot the last year, and reaching some of the same conclusions. Namely,
Most sites already are scanning with SiteImprove, WAVE, ARC Toolkit, or other accessibility tools outside of LW.
Fine-tuning the built-in scanner to return results that are useful (to editors? to developers?) is tricky, and has resulted in a lot of alarming false-positives for folks over the years
Also, behind-the-scenes, the scanner is a rather complicated process that involves spinning up a “ghost browser” so it can fully render the page before running its scans. When tech issues arise here, nothing is able to be scanned which isn’t that useful! Browser tools like WAVE are far more straightforward in this regard.
And finally—as I know you’re aware—automated checking can be a relatively small part of accessibility review, and there’s something that doesn’t always feel great about assigning a grade or score when the automated checker can’t test interactivity, keyboard and screen-reader usage, etc.
For all these reasons, I expect that in our next major release this spring we’ll be deprecating our built-in scanner and instead directing people to use some of the existing tools (SiteImprove, WAVE, ARC, etc.) for accessibility testing. Let me know if you folks have any thoughts about that, or if it’d be useful to get advice on simply hiding the existing results in the meantime. Thanks!
I did some of my own work on this today, deemphasizing it for the moment.
In the same file: /_ingredients/themes/global/styles/livewhale.scss.
// ---------------------------------------------------------
// Accessibility Tool: deemphasize, add note
// ---------------------------------------------------------
#lw_pages_accessibility {
// hide status
.accessibility_good,
.accessibility_partial,
.accessibility_poor {
display: none;
}
//add note
.lw_accessibility_summary_guidelines::before {
content: "If you have concerns about this page, please contact web staff.";
display: block;
margin-bottom: 1em;
padding: 1em;
background: #DDEEFF;
border: #003865 1px solid;
}
}
// show status when user is admin or when clicked
body.admin-user #lw_pages_accessibility,
#lw_pages_accessibility.open {
.accessibility_good,
.accessibility_partial,
.accessibility_poor {
display: inline-block;
}
}
Still, I’d be curious to know if there is a way to disable the functionality altogether, say in the case some external tool is used. I’m sure it has marginal performance impact, but that seems more ideal than simply hiding it, say in Jon’s case.
To your question: currently “hiding” would be purely cosmetic, what we’re talking about for 3.0 is a more thorough removal of that functionality. That being said, there shouldn’t be a big performance change either way: for awhile now we’ve offloaded the actual accessibility scanning to one of our license/API servers, so the ghost browser and calculations don’t actually happen on your production instance anyways.
