Many browsers include user preferences to select preferred colours for text, backgrounds and links. This is intended as an accessibility feature so that people with limited vision, dyslexia or other disabilities can choose a colour scheme that makes it easier for them to read web pages. In theory it’s a great idea. In practice however it seems to be nearly useless.

There are two “modes” these colour preferences can be used in:

In ARIA, there are two ways that you can attach a label to an element, aria-label and aria-labelledby. In theory, you should use aria-labelledby if the text is visually on-screen somewhere and this form is preferable. You should only use aria-label when it’s not possible to have the label visible on screen. This makes a lot of sense because generally sighted users like to be able to see the label as well and it prevents the visual and non-visual cues from getting out of sync.

Brad Neuberg has a post up about ARIA on the iPad and some of the tricks he’s used to bend it to his will. Blogger won’t accept my OpenID to comment on the post for some reason so I’ll add some thoughts here.

tabindex

As Brad notes, you can set tabindex=”-1” to prevent an item in HTML from appearing in the tab order. Also as Brad notes, this won’t stop the VoiceOver cursor from moving to that element. It’s important to remember that the VoiceOver cursor is not linked to the keyboard focus, it’s linked to what is being read out to the user. This can be very confusing but it’s an important concept, allowing you to review parts of a document without losing the current caret position where you want to continue editing. Most screen readers seem to have this distinction between the text input focus and the screen reader cursor.

The Wall Street Journal has an article on a new bill just passed by US Congress that updates accessibility requirements.

The legislation, called the 21st Century Communications and Video Accessibility Act, covers things like captions on Internet video, Internet phone services that work with hearing aids, television menus that can be seen by people with vision loss and even touch screens that the blind can use. The bill, which passed by voice vote and will now go to President Obama for approval, updates existing regulations to bring them in line with the Internet age. I haven’t taken the time to decipher the details from the actual legislation text as yet, so it’s hard to say exactly what implications this will have. It is at least good to see improvements to US laws – to date it has really been civil threats, such as the suit against Target, which have been the main legal avenue to ensure accessibility. This is generally under the American’s with Disabilities Act which was written in terms of physical accessibility for public places, but has been deemed to also apply to the web. As I understand it, this new legislation will provide some more teeth on the criminal1{#footlink1:1285835355912.footnote} side.

Over the weekend I went to JSConf EU and every time I met someone and told them I was working on TinyMCE the conversation rapidly veered off into why contentEditable is too hard/buggy to work with and how it would be so much better if it was all built on top of canvas or just used the DOM with a custom selection API. This matched the thinking throughout the conference that it doesn’t really matter how messed up browsers are because JavaScript can be used to work around it.

Austin Seraphin’s posts on his experiences using the Voice Over technology in iPhone and Mac OS has been mentioned fairly widely and they are definitely worth reading. Many people understand that blind users, and people with other forms of disabilities, are dependent on screen readers to interact with computers, but what is likely to come as a shock is just how expensive high quality screen readers can be:

I joyfully look forward to the day when blind people finally catch on and realize that for $700, HALF the cost of JAWS for Windows, the most popular software used or rather pushed on the blind, they can get a fully functional computer that delivers a superior experience and comes with a superior screen reader with superior speech. JAWS standard edition turns out to be $895 on the online store, professional $1095 but that still doubles the cost of a computer for users who need a screen reader. There are open source screen readers and my understanding is that some of them are quite good, but the defacto-standard is very much JAWS. Most accessibility testing that is done is with JAWS and so it’s an up-hill battle to use anything else.

I spent the weekend discovering just how poorly thought out and poorly supported closed captioning is in online video. Some highlights (based on the SRT format because that was the only one I could find any information about syntax for):

• Definitive guides to the format either don’t exist or are so poorly used that they don’t appear in the first 3-4 pages of a Google search.
• Timestamps use a non-standard format. The inventor was apparently French so instead of the usual hh:mm:ss.ttt the period is replaced with a comma. I sympathise with everything being US-centric, but the number of people who were making this mistake on forums etc and the number of players who support period but not comma (and visa-versa) is scary.
• Only DOS line endings are supported. \r\n is fine as part of the standard, but why can’t players be a little liberal in what they accept? It’s not like \n or \r by itself within the caption is going to work anyway…
• No standard font, so no way to know if the caption will fit or not.
• Absolutely zero feedback from any player I found about why it was ignoring the captions.
• Really, really poor tooling support for creating captions.

So, coming around to the real point of this post, I wound up writing my own tool to help take a script, synchronize it to the spoken voice and output the right format. Worked a treat, and now I have working captions on my video. I suspect it would be useful to others and there’s certainly plenty to do to improve it that would be great if others jumped in and helped with.

The Australian brings news of the growing battle for mobile banking leadership among Australian banks:

Brisbane-based Suncorp launched the first mobile browser-based banking service and last week made it compatible with iPhone and Google Android handsets.

The Commonwealth Bank has similarly updated its mobile service, which will work on any internet-enabled mobile phone, and has additional functionality for the iPhone.

People have been talking about the coming mobile revolution for a long time. In fact, as the article mentions, the Commonwealth Bank had previously tried to jump on the mobile banking wagon as early as 1999 via a WAP interface. So what’s changed and what does this have to do with accessibility?

When I wrote my post on accessibility the other day, what I really meant to say is what basically what Rob Foster wrote. Very roughly summarized, accessibility is about real people, not checklists.

The issues of accessibility are a daily reality for my family. For us, it’s not a political issue at all. Our oldest daughter, Ramona, has cerebral palsy and uses a wheelchair to get around.

…

Here’s my point–if your brother or sister had a disability, you would give a crap. But you don’t have to have a sibling in a wheelchair to genuinely care, even if it’s only in your work.

Mark Pilgrim and Sam Ruby have been going back and forth and back again about accessibility and in particular the SVG images on Sam’s blog. In Mark’s latest post he explains the somewhat crazy world of access enablement:

Long answer: As far as I know, none of the commercially available screenreaders support svg in any way, much less reading the title of an svg image included inline in an xhtml page (as opposed to, say, linked from the src attribute of an <img> element, or embedded in an <object> element). Nonetheless, you have provided a text alternative for the image, and theoretically, that could be presented to a user in place of (or in addition to) the image. You have therefore fulfilled your moral duty, even though no one actually benefits from it. Welcome to the wacky world of access enablement. Mark’s right – in many companies and other organizations you have to tick the boxes for accessibility rules and they are quite often just plain stupid. Mark calls that access enablement, I call it beurocracy or perhaps more kindly, the only effective way to get a large organization to meet difficult to understand objectives.