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

1. As preferences that web sites can override.
2. As forced settings, where website specified colours and background images are completely ignored.

Preference Mode

In the first case, there are a vast number of sites which become unusable because they specify a specific background colour without also specifying a foreground colour. So if you happen to set your preferences to have light coloured text on a black background, then try to log into Google you get:

Choosing white text on a black background would make half the text on the internet disappear.

Clearly this is poorly coded websites causing accessibility programs and they should get with the program and specify foreground and background colours in pairs. Which of course makes that dialog box look like:

Much better. Except now there is no sign that I ever changed my browser preferences rendering them completely useless. So now designers have a choice between respecting browser preferences or largely designing a black and white site.

The net result is that changing your browser colour preferences will have no effect on well coded sites and break a large number of sites. So why bother?

Forced Mode

So we’re left with forcing our preferred colours on web sites. This actually gives us high contrast and is most likely very useful for people with limited visibility. However, for people with dyslexia who wanted more readable colours1 rather than just high contrast now tend to struggle because so much visual context is lost from the page. Sure, on a well coded site all the information is there, but different background colours is a really useful indicator for the various sections. That extra context and readability is now lost. That’s a disaster for someone with good vision who was trying to make the page more readable.

Compare the very well coded BBC website with preferred colours vs with forced colours.

It’s important to note that the BBC website is actually quite well coded – all the information is still available when you force the preferred colours, the designers simply have a significantly reduced ability to provide context and delineation, so inevitably the page becomes harder to read.

What to do About it?

Frankly, I have very little idea. The never properly implemented and now deprecated CSS system colours would have helped a lot in some cases. Design heavy websites would have still wanted their own colour set but web applications could have at least used them. Perhaps some way to specify a colour along with a fallback system colour could have worked. Then in the forced colour mode, the system colours would be used.

Beyond that it would be really nice if browsers were smarter about the options they provide. Instead of just a default colour setting, have a minimum contrast setting – the browser automatically increases the contrast between background and foreground colours to a specified point. Then you could combine that with a preference that text is always blue – if the website specifies black text on a white background it comes out blue text on a white background. If it’s white on black then it comes out as blue on suitably contrasting gray.

I don’t doubt that there are huge challenges here and I certainly can’t suggest the answers, but it seems like it’s about time we started putting pressure on user agents to do more to support accessibility rather than expecting website designers to do the impossible and create great designs that work with such limited accessibility tools.

1 – blue on white is actually much more readable than black on white ↩

However, with current support, you should always use aria-labelledby, even if you need the label to be hidden. While at least JAWS 12 and VoiceOver both read the aria-label as expected, it turns out that VoiceOver doesn’t correctly read the hierarchy if aria-label is in use. For example:

<p id="group1">Outer group</p>
<p id="item1">First item</p>
<div role="group" aria-labelledby="group1">
<a href="javascript:" role="button" aria-labelledby="item1">Item Content</a>
</div>

everything here is using aria-labelledby and VoiceOver will read the button as “First item Outer group button”. In other words, the button label, the group label and then the type of object.

However, if you change any of the elements to use aria-label, for example:

<p id="item1">First item</p>
<div role="group" aria-label="Outer group">
<a href="javascript:" role="button" aria-labelledby="item1">Item Content</a>
</div>

VoiceOver will now read the button as simple “First item button”. It doesn’t seem to matter which item uses aria-label, if it’s anywhere in the hierarchy, only the label for the button itself will be read out.

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.

tabindex=”-1” also won’t prevent the user from moving keyboard focus to an element by means other than the tab key. For example, clicking on a textarea will move the keyboard focus to it even if it has a tabindex of -1.

aria-hidden

As a work-around to try and prevent VoiceOver from focusing an element, Brad then added aria-hidden=”true”. To his credit, Brad notes this isn’t a good situation and indeed it’s not. Now we have an element which is available to sighted users, but completely hidden to the screen reader. This is almost never what you want.

If something shouldn’t be a landmark, it probably shouldn’t be a heading element and if it shouldn’t be read by a screen reader it should generally be either not there at all or both aria-hidden=”true” and display:none; That way the element disappears for everyone, not just those using a screen reader.

I’m not quite sure what Brad was trying to achieve so I can’t really suggest the right workaround for his use case but it sounds like there may be a need to go back and get the basic semantics of the HTML right.

aria-labelledby

I’m not entirely sure what Brad’s aiming for here again but it’s a bit unusual to try and add extra audible information to a heading which isn’t available to sighted users. Normally labelledby would be used for form elements to link them with the text that describes what they’re for. My first thought here is to adjust the HTML to make it more semantic rather than trying to fix it up with ARIA. For the example HTML:

<div aria-labelledby="testH1 testH2 testDIV1">
<h1 id="testH1" tabindex="-1">
This is an H1
</h1>
<h2 id="testH2" tabindex="-1">
This is an H2
</h2>
<div id="testDIV1" tabindex="-1">
This is a div
</div>
</div>

I would say the right thing is to not have any ARIA attributes (or tabindex) at all. h1,h2 and div all default to the equivalent of tabindex=”-1” anyway and if a sighted user would see this as two separate headings and a normal paragraph, a screen ready probably should too. If it’s intended to be read as a single sentence then as a signted user, I’d appreciate it being laid out that way.

aria-label

As a side note, aria-lablledby is only one option for adding information and it’s useful if the extra information you need to present is already available in a textual form somewhere on the page. However, if the content isn’t available (for example because it’s using an icon instead of text) you can use aria-label=”The label you want” to directly specify the label text rather than referring to some other HTML element.

More Info?

It would be great to get some better background information on what’s being attempted here so that better solutions could be proposed. Right now it looks a bit like trying to use ARIA to hammer a square peg into a round hole which not surprisingly isn’t a lot of fun and doesn’t work very well.

The bottom line is that ARIA isn’t the answer to accessibility, it’s just a smattering of extra information to help out in complex cases where HTML and JavaScript are being used to create custom widgets. The first and most important tool for creating accessible web pages is still to use appropriate semantic HTML – especially for the “document” parts of a page as opposed to interactive widgets. If that foundation isn’t set, ARIA won’t save you.

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

1 – as in, Government-led as opposed to civil. I’m not sure I’m using the term right. ↩

What disturbs me is that incredibly few people realise just how much work is involved in implementing caret and selection handling correctly, let alone most of the other infrastructure provided by contentEditable. I wound up talking to Mark Wubben who actually does have a pretty good idea – he implemented a DOM based selection system for the Xopus editor. Needless to say he had quite the war story to tell, but despite doing what sounded like a very impressive bit of work, the selection code is still very broken in a couple of key ways: accessibility and international inputs1.

Accessibility

Accessibility support was my first response to anyone suggesting using canvas as an editor – no-one had considered it. If you play around with a screen reader for a while, you start to realise just how important the selection is to accessibility. Selecting text generally causes it to be read out for example. It’s not just screen readers either, screen magnifiers will move the screen along to keep up with the caret, ensuring the user can see what they’re typing. If the caret is fake, none of these features will work and the editor becomes inaccessible.

International Inputs

Even I’d forgotten about this one, but it’s likely an even bigger problem to solve than accessibility. The array of input devices, keyboard shortcuts and other ways that people input characters is pretty amazing when you start exploring it. People in English speaking countries don’t tend to notice this because they have quite a small number of characters in use which all fit on the keyboard. Even Western European countries have the vast majority of characters required available with a direct key sequence. However there are far more complex types of inputs around. The simplest of these is the use of “dead keys” such as acute on a US or British keyboard. To type é actually takes multiple keystrokes on a UK Mac keyboard:

1. Option-e. This is a dead-key so only a placeholder appears in the output ().
2. e. Now the e-acute character actually appears and is inserted into the document content.

Not to pick on Xopus but at least in Firefox on Mac, I can’t type é at all in the editor because it doesn’t correctly support dead-keys2.

Asian languages can have even more keystrokes required to type a character and much more complex input methods that to be usable, require changes to the caret, underlining content etc. Plus the methods and UI is different on different OS’s. While users can handle some variation, they shouldn’t have to learn a whole new input method to be able to use your application3.

The Way Forward

Instead of trying to work around the limitations in contentEditable we need to be pushing browser vendors to fix it and make it usable. Where the current APIs aren’t good enough, standardise better ones – we’re dealing with multiple incompatible APIs already so the backwards compatibility problems are limited. This needs to be a focus so that we don’t wind up in a world where online editors only work for fully-abled, English speaking users. Most if not all of what’s required is already there, it just needs some love and care to remove the bugs and better handle corner-cases.

1 – There is some good discussion of the complexities involved here from the W3C canvas list as they struggle with the accessibility implications of canvas.↩

2 – and to be completely fair, EditLive! fails to paint the placeholder, though the character does type correctly. ↩

3 – So no, Google Virtual Keyboard is not a real solution, however good an idea it is for people using things like internet kiosks with foreign keyboard layouts. Besides, would you like to be stuck typing only with your mouse? ↩

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.

If you keep that cost in mind, you can understand why old versions of screen reader software are so common. It also brings a new understanding to the blog post from the IE9 team indicating that screen readers would need to be updated to work with it:

IE9 fundamentally changes how users interact with the browser and how the browser takes advantage of the entire PC. Those changes also impact how assistive technology interacts with IE, which necessitates updates from some assistive technology. For example, the new notification model is not read by many screen readers, and screen readers can no longer depend on the GDI display subsystem since IE9 uses Windows Direct2D and DirectWrite as part of enabling hardware-accelerated HTML5.

The move to Direct2D and DirectWrite may well make sense, though it’s disappointing that screen readers felt the need to depend on a display sub-system instead of proper accessibility APIs for some reason. However, I find it quite appalling that the new notification model is inaccessible. Surely there is, or should be, a standard set of Windows APIs that can provide this kind of notification in a way that is also accessible to screen readers.

It seems to me that having the full screen reader API built in to the OS and maintained, as a priority, by the OS team is a pretty revolutionary step forward in terms of both reducing the cost of accessibility and improving it’s quality. It sounds like we still have an awfully long way to go though.

• 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 trouble is, to make playing the video easier, I used Cocoa and Objective-C. Great decision, got me up and running in no time – with really, really, really, lousy code. See, I haven’t done anything more than vaguely dabble in Objective-C and I’ve only used XCode back when it was Project Builder and I suspect OS X was in beta. Needless to say, the resulting code is terrible. I didn’t want to learn all the ins and outs of the Cocoa document system and where I’d have to change the names of things so the main document class is still called “MyDocument”. I think I turned on the Objective-C garbage collection, but if not it will leak like a sieve (it might anyway, not sure).

If you look at it one way, it’s pretty impressive to pick up a completely new tool set and get a useful application out in a morning, but more likely you’d look at the code and decide I was incompetent. So the great dilemma, should I push this rubbish code up to GitHub and hope someone comes along to refactor it, or will it just sit there waiting to appear in a Google search when I next wind up applying for a job, thus killing all my hopes and dreams?

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?

1. The capabilities and affordability of mobile phones with Internet access has dramatically improved. Firstly with the iPhone and now a top-notch browser is a must have feature in a smart phone.
2. WAP is out, users want the real web. It’s not ok to provide a text only WAP interface that works on phones, users want the full functionality and they want it to look pretty too. Modern phones support HTML, CSS and JavaScript and most of the time you should be writing just one site that works everywhere rather than a separate mobile site.

It’s that second point that really brings accessibility in. If you design your site so that it can be used with a range of disabilities, there’s a much better chance that it will also work on devices with a range of capabilities. In other words, someone using an iPhone to view the site is just a user with a particular type of disability.

• They have a small screen so the site needs to scale properly (use relative units, not absolute). If your site can handle users changing the size of the font, it can probably scale pretty well to fit on an iPhone.
• If the networks slow, they may not be able to see images. If you have good alt tags, they won’t need to.
• They can’t see flash. While you can design accessible flash, most people don’t so surfing without flash is often very similar to what a screen reader would see (at least for the flash side of things).
• They can’t use a keyboard very fast and can’t drag and drop anything.

There’s also plenty of unique things about various disabilities and the iPhone as well as different limitations on different handsets, but there’s also a lot of overlap.

Accessibility isn’t a cost centre – it’s a competitive advantage.

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.

And:

And from my perspective, accessibility is about giving a crap.

Accessibility is NOT a checklist.

Accessibility is about usability.

Accessibility is a paradigm shift.

Accessibility is a personal issue.

Checklists and accessibility reports are just tools to help you make things accessible – they can be really powerful if they’re used with the right intent, but they’re not the answer.

That’s why I’m so glad to see Ephox adding not just more and better accessibility checking and reporting into their products, but also tools to make it easier for authors to get accessibility right. We need to do more though, so much more, but at least it’s a start and we can start taking this message out to all the web content administrators that we talk to and try and get them to care.

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.

However, in the case of Sam’s blog, there really isn’t any loss of information if you can’t see the image. They act as a kind of category logo, and when you can see them, provide a quick way to scan the page for a particular topic. It would not be quick to scan the page if the images were displayed as a text alternative.

In fact, it could well be argued that adding the text alternative makes the page less accessible, not more. Compare:

Accessible

accessible

Mark Pilgrim: Deep thought: every post on @samruby 's blog since June 2006 contains an image without a text alternative.

With:

Accessible

Mark Pilgrim: Deep thought: every post on @samruby 's blog since June 2006 contains an image without a text alternative.

If you were a blind user accessing the page with a screen reader (the mythical one that supports titles in SVG), your screen reader would say the word “accessible” twice – once as a header and once as the alternate text for the image. You might get “Heading: Accessible, Image: Accessible” read to you but it’s still not useful. The single most useful thing that could be done with that image when encountered by screen readers is to simply ignore it.

One of the biggest challenges about accessibility is convincing people that it’s not just about adding alt tags to images, it’s about allowing people with disabilities to access the page. Following the rules to the letter is neither the absolute right answer nor a silver bullet. What you need to do is actually test with real world tools. That’s why the actual rules, particularly in WCAG 2.0, are so incredibly vague. The techniques are more detailed and more descriptive but the rules themselves are very high level.

The same thing applies in the real world. You have to provide ramps or elevators so that people in wheelchairs can get everywhere they need to go, but you don’t have to provide ramps everywhere. There are plenty of shopping malls and other public places that provide a normal set of stairs in the most convenient place and an elevator off to one side. Sam’s blog is a perfect example of that concept applied to software. I read Sam’s blog without seeing those SVG images all the time because they don’t come through to my feed reader, yet I can still tell what the post is about because it has a descriptive title.

If you’re asking yourself “does my site meet WCAG 2.0?” you’re doing it all wrong. You should be asking “is my site accessible?” Just meeting WCAG won’t necessarily make your site accessible – do it if that’s what is required to get paid, but don’t fool yourself into thinking that it’s the real aim.