The Second Step Toward a More Inclusive Web: Build a Solid Foundation

This is part two in a series of posts exploring how we view, approach, and implement accessibility on the web.

At Bloom Works, we set our partners up for success by leveraging inherently accessible tools. For example, in our recent work with The State of Connecticut’s Office of Early Childhood (OEC), we built their site with Wordpress, a user-friendly content management system (CMS), and installed the “Benjamin” Wordpress theme, which was derived from the U.S. Web Design System (USWDS). The USWDS was designed to be an accessible set of tools by the people who know this stuff in and out. By starting with such a solid foundation, we ensured accessibility out of the box, and equipped our client with the right tools for continued success, even after our work together is done.

As digital service professionals (DSPs), our goal is not only to build (and test! and iterate upon!) the best solutions, but to teach our partners how to maintain these best practices. So we make it a point to equip future in-house content managers with the know-how to maintain an accessible site.

To achieve this, we’ve curated a set of 10 best practice accessibility basics that our partners can use in their day- to-day. And, since a best practice is to keep lists under 7 items when possible (yes, this is a callback from Pt.1!), we’ve split this up into two parts. But enough chit-chat — here are the first 5 items:

1. Use descriptive link text to set an expectation for users.

Most people don’t read the internet.

“AUDIBLE GASP! SHOCK!”

— you right now, maybe

We skim, we scan, we search, but very few people read online content word-for-word. Check out this study by Nielsen Norman Group detailing how users read the web for validation that your web reading style is, in fact, normal. Since most people scan copy, it’s important to write in a way that quickly and easily directs people to the information they’re looking for.

One way to help your reader is to provide clear link language. Instead of the common “click here” or “read more,” add in more context that tells them what the link will actually lead to. When writing the language for links, remember:

• Link language should set an expectation — think: “what will happen when I click on this link?” and answer it!
• It’s also an opportunity to describe the action you want a user to take when they land on the page — so use more active words like “read, listen, watch, learn” etc.
• Instead of “Click here,” try “Read more about [The Document This Link is Talking About]”

2. Use heading tags properly

Headings (H) provide hierarchy and order to content. For a sighted person, this can manifest in differences in font size and weight, but for someone using a screen reader, they provide important guideposts to navigate content. Each heading should be an H-tag to describe where it falls in the hierarchy, numbered from H1 (largest, main point of the page) to H6 (smallest possible content in need of a heading).

So while stylistically you may want to choose the H4 that’s more in line with what you want (instead of the H2 you should be using), by mixing up the order of headings you’re actually creating a very confusing environment for users who rely on screen readers.

(Screen readers present the web audibly. Check out this article about a sighted user using a screen reader for a day to see what it’s like, and consider trying it out for yourself sometime!)

Making sure your page is in the right order is easy! For instance, in WordPress, you can tag a header by simply clicking the dropdown menu in the graphic user interface and selecting the proper one. Here’s how your page should shake out in regards to headings:

• H1s are typically the title of the page, and are only used once. It’s your main point, and thus the largest and most prominent bit of content
• H2s can (and will likely) appear multiple times, and can be thought of as the main “sections” of your content. You’ll likely use a combo of these and H3s (think of these as subsections) the most
• H4 through H6 is available, but often times you can get by without if the content is well-written and uncomplicated
• H-tags must appear sequentially in order — an H4 can’t immediately follow an H2, for example
• There can be multiple instances of all tags (except H1s) on a page, as long as they are preceded by the tag immediately above them (so, H2 > H3 > H4 > H5, etc)

3. Use Alt Text for all relevant images

Close your eyes for a few seconds, then open ’em. What did you see? Nothing, right? Ok, now close your eyes again and use the internet. Tough, huh? This is how a portion of your users interact with your site.

We’ve already covered how a screen reader interprets content, but what about images? Imagine an image or series of images that detail a process users need to know — how would you get that information without sight? This is where alt text comes into play.

• Alt text is a written description of an image so a user can get a clear understanding of 1) what’s happening in it and 2) why it’s included on the page
• Every image that describes a process or provides information should have alt text
• Images that are purely decorative (e.g. it is not imperative to understand the content), don’t need alt text

4. Use plain language, and define terms and jargon in context

In the Web Content Accessibility Guidelines (WCAG), there’s a whole section about making your content readable. In general, it’s best to avoid obtuse or jargon-y language.

• Avoid jargon whenever possible, and when you can’t, define it in plain language
• If you need abbreviations, make sure to spell them out first, and then add the abbreviation in parenthesis.
• Avoid the use of idioms, as they may not translate cleanly to other languages
• If using particularly difficult or scientific words, provide a pronunciation [pruh-nuhn-see-ey-shuhn] along with it, or swap it out with a more accessible/plain language alternative

Shout out to all the plain language advocates out there! Your work is not going unnoticed!

5. Be generous with font size and usage

Along with the words themselves, the font choice and size is just as important. While there’s debate whether serif or sans serif fonts are more readable, whatever you choose, consider the following:

• There’s no hard rule for minimum size of body copy on the web, but it’s commonly agreed that font size for body copy needs to be at least 16pt.
• Avoid installing or calling multiple fonts and/or styles on your site, as this may lead to increased loading times and thus a slower, less accessible experience
• Two fonts should be more than enough, with a couple styles if needed
• Instead of installing italic and bold font styles, go with bold only, as it’s both easier to read and works just as well for emphasis
• Beware of copying and pasting content wholesale — sometimes Word or Google styling can migrate with your content, and fall outside your established styling
• And PLEASE DO NOT put text in image files — screen readers won’t be able to read it, and it runs the risk of becoming pixelated. If you do have an image with text on it, be sure to include it in the alt text.

So there you have it — the first half of our “we know you’re busy (and possibly didn’t even read this, per our point earlier) so we’ve kept it short” list of accessibility basics anyone can do. Once we post the second half, we’ll add a link here — so it’s quite possible you are reading a sentence RIGHT NOW that will soon cease to exist. Mind blown? Mind blown.