Why web accessibility is more art than science
Ensuring your website is accessible to all members of your target audience can add unique requirements that demand novel solutions from your development team.
The art of accessibility
No matter the audience or the industry, every web development project has to balance design with functionality, resources with requirements, and wants with needs. But there’s an art to achieving balance when implementing accessibility measures according to David MacDonald, president of CanAdapt . MacDonald’s Toronto-based accessibility consulting firm provides audits and training to organizations implementing the Web Content Accessibility Guidelines (WCAG).
WCAG 2.0 offers three levels of accessibility conformance and success criteria : A, AA, and, AAA. “Most laws in the private sector don’t require AA, they require A,” MacDonald says. “In 2021 they’ll require AA, and we’ll have a new WCAG by then.”
MacDonald, a veteran invited expert on the WCAG Working Group, has provided accessibility audits and training for dozens of Fortune 500 companies and government departments in Canada, the U.S., and Australia, and encourages the organizations he works with to strive for conformance with the AA level. “We’ve created a standard that’s hopefully going to help a lot of people if you conform to it,” he says. “But accessibility applies to different people in different ways.”
A prime example can be seen in colour contrast criteria. “At the AAA level, colour contrast has to be 7:1,” MacDonald says. “But people who are low vision really rely on differences in colour, so there’s a great example of a conflict. If you go to the AAA level, your low vision audience members aren’t going to like that you don’t have an array of colours.”
Meeting the highest level of success criteria is virtually impossible, says MacDonald. “If someone says ‘we create WCAG AAA conforming websites,’ run as fast as you can,” he says, adding that some of the criteria are “really great things to do” but they also cause conflicts.
Because accessibility requirements mean adapting colours, navigation, and other key elements of your website, MacDonald’s advice is to start thinking about accessibility early on, before the design elements have been set in stone. “Work with marketing,” he says. “I’m working with some organizations right now where we’re looking at the wireframes and we’re going over the designs, and they have a lot less attachment when they’re in design and they can change things. There’s nothing more important than building in accessibility when the cement is wet.”
Standards vs. law
Some jurisdictions have made web accessibility a requirement under the law, but the extent of the law, and to whom it applies, varies widely.
In most of Canada, only federal government websites are required to adhere to WCAG accessibility standards , except in Ontario , where public sector organizations, as well as non-profits and private companies with more than 50 employees, must conform with Level A now, and Level AA by 2021.
In the U.S., the law is less clear when it comes to accessible websites, and has resulted in numerous high-profile lawsuits .
WCAG standards, whether or not required by law, are not only available for anyone to implement, but also make good business sense, opening your website up to millions of potential customers who may not have been able to access it otherwise. “We create guidelines that we think are really important and current,” MacDonald says. “If legal frameworks decide they want to impose that on organizations, then they have every right to do that.”
The art of implementing web accessibility guidelines involves making decisions and judgment calls that will ultimately affect how your site is developed, how it is designed, and how your various web accessibility audiences will experience it.
Here, MacDonald weighs in on a few problem areas to be aware of:
“Trusting that a development framework library is accessible is the biggest problem I see. People think that just because they choose jQuery or Angular, or a library framework, that it’s accessible. And most of the time it’s not. People hear Drupal or WordPress are the most accessible, so they think everything they choose is accessible. But that’s not true because it’s a community and everyone is building widgets. You can’t assume when you use a framework that says ‘we have some accessible components’ that they’re accessible.”
“Misuse of WAI-ARIA is the second biggest problem on the web right now. People get online, they find a few ARIA things, and then they throw it all over everything. And they’re doing this at the framework level. For instance I looked at a WordPress carousel the other day that had so much WAI-ARIA on it that we had to remove all the WAI-ARIA in order to make it accessible. It was not only overkill but it was misused. And the problem with WAI-ARIA is it doesn’t make any changes to the UI, so the person who is visual doesn’t notice any problems, but as soon as you turn on a screen reader, it’s a disaster.”
Mobile menus and pops-up
“Mobile hamburger menus are 99 percent inaccessible, so I’m always correcting mobile. Usually they’re built-in frameworks and it’s deeply embedded and you have to get in there and mess with the code.”
“In general, anything that pops up or flies out [is likely not accessible]. If it looks cool, then it’s highly suspect that you’ll have to fix it. And we don’t want it to not look cool -- WCAG allows it to look cool -- sometimes it just takes a little extra work.”
Operating system, browser, and screen reader compatibility
“Choose a limited list [of OS, browsers, and screen readers to conform to]. In general, use as much of the native HTML as you can, because browsers and screen readers tend to work toward those first. If you have a choice between doing a button with spans and divs or doing it with a button element, use a button element. Generally when you see a lot of spans and divs that do a lot of cool things, you know you’re going to have a lot of work.”
There are many scenarios in which it can be challenging to make a site conform to certain WCAG Guidelines. But MacDonald stresses that accessibility isn't an all-or-nothing endeavour, and opting for what’s known as a conforming alternative is better than not trying for accessibility on any level.
“It’s kind of like if you have a restaurant,” MacDonald says. “A person in a wheelchair arrives at the front door, and there are two steps to get in. The server says ‘we have an accessible entrance. Just go to the back, in the alley, and go through the back door by the dumpster, and go through the kitchen, wave to the chef, and we’ll take you through to your nice romantic table for your anniversary dinner.’ A conforming alternative is kind of like that. It’s best to make your main site conform. If you have to rely on an alternative, ok then do so.”
MacDonald adds, “If you have an application, like a flash widget for example, and making it conform to WCAG is going to be crazy hard for a screen reader, just make a text alternative. It’s not a black and white sort of thing.”
Commentsblog comments powered by Disqus
Hi, we're Mugo Web - Nice to meet you!
We're a group of web experts who solve complex web problems.Learn more about us »
- Business solutions (40)
- Case study (19)
- eZ Publish add-ons (17)
- eZ Publish community (8)
- eZ Publish development tips (56)
- Productivity tools (5)
- Site performance (9)
- User experience (24)
- Web accessibility (10)
- Web solutions (34)
- Work at Mugo (6)
Yes - we can do that.
Many years of experience with complex websites allows us to offer total solutions.Learn more about what we can do »
We love our clients (and they love us too)
We've solved problems across North America and around the world.Learn more about what we've done »
We tweet too
Follow us on Twitter for the latest Mugo happenings