About 10 people told me on various channels about Tomasz Wegrzanowski’s blog post ‘Making me think about usability’ and what my opinion about it is. Instead of putting up a short and powerful response I actually took this opportunity to write about the reason for posts like this: Communication between accessibility and usability geeks and technical geeks is broken – and very much so.

In a long blog post over at Scripting Enabled entitled The biggest barrier to accessibility and inclusive design is us I vent some of the frustrations encountered in my years of standing in the cross-fire of the two groups. I’ve found these points:

• Accessibility and inclusive design has one massive enemy: bad communication

** A problem of communication channels

** A problem with language – keeping it simple is not an option

** A problem of attention span. Err, what?

** A problem of adoption speed

** A problem of selling the issue

Read the full post here

I’ve met with the lovely people from Gamelab and the Metropolitan University on Friday and we finalized the details of Scripting Enabled.

Scripting Enabled is a two day event in London on the 19th and 20th of September 2008. The goals of the event are:

• to build accessible interfaces to currently inaccessible services,
• get hackers and non-technical people who know about accessibility problems to talk and
• release documentation and tools based on real issues to make the web a more inclusive place.

This event is separated into two different parts and you need to book separate tickets!

The first day is dedicated to getting real information about accessibility barriers of online systems and techniques to work around them. This day is for:

• Developers that will come on the second day to find out what needs building
• Anybody who wants to learn about accessibility barriers from those who get blocked by them and not from theory
• Anybody who wants to share their experiences in being blocked out from online services because of their ability

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.

This day is for:

• Developers that want to build truly accessible interfaces and legal hacks around currently inaccessible systems
• People that can give real information based on research and user testing to hep developers build the right things
• Testers that can give us a real user experience rather than having to simulate it.

Go and book your tickets now

This is a short explanation as to what I consider a good way to make online video accessible. I’ve based it on research done to create the Easy YouTube Player. There are no code examples in this article – only links to solutions that are already in place. We will tackle the issue of a sample framework for accessible online video at Scripting Enabled

Online video is a great thing, no doubt about that. Not a day goes past where millions of people on the web spend time watching tutorials, screencasts, instructions, TV shows, movies and yes – monkeys falling out of trees – online.

The problem is that whilst video can be highly inclusive – as shown in this example of a deaf chat room – it is also alien to the technologies the web was built on.

Video is a stranger to the web (for now)

Browsers do not have any native video display yet – HTML 5 is going in that direction but it’ll take some time until all browsers in use support that. In order to play videos on web sites we need to rely on other technology embedded into web documents – so called plug-ins.

Plug-in technology came and went over the years, there was RealPlayer with its infamous “buffering” messages, Quicktime with its amazing difference in quality between Macs and lesser fortunate computers, Windows Media player with its inability to play on other platforms than Windows (until lately, that is) and a plethora of Linux geek formats – OGG, Matroska and the like – all of them free, open source, full of great ideas and lacking any significant adoption and market share.

You can use any of these to create online video and they all come with good authoring tools – most of them on the expensive side – but if you really want to make your life easier, use the plug-in that left all of the others in its wake in terms of market adoption and cross-platform portability: Flash.

Flash – aaaaaaaaaaaahhhhhh, saviour of the internet?

YouTube and other online video sites showed that the main trick to reach millions of users and consumers out there is to make embedding video information as easy as possible. Most of YouTube’s views and traffic comes from outside their network from embeds in blogs, news sites and other web sites. With Flash being very much on almost every computer it’d be almost criminal not to support it. Monopolies are never good, but lately Adobe has gone leaps and bounds in making Flash more available to third party developers and in terms of internal structures and APIs many another technology can take a leaf out of their book. And of course we have Silverlight to battle this monopoly in the nearer future – let’s hope Microsoft take the Flash learnings into consideration.

The Flash video format (FLV) is tailored for web use – small, streaming, allowing for captions and sound and video separation – it simply makes a lot of sense.

So we have the technology, we have a good format, what keeps us from creating inclusive video?

Failure to focus – browser and plugin and assistive technology not sitting in a tree

The problem with Flash and accessibility is not necessarily the system itself – it is the communication of browsers with plug-ins. These things being alien to the native environment of HTML, we have once again to live with vast differences in implementation across browsers. If you open the flash movies directly in the browser, this is less of an issue, the problem is embedding them into HTML documents. This is what we constantly do though to ensure that search engines can find our sites as until recently Flash content wasn’t indexed by them.

Microsoft, with Active-X as the poster child of amazing productivity and interaction between standalone apps and the web (and allowing many a virus and Trojan to run free) did actually a very good job in allowing communication of Flash, MSIE and assistive technology.

In Firefox, on the other hand, you cannot use your keyboard to tab into a Flash movie. You can set and release focus in Flash and tab around movies, but somehow it is terribly flaky and a lot is down to luck – or sticking to Internet Explorer and Windows.

The latter does not sit well with me. Firefox has amazing accessibility opportunities and all extensions I have encountered so far are free. Why should someone have to pay lots of money just to access the web when I can buy a 100 pound (or 200 US Dollar) laptop, get Linux and Firefox or Opera and go for it? Apple computers come out-of-the-box with voiceover as a screen reader, why not Windows?

Anyways, back to the focus issue. Whilst there is a good visual clue that something is focused in Flash this does not necessarily mean assistive technology will know about it. This is a problem, and a lot of people also don’t like this to happen – do you know how many times you get asked as a web developer to “remove the ugly border around links when you click them”?

Avoiding the focus issue by creating the browser-plug-in communication

The way around most of these issues is to allow your Flash to be controlled by JavaScript from the outside by providing an API into your players. This may sound totally ludicrous – after all accessibility experts have told you for years that both Flash and JavaScript are evil, right? Bear with me though, cause here are the reasons for advocating both JavaScript and Flash interacting.

Progressive Enhancement

Using JavaScript I can test what a browser can do before I ask it to “make it so”. I can add a link to a video file in the browser and only add a player for it when and if the browser supports it (or even the user specifically asks for it).

Embedding Flash can be tricky, as – you might have guessed – not all browsers do it the same way. Therefore it is a good idea to use an abstraction tool like SWFObject to include your Flash. This means we are already depending on scripting to embed Flash, which has the practical upshot that we automatically know that both are available.

Solid interaction patterns

Using the DOM and JavaScript I can create HTML elements that work with all kind of assistive technology. Instead of hoping that keyboard users can access my Flash content I use what browsers already have – links, buttons and form fields – to interact with the it.

Possibly fixing the keyboard access problem

Technically you should be able to fix the tabbing-into-Flash issue by having a method in your Flash movie that focuses a certain element. Then you can create a text link that calls this method to “skip into Flash”.

Easing maintainbility

Developers that know HTML, CSS and JavaScript are not hard to find (well, really good ones are). You also don’t need Flash installed to edit HTML, CSS or JavaScript. Therefore it does make sense in terms of maintenance to keep as much of the constantly changing elements of an application or player outside of Flash. Having for example all your text labels in an external XML file makes it much easier to localize your player. If you mix Flash and HTML you will most likely have a system to maintain the HTML with. You shouldn’t have to use yet another one to maintain your Flash apps.

Piggy-backing on the browser

When the first Flash applications came out people talked about a revolution in web-based Rich Interface Applications. Instead of having to show hard-to-style form elements and non-scalable graphics and links we had a vector-based interface at our disposal and could create any application and interface element we wanted to create. Somehow Ajax put a dent into this some years later (and it is pretty amazing how many Ajax problems can be solved when you look at solutions Flash developers found for them long ago) and one of the reasons was that the HTML interface – whilst ugly and hard to style consistently – simply works.

HTML is much more than just a visual representation. It is an interactive layer describing what certain elements are and what browsers should do with them supporting a multitude of input devices.

Furthermore the browser notifies all kind of other software when users interact with HTML elements like links and buttons. Just try to create something as seemingly easy as a scroll-bar yourself and analyze all the interactivity both in terms of content to scroll and keyboard controls to support – it is not easy.

Therefore it does make sense to use HTML elements to drive Flash players – the base user interactivity has already been created and tested for you by browser manufacturers.

What to use then? How do you write a player?

The good news is that you don’t have to write your own player, as there are several options already out there.

• If you want to use YouTube content, you can use the “YouTube player API”:http:// to control the look and feel of the player.
• If you want to host video yourself, there’s the JW media player which does not only support a lot of formats and has an API to control it, but also has support for captions and other accessibility enhancements. Jeroen will be in London for Scripting Enabled and we’ll take a closer look at what we can do together.

Even if you don’t want to use the players themselves you can in the JW case look at the source and get your inspiration from that.

Summary

• Use what works – offer a description of the movie, maybe a thumbnail and link to the movie file explaining the type and the size inside the link
• Use JavaScript and SWFObject to turn this into a playable movie when and if the browser supports it
• Instead of relying on the player controls to be accessible, create HTML controls that drive the player using the DOM and a player API.
• We will create proper code examples for all of this at Scripting Enabled.

I have to thank Antonia Hyde, Mike Davies, Artur Ortega, Benjamin Hawkes-Lewis, Jacob Seidelin, Ian McBurnie, Steven Webster, Dirk Ginader and Jeroen Wijering for great input and their research on the matter. I’ve been asked to put this together by Kath Moonan/AbilityNet and Julie Schiller/BBC and hope this will be beneficial for all.

It is quite interesting to see that several products right now try to crowdsource accessibility. IBM released their social accessibility project and another project caused quite a stir in the accessibility world: WebVisum.com.

The latter is a Firefox3 extension that ties in with Screen Readers to allow users to enhance pages they have problems with by adding the correct meta data while surfing the page. The more controversial feature of WebVisum though is that they also provide a CAPTCHA recognition service in the tool.

I’ve caught up with Marc Dohnal from WebVisum and asked him a few questions about the product:

• Interview with WebVisum.com

It is scary how some obviously bad practices refuse to go away and developers jump through hoops to defend them and make them work rather than using simpler alternatives.

My pet peeve is the “chess rules” select box (you touched it, it needs to move):

Yahoo
B3TA
Google

Yahoo

B3TA

Google

This is the most evil permutation of this interface idea. A lesser evil version is part of a large form that will change the rest of the form or – if we venture back into more evil lairs – submits it to reflect these changes.

The arguments for this interface are not many:

• It saves the user one step of pressing a submit button
• The action is immediate

(Ok, these are actually the same argument, comment if you know some.)

The drawbacks of the solution are immense:

• People that use a keyboard will submit the form or leave the page without having selected the right option.
• People that are dependent on using a keyboard for web access will possibly know that you can press the Alt+Arrow Down keys simultaneously to expand the whole dropdown before selecting with arrow up and down and enter.
• Most people won’t know this though and a lot of people use keyboards and tabbing from field to field to fill out forms.
• Forms are a terrible annoyance of our times – nobody likes filling them in. Most of the time we won’t keep our eyes on the screen but actually look up information on papers, our credit card or read up the fine print that – of course – is not on the screen but only in the letter we got sent.
• I have no clue how something like that works with switch access or voice recognition – probably not
• It is scripting dependent – no JavaScript, no service

The latter is actually a reason for some companies for using this from time to time. Too many links on the same page are bad for SEO - Google considers your page not content but a sitemap and ranks it lower. That’s why some companies start offering the first two levels of navigation as links and the rest as a dropdown in this manner.

However, that still doesn’t make them a good solution, it just means that you offer far too many options to your users to begin with.

Here’s what people do to make this work: Aaron Cannon on the WebAim mailing list

A coworker and I recently devised a way to make a slightly more accessible version of the onchange dropdown navigation box. Basically, using javascript, we determine whether they are using their mouse or the keyboard to select each item in the list. If they used the mouse, it works as usual, immediately taking them to the selected page. If however the selection was made by the keyboard, we display a spinner and delay x number of seconds. If the user doesn’t make another selection within that time, they are taken to the page they selected. If they do, the clock is restarted.

I am not attacking Aaron here, he probably was asked to find a solution no matter what and did his best to find a technical way. The big scare in this for me is “determine whether they are using a mouse or keyboard”. My guess is they check for the event type, but assistive technology like voice recognition must simulate clicks without being a mouse. The other danger signal is the timer and the spinner – this complicates the interface even further (“Is this loading?”).

I simply don’t understand why we constantly try to make things work because this is what the design spec says or this is what we saw somewhere else. How about really testing it with users and see what happens then?