I spent a great weekend up in London at the Scripting Enabled conference and hack day. It was really great to catch up with people I haven’t seen in a while and to meet new people as well. There were a couple of “click” moments like bumping into Peter Abrahams while scanning through the alphabetically-challenged name tags and then figuring out that the lovely lady from Devon was Laura Whitehead who had recently blogged about my list of accessibility videos!
The Scripting Enabled difference
I come away from web conferences and geek meets inspired and chomping at the bit to get working on some of the ideas that have come out of such events. I get back to my cave, start blogging about something that I need to get out there, get distracted by something I wanted to look up (“Right, let’s open that in another tab and deal with it later”), rarely properly finish the entry, get back to doing proper work and not find the time to work on that cool idea or at least put the idea out there. Well, no more, damn it!
What has been the difference at Scripting Enabled this week? The hack day which followed the day of talks and discussion made sure I took the time out to do something with an idea.
Doing the hack day straight after the talks meant things were fresh in our minds and a lot of the clever people who were at the conference were on hand for the day of hacking to work with on an idea and to bounce ideas off of. Having people in the same room with different abilities and disabilities really made the hack day a hive of activity.
On top of that, the event was free to attend. Christian did a fantastic job of pulling together the sponsorship, venues, speakers, hackers… There are lots of people who have given to this event to bring together great people to produce results. I can’t wait for the next one now!
What did I do? I worked in a group of beautiful people to improve accessibility of maps on the Web using the Google Maps API. We were so chuffed to have something to show at the end of the day, but we’re not quite ready to show the world yet. Expect more words from me on that.
The University of Texas has decided to close the Accessibility Institute, which has been a guiding light in our field, giving important opportunity for research and providing useful resources to the world. It would be a real blow to web accessibility to see it go.
Christian Heilmann is organising a combined conference and hack day around accessibility and interface hacking. Scripting Enabled is a free event in London on September 19th and 20th:
“The aim of the conference is to break down the barriers between disabled users and the social web as much as giving ethical hackers real world issues to solve. We talked about improving the accessibility of the web for a long time – let’s not wait, let’s make it happen. […]
“The first day is dedicated to getting real information about accessibility barriers of online systems and techniques to work around them. […]
“The second day is a development event where we will try to build solutions and alternative interfaces into existing systems that work around the issues we learned about on the first day.”
It’s a great idea and presents a good opportunity for designers and developers to learn more about accessibility, how it affects visitors and perhaps get some practical experience while helping real users to access to some popular web applications.
There are quite a few tickets available for the “fact finding” first day (60 at time of writing), but if you’re interested in the second day of hacking, the tickets are nearly all gone. I’ve already booked mine; perhaps I’ll see you there!
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.
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.
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.
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 HTMLbr 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).
PHP all-stars, OmniTI, recently launched their web site; Jon Tan and I had the pleasure of aiding in its creation.
The additional layers of markup for both the contact details and search layers are requested from the server using Ajax, which jQuery makes really easy. It’s common for such layers to be embedded in the page markup and hidden using CSS when the page loads. The information in these layers are for convenience and is available on other pages of the site, so it doesn’t need to be on every page. Using Ajax in this way also allows the markup for those layers to be easily maintain server-side.
That’s all fine for the majority of users. Let’s make sure we think about other users who may have different, and diverse, needs.
A more accessible interface
Sighted users see the lovely jQuery slide down effect when they click one of the activating links; it grabs their attention and shows them that new information is on the screen. If you can’t see, you need different feedback to tell you what’s happened when you followed the link, otherwise you might think that nothing has happened.
Using focus for feedback
We need to pick a focusable element in the new layer we’ve added to the page, i.e. a link or a form element. Conveniently – although, some might say by design – there are appropriate elements at the start of our new layers. In the search layer, it makes sense to focus on the search input of the form. In the contact layer, the first element is an email link, so we can put focus on that.
Keyboard focus can be brought about easily by calling focus() on the required element, so long as the element is focusable. For example, after injecting the layer, we can pick it out the target element and give it focus:
Ironing out some creases
As a focusable element, the target link should be able to receive focus with no trouble, but in conjunction with injecting elements into the DOM, it doesn’t always work. However, there’s a fix.
We’ve got one last problem to iron out. In some browsers, setting a tabindex value of less than zero will remove the element from the tab order of the page. Keyboard users will often make use of the Tab to navigate around the focusable elements of a page. The tab order is the sequence in which these elements are given focus as a user tabs around a page. As our link should be in that tab order by default, we’ve just removed it by messing with its tabindex. Setting the tabindex value to zero (and possibly blank, but I’d need to double check) will put the link back in its place in the tab order. I don’t recommend setting tabindex in markup, but if you happen to be doing so, you should set the tabindex back to its expected value.
I'm a digital accessibility consultant with a passion for sustainability and business ethics. I help organisations make their websites and mobile apps accessible to Disabled people by establishing sustainable approaches to digital accessibility and inclusion.