Accessibility Recipes/Emphasis

From DPWiki
Jump to navigation Jump to search

What to do and how?

Search your document for inline presentational markup like

  • <i>
  • <b>
  • <sc> or <span class="smcap"> as generated by Guiguts
  • <g> or <span class="gesperrt">
  • <f> or whatever you've converted that to.

The idea is to work out the meaning of the markup, and replace these tags with ones that convey that meaning, styled to have the same appearance that you want.

List of inline tags and alternatives

Here are the tags you might want to change those presentational ones into. Don't worry if the browser's default rendering of them isn't what you want; we'll fix that with CSS later.

<em>
Emphasis (usually rendered in italics). For example

Instructions in the Project Comments override the rules in these Guidelines, so follow them.

<strong>
Strong emphasis (usually in bold).

Any notes or comments put in by a previous volunteer must be left in place.

<cite>
Citation (usually in italics). This can be an author's name or the name of a work.

A mathematician is a device for turning coffee into theorems.—Paul Erdös.

<dfn>
Definition (usually italics). You put this around the "defining instance" of a term not around the definition of it—it's common in books to see the first occurrence of an unusual word set in italics; this is the perfect HTML element for this.

A prime number is one with the property that whenever it divides a product, it must divide one of the factors.

Don't forget that if there's a neatly set out list of defined terms, you should probably be using a definition list instead.
<var>
Variable (usually italics). Useful for letters used in mathematics.

Let a denote the side opposite angle A.

<code>, <samp>, <kbd>, <del>
I haven't seen a use for these in our books. Add here if you have!
Headings
A bold, italic or other-font phrase at the start of a block of text might actually be a run-in heading. See the Headings page for discussion.
Language
It's common for books to use italics for words from other languages, e.g.

This is something that one must come to know a posteriori.

HTML has no element for this. See "meaningless markup" below, and also the page on Language.

Meaningless markup? You will come across instances of font changes that have none of the above meanings. They may be purely presentational—such as some italics used to prettify the title page—or they may have a meaning not covered by the above. You have two choices. One is to keep the presentational markup as it is: unfortunately some automated accessibility checkers will complain about <i> and <b>. The other is to move the presentation to the CSS using, say, spans, or by styling other elements if, say, all level-3 headings are italic: unfortunately doing this means the italics will be lost in a non-CSS browser.

Styling the tags

It is probably safe to assume that <em> will be rendered in italics and <strong> in bold, but you can ensure that in the CSS if you want. You can also over-ride the default, or add classes. Here are some examples:

em { font-style:italic; }
em.g { font-style:normal; letter-spacing:0.25em; }
strong.u { font-weight:normal; text-decoration:underline; }
cite { font-style:normal; font-variant:small-caps; }

What if there are other citations, defined terms, variables etc that aren't printed in a special font? If you're a real perfectionist, you could mark those too, with CSS to remove all styling, but you'd find it hard to catch them all.

Quick Fix

If the above sounds complicated, and if your book is simple fiction, you could just run a simple search and replace to turn <i> and </i> into <em> and </em>, and similarly <b> and </b> into <strong> and </strong>. It will result in some things, such as citations, being emphasised, but hopefully there aren't too many of those in simple books.

Why?

W3C:

  • WCAG 1, Checkpoint 3 Use markup and style sheets and do so properly. (Priority 2)
    • In the Techniques document Emphasis The proper HTML elements should be used to mark up emphasis: EM and STRONG. The B and I elements should not be used; they are used to create a visual presentation effect. The EM and STRONG elements were designed to indicate structural emphasis that may be rendered in a variety of ways (font style changes, speech inflection changes, etc.)
  • Draft WCAG 2, Success criterion 1.3.1 Information and relationships conveyed through presentation can be programmatically determined or are available in text (Level A)
    • Technique H49 Using semantic markup to mark emphasized or special text.
    • Failure Example F2 Failure of SC 1.3.1 due to using CSS to create variations in presentation of text that conveys information without also using the appropriate markup or text.
  • WCAG Samurai Errata for WCAG 1 (unofficial, controversial) explain Guideline 3.1:
    • Not only must you use valid HTML in your documents, you must use valid and semantic HTML. You must use the most appropriate elements and attributes for your content.... You may use presentational elements like b or i when marking up content that is presentational rather than structural.... This exemption applies to edge cases only, not to clear-cut items on a typical page. It is not a licence to ... use b or i indiscriminately.

Who benefits?

Screenreader users (blind or low-vision, dyslexic, or just like having a book read to them). This is because the screenreader can use an emphasised tone of voice for <em> and <strong> elements.

Non-CSS users (perhaps using handheld browsing devices?) will benefit whenever you avoid a <span> in favour of something semantic. For example using em.g as suggested above means that while the non-CSS browser will not show the gesperrt text spaced out, it will render it in italics instead, so it is still emphasised albeit in a different way.

Drawbacks

None whatsoever.

While some of these tags may be unfamiliar, they all are supported, even in the oldest and newest browsers. All have been in the spec ever since HTML 1! And all are included in the drafts of XHTML 2 and HTML 5.

Testing

  • Try the W3C's Semantic Data Extractor.
  • Run an automated accessibility checker such as Ocawa.
  • Search for <i> and <b>—feel smug if there are none, or only "meaningless" ones. Search for <span as well, to make sure that it isn't being used when a more semantic element would be better.

Further Reading