Category: screen readers

Poetry, punctuation, markup & screen readers

I’ve seen poetry markup discussed a couple of times lately, but it never seems to end in a definite conclusion. Most recently, it has been discussed on the Web Standards Group mailing list: Marking up poems.

For some, it is obvious that using a pre element around a poem is correct as it maintains spacing and shape. For others, the semantic richness of using more typical HTML elements, such as paragraphs, is the obvious choice.

Anyway, I’ve done some brief tests of poetry with screen readers to see how these two semantic constructs are handled.

Some options

Poems are typically broken up into blocks called stanzas, the paragraphs of poetry. So, in terms of typographic layout on the Web, paragraphs are probably what we’re dealing with here; specifically, paragraphs with single-line boundaries, the sort of layout we typically see browsers render by default.

I started out writing this thinking that paragraph and break elements were the answer, but layout and spacing are particularly important to poetry. Some poems have integral layout and deliberate spacing—lines with different amounts of indent, distinct overall shape—which should be maintained if possible. While we may be able to achieve the required results using CSS, would we be unnecessarily abstracting part of the content in doing so? In essence, a poem is pre-formatted text, so I can see why pre is a natural choice; even the W3C use a poem as an example of using pre.

Another option is to use a blockquote. While you may be quoting someone else’s work, what markup do you then use for your own poetry? There’s nothing wrong with using blockquote in this way, but it depends on the context of your writing.


First off, we don’t want to complicate things too much. There’s no grounds for developing poem-specific in HTML 5 and suchlike, and using overly-complicated HTML constructs to avoid the use of br elements is just plain silly in my opinion.

Paragraphs and line breaks make sense from a semantic point of view, but if we want to preserve spacing, do we really want to be mucking about with CSS to achieve specific effects? Does whitespace—beyond paragraph barriers, so indents and overall shape—really matter that much? Yes, I think it does.

By using pre elements for poems, we are able to preserve the author’s work more easily. However, with no paragraph elements available to us, we lose a bit of the semantic richness that HTML allows: Only a selection of inline elements are permitted inside a pre element, so you can’t validly put paragraph elements in there.

Still torn?

Let’s take off our semantic hats for a moment, depart from the debate a little and look at how screen readers handle things.

Picking a short section of a poem featuring lines with and without punctuation at their ends, I used the two markup methods discussed and ran recent versions of JAWS and Window-Eyes over them. I recorded the speech output, so you can hear the results for yourself if you really want to.

In summary, the speech output from the different markup methods sound pretty much the same. Judging by these brief tests, screen readers don’t seem to pay much attention to carriage returns, line feeds or HTML br elements when they speak. Lines of poems run together, but punctuation causes screen readers to pause or announce the mark, which is how it should behave in my opinion. I don’t know enough about the actual inner workings of screen readers to provide an authoritative answer for this, but how the stanzas of a poem are achieved through markup doesn’t seem to make any difference to how it is spoken by modern screen readers.

Being a standards-based kind of guy, when I started testing I did not expect screen readers to be able to navigate the contents of a pre in the same way it can a bunch of paragraphs. I had imagined long poems with little markup would be a bit of a hassle for screen reader users. I should know better.

Screen reader users can skip from one paragraph (or stanza) to the next (Control+Down Arrow in JAWS). I wasn’t sure this would be possible for content inside a pre. A quick test reminded me, as is the case with browsers, screen readers have had to deal with a lot of crap markup. Quite possibly with a helping hand from the browser, screen readers know what looks like a paragraph. So, within a pre element, a screen reader user can still navigate paragraphs, skip to the next line (Down Arrow in JAWS), etc.

What does it all mean, Jon?

It basically means that it doesn’t really matter which markup method you use for poetry when it comes to screen readers. There is something I’d like to address here though: Some people seem to think they need to put in special punctuation for screen readers; commas at the end of each line, for example.

Punctuation marks, being the signposts of the written word, guide us through bodies of text. When it comes to poetry, line breaks add extra guidance, but how they should be interpreted may be ambiguous. Should they incur a pause? I’m sure that people will read the same poem differently, perhaps putting a pause in where the author didn’t mean one to exist, thus altering the rhythm.

The thing is, the rhythm of a poem is at the artistic discretion of its author. You cannot go sticking commas into someone’s poem because you think there should be a pause at the end of a line, or at the end of every line. The line breaks in a poem aid the understanding of the poem; they often highlight rhyming in a poem and indicate rhythm. If we’re specifically concerned with how screen readers speak the lines of a poem, I don’t think we can realistically do any more than to let the author’s punctuation lead the way; and neither should we do any more than that.

So, with that out of the way, we’re just left with making a decision as to which method to use. This blog post is really just a long-winded way of saying that, fundamentally, I doubt it matters a great deal. If you want to preserve spacing and shape, it’s probably best to use pre, but otherwise, I don’t think there’s anything wrong with using p and br elements (and perhaps blockquote as well).

Character references: widening screen readers’ eyes

I ran some tests a couple of years ago that looked at how mathematical character references are handled by screen readers, specifically using default configuration in JAWS and Window-Eyes.

Jason Kiss of Accessible Culture has recently published a comprehensive set of results from his testing of how a variety of characters are dealt with by recent versions of JAWS and Window-Eyes: JAWS, Window-Eyes and Character References.


A web author may expect characters such as the minus sign – a proper − or − as opposed to a simple dash – would be read out in an appropriate way by a screen reader. However, the most prevalent screen reader, JAWS, does not announce the character and the next most popular screen reader, Window-Eyes, reads it as “dash”.

Using JAWS, the results seem to be consistent even when you change the verbosity level, the punctuation level or the synthesiser used. It’d be interesting to know if anyone has managed to get a screen reader to announce these characters using the more advanced settings.

Personally, I’d like to see (or hear!) screen readers announcing additional characters; it would add to the character palette we can draw from when writing content, which I would expect to be even more important as the Web embraces internationalisation and localisation.

In the meantime, Jason provides a convenient table of results comparing the speech output from JAWS and Window-Eyes.

Update: Having posted about Jason’s work on Accessify Forum, I thought I’d add that some characters that do get spoken are not announced as one might expect:

  • Both JAWS and Window-Eyes read a square root symbol (√) as the letter v and pi (π) as the letter p.
  • While Window-Eyes makes minor tweaks to its speech output to make it a bit more user-friendly, it doesn’t always do what I think it should. As mentioned above, it says “dash” for the proper minus sign character.
  • Window-Eyes announces quite a lot of characters as “question”. Presumably Window-Eyes hasn’t understood these characters so it is announcing the character as it would a question mark, which users may realise it means that Window-Eyes hasn’t understood. However, saying “question” is probably worse than simply not announcing anything at all.

Screen readers and abbreviations

I was pointed at some advice this week that was telling developers not to worry too much about using the abbr or acronym HTML elements. The reason given for the advice was lack of support for these elements from screen readers. There are certainly a few things to consider when using these abbreviation elements, but lack of support in screen readers is not a valid reason to forget about them. Besides the fact that their use is of benefit to more than just screen reader users, screen readers do actually support abbr and acronym.

The abbreviation elements have confused developers for some years now. I thought I’d try to clear things up a little with some information about how modern screen readers support and handle abbreviations.

What are the abbr and acronym elements?

The W3C quite simply tells us:

The ABBR and ACRONYM elements allow authors to clearly indicate
occurrences of abbreviations and acronyms. […] The title attribute of these elements may be used to provide the full or expanded form of the expression.

Differing opinions on the definition of an acronym sparks debate about how to use the elements correctly. Juicy Studio has an in-depth look at the confusion surrounding abbreviations that’s well worth a read if you want some background on that. Essentially, it’s debated whether an acronym is always spoken as a word (e.g. NATO) or may sometimes be spoken one letter at a time (e.g. FBI). If you ask the W3C, both examples I’ve just given are acronyms. Grammarians will often say that an acronym should be pronounceable as a word, demoting FBI from acronym status. This leads to confusion when trying to decide when to use acronym in markup. However, most people will agree that an acronym is a form of abbreviation.

A common approach to marking up abbreviations

One approach, which is often quoted as the best approach, boils down to practicalities of pronunciation and the technology involved rather that who wins the argument over grammatical considerations.

In theory, the acronym element could be used to distinguish between those abbreviations that are usually spoken as a word and those that should be spelled one letter at a time. In practice, this is not the case. I used this approach too until I began researching how abbreviations work in JAWS several months ago and changed my mind.

Abbreviations are supported in JAWS and Window-Eyes, which I’ll come back to in a moment. What JAWS does not appear to do is use the difference between abbr and acronym to inform how it speaks. I’m not sure about Window-Eyes having not tested it – yet!

Instead of differentiating between the elements, screen readers analyse words to determine whether or not they can be spoken as a word (using lexical analysis) – they don’t know whether or not it should be, so they guess. Screen readers may use the different elements to inform their analysis of words, but I haven’t found research to support that.

Aural style sheets could be used by a developer to specify the required pronunciation, but near-zero support for aural style sheets puts a damper on that one.

So, in fact, it actually doesn’t matter one way or another which element you use. Since, an acronym is a form of abbreviation and screen readers don’t seem to pay any attention to which element you use in your markup, I don’t use acronym at all any more.

It’s probably a topic for another time, but I currently use something along the lines of <abbr class="acronym"> where a plain abbr doesn’t quite scratch the itch. It allows me to classify an abbreviation, should I wish to do so, and provides a useful hook for applying aural CSS, should it ever enjoy a good level of support. XHTML 2.0 even drops acronym in favour of using abbr. Even though XHTML 2.0 is still a draft, hopefully it means I’m along the right track.

Accessibility myth: screen readers don’t support abbr and acronym

Interpretation of “support” for abbreviations depends on what you’re expecting the abbr and acronym elements to do for you.

If you’re expecting all words marked up as acronyms to be pronounced as a word and all others letter-by-letter, you’re out of luck. Screen readers will do their best to figure out what should and shouldn’t be read as a word. If the screen reader gets it wrong, a user can tell it to stop, go back over an offending word pronouncing it one letter at a time and then continue with the text. For common problem words, a user can set an entry in their screen reader’s custom dictionary that specifies a personal preference for how a particular abbreviation should be spoken.

But there’s more to it than pronunciation alone. The second half of our W3C quote gives us another use for the abbreviation elements.

The title attribute of these elements may be used to provide the full or expanded form of the expression.

A bit of Googling suggests that JAWS and Window-Eyes, two of the most common screen readers, have been able to speak expanded abbreviations marked up with abbr and acronym since 2003, when JAWS was in version 4.51 and Window-Eyes was in version 4.5. Older versions of these screen readers did not have this support for abbreviations.

In JAWS, the user can configure whether or not the software speaks the expansion provided by the title attribute in place of the abbreviated form. This can be found under the Verbosity settings HTML Options in the Configuration Manager (seems to have been removed from the Verbosity settings in JAWS 9.0). I know that Window-Eyes has similar options, but I’ve not tried them myself.

My own testing, primarily with JAWS, has found the options to work in recent versions. However, I have identified a couple of quirks with abbreviations in JAWS 7.10 and JAWS 8.0 that are worth noting. The settings for abbreviations haven’t worked properly in certain versions, but support has been around for quite a while and seems fairly stable now.

Another thing worth mentioning: don’t get tripped up by thinking that Internet Explorer’s lack of support for the abbr element in version 6 and below means that screen readers can’t use them. If you’re thinking, “Surely screen readers sit on top of a browser and if the browser doesn’t support something, the screen reader cannot either?” you’re about to learn something new. As the saying goes: “There’s more than one way to skin a cat!” Screen readers don’t rely on the browser’s document model for everything – they can use other ways to access the information they need.

Please be careful

So, there you go. Make of that what you will. If you want to know more about using the abbr or acronym elements in your markup, stay tuned!

I’ll close with a plea – please be careful when giving advice or publishing research!

While many people like short and sweet advice, I don’t like seeing information touted as “fact” without evidence – I see it too often in the papers (I say with a wry smile). If you’re going to provide advice to people, be able to back it up with links so that people can find out more. If you don’t, confusion breeds and gives birth to myth.

Lab Update, October 2006

This is just a quick post to say that I have updated the lab with some of my latest screen readers tests, including a series of tests investigating how screen readers pronounce certain words and phrases in different contexts.

I’ll be updating those tests with more results as I get them, and I may be persuaded to re-post here with any findings too!