Category: accessibility

Android keyboard shortcuts cheat sheet

Did you know you can control your Android devices using a Bluetooth keyboard? I use a keyboard to test apps on Android for accessibility. Having to remember keyboard commands across multiple platforms, one can get quite confused. This is why I have a series of cheat sheets to help me when my memory fails me.

Earlier in the month I popped my rough and ready cheat sheet for Android keyboard commands up on Github for anybody to use or contribute to:

Android keyboard shortcuts

I’ll be adding more resources here over the coming weeks, so stay tuned.

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.

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

John Slatin Fund Accessibility Project

John Slatin was a leading light in the field of web accessibility, which is a passion of mine and my area of work. He co-authored Maximum Accessibility – a book on web accessibility – was co-chair of the WCAG Working Group for a time and led accessibility research at the University of Texas at Austin. Sadly, John passed away in March after a three-year battle with leukaemia.

I never met John, but along with many other accessibility experts, I’m taking part in the John Slatin Fund Accessibility Project to help raise money for John’s wife, Anna, to honour John and to promote his cause; accessibility.

The project aims to raise money to help his family with the medical expenses incurred during John’s illness. Volunteer accessibility experts are matched to companies that want to have their web site checked over for accessibility issues. In return for a brief accessibility audit, the web site owners contribute a minimum of $500 to the John Slatin Fund.

More than 70 accessibility experts have volunteered their time to the project; now we’re looking for companies to take part too. If you work for or know of a company that would be interested in taking part, please point the appropriate people to the project information for companies or contact me directly.

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 &minus; or &#8722; 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.

Experiencing accessibility (and a video tour)

I first became interested in accessibility when I was at university. I met several people involved in using music technology to help disabled musicians to explore music. It was inspiring to see innovative forms of human-computer interaction take shape and enable disabled musicians to compose and perform their own music.

The enthusiasm that these people had for making music more accessible got me into accessibility in the first place. And no wonder they were so enthusiastic. Most musicians will be able to tell of the satisfaction they get from music, whether it be in writing their own pieces or playing at a gig. Some people find solving problems with technology very rewarding. Combining a love of music and of technology for something worthwhile is a triple whammy!

I had first hand experience in making music more accessible while working on a software project with the Drake Music Project. During this project, I was able to have the software I worked on tested by musicians who use single switches to interact with computers. Admittedly, the software wasn’t the most wonderful thing since sliced bread, but seeing how disabled users may go about using a piece of software was invaluable.

A video tour

Today, my musical endeavours are few and far between and my work is geared towards the Web. Still, my experience of and enthusiasm for accessible technology continues to steer my thought processes when building websites.

Getting our own experiences of accessibility inspires us to think and validates what we do with accessibility in mind. I was reminded of this a few months back while I was reading Grant Broome’s post in which he linked to a video by Victor Tsaran, an accessibility engineer working for Yahoo! — Introduction to Screen Readers. It can be difficult for us to appreciate the user perspective by getting direct exposure to disabled users, but watching a video can help us to build an appreciation for accessibility.

Since seeing Grant’s post, I’ve been slowly putting together a list of videos that demonstrate accessibility, which I thought I’d share with you. I’ve kicked it off with some interesting videos I found from Yahoo! in their YUI Theater channel and have listed a couple of other interesting resources. I hope that people find the page useful and perhaps I will add to the list over time.

Related reading

Analogies for accessibility

I’ve never been able to pin down my learning style. Although I’ve always thought myself to be hands-on, my learning style tests always seem to suggest that I’m multimodal, varying slightly around level scores.

I like analogies. I find them to be useful tools for learning, particularly ones that have physical value. They make understanding a new topic easier by relating it to and drawing parallels with an already understood topic. Apparently, it’s auditory learners who tend to use stories or verbal analogies to understand things. Hmm, perhaps that somehow links with my love of music.

Making accessibility more… accessible

Okay, before I wander off on any more tangents, I’ll get to the point. In learning about Web accessibility, I’ve come across a few analogies for helping people to understand the topic and I have a couple of my own. I thought I’d air some of them to see what people think and perhaps hear some new ones.

The access ramp analogy

It’s probably safe to say that most people will think of physical access to buildings when you talk to them about accessibility. It’s something that most people know about and can understand without much effort.

Ramp access to buildings makes a good analogy for any kind of access technology — something that reduces the effect of a barrier or bridges a gap. Ramps improve accessibility for wheelchair users, parents with prams, the UPS guy delivering your office’s new photocopier – notice it’s not just about people with disabilitiesfootnote 1.

Jon Dodd from Bunnyfoot uses a library as an analogy for Web accessibility (or see the library analogy in more detail in the Northern Ireland Civil Service’s accessibility primer). It makes good use of the ramp analogy. Personally, I think a ramp is more an example of what I call bolt-on accessibility, designed to overcome existing obstacles rather than prevent them.

The transport analogy: everyday access

Think about the innovation that are curb cuts while reading this quote from someone who obviously knows what he’s talking about, me:

“We all know, the Web is not as real to people as the physical world. Using a computer is still very alien to some people. This, I think, is one of the reasons that people are unaware of Web accessibility. Most people will see accessibility on a daily basis in the physical world. In a way, everyone experiences accessibility on a daily basis — every time a person drives their car, rides their bike or uses their wheelchair. Roads, pavements and buildings are reasonably barrier-free, or getting there. People can understand these kinds of physical considerations easily.

“I think some people have difficulty considering accessibility in computers because it’s fairly intangible and those people almost expect accessibility to just exist because they don’t have any problems.”

Roads are so common that we forget that they facilitate accessibility — to get you from A to B. Pavements (“Sidewalks” for the uninitiated) have curb cuts, an innovation that facilitates accessibility for many of us on a daily basis.

Websites are like mobile phones

This one is more related to user experience rather than directly to accessibility.

You know how annoying it is when you’re trying to send a text message on your mobile phone and you can’t get a signal? You try holding your mobile up in the air to get a better reception. You try a different room to see if there’s a better chance of a signal somewhere else. You try hanging out the window. You wonder if there’s a problem with your phone.

It’s an example of a poor user experience and inaccessibility caused by a barrier or some other problem. Like trying to send a text message when you’ve got poor signal, sometimes things are not as immediate or as obvious as they should be.

People may try to muddle through, but rarely without frustration. We try relentlessly to get better reception with our mobile phones, hoping for success, but sometimes there just isn’t a signal. Likewise, sometimes a website is simply more noise than signal. Don’t fuel user frustration — take time to consider how you might create a positive user experience.

You may not be able to send your text message because there’s too much interference from something — a problem caused by things you cannot see. Sometimes there’s a problem with the phone that you don’t know about. If you cannot see or do not know about a barrier, it doesn’t mean it’s not there. Being able to foresee problems comes with experience, but it’s important to be receptive to problems faced by frustrated users in order to learn. When it comes to accessibility, if you can’t see or don’t understand a disability, it doesn’t mean you’re okay to ignore it.

Bad experiences with your mobile phone will make you think twice about using that service provider in the future or buying that brand of phone again, won’t it? People are impatient, so don’t burn their fuses at both ends by not taking the time to think about accessibility and ensuring a good user experience.

Accessible specsfootnote 2

Okay, this one’s not an analogy for Web accessibility as such, but I think it’s worth mentioning.

Think of how many of your family and friends either wear glasses or contact lenses. Quite a few I’d imagine. Myopia (nearsightedness) is surprisingly common. Something in the order of half of us are affected by it. Much of the world will probably think nothing of it these days, but there was a time when specs were a new technology (eyeglasses were invented in northern Italy some time around the end of the 13th century).

Spectacles are really a crutch — an aid, not a solution. We have solutions for improving Web accessibility, and techniques that help us to avoid causing problems for people, but my guess is that the majority of Web designers don’t use them. I sometimes feel frustrated to think that accessible techniques are not used by every Web professional. Then I remember the specs that are perched on my nose and wonder how quickly they caught on when the technology was new.

Your analogies

A couple of rather straggled analogies there, so I’m sure there are better ones. Do you have a favourite analogy for accessibility you’d like to share with the world? Post a comment and let us know…


  1. Some people would argue that a ramp is an example of universal design rather than being an accessibility feature. That’s not meant to sound like a dig at the “universalists” out there, but while I’m thinking about it: It seems to me that there are more useful things that require our attention than arguing about different interpretations of what accessibility encompasses. Just a thought. Back to footnote 1 source
  2. Nope, not WCAG – I said specs! Back to footnote 2 source

abbr datetimes in microformats?

James Craig and Bruce Lawson have raised an issue on the Web Standards Project blog today that I’ve been meaning to blog about for a while: accessibility issues raised by the use of abbr elements in the Datetime Design Pattern to provide machine-readable representations of dates in microformats.

In their blog entry, hAccessibility, James and Bruce explain my thoughts on it very well – it saves me writing it all up! It’s well worth a read if you’re into microformats.

To summarise my thoughts…

Basically, I think the expansion of an abbreviation should be human-readable. Inspired by an e-mail from Jim O’Donnell, testing microformatted date and time with screen readers back in October demonstrated that an ISO date format is hardly nice to hear being read out by a screen reader.

Having said that, it’s worth bearing in mind that, if a screen reader user cannot understand what is being said, they may well go through the text character-by-character in order to understand it. If someone does this with an ISO formatted date, it may still not sound great, but might then be easier to understand.

More recently, after discussing this quite a bit with Jon Tan, I settled (at least, for now) on using span for microformat datetimes instead of abbr, which obviously means my microformatted dates may not get parsed correctly. I think it’s a far better solution than using abbr, at least until something better is decided upon.

Jon and I have discussed a couple of alternatives:

  1. Prepending the title attribute of an abbr element with some human-readable text to give context to users, e.g. “ISO date format: YYYY-MM-DDTHH:MM:SS+ZZ:ZZ”
  2. Although this may be a corruption of Web standards in itself, using the lang attribute to declare the date format being used, either following it by the formatted date or putting the formatted date in the title attribute.

Anyway, check out the discussion on the hAccessibility entry. I’m interested in seeing where it leads and to what solution.


29 April 2007

Following comments on hAccessibility, it was proposed that the datetime design pattern for microformats be extended to allow the use of the title attribute on a series of permitted elements, e.g. span, em, etc.

There are problems here:

  1. Losing the abbr means that the “semantic tie” between the marked up text and formatted datetime is lost. We are no longer providing context to the datetime information.
  2. The title attribute may be validly used to provide additional information to an element. As such, wherever a title attribute is already in use on an element, that element cannot be used to also provide a formatted datetime. We don’t want the datetime to get in the way of any valid use of the title attribute. It could also make parsing unnecessarily complicated. The span element is meant to be semantically neutral, so the title attribute on a span is unlikely to carry something functional to users since there is no “semantic tie.”

This is just a cursory observation, but it seems we’re trying to use the title attribute to contain what is essentially metadata meant for machines. Other microformats design patterns have used the rel attribute for meta information. The problem is that rel always contains the context for a (usually human-readable) value specified elsewhere, e.g. the name of a person marked up with XFN is given context by the value of the rel.

What we need is a mechanism by which we can specify a “meta value” – a value that is not appropriate within the context of normal page flow – as you might with meta elements in the head. XHTML 2 adds support for this kind of thing, but what can we do now? Unfortunately, there’s no other attribute more appropriate for this use than the title attribute. The datetime attribute is only permitted on ins and del. If only we could do something like <span class="dtstart" rel="datetime:YYYYMMDDTHHMMSS+HHMM">!

The discussion continues on the microformats discuss mailing list.

30 April 2007

I knew I’d read about this before! Accessify Forum: Use of <abbr> in microformats