Category: accessibility

Character references: widening screen readers’ eyes

April 13th, 2008 · accessibility, screen readers No comments

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.

Analysis

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

February 6th, 2008 · accessibility, screen readers 14 comments

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)

November 20th, 2007 · accessibility, assistive technology 2 comments

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

November 8th, 2007 · accessibility, Web 4 comments

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…

Footnotes

  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?

April 27th, 2007 · accessibility, microformats No comments

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.

Updates

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

Elsewhere