5 Accessibility Myths

During my preparation for the WAS exam I touched on the following myths about accessibility (Day 87: Guidelines, Laws, and Myths), but this time around I’ll go into greater detail from the Deque course I’m taking. You can also read Carie Fisher’s wonderfully written article (with great visuals!): 5 Digital Accessibility Myths Busted, which is also from Deque.

Accessibility only benefits a small minority

Misleading. As I stated in Benefits of Accessible Design, accessibility benefits more than just people with disabilities (note: they are a significant 20% of the population). Accessibility often makes sites and products more usable (see Usability and Accessibility), which is good for everyone. Other specific benefits for everyone:

  • improved mobile device experience
  • improved browsing experience for people who don’t use the latest and greatest browser, operating system, or computer
  • improved web indexing and search engine optimization (SEO) with increased findability
  • improved user experience for an aging population
  • consistent experience for people who acquire a temporary disability

Accessibility is a short-term project

Laughable! We would all love to have every aspect of our work be a short-term project. One-off and done, right? Accessibility is no exceptions. It’s an on-going design requirement that deserves just as much attention as security and performance each time a new roll-out happens. That means that accessibility needs to:

  • be part of the design process from start to finish (see Day 31: A11y throughout a Product’s Lifecycle, Waterfall vs. Agile)
  • be part of company culture (remember, an organization is only as strong as the weakest link in their chain)
  • have committed resources & jobs within an organization
  • involve actual people with disabilities, like adding people with disabilities to teams (nothing about us, without us)

Accessibility should be the last step

Oh myyy. I’ve spent the last couple years teaching co-workers how to remediate inaccessible documents and webpages. Please, please please… don’t save accessibility as the last step. Otherwise, you will have a lot of frustrated and angry people on your hands.

Accessibility may seem like it takes more time at the beginning, but really it’s the forethought that intimidates people. Users will thank you for that forethought, though. Bolting on accessibility at the end is what really costs you more time (and sometimes money) after you realize the late solution didn’t work (fit) and has to be fixed again (and again). Not to mention, accessibility often gets neglected more when it really does get hard during retrofitting, which then puts the organization at risk of facing a lawsuit.

Accessibility is hard & expensive

Speaking of hard (and expensive), let’s address that issue, which should be a non-issue. Accessibility isn’t free, but the cost of implementation is reasonable compared to the cost of its alternatives. Why?

  • Consistent maintenance is cost-effective (especially when including accessibility from the start).
  • Lawsuits are expensive.
  • Bad publicity and ruined reputation is costly.

Accessibility is ugly

Aesthetics versus accessibility seems like one of the most controversial points recently. I’ve definitely got some strong feelings about it, myself. In reality, inaccessible designs are a lack of creativity rather than a barrier due to accessibility. To further address this battle between design and accessibility, my experience is that people don’t fully understand what makes a site or app accessible when they argue for a “prettier” design. So much of accessibility is invisible to people who don’t use assistive technology or adaptive strategies as a way to use the internet. Text alternatives, semantic markup, keyboard operability, reading order, captions, audio description, label and input association, headers and captions for data tables, and defined page language are things that ask nothing at the expense of aesthetics. If all a designer cares about are rigid color palettes and hiding “ugly” functionality and content (e.g. skip to main content link, acronym expansion, or text & image balance), then the medium of the web may not be the best place to practice design. The web is for everyone.

Additional reading

Day 87: Guidelines, Laws, and Myths

My intention today was to complete the first Deque course within the WAS certification prep program. I did do that, but not without being led to more resources that I need to read through. I’ve done a little research into US laws, but I need to read them again, plus read other laws mentioned in what I reviewed today. Looks like tomorrow’s study session is laid out for me.

Thing I accomplished

Completed guidelines, laws, and myths sections of Deque’s Accessibility Fundamentals.

What I reviewed today

Guidelines

Principles, guidelines, and authoring practices help create an accessible interaction between user and website or application. These guidelines and practices ensure that a variety of disabilities are taken into consideration.

I covered these more in detail on my own, which I’ve journalled on this site, but Deque does a decent job of getting the learner started with the basic principles and guidelines, and points them to official specifications. I’ll admit, I need to go back and spend some serious review time to go over all these.

Laws

Web accessibility laws usually fit into one of the following categories:

  • civil rights: discrimination against disabilities (Americans with Disabilities Act)
  • procurement: purchasing accessible IT products (Section 508 of the Rehabilitation Act)
  • industry-specific: regulations for private industries (21st Century Communications and Video Accessibility Act, Air Carrier Access Act)

United States

Canada

Europe

Other Regions

The Web Accessibility Initiative (WAI) has a comprehensive list of international accessibility policies. Additionally, PowerMapper has a list of government accessibility standards.

Myths and Misconceptions about Accessibility

  1. It benefits only a small minority. Truth: It actually benefits everyone.
  2. It’s a short-term project. Truth: It’s on-going.
  3. It should be the last step. Truth: It needs to start at the beginning of the project and last throughout the project’s life cycle.
  4. It’s hard & expensive. Truth: Remediation is harder and more expensive than considering it throughout the life cycle.
  5. It’s ugly. Truth: Most accessibility features are not visible to everyone.

Best takeaway

“Inaccessible web sites are not just inconvenient for people with disabilities, they are blocking.”