Archive: June, 2008

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.

Practicalities

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).

Semantic markup for poetry

Denna Jones’ Locker?

I recently worked with Jon Tan to build a site for Denna Jones, a multi-talented consultant and writer around architecture and culture. We took a somewhat new direction with her site; all of her content comes in from Web services, such as Flickr, Tumblr and Twitter. I’m going to run through how we used Flickr to manage the majority of the site’s imagery and even some of its text.

A bit of background

From the outset, the idea was to focus on content and make it as easy as possible for Denna to update her site. We gathered content into the site from the various services Denna uses (Flickr, Tumblr, Twitter, Ma.gnolia, Upcoming), removing the need for a conventional content management system.

If you want to read more about the general idea, there’s an overview of how Denna’s site was designed and built in the colophon on dennajones.com and Jon Tan gives more detail on the concept and visual design on his blog.

Denna’s site was a fun project to work on because it was a bit of an experiment. (Denna obviously enjoyed it too!) Anyone who knows me well will know that I like to play with things; I break them, find out how they work, and then piece it all back together again. I’m an engineer. Playing with a new idea gets the creative juices flowing in Jon Tan and is a catalyst for my more technical sleight of hand. (It often feels like magic, even to me!) Now, that’s always a good place to start a project! So, it wasn’t exactly the watery doom you might have expected from the title of this entry, but then my clever play on words wouldn’t have worked; the apprehensive thalassophobic among you can breathe a sigh of relief.

Fostering the friendship with Flickr

Denna was already making good use of Web services, particularly Flickr. It made sense to lasso these elements from the sea of Web services and turn her site into a treasure trove of content, helping it to reflect the very essence of what Denna is and does. So, we jacked in the usual content management system approach in favour of outsourcing everything.

Denna finds Flickr a great tool for inspiring her work, but she also uses it to document her projects and share snippets of her day-to-day life. She’d modestly tell you that she’s no photographer, but she has a strong sense of the spirit of a place and is able to capture an environment, a building or room, even intricate details, in her own unique way.

We wanted to put Denna’s photos to work. Beyond simply including the photos in the site, they formed an integral part of its design and functionality. I’ll cover some of the mechanics involved in a moment, but first I’ll run you through the areas of the site where Flickr was used:

The masthead imagery

The masthead images throughout the site are pulled from Flickr using a photo tag search. All Denna has to do to add a new masthead image to her site is tag her photos; the site does the rest. On the home page, you can flick through the full series of masthead photos.

Denna’s work portfolio

We had originally collected the projects together into one set where each photo represented a project and its description introduced the project. We soon realised that we needed sets for each project, so that Denna could easily group together several photos for each project.

This is where Flickr’s photo collections came in useful. The photos and text descriptions used for Denna’s work portfolio all live inside a specific collection on Denna’s Flickr account. Each set represents a project and the set’s description is the project’s introductory text. Visitors are invited to see more photos of each project on Flickr.

The key photo for each project set is the one used to represent that project in the portfolio, so Denna can easily change that too from Flickr’s interface. Denna’s introductory text on the work page (to the side) is also pulled from Flickr; it’s the collection description.

Denna’s footer photo

As a little added extra, the photo of Denna used in the foot of each page is her “buddy icon” on Flickr; it’s just rather nice for the two to correlate. Again, this is simply requested from Flickr using the Flickr API, so if Denna changes her buddy icon on Flickr, the foot of her site gets updated as well.

The mechanics

PHP does the hard work on Denna’s site. To be more accurate, the CakePHP framework does a lot of the hard work with a little help from some friends. One particular friend is the rather wonderful phpFlickr class, which is a wrapper for the Flickr API and makes it really straightforward to liaise with Flickr from within PHP via the Flickr API.

Those of you who have worked with the Flickr API may already be wondering how I used Flickr’s photo collections when they are not yet supported in the API. As Jon mentioned in his entry about Denna’s site, I initially had to hack tags support for Tumblr, which used cURL to scrape the necessary data directly from their site. After emailing support about the fact that you could add tags to posts but do absolutely nothing with them, the Tumblr crew eventually exposed tags via their API. In a similar way, we had to work around the missing collections features in the Flickr API as well, which I may have to cover in a separate entry. Flickr collection support been discussed by users for some time, and while it looks like a solution may be on its way, it’s not yet seen the light of fibreoptic cable.

Denna’s site also uses PHP to resize photos from Flickr as necessary and then cache the images on the server. To keep the site up to date, the cache is flushed every night and repopulated, but it can also be manually refreshed by Denna. The number of masthead images pulled from Flickr is capped off to a limit. This is so that the server doesn’t have to go processing every image that meets our photo tag search, saving the server from heavy processing tasks and potentially bringing the site down.

The masthead image on the home page is rotated when you hit “next”. This is achieved using PHP sessions to remember the current image and some cache control to switch to the next image. As a progressive enhancement, a JavaScript image rotator takes over control of this feature so that a page reload is not necessary. To speed up development, my framework friend this time was jQuery. Other pages feature randomly selected masthead images on each page load.

Until next time

That’s about it for now. I hope you’ve found this little commentary on how we put together Denna’s site interesting.