Share
Technical Penguins Web Accessibility Guide: An image of a tall staircase covering at least two floors is visible in a public space. The backs of two people ascending the stairs are visible at left. No elevator or other automated technology is visible; instead, two thin tracks are laid over the right side of the staircase, about as far apart as the wheels on a wheelchair, making a very steep ramp.
Sure, that’s accessible? Image by Flickr user chriswaits

Why does Web accessibility matter?

This white paper has been unlocked and is available to all users

Executive Summary

Web accessibility should mean that all people can use the Web. Design decisions regularly cater to different audiences: Smartphone users, tablet users, users with spotty connections, and so on. But when it comes to the question of accessibility to those with disabilities, considerations are rarely made without an eye toward impact: How many blind people are really going to use our site? Why would anyone ever need to browse without (or only using) a keyboard?

These are the wrong questions. Instead of wondering how few people a given change is going to affect, it’s our moral (and legal) duty to do everything we can to make sure our content is available to whomever wants to consume it, however they want to do so. Here’s a look at how to get started with digital accessibility.

Special hello to WPCampus Online visitors! Thanks for attending our presentation of case studies on “accessible-izing” difficult content. In addition to the many resources in this white paper, you can see our slides from that presentation here. No, they’re not accessible, and yes, we realize the terrible irony.

Details

Web accessibility means that people with disabilities can use the Web.
~ W3C Introduction to Web Accessibility

When you navigate to Google.com on your phone, what you see on your screen is fundamentally different than what you see if you were to navigate to the same website using your desktop browser. Your phone fundamentally handles information differently than a standard computer, and forcing you to interact with a version of the site that is formatted for a different experience would make it frustrating, if not impossible, for you to use.

Maybe, like more than half of the people who will read this article, you wear glasses or contacts. Telling you that you could not wear them when accessing this website would make it frustrating, if not impossible, for you to use.

This is what we mean when we talk about “web accessibility,” but that’s maybe not the right term to use. What we want to talk about is “designing websites for humans.”

While we often frame accessibility in the context of disabilities, disability is not a binary: Everyone is somewhere on a scale of disability, and even though you think you’re definitely “not disabled,” that’s a) probably ignoring some things, and b) a factor that could change at any moment.

Defining disability

Disabilities are often thought of in “can’t do [x]” terms: Can’t move legs, can’t see, can’t hear, etc. A common rhetorical example at many sessions on disability is to ask who in the room has visual impairment — you’d be surprised at the number of hands that don’t go up, even among those wearing glasses.

We mentioned that example earlier. Glasses (or contacts) are an everyday accommodation that, since we’ve gotten so used to it, doesn’t even register as an accommodation any more. It seems almost as strange as pointing out that most people wear shoes when they go outside to protect their feet — it’s just the way things are.

But that doesn’t change the fact that glasses are an accommodation that, if most people had to do without (your Technical Penguins team included), we’d have a much harder time doing things. We probably wouldn’t (or shouldn’t, at any rate) be allowed to drive without them, and would not be able to do our jobs without sticking our faces right up next to the monitor.

When it comes to visual impairment, the difference between us and someone who’s legally blind is almost irrelevant in most contexts, except that we have an accommodation that allows us to get along.

Who are we to deny a legally blind person that same ability when it comes to the web?

Thinking about accommodations

When we think of disability accommodations, we often think in very binary, simplistic terms: A handicapped parking space is larger, and supposed to be placed close to a curb cut so a wheelchair can access the sidewalks.

A handicapped bathroom should have doors wide enough for a wheelchair, a larger stall with handrails, appliances and dispensers placed low enough to the ground to be used by someone in a wheelchair, and a mirror at either a certain height or slanted downward.

In other cases, Braille is featured on signs so that blind people can read them. Crosswalks have verbal as well as visual indicators showing when people can cross the street.

Those are legitimate accommodations that help lots of people. But while they may fill legal requirements/satisfy legal liability, the point is to make things accessible to everyone.

What are the accommodations that help someone with color-blindness navigate in the physical world – or the digital one? What about a person with neuroprocessing differences? What needs to change, physically as well as technologically, to make information as understandable to that person as to someone more neurotypical? What if someone using your website recently broke one arm and needs to navigate your site using only one hand and the keyboard, no mouse? Is that doable?

The cost of accessibility

You may make the argument, “Well, no blind/color-blind/deaf/neurodifferent/mobility-impaired people use my content.” That may be true – though it’s incredibly unlikely. Even if true, it’s definitely a chicken-and-egg thing, because if your content isn’t accessible to those people, they’re never going to START using it, either.

It absolutely costs money to make your website (and your physical location, if you have one) accessible. But being accessible is, more and more, not optional. It’s part of the cost of doing business. As we go into the requirements and methods of web accessibility, please know that we list them with the full knowledge that they constitute a ton of work. But we would encourage you to think of it as work rather than extra work, because these are the things we need to do in order to ensure that everyone can access our content.

Also, the whole “it’s sometimes against the law not to” thing. If you need to be convinced about the importance of web accessibility, that’s a good place to start.

Legal requirements

We can’t get into the case law here for every situation and every industry, but the tl;dr (too long; didn’t read) version is this: In a LOT of areas, the courts are beginning to hit businesses with big penalties for not using web accessibility practices on their websites.

The standard that these businesses are being held to is the international WCAG 2.0 AA standard, which can be found here.

Pro tip: There is NO WAY your current website meets this standard. Just an FYI.

So what do you do if you want to start moving in the direction of web accessibility?

Shameless plug

Accessibility is a huge topic, and it’s hard to know where to start. We offer assessments of your current areas of weakness, tips for future best practices, and support converting your content and your code into accessible formats.

Contact us for more information

Tips, Recommendations & Takeaways

For direct application, we’ll go with a very high-level overview. These are a few things to keep in mind when designing websites and inputting content that will get you a long way toward web accessibility.

1. Stay away from downloadable documents

Probably the biggest hindrance to accessibility is the ease with which content management systems accept PDFs, Word documents and even PowerPoint presentations. And look, I get it — you design a flyer once, you upload it to the web, and your content works in both places. And many people make their money this way, selling guides and printables and all manner of other downloads.

The problem with these types of documents are threefold:

  • Most of those documents are not screen-reader friendly to people with visual disabilities.
  • All of these documents are navigational dead-ends, in that once the document is open, it’s very difficult to get back to the page you were on without moderate to advanced skill (because, as the content creator, you have no control over whether it opens in a dedicated application, as a new tab in the browser window, replacing your current browser tab, etc.)
  • None of those documents work very well on devices that are not desktops or laptops.

The device-agnosticism might seem more suited to a mobile-friendliness discussion, but remember that people use all sorts of devices to access your content, for a variety of different reasons. Maybe they only use a tablet, maybe they only use a mobile phone (because in some places/communities, mobile phones are the cheapest and best way to access the internet). Regardless, you can’t assume that the desktop is the only way people are going to access your content, or that everyone has access to Microsoft Word/PowerPoint software licenses.

2. All content needs to be reducible to text

This sounds very onerous, and it is to an extent: If you have content, be it images, video, audio or whatever, it needs to have a textual equivalent. And note that “equivalent” does not equal “transcript” for any media other than audio, and sometimes not even that. While we know that screenplays of popular movies are available for purchasing, most people would acknowledge that reading the Titanic’s dialogue is not the same experience as watching Leonardo DiCaprio freeze to death in an icy ocean.

Old Rose: But now you know there was a man named Jack Dawson, and that he saved me in every way that a person can be saved. I don’t even have a picture of him. He exists now only in my memory.

Random Voice: Keldysh, Keldysh, Mir 2 on our way to the surface.

Captain: You know, I was saving this for when I found the diamond. I’m sorry. Three years, I’ve thought of nothing except Titanic, but I never got it. I never let it in.

Old Rose: (Small gasp)

With just the text as your guide, you almost certainly would have missed the part where Old Rose chucks a multi-million dollar diamond off the back of the boat, right?

For videos, you need to include a transcript along with descriptive text that sets the scene. It’s not enough to just have the words to the Reading Rainbow song, you need to describe the cheesy ’80s rainbow effects and children running through a park. There are services that provide transcriptions — that’s a good start, but you really need to make sure you’re including descriptive text as well.

Similarly, images need to have a lot more than a barebones description (“heart” or “dog” are common alternative text descriptions).

Do you see the photo at the top of this guide? Here’s the alt text we wrote for it:

Technical Penguins Web Accessibility Guide: An image of a tall staircase covering at least two floors is visible in a public space. The backs of two people ascending the stairs are visible at left. No elevator or other automated technology is visible; instead, two thin tracks are laid over the right side of the staircase, about as far apart as the wheels on a wheelchair, making a very steep ramp.

Is that a lot of words? You betcha. A decent bit of work for every image uploaded? Affirmative. But that’s the amount of work required to make sure that everyone who wants to see your content can, in fact, “see” your content.

3. Color matters, but color can’t be the only distinguishing characteristic

This section is going to seem slightly contradictory, but the two tenets aren’t opposed:

  • You cannot only use color to distinguish things.
  • Make sure that you distinguish between things of different types.

The first part is pretty self-explanatory: We need to make sure that people who cannot see the full spectrum of color can still navigate and use the website. Do you use colors to differentiate between sections or parts of your website? That’s fine, as long as you also use words. If the only difference between the “For Parents” and “For Students” sections of your website is that one uses the color blue and the other orange, that’s a problem.

You also need to keep in mind the minimum differentiation between text and the background. Many people like to use brightly colored backgrounds to make words “pop,” but there is in fact a minimum contrast ratio (4.5:1, except large text, which is 3:1) that you have to meet. This is yet another reason why you shouldn’t do document uploads — printed materials are rarely created using such restrictions, and most don’t bother to change color choices for the web.

As for making sure you distinguish between things of different types, think primarily in terms of links. Links need to be distinguishable from the text around them, and it’s helpful to differentiate between visited links and non-visited links. The old “blue for new, purple for visited” style for links has largely gone out of fashion, but there’s an accessibility case to be made for making the distinction. People who have difficulty with neuroprocessing may find themselves with a large list of links, click on a few, then have no idea which ones they’ve already looked at.

4. Thinking about humans

We heartily recommend reading the Alphabet of Accessibility Issues, which provides 26 different accommodation stories, and doesn’t even start to scratch the surface of all the possible use cases.

Beyond total inaccessibility, though, we must also think how to serve our users by making them comfortable, or at the very least avoiding actively causing them discomfort. This shows up in everything from the front-end user experience to back-end databases, and everything in between.

Forms that ask for information typically include a first and last name field, and both are often required. But not everyone has both a first and a last name.

In the United States, there are (at least) thousands of people named FNU, with the last name LNU, or whose visas read “No Name Given [Surname].” As the last example implies, these are not family names or common first names from a foreign country: They are acronyms (First Name Unknown and Last Name Unknown) that are given to people at various stages of the immigration process.

In some countries, passports are printed with two names as the “Given Name,” and no surname. In the U.S., when a visa is issued, if there is no surname in the passport, the “given name” becomes the surname, and the first name becomes First Name Unknown, or FNU. This may seem like a minor bureaucratic headache, but thanks to I-9 compliance (the forms you use to prove you can legally work in the United States) that has now become your official name. Your name on your ID badge and in the directory at work is “Fnu,” so your mail comes addressed to “Fnu,” and suddenly you have a new first name courtesy of United States Citizenship and Immigration Services.

Similarly, many less-than-well-programmed forms block certain characters in text fields. That’s fine… unless your last name is O’Toole, O’Malley, Davenport-Smith or any number of other totally common and legitimate names that you now cannot enter.

This gets beyond basic web accessibility and into user experience design, but we think it’s relevant to mention here. It’s not enough to have good ideas. If people can’t do what they need to do on your website, you have a business problem.

Big Takeaway

Websites should be as easy as possible to use for as many as people as possible. Everything we do should work toward that goal.

If you’re not sure where to start, begin by trying to learn more about the WCAG 2.0 standards, and begin looking for places where users may be struggling with your website.

Above all, have empathy. Web accessibility isn’t “extra work,” it’s being a good businessperson – and a good human.

Get more great advice

Technical Penguins is a full-service digital shop. We offer content, development, design and other internet services. Have a project you’re thinking about pursuing, but need a little help? Get in touch!

Contact Us

If you’d like to read all of our white papers (including tips and recommendations), you can either join with a content membership plan or purchase a maintenance agreement, which includes access to all content! Maintenance agreements also include discounts on all services, as well as other perks.

An illustration of a penguin in glasses holding a book.

Content-Only Membership

  • Includes access to all our white papers, with members-only recommendations and tips.
  • Includes a regular email newsletter on topics such as security, updates and website best practices.

$15/month

Find Out More
An illustration of a penguin in a hard hat, holding a wrench and a screwdriver, with an open toolbox in front of him.

Standard WordPress Maintenance and Security Plan

  • We'll keep WordPress and your plugins up-to-date on a monthly basis.
  • We will ensure your site is being comprehensively backed up.
  • Includes access to all our white papers, with members-only recommendations and tips.
  • Includes a regular email newsletter on topics such as security, updates and website best practices.
  • 10% discount off regular hourly rates for scheduled work performed.

$40/month

Find Out More
An illustration of a penguin wearing a security guard uniform and hat, with sunglasses and an earpiece.

Premium WordPress Maintenance and Security Plan

  • We'll keep WordPress and your plugins up-to-date on a monthly basis.
  • We will ensure your site is being comprehensively backed up.
  • Additional automated scanning for security vulnerabilities, malware and more.
  • One hour of scheduled work per month included ($55 value).
  • Includes access to all our white papers, with members-only recommendations and tips.
  • Includes a regular email newsletter on topics such as security, updates and website best practices.
  • 15% discount off regular hourly rates for scheduled work performed.

$80/month

Find Out More