Thanks to an off-hand comment from Steve Green while discussing a forthcoming Accessites article, I’ve spent some time today thinking about what it takes to write for accessibility.

Most of the time, the primary focus of information about accessibility has to do with making non-text information available as text. Captioning and audio description for video, transcriptions for audio, simple text alternatives for static images. Next in the list tends to be availability of functionality: progressive enhancement for client-side scripting, ability to navigate the page via skip links or semantic HTML (HyperText Markup Language) headings, and so on.

But what about the content itself?

Disregarding issues concerning the use of abbreviations, typography, headings, and other semantic structures in HTML, the simple use of punctuation can be a significant barrier. This is a problem which applies to all text content for any user of a screen reader, in particular, although following these suggestions will benefit any reader of your content.

The issue isn’t precisely correctness. A sentence can be punctuated with perfect correctness but still lose clarity when spoken by a screen reader. It’s a matter of the lack of refinement in screen reader voice interpretation.

As a human speaker or writer, aware of the meaning and context of a sentence, it’s easy to speak a sentence and convey the meaning you expect in that sentence. A slight emphasis on one word or another is highly significant. However, in HTML, as in normal writing, there’s no means to indicate this kind of special emphasis which is readily understood by current screen reader technology. As important as strong and emphasis are semantically, they are not interpreted meaningfully by screen readers.

Punctuation is left as the sole means to refine and polish the meaning of a sentence for screen readers.

How do screen readers use punctuation?

Screen readers read most punctuation by default, such as parentheses, dashes, asterisks, and so on, but not all screen readers choose to read the same pieces of punctuation. Some do not read asterisks by default, for example. Periods, commas, and colons are usually not read out loud, but screen readers generally pause after each. Users can set their preferences so that screen readers read every punctuation mark and character. Web AIM, “Designing for Screen Reader Compatibility”

So common sentence punctuation marks, such as periods and commas, are indicated by pauses. However, special punctuation, including dashes and parentheses, are read as characters. This should immediately tell you how difficult it could be to understand a sentence containing numerous subclauses or parenthetical statements!

Only a few years ago, it was common to see pages that explained quote this page best viewed in Internet Explorer quote left paren or Netscape right paren. Web AIM, “Designing for Screen Reader Compatibility”, as rendered by Fangs

Although this is a relatively simple example, containing a single quoted passage and a single parenthetical statement, it could readily be very confusing to follow a more convoluted sentence structure, regardless of the correctness of the sentence.

So what’s the solution? Simply speaking, to write simply. Keep your sentences on the short side, avoid excessive parenthetical statements, and avoid excessive subclauses. Above all, try reading the sentence without giving any particular emphasis to the terms and see how easy it is to understand the statement. It’s easy to write an ambiguous sentence if you’ve assumed it will be pronounced in a particular manner.

Ultimately, the expectations when writing with a screen reader in mind aren’t that hugely different than without. After all, it’s not as if you intend to write confusing and ambiguous statements. However, the line drawn between “confusing” and “clear” is not necessarily in the same place for a computerized reader.