Bonus Tips on Web Accessibility Testing with David Berman
International web accessibility expert David Berman presented 11½ Free Tools for Testing Website Accessibility as part of a free webinar with 3Play Media. He gave attendees the inside scoop on all the free resources you need to make your websites, documents, and software inclusive of people with disabilities.
Watch the recording of the webinar above or catch the highlights of David’s presentation here.
Read on for excerpts from the Q&A with David for bonus tips on accessible web design.
If you could use only one accessibility tool, which would it be?
- DAVID BERMAN: I love the WAVE toolbar. I’d probably take the WAVE toolbar as my one tool.
How does accessibility testing work within learning management systems like Blackboard?
- DAVID BERMAN: This is a big topic. In fact, we have a course on nothing but accessibility for distance learning.
Part of the challenge is that we don’t just have to worry about an accessible experience for the audience. We also have to make sure that presenters living with disabilities can present, and administrators who manage the LMS can access it, too.
We did a study of all of the major LMS systems, and we couldn’t find one of them that would be compliant with WCAG 2.0 level AA. The Canadian government, which is quite committed to accessibility, had us go deep with this. And we found the only way to create a completely accessible experience in an LMS was to cobble something together — there was no elegant solution. There wasn’t one platform that was fully accessible.
Is it possible to test for closed captioning on web videos?
- DAVID BERMAN: Yes, certainly. One of the simplest ways is just to identify whether a caption file is present. Check the server where the video is stored to see if there’s a caption file in the same folder as the video. If there’s none, we can be pretty sure there’s no captioning.
It’s possible that captioning is present in the form of open captions, which are burned into the video file. But closed captions are much more common, so simply checking for the presence of the captioning file usually tells us whether the captions are missing.
“[3Play] is the best captioning house in the continent.”
The Compliance Sheriff can be programmed to scan your whole site for those missing pairs and send you an email saying, “hey, there’s a video posted in sector 17 that has no SRT file.”
Now, even if the captions are there, though, it’s another matter to make sure the captions are all high quality, and that requires a human eye — or you smartly order all your captioning from 3Play Media. They’re probably the best captioning house in the continent. We used to do our own captioning, but we found we got better captioning for far less money if we just used 3Play’s process. So we know when we get captioning from 3Play, they’re always excellent.
Should a site pass 100% of the criteria? If not, what is an acceptable measure of success?
“Our ideal is to have perfect accessibility on every platform at every bandwidth with every operating system on every platform, every device, at all times. And we’ll never reach that. And no one expects you to reach that.”
- DAVID BERMAN: Well, there’s no software on the planet that’s bug free. And so our ideal is to have perfect accessibility on every platform at every bandwidth with every operating system on every platform, every device, at all times.
And we’ll never reach that.
And no one expects you to reach that.
And I don’t want you to be intimidated by that.
To declare a site compliant with WCAG 2.0, you should test a statistically relevant sample of pages. For a very small site, you’re going to test every page and test it thoroughly. But if you had a 3,000-page website, it’s not realistic to test every one.
You can identify different page types and test a percentage of random pages. If each of those selected pages passes the WCAG design criteria, then you can declare the site compliant.
I also want to mention that it’s perfectly OK to have accessible alternatives. So for instance, let’s say you had a PDF that isn’t accessible enough to comply, but the very same content is available in a completely accessible way on an HTML web page. You don’t have to make the content accessible every place it’s presented — though, of course, that would be nice.
It’s even reasonable in some cases to have a message that warns iOS users, “we’re sorry, but for a fully accessible experience of this content, please go to a desktop and view it there.” Not the best solution, but definitely a compliant solution.
Can accessibility tools test pages that are password-protected?
- DAVID BERMAN: Some of them can and some of them can’t. For instance, CynthiaSays can’t go beyond a login screen, but Total Validator Pro has a feature to input the credentials and get to gated content.
At which phases of a website development cycle would you do accessibility testing?
- DAVID BERMAN: The best practice is to be thinking about accessibility at every step in the process. Even when we’re wireframing, we’re already thinking about how we’re going to build in accessibility along the way.
Once you’re in the development process, you want to check accessibility at every step.
“The best practice is to be thinking about accessibility at every step in the process.”
Some things are editorial issues, like making sure the writers include alternative text for images. Even as they designate a photo in a Word document that’s eventually going to be web content, they should write that alternative text now. Then when this document goes to translation, the Spanish translation will include the Spanish translations of the alternative text.
We make sure that writers understand that written instructions shouldn’t assume a person can perceive color. We don’t want to catch that at the 11th hour and have to go back to fix it.
We also want to make sure graphic designers are aware of color contrast minimums for readability.
The worst thing to do is to wait till your product’s almost done and then test for accessibility — because you can’t come up with a more expensive, more painful, more time consuming, and ineffective way of developing a product than that.
What do you recommend for total novices, like a faculty member who has made their own WordPress site but otherwise doesn’t know HTML?
“The worst thing to do is to wait till your product’s almost done and then test for accessibility — because you can’t come up with a more expensive, more painful, more time consuming, and ineffective way of developing a product than that.”
- DAVID BERMAN: If we just say, “faculty member, here’s WordPress. Knock yourself out. Go crazy. Choose the prettiest theme you want,” we’re undoubtedly going to get a site that’s not accessible — especially if the faculty member knows squat about accessible programming.
Instead, I recommend giving that faculty member a CMS template.
Let’s say it’s a WordPress site. We create our theme, which is already vetted for accessible design. Then that faculty member gets a product that’s hard to break. We just have to give them guidance as they populate that theme, letting them know what to keep in mind to reduce the chance of breaking something. Then we can just do a spot check and we’re good.More: a11y, accessibility expert, accessibility testing, accessible design, Blackboard, closed captioning, closed captions, david berman, digital inclusion, disability discrimination law, ed tech, inclusive design, instructional design, LMS, Online Video, universal design, video accessibility, video captioning, WCAG, web accessibility, web design, webinar, whitepaper