Web accessibility: An editor’s guide

By Ambrose Li

Is web accessibility for people with disabilities the responsibility of just web designers, web developers, or accessibility consultants? Editors Toronto certainly disagrees, or it wouldn’t have organized a seminar on web accessibility standards last November. But what if you missed that seminar?

Web accessibility in a nutshell

Ontario’s web accessibility standard is based on Web Content Accessibility Guidelines (WCAG) 2.0. It consists of four principles divided into 12 guidelines that together form the basis of more than 60 success criteria and over 400 techniques; it deals with not only web pages but also other kinds of content posted online, including PDFs. Its official guide, at 262 letter-sized pages, is more than five times longer than the standard itself.

This sounds intimidating, but the four principles of accessibility (perceivable, operable, understandable, and robust) and 12 guidelines that underpin the WCAG standard are surprisingly simple. And, as an editor, only two of those guidelines should catch your attention: readable and navigable. Readability is clearly the job of all editors, and navigability—organizing the site so that readers can easily glean its structure and find their way around—is central to what substantive editors do. Even when acting within traditional editorial roles, we are already qualified to meaningfully contribute to a site’s accessibility.

In its essence, web accessibility is about equal opportunity; it’s about making web pages equally usable and understandable by everyone, regardless of their abilities. To achieve equal opportunity, web pages should not easily “break,” even when used with unknown or future devices. This is called robustness (the fourth principle), and you can think of it as both proactive and reactive: we look to the future by following the latest standards, but we also acknowledge present-day realities by marking up web pages in ways that are compatible with assistive technologies.

Semantic markup for future-proofing content

For web pages, the latest standard for markup is HTML5, and it should be used in a way that is both correct and semantic (see Chicago A.6–9 and A.14 for the terms markup, semantic, cascading style sheet, and tag). Generally speaking, instead of indenting, changing font size, bolding, or italicizing, we should talk only about paragraphs, headings, book titles, non-English words, or emphasis. (How text actually appears on the screen should be described in separate files called cascading style sheets, or CSS.)

Watch out for outdated advice in HTML seminars or tutorials; things have changed in HTML5. Some seminars, for example, still teach that HTML has a bold tag (“b”) and an italic tag (“i”); these tags no longer mean bold and italic. Some also still teach that heading tags must be used in order and that you can’t skip a level, but because of HTML5’s concept of sectioning, this is no longer technically correct.

Screen reader compatibility as a reality check

Unfortunately, the realities of today’s assistive technologies do not permit us to fully utilize HTML5. As a result, web accessibility is often measured against compatibility with assistive technologies, often specifically against a screen reader, an assistive technology for people who are blind.

Screen readers do not actually read your screen: they examine the marked-up copy on a web page and then read it back to you, usually through speech synthesis. Because you can’t scan speech the way you scan a page on a screen, many screen readers treat headings and links as bookmarks or even as tables of contents.

Tips for making online content more accessible

Now that you have an idea of what web accessibility is about and how robustness affects how we approach it in practice, let us revisit some tips you might have heard of and dissect and critique them a bit. If you have an online subscription to or a physical copy of the third edition of Editing Canadian English (ECE), or a copy of Editorial Niches (the print edition of chapter 13 of ECE), keep it handy.

Always specify alternative text

Alternative text is the poster child of web accessibility. We must tell screen readers what words to say—or whether to say any words at all—when they encounter a picture. Alternative text carries out this function by providing words that would have made sense in a given context if the image were replaced with words. Context, naturally, matters a lot:

1. Images that serve as links should have alternative text appropriate for them because links are bookmarks and might appear in a table of contents. For example, either Editors Canada or Editors Canada Home might, depending on the context, be appropriate for an Editors Canada logo that is also used as a link to the home page.
2. Decorative photos and other purely aesthetic images get null alternative text because no words would be suitable in place of them. For example, an Editors Canada logo used as an end marker might be considered decorative. Null alternative text means you specify alternative text but leave it completely blank; this is not the same as not specifying alternative text, which would cause screen readers to read out the image’s file name.
3. Images containing words that contribute to the meaning of the text should include those words in its alternative text; otherwise, what’s read out loud by the screen reader won’t make sense to readers who can’t see the image. For example, the alternative text for an image containing a paragraph of text should ideally be made into an actual paragraph, unless it’s impractical or pointless to do so.
4. In cases where alternative text should describe the image, approach with caution. Many people assume this means explaining what they see in the image, but this is seldom helpful. For example, the alternative text for a graph should ideally describe what the graph is depicting; descriptions like “A graph” neither make sense nor are considered equal opportunity.

Note: Since alternative texts are also important for search engine optimization, it is surprising they are not mentioned in ECE, section 13.1.6.

Always use correct heading tags

Be sure you use proper heading tags for titles; this is required by HTML standards old and new, and, as mentioned above, headings might appear in a table of contents.

HTML provides six heading levels, from h1 through h6. The usual advice you will hear is that h1 should be used for the page title, h2 for “A” heads, h3 for “B” heads, and so on, and you should never skip a level. While this is correct, HTML5 allows for other possibilities (that is, through HTML5 sectioning elements). However, because screen reader technology does not currently support sectioning the HTML5 way, it’s best to stick to the old method.

The visual aspect of headings is, of course, still important, but this belongs to the CSS and not to HTML markup.

Use words instead of web addresses

Some accessibility “tips” masquerade as “rules” for editing online content. For example, ECE, section 13.1.4.2(c), says to “never use a URL as link text.” I wouldn’t say “never,” but remember that screen readers are text-to-speech systems, so most URLs would be confusing to hear spoken out loud by a computer. Out of respect for people who use screen readers, avoid using actual web address as link text unless the context demands it: use words instead, as this blog post does.

Always insert spaces around dashes

Another of these “tips” that masquerade as “rules” is ECE, section 13.1.3.2.1(b): “always place a space on either side of an em dash.” Many, if not all, screen readers can’t distinguish hyphens from dashes, treating all spaced hyphens or dashes as dashes and un-spaced hyphens or dashes as hyphens. They might also not interpret thin or zero-width spaces correctly, so it’s safer to use regular spaces. Therefore, always place a space on either side of an em dash. However, you can still preserve the traditional typeset look and maintain web accessibility by asking the web developer to use the CSS to style these spaces out.

Further reading

Anyone who wants to learn more about WCAG’s four principles and 12 guidelines should read Olga Revilla’s WCAG 2.0 tutorial: Web accessibility made easy. Revilla provides explanations that are easier to understand than the official guide for WCAG.

Discussion

So, has your editorial work ever involved web accessibility? What specific problems have you run into? Leave a comment below to keep the conversation on web accessibility going.

Ambrose Li is currently a research assistant with the Perceptual Artifacts Lab at OCAD University.

This article was copy edited by Ana Trask.