Accessibility mistakes run rampant across the Internet: A scourge of usability errors and disregard for screen readers or the blind. Unclear legal constraints, lawsuits – oh my!

It is time to put an end to the widespread ignorance of web accessibility.

The dictionary definition of accessibility is simply, “the quality of being easy to use.” An “accessible” website can be used, its content consumed, in various ways: Not just in a “I have 20/20 vision, can appreciate the full color spectrum and am very good with a mouse” kind of way.

While the legal constraints for accessibility on websites have been hazy at best, proper accessibility on the web is, in fact, law.

In the summer of 2017, Winn-Dixie was sued by a shopper on their website. The plaintiff, a blind individual, reportedly “could not read the store’s online coupons using his screen reader,” rendering the coupons feature unusable. Winn-Dixie lost this suit – and they are not alone.

In the United States, a website that meets the WCAG (Web Content Accessibility Guidelines) “single-A” level compliance can be considered more accessible than average. But there are also more stringent “AA” and “AAA” levels of compliance, the latter of which is only needed in rare cases, like government websites.

Making your website accessible opens you to a wider user base and means you’ll be complying with the law. It’s also just kind of nice.

Sadly, learning what goes into accessibility is a bit messy. Accessibility guidelines are rarely described in layman’s terms, and unless you have sensory limitations yourself, it can be hard to understand the challenges others face.

Take the W3C’s “Accessibility Principles” page, for example. It’s a good write-up, but if the reader knows nothing about accessibility, they would have to dig for actionable website modifications to get excited about.

Rather than name every requirement that goes into WCAG compliance, let’s examine some of the most common accessibility pitfalls. We will describe what the issues are, with practical steps to resolve them.

We have also covered issues related to keyboard accessibility in a separate post.

Pitfall #1: Missing Labels on Form Inputs

Form inputs – contact forms, search boxes, selectors, you name it – are important interactive features of your website. Unfortunately, labels are an often overlooked part of forms.

Labels are simply text that accompany input fields to describe what should go into each field, whether it’s “Username,” “Password,” whatever.

Labels matter because they are the most screen reader-friendly way to identify an input.

An underlying theme of accessibility is that your website must cater to, or play friendly with, screen reading technologies. Specialized software like JAWS or NVDA read web content to impaired users. To do that, the software must be able to read all aspects of your site.

To “read” what an input is for, the screen reader seeks a label. Specifically: A single label tied to a single input.

Input placeholders are not suitable replacements for labels. Placeholders are bad for general usability because they disappear when text is entered in the field.

When adding labels, the key is this: The label’s “for” attribute must match with a single input’s “id” attribute. This means:

• Every label needs a “for”;
• Every input needs an “id”;
• Every ID must be unique. (That’s just proper HTML.)

What goes between the label tags is what the user, or screen reader, will read. The “for” and “id” must match exactly:

<label for="example-name">Name</label>
<input type="text" id="example-name">

Also be sure to include labels on radio buttons, select fields, and checkboxes, following the same rules.

If you don’t like how your labels look, you can have labels present and available for screen readers while hiding them from sight. Just be sure not to apply CSS rules display: none; or visibility: hidden; to labels since they render elements invisible to screen readers as well.

Instead, try something like this “visually-hidden” class. Applied to a label, it will hide it while keeping it accessible. This is a useful bit of code to keep handy as it can be added to anything:

.visually-hidden {
	border: none !important;
	clip: rect(0 0 0 0) !important;
	height: 1px !important;
	margin: -1px !important;
	overflow: hidden !important;
	padding: 0 !important;
	position: absolute !important;
	white-space: nowrap !important;
	width: 1px !important;
}

In summary: Every input should have an associated label.

Pitfall #2: Missing or Improperly Used Alt Tags

Alt tags are like the gateway drug to the world of web accessibility. Every developer has seen the “alt” attribute on an before. But often they are mis-used, if not missed entirely.

A simple alt tag on an image looks like this:

<img alt="Vista view over plains" src="/images/dakota_plains.jpg" />

Alt tags serve as an “alternate” means of communicating what an image represents.

Simple, right?

Well, no, not really. Let’s dive into the details with assistance from this excellent breakdown by WebAIM.

First, every img technically needs an “alt” tag, but there’s a catch. Having a “null” alt tag is acceptable in places where an image is purely decorative.

Does a visually impaired user need to know there’s a “blue-green textured background triangle shaped thing” here? No! A visually impaired individual might not even know what “green” is in the first place.

A “null” alt tag is simply blank quotes, like so:

<img alt="" src="/images/buddy.jpg" />

Now, writing alt tags is kind of an art in itself. Some guidelines:

1. Keep them short; 125 characters is a good cut-off.
2. Minimize redundancy with nearby content. The image’s context on the page matters.
3. Avoid phrases “image of…” or “graphic of…” in the alt tag.

Something you definitely should not do with images is convey text through them. Use text for text and images for images. Text is screen reader friendly; it can be copied and pasted; it doesn’t take much file size; and Google’s crawlers can read it. Text is good!

Master alt tags and you are on your way to accessibility mastery.

Pitfall #3: Poor Color Contrast

Ever try to read dark text on top of a dark background? It’s not easy to read. And for someone with a visual impairment, it could be impossible to read. Eye strains don’t keep people on your site, they compel them to leave.

You must choose colors that are readable on top of other colors. Contrast, contrast, contrast.

The color contrast between text and background color can be expressed as a ratio. The higher the number, the more contrast, and the better the readability. WCAG AA and AAA guidelines require different contrast ratios. While AA guidelines call for a 4.5-to-1 contrast ratio, AAA compliance requires a stringent, difficult-to-meet 7-to-1. For a grasp of what this means, play with a contrast ratio tool.

Google Chrome’s DevTools provide an excellent built-in tool for color contrast checking.

Open the DevTools (Ctrl + Shift + I), then look for the “Styles” tab. Click into a color on an element.

In the color picker, look for the contrast ratio. Remember, you are shooting for a 4.5:1 color contrast ratio, the AA accessibility bar. This isn’t always easy to meet, so tinker with the colors – either the text color or the background color – until it works.

“Readable website content is just better content,” grandma used to say.

Accessibility: It’s A Habit

Assumptions like “everyone has a computer mouse” or “everyone has decent enough vision” must be discarded. We should build websites that include everyone.

Once you understand what makes an accessible website and the mistakes that make websites less accessible, you’ll find yourself building websites with accessibility in mind from the get-go.

These tips are but a launching point, but by integrating them into your process, you are sure to produce friendlier websites for all kinds of visitors.

Let us build you a professionally-made, fully accessibility compliant website. Get in touch today.