Accessibility Series: Defining “Accessibility”

In my last post, I made the general case for “why accessibility” — the reasons that accessibility is important, and why it deserves first-class consideration at every level of development and project management. In this post, I’d like to explore the “what” of accessibility — what do we mean when use the term “accessibility?” Who are our users? What are our targets?

Big Tent

If we start with a broad view, there’s really nothing about the term “accessibility” that necessarily implies that it relates to persons with one or more disabilities. From this broad perspective, we can define “accessibility” simply by its dictionary definition as making the content of our site as easily obtainable as possible to the widest audience possible. Laura Kalberg makes this case in Accessibility for Everyone. This approach has an understandable appeal: by defining “accessibility” generically, the concerns of making a web experience accessible to users with disabilities falls under the same heading as browser support and mobile device support. From a business or project management perspective, this would be an extremely useful model with which to conceptualize accessibility. For our purposes here — understanding accessibility from the perspective of front end web development — we are going to keep our scope relatively narrow and deal with defining accessibility in the context of serving a usable and useful web experience to users that have one or more disabilities that might impact how they use the web.

Defining Disability: Disabilities/Disorders That Can Affect How A Person Views The Web

Disabilities of Movement/Motor Impairments

There is a certain irony in the fact that I’ve used the Accessible Icon Project’s variant of the classic ISO Wheelchair Symbol as the logo for this series — there is nothing about being a wheelchair user that inherently or necessarily impacts a person’s ability to use a computer. I spend upwards of eight hours per day working on a computer and I can say with confidence that my legs account for exactly zero percent of that interaction.

That said, there are plenty of motor impairments that can impact a person’s ability to interact with a computer, tablet, or phone. This can range from chronic or intermittent tremors caused by conditions such as Parkinson’s Disease to paralysis caused by injury or disease or missing limbs. An individual suffering from tremors may have some difficulty using a mouse/touchpad or touch screen, or may even be restricted to the keyboard as their exclusive input device. Individuals with more severe forms of motor impairment might make use of other assistive technologies, such as modified or simplified input devices.

People with very limited mobility may employ a switch. In its simplest form a switch is an input device that essentially just “clicks” and nothing else. This is combined with software that sweeps the focus across a site; the user then waits until the focus is over their desired target and they “click” the switch to interact with the target. Switches can come in various forms, and are placed somewhere the user finds them convenient to use and has motion with which to interact with it; they can even be breath-controlled.

Visual Impairment

Visual impairment such as blindness is perhaps the thing that people most often think of when discussing web accessibility; navigating a website without the ability to see presents obvious challenges that are easy to understand. A user who cannot see the content they are trying to access is going to need some way to experience and navigate the site. Generally this means leveraging a screen reader and using a keyboard for navigation (although there are other assistive technologies available for visually impaired users, including refreshable braille displays).

However, it is worth noting that there are other visual impairments beyond full blindness that can impact the way an individual uses a website. For instance, there are several types of color blindness that limit the range of visible colors a person can perceive. A site that uses colors as the sole means of conveying some piece of information could present difficulty to a user with some form of color blindness.

In the above example, we see in the “Not Color Blind Safe” example a green circle indicating a valid state and a red circle indicating an error state. An individual with red-green color blindness would have trouble differentiating between the two circles. In the “Color Blind Safe” example, we see the green circle and red circle replaced with a green check mark and red X respectively; a person with red-green color blindness might not see them as different colors, but they would be able to use the shapes to differentiate the two.

Also, there are several other forms of visual impairment that might not entail full loss of vision that still qualify as a form of disability. Users with visual impairments of this nature might leverage a keyboard and/or screen reader just as a person with complete blindness might. Alternatively, they might leverage magnifiers, or they might zoom in on the page or resize the text (depending on the severity and nature of the impairment and individual preference).

Hearing Impairment

When discussing disabilities that impede a person’s ability to navigate the web, hearing impairment may not be a disability that most people consider. This isn’t terribly surprising — a person with deafness and no other impairments can still use a mouse, touchpad, or touch screen and see the content displaying on the page. However, one aspect of how a user with a hearing impairment might face difficulty is watching video. Streaming video accounts for over 50% of global internet downstream traffic. Obviously video is a bigger bandwidth hog than static text and images, but regardless it is clear that watching streaming video on the web is a major component of internet usage today. Meaningful, useful closed captioning for prerecorded video is a requirement for even level A compliance with the W3’s WCAG. Captions are required for US federal sites by Section 508 and may be required by the ADA.

Epilepsy

“Epilepsy” is a word that encompasses a number of neurological disorders that cause epileptic seizures. Of the roughly 39 million individuals who have epilepsy, about 6% (2.34 million) have reflex seizures which can be triggered by various external stimuli, most commonly “flashing lights; bold, regular patterns; or regular moving patterns.” This is a case in which failure to exercise mindful web design and development wouldn’t merely inconvenience a person, but could actually cause them grievous harm.

Balance Disorders

I must admit that, before I started doing research for this series, balance/vestibular disorders weren’t on my radar at all — I don’t think I realized that such a class of disability existed, and it certainly wasn’t something I was thinking about for my web development work.

Balance disorders are caused when one or more of the body systems responsible for achieving our sense of balance is disrupted. The symptoms can include dizziness, nausea and disorientation.

You might be asking “what does this have to do with websites?” As Val Head’s article Designing Safer Web Animation For Motion Sensitivity describes, there are a number of ways that motion on websites can trigger or exacerbate symptoms for users with balance disorders, including animations, repeating gifs, and parallax scrolling.

Cognitive Disorders

This is another category of disability that hadn’t crossed my mind before I read Accessibility for Everyone. The term “cognitive disorder” can describe various impairments of concentration, memory, problem solving, and problems with various forms of information processing (such as dyslexia and dyscalculia). Additionally, cognitive disorders can range pretty drastically in their severity. People with cognitive disorders may struggle when navigating sites with confusing layout, convoluted language, needless distractions, or poor screen reader support. Also, individuals with cognitive disorders may struggle to follow time-based media like video and audio where they are not able to consume the information at their own pace; this is one reason the WCAG 2.1 includes providing alternatives to time-based media as a level AAA success criterion.

Age

Although I don’t have any source for it, I can’t think of a single item on the above list of disabilities/disorders/impairments for which the likelihood of incidence doesn’t increase with age. As the average global lifespan increases, we might expect that the number of users with some form of impairment may steadily increase.

Defining Accessibility

Thus far, we’ve merely identified a group of people for whom special provisions need to be made to provide “access.” So, in this context, how do we define “accessibility?”

Wikipedia defines web accessibility as “…the inclusive practice of ensuring there are no barriers that prevent interaction with, or access to websites on the World Wide Web, by people with disabilities. When sites are correctly designed, developed and edited, generally all users have equal access to information and functionality.” This is a decent summary. However, as a working model for our discussion it doesn’t provide us with any guiding principles for how to proceed.

In Adam Silver’s Form Design Patterns, he discusses how to define or determine the principles by which we can judge our work “objectively good” when trying to make accessible web experiences. He settles on the Inclusive Design Principles from The Paciello Group. In his words:

Whatever we build, in the end, is about users. I don’t want to leave a single person behind if I can help it. The web is for everyone. I can’t think of a better set of principles than the inclusive design principles from the Paciello Group. These principles are about good design — and good design is inclusive.

(Incidentally, Adam Silver is a contributor to Medium).

The Inclusive Design Principles, along with their summary, are quoted below, verbatim from the site:

  • Provide comparable experience
    Ensure your interface provides a comparable experience for all so people can accomplish tasks in a way that suits their needs without undermining the quality of the content.
  • Consider Situation
    People use your interface in different situations. Make sure your interface delivers a valuable experience to people regardless of their circumstances.
  • Be Consistent
    Use familiar conventions and apply them consistently.
  • Give Control
    Ensure people are in control. People should be able to access and interact with content in their preferred way.
  • Offer Choice
    Consider providing different ways for people to complete tasks, especially those that are complex or non standard.
  • Prioritise Content
    Help users focus on core tasks, features, and information by prioritising them within the content and layout.
  • Add Value
    Consider the value of features and how they improve the experience for different users.

(It is worth visiting the site because each of these principles is given a more in-depth description.)

What I like about this set of principles is that it illustrates how people with disabilities should be able to interact with the web by defining how everyone should be able to interact with the web. These are principles that should be studied and adhered to by stakeholders, designers, and developers alike for their audience in its entirety, not simply for their users with disabilities or impairments. In this, we see a proof for the inverse axiom — that improvements for accessibility will tend to lead to improvements generally for your site.

I hope to use this understanding of web accessibility as a framework to help guide the subsequent entries in this series. In upcoming posts I hope to explore some more concrete techniques of putting these principles into practice in order to provide a fully accessible experience to all potential visitors to a site. Thanks for reading, and stay tuned.