We cover how to create an audit checklist using the Audit Checklist Builder tool on EasyA11yGuide.com.
The checklist builder covers different types of checklists:
- Content – for people adding content to a page or blog post.
- Design – for people reviewing a static mockup of a website.
- Full – for people who want to review a full page of a website to the full WCAG criteria 2.0 to 2.2 level AA.
- Quick Audit – for people wanting to do a quick audit for serious issues a web page might have.
With the builder, you can also select to include best practices or just the WCAG criteria. And you can select your level, WCAG 2.0, WCAG 2.1, and WCAG 2.2.
Transcript
One of the most time consuming things about doing website testing is writing up the reports afterwards. So we have an exciting update to the audit checklist builder to make writing your reports easier.
The first update is we have added two new buttons to this page. We have copy formatted report for Google Docs. So that’s going to copy the content in a friendly way that you could paste it into Google Docs or others type document tools.
The second is we have copy HTML report which will grab all of the raw HTML. If you want to put this into a different type of tool, both are available now.
The report we have in square brackets a number of different things for you to fill in such as the company or product name, name and version description or other information that you would like to include. The date will be pre populated for you and what was tested will be pre populated for you. We’ve added an improved testing summary.
The testing summary is designed for your clients. So this just gives a short list of how many tests passed, how many partially passed, how many failed and how many were not relevant. And then it just itemizes out which tests were in each group. And we’ve included some simple icons to help clients.
Then we get down into the section of the report which is intended for people who are actually going to be doing the remediation. This is going to be intended for developers or people implementing it.
First we define the terms that are being used and then we get into the detailed testing notes. And so here it allows us to pre populate all the different information that happened during the testing.
And we can put all of our notes in here as we’re testing so that they get populated into our report, speeding up the report process a lot. So I’ll walk you through from the top.
Here is the checklist builder. At the top is the current instructions. Make sure to check them out whenever you forget. The first thing that we fill out is the checklist purpose. And so here I have used the quick audit, but I can also use development which is a full page that’s going to be all of the WCAG criteria.
I can do design which would be for a static mockup or wireframe that’s being reviewed. I can do content which is going to be for people who are doing copywriting or content addition. So this is a truncated list.
I can choose whether or not I want to include the best practices, yes or no. The best practices are going to include information that is not in WCAG and then I can check my WCAG level.
This allows 2.0, 2.1 or 2.2 level AA. The reality is you are almost always in every circumstance going to be testing to Level aa.
There is some information on how to fill out the checklist tool here and then we have a handy button called Pre fill conformance level column and what that does is it pre fills the conformance level column based on how often something shows up.
So the accessibility statement for example occurs pretty often that there’s an issue with it. So it’s going to populate in as partially supports.
When I actually review the page I will possibly change that to supports or some other answer. Generally when I leave it at supports I don’t need to fill in anything in the issue source and notes column. Let’s say for example the privacy policy was good, but there was an issue with the cookie policy.
Most likely I would mark this as a website add on as most cookie things are third party tools. And then I would write a short note about the cookies.
Then I would continue through each of the items and if the answer was something besides supports or not applicable, then I want to put information into the issue sorts and notes. Occasionally, even when I answer supports I may still add some notes in here and then I will generate a report.
When I generate the report I can either include the simplified explanation information or I can choose not to. Depends on who you’re generating the report for and whether you want this information included. So now I will generate my report and here we have it’s tested to WCAG 2.2 level AA as relevant to content copywriting or content addition.
Now I’m going to click Build checklist to actually build out this updated checklist. So here we have our different criteria and we have a button to pre fill conformance level column. I use this pretty often as a lot of times this will speed up the report writing process.
For example, we have audio only and video only pre recorded. If this page doesn’t have any audio or video then the answer is going to be not applicable and I can move on.
And the conformance has already been filled in. So several of these apply to media. Well, if I don’t have any media I can leave them as not applicable instructions on the page. Don’t rely only on sensory characteristics. That is you don’t tell people they must pick the square or they must pick the red button.
So I’ve listed partially supports because it happens sometimes. If there were no issues I will click supports if there were some issues, partially supports if there were a lot of issues, does not support and sometimes I will click not applicable for example, if there are no instructions on the page I would probably click not applicable the three flashes or below.
That very rarely happens, so I’ll leave that as not applicable. The Link Purpose in content Very often we find that people have used Learn more for multiple of their links on a page. This is not helpful.
If they’ve used it a lot, pretty much everywhere, then I’ll mark does not support. If they’ve only used it once or twice and used good link text the rest of the time I’ll use partially supports and if they used good link text all of the time I would mark supports.
The most common is going to be partially supports and most commonly the issue source comes from content and then I will put notes on specifically what happened.
So now I’ve populated in the content, I’ll continue through and fill out each of these as they happen. When I’m done I will decide whether or not I want to include the simplified explanation which is the third column in the report or not.
I check the box. If I wish to include it I leave it. If I don’t, I click Generate report. And so now we can come down and you’ll see that it’s been updated to say that it’s testing WCAG 2.2 level AA as relevant to Content Copywriting or Content Edition.
Here I will see the testing summary and it’ll tell me how many passed, how many partially passed, how many failed, and how many were not relevant.
Then we get into the detailed testing notes and I wrote out the information for the link purpose in context. And so here you can see that the notes were populated in as well as the issue source.
Now all I would have to do for the final report is I would just write in what they should do frequently. What’ll actually happen is once I copy this into my document is I would probably just grab this information, copy it and put it right here into what to do. And so that is the Audit Checklist Builder tool.
The Audit Checklist Builder tool saves me a lot of time when I am doing audits and getting the reports written. I found that it cuts my report writing time in half or sometimes even more.
The Audit Checklist Builder is available to everyone who has a subscription to either the Agency Accessibility System or the Agency Sales System. If you found this video useful, please give it a thumbs up and subscribe to the channel that really helps us out.