Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for July, 2008.

Archive for July, 2008

Yet another rant on accessibility and usability

Wednesday, July 23rd, 2008

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

Scripting Enabled Venue and Tickets are now available!

Monday, July 21st, 2008

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

So you want to create accessible online video, huh?

Monday, July 21st, 2008

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.

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.

Again with Ajax Accessibility – my talk at AbilityNet in London

Thursday, July 17th, 2008

Today I went again to help out AbilityNet with one of their workshops talking to a small group of developers and project managers about the problems with Ajax and Accessibility and general Web2.0 concerns. Instead of giving a lot of technical details I tried to point the audience to good resources and get them to find out more for themselves. I hope I succeeded.

[slideshare id=514640&doc=ajaxandaccessibilityredux-1216171321459432-9&w=425]

For the first time I also successfully recorded the talk in mp3 format using the mac powerbook. GarageBand is great for recording, but the editing features suck, good old Audacity came to the rescue. Bear in mind I had 4 hours sleep and a day of presentations behind me when I did this one, and it is more fun to see me explain some of the pauses with gestures :)

WebVisum.com – crowdsourcing accessibility

Monday, July 14th, 2008

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: