Alongside me on the screen is a spreadsheet, and the spreadsheet contains my WCAG 2.1 AA checklist. So just in and of itself, the spreadsheet provides value because it’s dynamic in that you can sort through the different columns and adjust the display in how you would like.

But I’ve added a few additional columns which are going to be extremely helpful as you work through the different guidelines. One column is the action column. This column tells you whether or not you’re likely going to need to take action for the given success criterion. One thing that many people don’t know is that for most of the success criteria, you probably don’t need to do anything because either they’re inapplicable to you, or your website doesn’t. For example, your website might not have live closed captioning, and if it doesn’t, then you just need to be aware of that when you do have a presentation where there are live presenters. But that likely is inapplicable to you, so you don’t need to take action on that.

There are some success criteria which you’re likely already meeting, you’re conformant with, and you just need to review to make sure that is the case. I’ve gone through each success criterion and told you what you likely need to take action on and you likely don’t. This is a way to not only sort through what you need to do, but also prioritize the actions and the next steps that you take.

There’s also a column for completed. This is a way that you can easily identify which success criterion you’ve already taken care of. There is also a column for role, so you can sort through this and know, okay, here are the different people that need to be responsible for these respective success criteria. It could be your content editor, it might be your designer, it might be your developer. This column gives you the ability to sort through and assign responsibility for each one, because the different success criteria, it’s not just one person that is going through everything. You are very likely going to have multiple people working on conformance. And when you do, you will want to know which people should be working on each success criterion.

This spreadsheet is available in my WCAG course. I think this spreadsheet alone is worth the price of the course. But then there’s also the course, which builds upon my checklist and guide, and it has video explanations in plain English, really for beginners, so that everyone can understand what each success criterion is asking for. Some of the success criteria have code examples to help guide you through and understand what each success criterion, really the implementation or the finding of issues to see where you might have an issue because your code isn’t technically correct.

This course is really what you need to have if you want to understand the web content accessibility guidelines. It’s beginner-friendly, in plain English, and there’s the spreadsheet checklist. I’ve incorporated what you need to understand and take action to become more conformance with whatever web asset you have, whether it’s a website or not. This spreadsheet is really going to help.

The post Inside the Course: WCAG 2.1 AA Checklist in Excel Spreadsheet Format With Sortable Columns appeared first on The ADA Book.

I received an email from someone asking about a freelance service, and the service promised to manually go through his website and fix accessibility issues and that each page would pass a WAVE and an Axe scan. In my reply, one of the things I wrote back is to keep in mind that you can get scan errors down to zero without truly remediating for accessibility, and he wrote back asking how that is possible.

Well, it’s possible because scans are only based on rulesets, so they’re very powerful but also very simple in that they’re only looking for certain things. Scans have these rules that are defined, and if you pass those rules, then no accessibility issues are returned, and if you don’t, then you will get errors and or alerts. Keep in mind that it’s only based on automation, so it’s only based on what can be caught through automation.

With a scan, it’s looking through your code, and it’s looking for any scenarios where, if this exists, then return an error, but you can code your website in a way so that no ruleset is triggered, and so no error is returned. I’ve got a blog post where someone showed all of the different ways that he could have completely different websites, and yet still get a 100% perfect score on Google Lighthouse. This is not to dismiss scans, but it’s simply to bring awareness to their limitations.

Scans are limited in more ways than one, but in this instance, they’re limited in the sense that they can only flag accessibility issues when their rulesets allow them to, and the number of rule sets that we can have are limited because many accessibility issues simply require manual work. They require someone to manually inspect and find whether or not an accessibility issue exists.

One example of this is with text embedded within an image. A scan is not going to know whether text is embedded within an image; a scan will only know if an image exists. So if I have a bunch of text within an image, let’s say it’s an infographic and there are 100 words embedded within this image, a scan is not going to know that, and a scan is not going to then ask if this meaning is conveyed in the alternative text description or in a longer description outside of the alternative text value.

There are several other examples where automation is just limited in what can be caught. The primary concern is going to be false negatives, where a scan clears you, but accessibility issues remain. And so that’s what I was getting at in my reply: there are ways that we can work around scans so that we aren’t triggering their rulesets, so we’re not breaking their rules, and so therefore errors are not returned. But it doesn’t mean that we’ve made our website accessible. It simply means that we’ve found what errors are being returned, and we’ve worked our way around those errors.

It’s important to know that we can have a perfect score and yet have a completely inaccessible website. I’ll link to this article in the description, which does a really good job of showing that it’s easy to work around these rulesets and still get a perfect score. Again, this doesn’t dismiss scans; they’re very helpful, but it’s just important to know their limitations. When you’re aware of their limitations, then you have better context for how to view them, use them, and understand the different services that are being offered.

The post Your Website Can Pass Accessibility Scans (Checkers) Despite Being Inaccessible appeared first on The ADA Book.

There is still confusion when it comes to website accessibility and what can be done through automation. So let’s start with all work must be performed manually, and that is the case when we are auditing a website, so finding accessibility issues and remediating a website, fixing accessibility issues.

And we can’t combine automation with manual work, so we can’t install an overlay widget and say that overlay widget fixes 70% of issues, and then we just need to fix the remaining 30%.

And similarly with the scan, we can’t run a scan and say that scan has caught 30% of accessibility issues, and then we just have to refine the remaining 70%, that’s not how this works.

So let’s start with scans, scans are very helpful, but they are limited. With a scan, you might be able to flag or partially flag 12-15 accessibility issues. It really depends on who you ask and what accessibility scan you’re using. But think of a scan as being able to flag or partially flag about 25% of accessibility issues under WCAG 2.1 conformance level AA.

So in 2.1 AA, there are 50 success criteria or requirements, and the scan is going to flag or partially flag about 12-15 of those, so that’s very helpful. It reduces incidence of error,
it speeds up the process. But we can’t solely rely upon that scan to find accessibility issues, and a big reason why is because scans can have false negatives.

So that means a scan will not return an error or alert when an accessibility issue exists. And the reason that is so is because scans are using rulesets, and that’s all that’s happening, is someone has programmed to look for x, and if x is there, then return y result, and that does not- there can be many times where an accessibility issue exists, but a scan’s rulesets will not catch that accessibility issue.

And so for that reason, we still have to look through everything manually. But we can use the scan to help with again reducing error and speeding up the process, but we can’t rely upon that scan, remember, I said flag or partially flag. What that means is it’s raising our attention- it’s bringing our attention to a potential accessibility issue.

But it doesn’t mean that the issue necessarily exists, so there could, in rare instances there, are false positives, but again, I’m more concerned with false negatives where a scan does potentially flag an accessibility issue, but it hasn’t done so in the case of our website.

So even though scans are really helpful, we still need to manually review the entire website. And now, when it comes to overlays, they don’t help at all there may be marginal benefit, because what’s happening with an overlay is there is a script that’s literally laying over the website, and so that script is rendering adjustments that are literally laying over the website.

So it’s not the script that’s a laying over the website, but the script is rendering adjustments that lay over the website, but the website itself, the code and the content has not been remediated, so it remains inaccessible.

And this is not to say that even the adjustment rendered has made the website accessible even when it’s activated. This is just to say that there are automatic adjustments that are being made and rendered on the website.

But they don’t make the website accessible, and in fact, overlays can actually introduce accessibility issues, and that has been the case time and again, or that has been shown through many demonstrations. So any marginal benefit to using an overlay is outweighed by the problems it introduces, and we have to keep in mind that it’s not making our website accessible.

It’s just making some adjustments that lay over our website. So keep in mind there may be a pop up blocker or an ad blocker that exists that blocks the overlay widget from even showing, or someone may not notice the overlay widget on the website, or someone may not want to use the overlay widget, or again, it doesn’t make your website accessible anyway.

And if you’re concerned with litigation, plaintiffs’ lawyers have repeatedly shown that they disregard overlay widgets and they don’t think the website is made accessible by them. So there are really nothing, you shouldn’t use them; you should avoid overlay widgets altogether.

But the point of this video is that automation can only take you so far, and the way to think of automation in terms of website accessibility is there are website accessibility scans, or they’re commonly referred to as checkers.

These scans, through automated rulesets, help you flag certain accessibility issues. But it’s important to remember that they are limited in the accessibility issues they flag, so there are many accessibility issues that remain unchecked by scans. But even the accessibility issues that are flagged by scans, we still need to manually review them because the scans are not conclusive.

And importantly, there may be a false negative or a scan has not detected an accessibility issue that remains on your website, so if you solely rely upon a scan, you could still have a perfect score on the scan returning zero errors, and accessibility issues can remain.

So when it comes to automation, just remember that everything must be- all work must be performed manually.

The post The Limits of Automation in Website Accessibility: How Scans Help and Overlay Widgets Fail appeared first on The ADA Book.