6 Accessibility Myths

Mar 10, 2020

On the face of it, most people would agree that web accessibility is a good thing. But myths and misunderstandings exist.

1. Accessibility is Only for People Who are Blind: FALSE

Many discussions and resources for web accessibility focus on ways to make websites more accessible for people who are blind or have low vision: making them screen-reader-friendly, improving the contrast etc. While these are extremely important considerations, people with visual disabilities aren't the only group to consider when thinking about accessibility. Accessibility can be broken down into 4 key categories:

  1. People with Mobility/Motor/Dexterity Disabilities
  2. People who are Deaf or Hard of Hearing
  3. People with Cognitive Disabilities
  4. People with Visual Disabilities

According to last US census results, about 19% of the United States population identifies as having a disability. That works out to roughly 57 million individual people. If you consider a global audience, you are talking about 15% of the world's population according to the World Health Organization (WHO). That is over one billion people worldwide! Web Accessibility actually casts a very broad net. Sometimes, those of us who aren't currently dealing with a disability tend to create an "us" vs. "them" mindset. We think that we're in the "no disability" camp and that's where we're staying. But the truth is that everyone is going to grow older. And with advancing age can eventually come lessened abilities. We may have a great vision, hearing, mobile dexterity, and cognitive functions at 18, but in our 80's or 90's it may be a little different. Won't you want to still use websites then? So, accessibility really is for everyone.

The W3C Web Accessibility Initiative (WAI) has created a series of short videos that show the impact of web accessibility for people with disabilities, and the advantages for everyone in a variety of situations. You can watch the full series in about 10 minutes.

2. Accessibility is Optional: FALSE

Accessibility of a website is required by law. 2 laws specifically apply to accessibility in education:

  1. Section 504 of the Rehabilitation Act of 1973 states that "no qualified individual with a disability in the United States shall be excluded from, denied the benefits of, or be subjected to discrimination under" any program or activity that either receives Federal financial assistance...".
  2. The Americans with Disabilities Act (ADA) prohibits discrimination on the basis of disability. Title II of the ADA requires that state and local governments (including the University of Minnesota) give people with disabilities an equal opportunity to benefit from all of their programs, services, and activities.

The University of Minnesota Accessibility Policy states:

…All colleges, departments, central units and faculty are responsible for ensuring access to their Web content, Web applications, digital materials, environments and services…

3. Accessibility is Only About Following WCAG: FALSE

The Web Content Accessibility Guidelines, or WCAG 2.1, serves as the University of Minnesota Standard for accessibility. However, as stated in WCAG 2.1,

Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability.

Moreover, on its own, WCAG doesn't guarantee usability.

As the late Phil Kragnes said:

If you're just trying to meet the guidelines, you're not creating an accessible page. I can make a page that complies with WCAG that is not usable or accessible. Compliance does not equal accessibility. But if you make it accessible, it will be compliant (to WCAG)."

The Department of Justice has provided a definition of "Accessible":

A person with a disability is afforded the opportunity to acquire the same information, engage in the same interactions, and enjoy the same services as a person without a disability in an equally effective and equally integrated manner, with substantially equivalent ease of use. The person with a disability must be able to obtain the information as fully, equally and independently as a person without a disability. Although this might not result in identical ease of use compared to that of persons without disabilities, it still must ensure equal opportunity to the educational benefits and opportunities afforded by the technology and equal treatment in the use of such technology. - Source: Resolution Agreement South Carolina Technical College System (PDF)

4. If I Focus on Usability, I Don't Need to Worry About Accessibility: FALSE

Accessibility and usability are closely related and often confused, as they both improve satisfaction, effectiveness, and efficiency to the generic user population. But while accessibility is aimed at making a web site or application open to a much wider user population. Usability is aimed at making the target population of a product happier, more efficient, more effective.

International Standards Organization (ISO) provides more detailed information:

Usability (ISO 9241 standard)

ISO 9241 explains usability as the "extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use" Specifically this means designing systems or products that have 5 characteristics:

  1. Effective
  2. Efficient
  3. Engaging
  4. Error tolerant
  5. Easy to learn

Accessibility ISO/IEC 40500:2012/WCAG

ISO/IEC 40500:2012 covers the WCAG principles:

  1. Perceivable
  2. Operable
  3. Understandable
  4. Robust

As the Accessibility ISO states following these 4 principles:

will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photo-sensitivity and combinations of these.

Accessibility is basic and vital to people with disabilities. One way to think about it is accessibility being a prerequisite to usability. If a person encounters barriers in a web site or application they certainly cannot use it.

5. Automated Testing Tools Catch All Errors: FALSE

Passing automated accessibility testing such as the WAVE or UDoIT does not mean that a web site or application is accessible. The greatest danger with automated accessibility tools is the assumption that they can somehow replace human involvement in improving accessibility. Use auto tools, but remember they are only one part of the toolkit. Be aware of the Strengths and Limitations of Automated Tools.

To be effective, accessibility checkers should form part of a wider process. A comprehensive approach, including testing by people with different abilities and skills as well as evaluation by individuals knowledgeable in the field of accessible web design is best.

Using automated accessibility checking tools is a bit like spell-checking a document. The spell-checker can make best guesses of misspelled words based on patterns that it knows. However, it takes a human to make the final decision. The greatest danger with automated accessibility tools is the assumption that they can somehow replace human involvement in improving accessibility. Do use accessibility tools, but remember they are only one part of the toolkit. Sole reliance on them as sole indicators of accessibility compliance gives a false sense of security. In addition, it may inaccurately portray a site as being fully accessible to people with disabilities when in fact there may be problems. Evaluating website accessibility is an art not a science - it can't be reduced to running a site through an automated tool.

6. Accessibility Should be the Last Step: FALSE

Accessibility is not something you do at the end. You can't sprinkle magic accessibility dust and have it all be better at the end. You have to build it in. That means paying attention to details. You don't want to find out in the middle of a pandemic that your online class or site is not accessible.

For content authors, be sure to build in the Accessibility Core Skills.

Likewise, for developers, be sure accessibility is addressed from the beginning of every development project. Weave it into the fabric of a product from the setting of requirements through development and testing. For example, choose a JavaScript library that meets accessibility standards and ensure that color schemes have the necessary contrast to be viewed and understood by people with visual disabilities. You don't want to find out 2 weeks before your site goes live that your colors are not accessible.