Last Tuesday I attended a training day run by AbilityNet in London on the topic of Rich Media. The day covered a range of topics concerned with Rich Media and Accessibility and I’d thought I would share a few thoughts from what was covered here.
An Introduction
First off, Kath Moonan of AbilityNet gave an introduction to Rich Media… she explained about the benefits of Rich Media for web users with a learning difficulty and I would definitely agree with her that visual content can often actually be easier to understand for many web users.
Kath made the point that with the way the web is now moving the users missing out the most are the hearing impaired… this led the focus of this session into being largely about transcription and captioning for web video and audio.
Text Transcripts
Transcripts are an alternative text version of Rich Media and do not have to be exact accounts of spoken word versions. You can make a transcript as accessible as you want and add extra information. It seems that transcripts of video or audio are best provided as HTML (semantically marked-up) or as a .txt file.
Text Captioning
There are basically two types of captioning: ‘Closed Captioning’ – like the TV teletext style and ‘Open Captioning’ where the captions are embedded in the actual video file.
It seems that the best method to use on the web is ‘Closed Captioning’. A free software tool called Magpie was demonstarted as a way of captioning Windows Media Player files… it was also covered later in the day that Magpie could also be used to create captioning with Flash video files.
One important point I picked up at the training is that when dealing with Rich Media as a website owner you will have to offer different versions of content. Currently 90% of users have the Flash plug-in but you should also probably offer video content in Windows Media Player and Apple Quicktime Formats.
The importance of explaining Rich Media properly on websites came out as a theme in this session and it is clearly important that we explain to users about any plug-in’s they might need to be able to view Flash/WMP/Quicktime files and how they can easily set this up within their browser. A simple thing like a missing plug-in could provide a real block to some users trying to access Rich Media content. Kath gave a really good example of how in In Windows Media Player you actually have to turn accessibility features on so users need to be shown somewhere how to do this.
The logical solution is surely that it would be good for all websites to actually include information about accessing Rich Media as part of the sites accessibility statement/page as a minimum requirement.
Audio Captioning
The ideal scenario when producing video for your website seems to be to provide captioning and a written transcript. You only have to provide a separate audio transcript if you feel it is necessary to your users.
Flash Accessibility
In the next session Jon Gooday from AbilityNet looked at Flash accessibility… this continued on in a second Flash session in the afternoon.
I should say first of all that I don’t work with Flash and am not a massive fan of Flash based sites. That said, I would have to agree that Flash sites can actually be good for people with some disabilities. Unfortunately this has always been balanced with the fact that Flash has traditionally proved very hard work for those with visual impairments to access.
One very good example of good use of Flash we looked at that I would recommend checking out is British Sign Language website.
The one area that still worried me about Flash was when John looked at the built in accessibility features. I think the fact that they only work in Windows is still really disappointing and will prove a real problem if your producing Flash only sites.
As I’m not a Flash user I won’t go into more detail about the Flash sessions here other than to say that the recommended starting point for Flash and Accessibility is Adobe’s ‘Best Practices for Accessible Flash Design‘.
Ajax and Accessibility
Mike Isofarro from Yahoo arrived to speak at this session which was the highlight of the day for me. Ajax is a current area of interest for me and I’ve just finished reading ‘Bulletproof Ajax‘ by Jeremy Keith so this tied in nicely.
I intend to blog about Bulletproof Ajax sometime soon but Mike looked at some very similar ideas in this session with the key point being that the way to build Ajax functionality on your website is to use progressive enhancement. This means that if users don’t have Javascript enabled the site will degrade gracefully and still be fully functional.
When testing an Ajax enabled site you should test the whole site without CSS and Javascript enabled.
Dealing with no page reload
Mike looked at ways of dealing with the lack of page reload and mentioned the yellow fade technique and looked at how this would only work for visual users. He mentioned a technique to deal with screen readers by updating the screen readers virtual buffer which can work with Jaws 7.1 onwards – more information on this can be found on Jez Lemon’s website.
This technique along with many others still comes with some problems and won’t work with every browser combination/screen reader. Because of this I would agree with one of Jeremy Keith’s suggestion’s that you could add a hidden link to your site for Screen Readers at the top of your home page that enables users to turn off Ajax funtionality. If the Ajax functionality has been built as progressive enhancement on top of an existing working functional site the website will degrade gracefully and Screen reader users should have no problems.
Screen Reader Testing
One interesting point Mike made was that if you get a screen reader user to test your site don’t employ a ‘power user’. You actually want normal level users not people who test sites with screen readers for a living as they will actually manage to get around problems on your site that more basic users would get stuck with straight away. I’d actually never thought of this before and it makes a lot of sense.
For more details on Mike’s session and two really good case studies of accessible Ajax in the real world see his notes from this session that he has kindly posted up on his blog.
PDF Accessibility
This was another session from John Gooday at AbilityNet and I was surprised to learn that the RNIB are currently reporting that they are currently receiving more complaints about PDF accessibility than web accessibility .
Briefly, I learned in this session that the user needs to actively use the accessibility functions with Acrobat Reader which, as I discussed earlier, could provide a stumbling block for some users and you should really be explaining how to access PDF’s somewhere on your website.
It seems to be a lot more difficult to convert existing PDF’s into accessible PDF’s than creating new PDF’s and also seemed to be more difficult and involved than making HTML accessible.
Again, this is not an area I really work with regularly but like any website good structure is the key… a poorly structured document will basically equal a poorly structured PDF. If your using a tool like Microsoft Word to put together a document make sure that use the available semantic mark-up like H1, H2, H3 etc for your page structure/document styling.
Final Thoughts
This was a useful day out the office and had some really good information for me to get hold of… for the record AbilityNet training is of a very good standard and I would especially recommend some of their courses aimed at covering Accessibility issues and WCAG for Website Administrators and Managers.
Making Flash websites accessible still seems to me to be a difficult area to get involved with while using flash video on your website seems like a logical first step to try and get right.
All websites should be providing multi format video (Quicktime/Flash/WMP) as well as captioning and transcription services for users where appropriate while the production of transcripts alongside podcasts should also be considered.
The Ajax session was great and focused on progressive enhancement, something I want to blog about in more detail soon when I try to get together my own thoughts on Bulletproof Ajax.