Category: Web

Joining OmniTI

Right, now that the cat’s out of the bag, I’m happy to announce here that I will be joining Jon at OmniTI to form part of their interface design team as an accessibility engineer!

Essentially, I’ll be doing the stuff I love: accessible interface design, consulting and training, and quality assurance (“pedant duties”). And I’ll be doing it from within the loving arms of one of the Web’s cleverest companies. To echo what I said the other day, working with the people at OmniTI over recent months has been great. Even though I’ve been working remotely, I’ve been surrounded by really clever folks, which means it’s always a learning experience, and always fun. Hopefully, some of them feel that they have been learning from me, too.

I’ve always sat somewhere between the back-end development geeks and the front-end creative types. In my new job, I will be concentrating on interface design, but I will be working closely with other teams to help ensure accessibility is built into the applications built by OmniTI. It’s perfect for me, and I’m really looking forward to it.

What a way to round off the year! I have a feeling there’s going to be a lot of cool stuff in store for 2009. I hope you all have a great Christmas, and I’ll see you on the other side of New Year!

End of the year—all change, please!

Wow! These past few weeks have been a bit of a roller coaster ride. Sit with me a while, and try not to throw up on my trousers…


In November, I was invited to the Web Developers Conference in Bristol to sit on a panel with Elliot, Elliott, Dan and Dan (spooky, eh?) to talk about Working in the Industry & Loving the Web. It was a great day, organised by Alex Older to give web design students at UWE in Bristol the chance to meet and talk to people in the industry. The panel was great to be part of—it was my first time seeing a conference from the stage and I really enjoyed it. Hopefully, we imparted some valuable words of wisdom to the audience! As always, it was a real pleasure to meet wonderful folk from our community, and to talk with some of the students in the bar after the event. Both the conference and Bristol SkillSwap the night before were great. If you’re a web design student at UWE, go to next year’s conference. It’s really something that other universities should be doing as well.

November was also brought to you by the number 5, the colour blue, and a healthy dose of rock music. Unfortunately, I didn’t get to PHP North West, but I heard it was excellent and lots of fun.


This month, I’ve mostly been wearing my editor’s hat, both at work and in play. I have a strange affection for editorial work, especially as I was pretty crap at English at school. My inner stickler for correct grammar seems to prefer the written word as a medium for articulating my thoughts—a little like how just the right amount of alcohol brings moments of clarity. One of this month’s highlights has been working with Chris, Sean and Jon to set up and run this year’s PHP Advent Calendar. If you’re a PHP developer, be sure to head over there for a good read.

But the big, fat news is that my esteemed colleague and friend, Jon Tan, has joined OmniTI as their Creative Director. We’ve been doing work with OmniTI for some time, and I must say that working with them has been edifying and a real pleasure. The offer they extended to Jon is a great testament to his talents and character, and is truly deserved. Congratulations, my friend.

What about Grow Collective? Well, you’ll have to wait and see what the New Year brings. Well, now that the cat’s out of the bag, I can tell you: I will also be joining OmniTI. In the meantime, I’m off to start my Christmas holiday by getting cosy with a glass of mulled wine and a mince pie! Happy Christmas to you and yours, and I’ll see you in 2009.


  1. Alex Older: WDC2008, It’s over….for now
  2. Dan Donald: Web Developers Conference
  3. Elliot Jay Stocks: Round-up of 2008 speaking events
  4. Pete Coles: Web Developers Conference Write Up
  5. Rick Hurst: Web Developers Conference 2008

jQuery UI accordion: enabling keyboard navigation

A couple of weeks back, Karl asked a question about jQuery UI’s Accordion interface widget and keyboard accessibility. I’ve got my head in various JavaScript frameworks at the moment, so I took a quick look.

This article is now a little out of date. The jQuery UI team seem to have updated the framework to use tabindex="-1", fixing one of the problems I outline below. The example code may now be obsolete. I hope to review this soon.

So, what’s an accordion when it’s at home?

You’ve got an accordion interface when you have a small collection of vertically-stacked, collapsible layers of content that a user can flip between. It’s a similar concept to tabbed interfaces where you view one chunk of content at a time, but in an accordion each of the interface controls are vertical and span the full width of the content. It’s easiest explained with an example (make sure you have JavaScript enabled).

Problems with keyboard accessibility

Karl was finding that, while you could navigate and control the accordion using the keyboard in Safari 3 and Internet Explorer 7, there were problems when using Firefox 3. I’m not yet sure why, but it didn’t work at all for me in Opera 9.6.

When testing with Firefox 3, I observed the following:

  • If there is a link inside the accordion control, you cannot navigate to it when tabbing forwards through the page. However, you can access the link when tabbing backwards using Shift+Tab.
  • You cannot tab back through the page from the accordion control using Shift+Tab. Keyboard navigation is trapped.

I traced the problem to the tabindex="0" that jQuery dynamically adds to the accordion controls. The idea is to actually improve accessibility; tabindex="0" should tell browsers to make the accordion control part of the tab order, no matter what type of element it is. For example, if you have a heading as a control for your accordion, setting tabindex="0" on it should allow you to tab to it, even though a heading is not normally accessible using a keyboard.

The onclick problem

Despite this seemingly life-saving technique for adding elements to the tab order of a page, it doesn’t necessarily ensure that our interface is now keyboard accessible. I’ll be doing some testing and explain in a follow-up entry. Following Alistair’s comment, I’ll clarify here by adding that the tabindex technique is valid, but I believe it needs to mature before it can be relied upon.

For now, I can only advise that developers use standard HTML control elements (such as <a> and <button>) to ensure accessibility to keyboard users.

Firefox has problems handling tabindex="0"

So, back to the problem at hand…

Unfortunately, it seems that Firefox has problems with tabindex="0", causing the keyboard navigation issue that Karl was experiencing. The technique could be a good solution, but only if it was widely supported by browsers and was sure to work with assistive technology.

It looks like Jörn Zaefferer is on the case at the jQuery end and is removing the tabindex attributes set by jQuery. In the meantime, this move will (hopefully) force developers to use standard HTML control elements for their interface controls. Unfortunately, the majority of developers may see their interfaces working when using a mouse, assume that it’s all okay, and not test keyboard accessibility.

Fixing it in the meantime

You can “undo” the tabindex that jQuery sets by setting up your accordion something like this:

	header: ".ui-accordion-header"
$('#accordion .ui-accordion-header').attr('tabindex','');

Here, we’ve told jQuery to blank all the tabindex attributes on the accordion “headers” (i.e. the accordion interface controls).

An even better solution would use standard HTML control elements (<a>, <button>, …) in the first place, as mentioned above. However, this can restrict your markup a little, and may not make much sense, for example, if you’ve marked up each of your accordion layers with a heading. In any case, you can always the accordion controls dynamically, giving you a bit more freedom as to what element you use.

dotjay feeds fixed

I’ve been aware of a problem with my feeds for a little while. The main feed has been working okay, but some of the others I used to offer went a bit screwy. It should all be fixed again now.

You can subscribe to just my blog entries or to entries with a particular tag. So if you only want to be fed my accessibility posts, you can just subscribe to my accessibility feed. I’ve also included a new lab updates feed. Lab updates will also appear in the main feed. I’ve tried to redirect all previous feed URLs so that they will continue to work. My apologies if they break.

Trouble setting up a custom front page in WordPress 2.6?

I don’t know if this is a quirk of WordPress 2.6.2 or if something has changed in recent versions that aren’t reflected by the WordPress documentation, but I’ve had a hell of a time setting up a custom front page and shifting the blog index off to its own directory (like If anyone else is having a problem with 2.6.2 and custom front pages, this could help you…

In case it matters, I’ve got WordPress installed in its own directory and the site is using a custom theme.

To create a custom front page, you can use the is_front_page() conditional in the index.php theme file:

if ( is_front_page() ) :
<h2>My front page</h2>
<h2>Other templates</h2>

To create the blog index at /blog/, you need to create a dummy page called “blog”. You should be able to create a template for that page as the blog.php theme file. For some reason, my WordPress installation is not picking up the blog.php theme file, as it should according to the documentation. Without that file, it wasn’t falling back to index.php as I expected either. The latter observation I realised to be my own stupid fault as I had a page.php theme file that was being picked up by WordPress and used for my blog index. Still, blog.php should override the page.php file and it isn’t.

So, I’m currently using page.php for the blog index, detecting it using if_page('blog'):

if ( is_page('blog') ) :
<h2>My blog index</h2>
<h2>Other page templates</h2>

If you don’t have page.php in your theme, WordPress should fall back to using index.php. As mentioned above, you can detect the front page in there using is_front_page(), but you should also be able to detect the blog index in that file using is_page('blog').

if ( is_front_page() ) :
<h2>My front page</h2>
elseif ( is_page('blog') ) :
<h2>My blog index</h2>
<h2>Other templates</h2>

I hope this helps someone else out there.

PHPNW08 Conference

Just a quickie to say that my friends over at PHPWomen and GeekUp are helping to organise the PHPNW08 conference to be held in Manchester on November 22, 2008. There’s quite a lot of geek activity up north, and the conference aims to bring together the local PHP community for a ronkin’ good conference.

Looking at the schedule, there are going to be some interesting talks from some well-known PHP bods. The tickets are now on sale with early birds getting in for £50. Concession tickets are also available.

I’m not yet sure if I’m going to be able to go, but figured some of you lot might be interested. Let me know if you plan to go.

Scripting Enabled debrief

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.

In the meantime, check out the photos from the event and keep an eye on the Scripting Enabled site.

Help save the Accessibility Institute

Most people with an interest in web accessibility are likely to have at some point stumbled across the work of the Accessibility Institute at the University of Texas in Austin, which was founded by the late Dr. John Slatin.

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.

If you care about web accessibility, please show your support by putting your name on the petition to save the Accessibility Institute that Knowbility have set up. It only takes a few seconds to do.

There are some great thoughts and comments from people who have signed the petition. Henny Swan has also given some reasons to keep the Institute going on her blog:

Reasons for saving the Accessibility Institute include:

  • Need for research based findings to support accessible design practice.
  • Opportunity for a world class institution like UT to serve as an example to other institutions.
  • Place where emerging practices can be tested and modelled.
  • Contributions to international body of knowledge on inclusion.
  • Maintain thought leadership in Texas, easily disseminated to state agencies that have accessibility mandates.

Thanks for taking the time to read this. Extra special thanks if you have signed the petition.

Read more

Scripting Enabled: accessibility conference and hack day

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!


Christian has now announced the schedule for Scripting Enabled. The tickets for the second day (the hack day) have all gone now, but there are still tickets available for the day of talks on 19 September.

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