Grow Blog« back
Q&A with David Berman: Web Accessibility and Inclusive Design, Part II
Let’s pick up where we left off. Below is the continuation of my Q&A with web accessibility guru, David Berman. (Click here… oops, if we’re following accessibility rules, I should say “follow this link” if you missed Part I of the post). It was a great privilege to have such an insightful and candid conversation with David. He is an asset to the industry and I am excited to share his knowledge with you.
YP: We're not only dealing with desktops and laptops anymore but also tablets, smartphones, and even wearable technology. How does a creative team tackle accessibility with all of those various devices and with such diversity of content? (Many jokes ensued at this point about Flash’s demise. I’ll spare the details.)
David Berman: This is going to get nerdy but there’s an answer to it. It's a real challenge to create standards in an industry where technology changes so rapidly. In fact, one could argue there's nothing that changes faster on the planet than technology. Establishing formal minimum standards is tricky and it's hard to keep up, so the language of the standards unavoidably lags. But the standards were drafted with this in mind. The World Wide Web Consortium (W3C) issued a guidance document in 2013 – which has a very unfriendly name – called WCAG2ICT (WCAG 2.0 to Non-Web Information and Communications Technologies). This document addresses how to apply each WCAG success criterion to non-web documents and software. Other documents unpack how to get it done on mobile browsers and apps. Some of the criteria don’t translate so well to various devices, while some of them fit perfectly. For example, alternative text for images can be achieved on every platform and container, though the recipes may differ in each case.
Other criteria require a bit of reinterpretation. For example, there's a criterion called “Language of Page” which requires a declaration of the natural language within the metadata of an HTML page. This tells the browser which natural language the web page is expressed in: English, French, Spanish, Klingon, et cetera, as opposed to a computer language. In HTML, this looks like <html lang="en-US">, which is the declaration for the American dialect of English. So when we apply the “Language of Page” success criterion to a document, like a Microsoft Word document, PDF file, or a Google Doc, we only need it declared once for the entire document. And so it would be more fitting, and more flexible, for that criterion to be renamed “Language of Document” as Language of Page confuses people into thinking maybe they have to declare the language on every page of a PDF. Besides, a web page technically is a “document” (in fact, that’s why I’ve proposed the success criterion we renamed “Language of Document” for the WCAG. 2.1).
So, all to say that the current vocabulary is not always such a great fit, however the principles transfer over and the success criteria do as well. In the instance of color contrast, as we discussed previously, those rules transfer seamlessly across devices. You measure minimum color contrast for a Powerpoint presentation or an EPUB the same way you do for a web page.
For auditing sites on mobile devices, it’s important to specify what platforms are being audited because it’s impossible to audit every combination of device, operating system, and browser. Taking into account the number of legacy operating systems and browsers, it would be impossible to audit for all possible combinations. Plus mobile platforms aren't necessarily as robust or fault-tolerant as desktop platforms are. Chrome on Android just isn't as clever with filling in the gaps when a coder writes bad code as Chrome on the desktop, for example, which is why it’s so important to do rigorous testing.
To be really thorough, my firm will actually test responsive design on a drawer full of devices. Then we'll get into the nerdy details of how many versions of a browser or operating system to go back and make a plan based on the audience.
However, an organization could state something like, “For a fully accessible experience of this product please use the latest Chrome browser on Windows 10.” That's a compliant response. It’s not the best, but you're communicating that your site is validated on that specific platform. For some situations, that may be sufficient. However, it isn’t the most positive message to put out there, and may not be good enough for some organization’s corporate social responsibility or marketing goals.
For mobile, too, it’s important to take the touch experience into account when designing landing zones. Interactive objects need to be large enough to touch easily. Typical standards state that buttons must be a minimum 42 pixels high and wide. In addition to their size, touchable objects need to be sufficiently spaced so anyone, especially a person with shaky fingers, can avoid clicking in the wrong place. No one likes having to try to touch a button or a link so tiny that they can't tell if they’re on the right spot or they’re forced to zoom in just to make sure they press the correct button. Imagine how awkward that same situation is for someone with a shaky hand to accomplish. My philosophy is if we do it right, everyone benefits.
YP: What are the top common newbie mistakes you see the most regarding accessibility?
David Berman: This is a great question. One of the most basic mistakes people make is assuming that you can do automated testing only to determine if a site is accessible. It’s an inconvenient truth that you do need manual testing as well. People love the idea that they can run a site through automatic testing like the WAVE toolbar and be done. Everyone wants to believe that works because then you can say, “Great! Here is this report that shows zero errors. We're done. We're out of here.” In truth this doesn’t work.
Another classic error is trying to implement all the criteria for WCAG Level AAA. As we discussed, AAA level sites are often not realistic and it isn’t actually desirable for everyone to have an AAA level site. When needed, of course, specific elements of AAA should be used. Instead, people should strive for Level A or AA, and then perhaps augment that with specific Level AAA success criteria that are appropriate for their situation.
Often times people don’t realize that the WCAG levels are additive. For a site to comply with Level AA, it must comply with all of the Level A criteria plus all the Level AA criteria as well. Some people don’t realize that because it's not intuitive.
I notice that newbies also tend to think about only the extremes – like complete blindness, for instance. Many designers are thinking about the screen reader as being the only assistive technology to be concerned with. But in reality the number of blind people in society is under 1% (it ranges from about .5% and .9%) so it's a relatively small piece of the population. Visual impairments of various degrees, such as color deficiencies and macular degeneration however, are a larger percentage — somewhere between 2% and 4%. (To break that down even further, 10% of men and 1% of women have color deficiencies.) In total, people with visual impairments make up about 5% of the population, so it's not only about people who can't see at all.
Development teams often overlook the sighted person who can't use a mouse and is using the keyboard only. For instance with “Skips,” where users can “Skip” to main content or “Skip” the navigation, if a screen reader announces them yet the sighted keyboard-only user cannot see them, then the “Skips” are unusable for that person. It’s imperative to think about the use case for someone who can't see it all, but it’s equally important to consider the use case where someone can see yet can't use a pointing device. Everything on a site needs to work properly and easily via keyboard-only. And so you should put your mouse away and test the site you’re working on by navigating with the keyboard only. If it works that way, then you know that all the various switch devices will also work (because they will have a way of emulating every key combination on a keyboard).
Another common newbie mistake is assuming that automated captions are good enough. Even though YouTube generates decent captions and it’s magical and convenient, the automatic captioning today rarely comply with WCAG without manual input and enhancement. If you have a video of one speaker that is professionally recorded with no background noise, YouTube’s automated captioning will be pretty good. In reality, though, most situations aren't that clear. The equipment may not be so good, or there are many people talking, or the speaker is using vocabulary which is not easily parsed by an automated system… or not speaking English. There could also be meaningful non-speech that automatic captioning can’t parse — noises that are important for conveying the mood or that are important to the plot line. You typically see such text in brackets, like “sounds of keyboard typing”. For example, automatic captioning won’t know to inform you about the sound of a key being inserted into a door lock alerting you to the murderer’s arrival. Those are sounds to help you know what's going on. Otherwise you’re thinking, “I don't know why that person just jumped out of the window!” Therefore, automated captioning is almost never good enough… and always needs to be checked manually. It saves a lot of work to use YouTube for the first pass, but then you have to clean it up and add the descriptors when necessary.
YP: Earlier, we were talking about certifications for accessibility. Are there specific training and certifications for creative agencies who might be interested in becoming certified on accessibility?
David Berman: Yes. There are two places on the planet where graphic design is a certified profession. One of them is here in Ontario. Just like engineers, doctors, nurses, and lawyers, we have certified designers. The certification examination includes accessibility topics. And being certified in graphic design in Ontario now includes that you understand the minimum accessibility guidelines. This results in that learning about accessibility is built into the curriculum required in design programs in schools, universities, and colleges here. It is my dream that every country does this.
But there is a lot of pushback on having certified graphic designers. Some people feel like it’s too stifling. And some rock star designers say that great design can't be taught, but they aren’t the everyday designers. I would be wary to ask one of these rock stars to design an accessible transportation system for a major city. Maybe it's going to be awesome-looking, but people could still die in a crisis or people could be harmed in a fire because they didn’t know about color contrast or that braille on signage needs to be sixty inches from the ground. Maybe they would get it right, but it's not about being a rock star creative, it's about minimum standards, safety, and independence.
CPACC and WAS are two ways to certify someone as an accessibility professional. We have discussed WAS, which is an IAAP Web Accessibility Specialist. It is a credential representing a developer’s detailed technical knowledge about the WCAG guidelines and web accessibility. And the CPACC (IAAP Certified Professional in Accessibility Core Competencies) is more of a general knowledge. CPACC also goes broader, it’s not just web. It covers wayfinding and theatre seating, or lines of sight, for example.
YP: Are there courses or college programs that specialize in accessible design?
David Berman: Yes, there are some schools which specialize in inclusive design. The Ontario College of Art and Design University (OCAD U) in Toronto has arguably the strongest inclusive design program on the planet. So you can assume someone with a degree from the Inclusive Design Research Centre (IDRC) program at OCAD probably knows their stuff.
My firm offers courses on accessibility. We hold them online at least twice a year. We also have specific courses that we teach online or in person for individual organizations, so they are customized for that group.
Accessible design is really a 10,000 hours rule commitment — you just keep doing it and learning!
- - - - - - - -
Follow this link to get caught up with Part 1 of the Q&A with accessibility expert, David Berman.