Formatting for Accessibility
Six rules every content manager needs to know
Someday everything we create with those user-friendly blog, website, and email services will be accessible to readers using assistive technology. Someday posts like this one won’t be necessary because web accessibility guidelines will be built into every theme, template, and tool.
Until that day arrives, learn with me how to improve what we publish and send so that more people with disabilities have access. I’m as likely to learn to code as I am to solve the Rubik’s cube. If I can do it, you can do it.
Here are six formatting rules everyone should know:
One: Use Heading Levels and Use Them in Order
This is important for screen reader navigation and for skimming. It’s also helpful for all users and when headings incorporate appropriate keywords, they improve Search Engine Optimization (SEO) which makes your content findable on the web.
Best practice is to use one Heading Level 1 (H1) for the primary title of the page and then use Heading Level 2 (H2) under H1 and H3 beneath H2, etc. Choosing heading levels from the styles provided in your software toolbar will also keep your page visually consistent because the same font, weight, and size is applied to each H1 and H2 and so forth.
Heading levels are also important for those Constant Contact or MailChimp email service campaigns. If you send an email without document structure (or if your web page has no heading structure), there is no way to skim the content because everything on the page will have the same weight. This is very time consuming for someone using a screen reader whose only other recourse is to skim hyperlinks…
Two: Use Descriptive Hyperlink Text
I covered this in Link Accessibility No-Nos, but it is worth repeating here. Generally, we don’t think of link text as having anything to do with formatting. And you can tell most of the world doesn’t think of it that way (the New York Times appears to know nothing about link text best practices).
We can do better.
Users of screen readers skim links on a page to learn what is there (particularly in the face of no heading structure). So consider your links part of formatting. Never use “click here” and always use link text that describes what is provided. This practice is useful for all readers. Most of us skim links to one degree or another. I don’t want to read surrounding sentences to determine where each “click here” link will take me. Learn more about descriptive link text.
Three: Avoid All Caps for Emphasis
I just learned about this one. Words emphasized using all capital letters may be screen read as the letters of an acronym and are generally harder to read by persons with print disabilities. For this reason, caps should not be used for emphasis. Use bold instead but…
Four: Use Bold and Italics Sparingly
Screen readers will distinguish bold and italics if they are coded using the < strong > and < em > HTML tags, but not if they are coded using the < b > and < i > style tags (they appear the same visually either way). I’m relieved to see WordPress is using strong and emphasis tags (I check by toggling to the HTML view of my post). You don’t need to know how to code to check this. It is fun to learn little bits of code such as this to improve accessibility, however (I feel like I’m using a secret decoder ring). Read more about the accessibility of bold and italics.
The most important thing to remember is to not use bold or italics in place of heading levels (rule One). Each time I use them I ask myself if there’s a heading-level option that makes more sense.
Five: Use Lists Made with Styles Only
Formatting a list of items should be created using the style options provided by your software’s toolbar. Don’t override these with your own spacing or indents. When styles are used, lists are properly tagged and announce themselves to screen readers. List items are also automatically indented to visually set them apart from surrounding text.
Be mindful of using ordered lists when they are called for instead of bullets. Ordered lists suggest a progression or sequence using numbers or letters. If you type these in yourself a screen reader will not read them appropriately for lack of proper coding.
- This is an example of a properly ordered list using the WordPress toolbar option.
- WordPress, you’ll note, has indented each of these items. I did not choose this formatting. It will read properly for a screen reader.
a. This is the first item in an ordered list that does not use styles. A screen reader will not announce this as an item of an ordered list.
b. This is the second item. I typed the “b” by hand on the keyboard rather than letting WordPress create the list item, a total nightmare for screen readers.
Learn more about using lists correctly.
Six: Color Must Not be Used to Convey Meaning
I think this is pretty obvious, but it’s worth mentioning. Since not everyone perceives color, using color to convey meaning is counterproductive. For example, you would not want to differentiate poisonous plants in a list using a different font color (aloe, sorel, hemlock). Instead, label your poisonous plants with text and avoid putting anyone in the hospital! Or use color and a text label.
- wild parsnip
If you use color, one of the most common accessibility errors found on web pages and emails is poor color contrast. We touched on this in Link Accessibility No-Nos but it’s worth repeating here. The color of your text must stand out adequately from its background. This “contrast ratio” is measurable by entering the hex value for the colors you are using in the WebAIM color contrast checker. Learn more about color and contrast for accessibility.
Accessibility rules are dull, like grammar. Yet I have Grammarly running (slapping my wrist with a ruler) as I write this. It’s even a subscription I pay for. Someday we will all feel an equivalent pressure to be accurate with accessibility. After all, if I make a grammatical error, mostly I embarrass myself. When I make an accessibility error, I risk alienating my audience. Upwards of 25 million Americans are estimated to have a disability that affects computer access.
It helps, too, to have particular readers in mind whom I’d like to reach. In that spirit, here’s a dose of motivation from the Missouri AT Program: Missouri AT Users Make the Case for Web Accessibility.
Monthly Blog Digest
Search the blog
State AT Program Blogs
State AT Program Blogs
The AT3 Center, the Association of AT Act Programs (ATAP), and the Administration on Community Living (ACL) make no endorsement, representation, or warranty expressed or implied for any product, device, or information set forth in this blog. The AT3 Center, ATAP, and ACL have not examined, reviewed, or tested any product or device hereto referred.