I’ll never forget the first time I used a screen reader. Years ago, I was working on a client project and knew “accessibility” was something they valued—this particular client was aiming for Web Content Accessibility Guidelines (WCAG) 2.0 level AA. The designers and developers were considering issues of contrast, typography, keyboard navigation, and reflecting the reading order in the code order (you can read more about accessible design in Sparkboxer Andrew’s recent Foundry post), but it was up to me as a budding UX and content strategist to make sure the site’s content was accessible.
I had no idea what “accessible web content” meant. So I did some research, activated VoiceOver on my iPhone, closed my eyes, and tried to navigate the site my team and I had worked so hard to create. Using a screen reader, as Sparkboxer Lindsay has documented in another post, can be disorienting for sighted users who are used to seeing, rather than hearing, the web. It certainly was for me. But for anyone in our industry, it is important to understand first-hand that how we build the web impacts who can use it.
Trying to make sense of that site through sound only, I realized that the way our team had written and structured some of the content, including headings, links, and alt text, was not in fact accessible. So we did a full audit and reworked the content to make sure it was usable by as many people as possible.
In the years since, I’ve taken the knowledge of that first disorienting screen reader experience and built upon it. Here, I’ll share some thoughts about creating accessible web content for your next project. These suggestions are certainly not comprehensive, but they’re a good start.
Write for Humans
Take a moment and consider how would you define good writing for the web. Is it clear? Succinct? Scannable? Action-oriented?
Now, think about how you’d define good writing for print. Is it clear? Succinct? Scannable? Action-oriented?
It turns out that good writing is good writing, no matter the medium. The same holds true for accessible web content. When thinking about creating accessible web content, step back and remember: You’re not creating accessible web content. You’re creating good content, and it is good because it is useful and interesting to people of all abilities on all devices.
Realize There Are a Range of Disabilities
According to a 2010 U.S. Census Bureau report, nearly 1 in 5 Americans has a disability—including those that impact vision, hearing, mobility, and cognition. Each of these disabilities can affect how a person interacts with the web.
A few examples: People who are deaf or hard-of-hearing need captions or text-based scripts for audio and video content. People with limited mobility may use a keyboard to tab through a web page, which means you should provide “skip navigation” links so they can jump directly to the content. And people with cognitive disabilities, such as Alzheimer’s disease, autism, or attention deficit hyperactivity disorder (ADHD), may become overwhelmed with content that is inconsistent, complex, or timed.
The way you write and organize your content can help everyone—including users with disabilities—have better, more meaningful experiences on the web.
Organize for Screen Readability
If you are sighted, scan over this page right now. Think about how your eyes take in everything, and how your brain processes the main points and overall shape and length of the content before you even start reading. Now, think about trying to get the same sense of this page without using your eyes.
Chunk Your Content
Imagine if this Foundry post were one long block of words, paragraph after paragraph with no headings or subheadings. Anyone would have trouble making sense of that post.
How would you fix that?
Start by organizing your content into well-defined groups or chunks, using descriptive, properly marked-up headings and lists. While visual styling like bolded text, font size, or color could communicate hierarchy to a sighted user, someone on a screen reader would miss those cues. Instead, use heading tags like <h1>, <h2>, and <h3>.
These make the document’s structure as obvious as possible to someone on a screen reader, as most screen readers have a feature that lists all the headings and describes their hierarchy—akin to scrolling up and down and skimming for highlights.
In addition to making the experience easier and more consistent for all users, proper markup also saves you time and effort in the long-term. At some point, you may want to redesign the site, and importing properly marked up content is significantly more straightforward than going through and restyling all body copy.
When thinking about chunking your content, you should also pay attention to heading wording. These headings should accurately describe what’s nested beneath for all users. For instance, “Organize for Screen Readability” is a lot more descriptive than simply “Organization” or “Screen Readers.”
Stick With the Inverted Pyramid
You’ll want to start each page and subsection with the most important information. As we say in journalism, “Don’t bury the lede.” Put your key points first, and you’ll keep your users happy.
For this piece, I wanted the biggest takeaway to be that writing accessible web content should not be some intimidating enigma. It is just writing good content for people of all abilities. So, that’s the first subsection.
Avoid All Caps and Leetspeak
Many folks who are blind or have low or tunnel vision can interact with the web only via a screen reader. Screen readers do exactly what it sounds like they do—they read what’s on the screen. That means that all caps and acronyms can be problematic, as some screen readers read all caps letter by letter, rather than as words.
Steer Clear of Unnecessary Capitalization
To improve readability, including for people on screen readers and those with dyslexia, limit the use of all caps as well as italics. If you intend to use an acronym or abbreviation in writing, make sure you spell out a full title or name on first reference to make sure all readers understand what it stands for.
For example, in the first paragraph of this post I made sure to specify that WCAG stands for Web Content Accessibility Guidelines; otherwise, some readers may have been left scratching their heads.
Don’t Use Numbers or Symbols in Place of Letters
Be careful, too, with “leet speak” that uses numbers or special characters in place of letters. For instance, “accessibility” is often abbreviated to “a11y.” There’s a reason that this post spells out accessibility rather than uses “ally,” though. Most visual readers will see “a11y” and ready it as “ally.” But the great irony is that a screen reader will read it as “a + 1 + 1 + y,” which is gibberish. There are accessible ways to use slang (Sparkbox developer Ethan suggests an <abbr>tag) but doing so requires some thought and care.
Make Links Make Sense
People on screen readers often navigate websites by tabbing from link to link, so make sure that hyperlinks are accessible.
Describe the Destination
When you create an in-text link, be sure the link text describes its purpose and destination, and would make sense out of context. For instance, rather than writing, “Click here” to link to a Foundry post about Accessible Rich Internet Applications (ARIA) labels and web accessibility, consider something like, “Read this post about ARIA labels and web accessibility.”
Also, there’s no need to use the word “link” in the link text or as alt text for a graphic that’s being used as a link. Most screen readers already say “link” before each link.
Indicate If a Link Opens In a New Tab or Tool
If a link opens a new tab or takes the user out of the current format or application, make sure the link indicates that, otherwise it can be disorienting to users—especially those with cognitive, sight, or mobility issues. For example, if the ARIA label post were to open in a new tab, you could write, “Read this post about ARIA labels (opens in a new tab).”
Use Alt Text for Visual Content
Alternative text attributes describe pictorial content in words and are helpful not just to people using assistive technologies but also to people who may have images turned off on their mobile devices to save data.
Before you add alt text, consider if an image is decorative or informational.
If the Image Is Informational
If the image is important to the context of the page, the alt text should contain a short description of the image, without including the phrases “image of” or “picture of”—assistive technologies already do this. Similarly, if the image is a link, the alt text should describe where the link goes rather than the image itself.
This post does not include any informational images, but if, for example, I were to include screenshots of how to activate VoiceOver on your iPhone, those screenshots would be informational and should include descriptive alt text.
If the Image Is Decorative
If the image is purely decorative, add an empty tag (alt=““) to instruct the screen reader to skip it. If you don’t use an empty tag, the screen reader will read the src attribute, which is often long and confusing.
The image at the top of this post is an example of a decorative image. It’s a lovely illustration but is not informative nor instrumental to your understanding of the content. Thus, we’ve used an empty tag so screen readers will skip it.
Provide Captions or Transcripts for Multimedia
To be fully accessible to the maximum number of users, a web video should include both synchronized captions and a descriptive transcript. For content that is audio-only, a transcript will usually do. If you’re interested in learning more, you can follow these best practice guidelines established by our friends at the Described and Captioned Media Program (DCMP).
Below, I’ve included audio in which I describe what DCMP is. And below that, I’ve included a transcript.
Transcript: The Described and Captioned Media Program, or DCMP, promotes and provides equal access to communication and learning for students who are blind, visually impaired, deaf, hard of hearing, or deaf-blind.
Adding transcripts like this are helpful not just to people who cannot hear; they also help people who may have their sound muted and those not fluent in the multimedia’s primary language.
Keep the Conversation Going
I hope that the suggestions I’ve offered in this post help you create accessible content for your next web project or assess and revise content that already exists. It’s helpful to remember that web accessibility has as much to do with content as it does code and design. If you have any questions or ideas to make web content more accessible, send an email. I’d love to keep this conversation going.
