iheni :: making the web worldwide

I forget that at its core the web is all about  ”search” so it was humbling and eye opening to spend two days in the company of 8 silver surfers aged 60 to 80 testing  Opera desktop and observing, amongst other things, how they went about carrying out searches.

It’s more or less the first skill you learn when you’re new to the web (our testers had between a month and 18 months experience each) and by far the most essential. It took me right back to how I felt when I first used the web and it was fascinating to watch how people tried to differentiate between web content, a browser and a search engine, often getting it wrong but for entirely for logical reasons. Our testers all came from the analogue world with little or no experience using computers.

So here are a few rough findings around the subject of search for older users new, or relatively new, to the Internet.

First let me describe the set up.

We had a vanilla install of Opera 10.10  with www.bbc.com/news set as the home page. We left the side panel open not because we were testing it as such but because we were curious to see how people used it when carrying out tasks. Finally we removed all additional toolbars that a user would not typically have.

The BBC search field centered at the top of the page below the browser address box.

Website search versus the browser address field

All participants had a hard time distinguishing between the search field in the web page (positioned top-centre just below the browser address box), the browser address box and the browser search box. When asked to look up www.tesco.com most would write the URL in the BBC search field and hit search.

When this didn’t work people would eventually venture up to the browser address box and start typing there  often typing text in the middle of the BBC URL.

Text typed into existing text in the browser address box

Others would click in the browser address box, highlight the existing URL then not know they could over-ride it by either writing  or using the ‘delete’ key. Only one tester knew to use the delete key. Not using the keyboard for anything other than typing text was a common theme as this group seemed to rely totally on the mouse to get about making me wonder if using a keyboard was only relied on when it had to be. I also had a sense that having a URL address box populated with text put people off using it.

The main, and obvious issue here though was people not being able to differentiate, or understand what the browser was and what web content was. The focus was very much on content with the browser menus and features ventured into as a last resort. This is something that we’ve already come a cross before in tests and is not an issue restricted to just this group.

Browser search versus website search

Very few of our testers ventured to the browser search box opting instead to use the search field of the site. When they did there was a degree of confusion around what the field did. Most looked for a ‘Go’ button and in lieu of that accessed the drop down menu (showing various search engine options).

The browser search field and drop down menu of search engine options

It was clear that typical user behavior was to take the hands away from the keyboard and use the mouse to hit ‘Go’. In other words hitting ‘Enter’ was not commonly known linking back to this groups preference to do everything (bar typing text) using the mouse.

Using the Home browser button

When testers got lost default behaviour was to go for the browser ‘Home’ button or, in a couple of instances close the browser and start again. I’m really glad I saw this as I’d all but written off the ‘Home’ button as a bit of browser UI clutter (based on personal and peer preference admittedly).

Given the combined preference to set Google search as the home page and the almost universal avoidance of the browser search field this made a lot of sense.

“Where’s my Googlebox?”

As we worked with more testers it became evident that the preferred home page of choice was Google search. This may well account for people confusing the BBC website search field for the browser address box.

My Mum in law first brought this to my attention when, after we’d just set her up with browsing. I heard her shout in absolute frustration from the other end of the flat:

WHERE’S MY F@^&ING GOOGLEBOX?!

That’s when I realised that familiarity is key and having a ‘safe’ place to start from and return to makes all the difference when starting out with using the web. It all links into the confusion between the browser, web page and definition of what a search engine is. Being able to search the web from the browser is a hard concept to grasp and understanding that the browser is not the web page, or vice versa, problematic.

This is of course the tip of the iceberg (and only part of what we looked at during our testing) but I remain convinced that we have a lot to learn from this group. Some of the issues and barriers they hit I’ve seen seasoned users stumble upon and I think if we are going to make truly usable websites and browsers we need to go back to the source and learn from new and older users.

A big learning point for me, with a developer hat on, is to consider how your content works within the context of the browser – something that is rarely considered, if at all. This was evidenced by the placement of the BBC search field in the top centre of the page under the browser address box. While I don’t think BBC are wrong it is something that is worth considering especially given they are such as well known website (globally) and is prone itself to being confused with a search engine.

A second learning point was to not fall into the trap of making assumptions. Not everyone knows what a browser is, not everyone uses the keyboard for simple shortcuts (including ‘Enter” and ‘Delete”) and what we may think as logical as a result of doing something repetitively may not be to others.

A big thank you

We couldn’t have done these tests without the wonderful Digital Access Media Group at Dundee University, especially David Sloan. David provided the space, facilities, and hospitality for us and the wonderfully helpful participants who were great company as well as fantastic testers.

Thank you also to Lawrence Eng from Opera who flew in from San Diego especially to lend his extensive knowledge of Opera and user behaviour to the project.

We hope to do more testing and are already looking at how our findings can influence decisions on improving browser features and accessibility. Watch this space!

Tags: user testing

The genius that is Mathew Smith (@smiffy) coined the  term Accessibility As An Afterthought in relation to WCAG Triple-A (ok so the clever among you will spot that it’s four A’s) over Twitter this morning and I couldn’t agree with him more:

AAAA (Accessibility As An Afterthought) seems to be pretty much standard MO for Google.

Triple-A (AAA) is the highest conformance you can claim in WCAG 2.0 with Single-A (A) being the basic and Double-A (AA) being the norm. Triple-A is generally seen as a nice to have with Success Criteria that you aim to achieve if it’s do-able.

Smiffy is right when he says sites or clients aiming for Triple-A are doing so an afterthought or because they really don’t know what it is they’re asking:

• AAA is an aspiration, not a realistic goal. Go for Double-A with what Triple-A’s you can fit in
• As the Not-so-evil Jim O’Donnell says “Was just thinking this morning how AAA compliance may be a good sign that a site hasn’t done user testing.”
• A client requesting AAA conformance clearly has not read WCAG 2.0 and what it has to say on conformance:
  

  It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

Hat tip to ya Smiffy!

"Please install the paper dispenser so people can reach it without falling off the loo."

Image courtesy of  Austin ampersand Zak

If your (X)HTML is valid and your ARIA is valid, your document is valid, so don’t worry about it. No harm, no foul.

Jared Smith, from WebAim, posted his excellent slides on the accessibility of Rich Internet Applications presented at Accessing Higher Ground Conference. In them he maintains that if your (X)HTML is valid and your ARIA is valid then you need not worry about passing validation tools which currently have varying or no support.

This poses problems for developers who want to validate their code whilst making pages as accessible as possible. As Mathew Smith (@smithytech) commented:

I’ve been retro-fitting the ARIA stuff with JavaScript to get round the validation problem. Best not to care about validation?

John Foliot’s pragmatic response was:

@smiffy problem is that the validators aren’t wired for ARIA, but removing ARIA for validation is worse. Practical results vs. purity = win!

The Mighty Steve Faulkner has already gone into detail about this in how can I validate (X)HTML and ARIA so I wont repeat what’s been expertly covered but I’m curious to know what this means to you: working on websites in the real world how does this impact your design decisions and code choices? Does validation go out the window or does pragmatism prevail?

(Twitter is lovely but useless at tracking threads – if you have comments why not be old skool and leave a comment here).

Tags: (X)HTML, validation, WAI ARIA

The World Health Organization estimates 278 million people worldwide have some form of hearing impairment.

A Nielsen study suggests that there has been over a 300 percent increase in online video watching since 2003. Further, most watching is done during work hours. Workplace computers are often muted or have no speakers.

Several billions of videos are watched monthly worldwide, with many of them in different
languages.

See 22frames.com for more about this.

I had my first foray into captioning this week for a short video that a colleague Daniel Davis (@ourmaninjapan) did on remote debugging with Opera Dragonfly and Opera Mobile 10 to mark the release of Opera Mobile 10 Beta (go try it, it’s free).

I’m slightly pink faced to say I’ve not done any captioning before having always opted to transcribe video and audio so I had to start from scratch sourcing the right tool and figuring out how to go about editing and setting up a process. Whilst I set out to caption a video my purpose was also to see how easy or difficult it was as captioning is the poor cousin of accessibility considered to be expensive, time-consuming and only relevant to hand-full of people.

Before I launch into my findings below is the final product captioned in English, Japanese and Russian using  Overstream and hosted on YouTube. Big thank you to Daniel for the translation and original video and Vadim for the Russian. You can also watch the video on Easy YouTube.

There’s also a hidden Easter Egg in there, see if you can spot it.

Captioning benefits

Accessibility – this is the obvious benefit as you’ll be opening up your content to deaf and hard of hearing users as well as people find it easier to read rather than listen (or do both together). If you don’t have translated captions some non-native speakers may also find content easier to consume when reading captions.

Localisation – adding translations to your captions widens your potential audience massively. There are plenty of tools out there such as dotSUB that enable you to crowdsource translations and many hosts such as YouTube which support multiple caption tracks.

Mobile – users with mobile phones who may not have earphones or are in a noisy place also benefit. I do wonder how much can be visible on some small screens but certainly some people will find it useful.

Search – site indexing may also get a boost. For example YouTube supports video searching of caption data which also filters through into Google search.

Getting the right tool

There are more captioning tools out there than I’ve had hot dinners so I thought I’d narrow it down scientifically and just ask over Twitter what people recommended. My only stipulations were that it had to be quick, easy and free (what else!).

CaptionTube

I gave Google’s web based tool CaptionTube a go first. It’s super easy to get started as you just use a Gmail login and from there you upload video from your YouTube collection. So far so simple.

What I didn’t find so intuitive was the captioning interface itself. When dropping text into the timeline I wasn’t able to clearly see when text started and ended as the end time was measured in how long the segment was rather than when it stopped in the overall timeline. This just didn’t work for me.

The CaptionTube interface fails to show captions overlaid the video

In addition to that I had to flick between the Timeline and Preview screens to see the captions I’d just created overlaid on the video. With pages taking a time to download, not to mention breaking the rhythm of what I was doing, this really held me back. Too much buffering for my liking.

Overstream

Being a newbie to all this I wasn’t sure if I was expecting too much or missing the point but after a chat with Antonia Hyde – who knows a thing or two about accessible multimedia – I decided to switch to Overstream which had originally been recommended by AbilityNet.

This was altogether a lot better plus Overstream support a number of video providers: YouTube, Google Video, MySpace Video, Dailymotion, Veoh Blip.tv and Archive.org. It was pretty easy to upload a YouTube video but equally easy to miss a crucial instruction that you need to have the video in question playing in YouTube when you hit the upload button.

Overstream shows the edit box and video with captions overlaid on the same page.

The interface gave me much more of an integrated toolbox and by now I had an idea of what I wanted which helped. One huge bonus was being able to add text to the timeline, complete with start and end times, adjust time lengths and see in real time the text overlaid on the video on the same page.

I had a few problems trying to play the video once done in a new window with a URL warning popping up but it was easy enough to download the .srt file (with all the captions and timeline in) and upload that in turn to YouTube.

MAGpie

Next on my list to try is the downloadable tool MAGpie, from the National Centre for Accessible Media. I didn’t try it this time as Overstream got the job done plus MAGpie supposedly doesn’t play nicely with Intel based Mac’s. I did have a quick look at it however and while very clunky and old looking it does give you an the option to style captions which looks pretty good. I’ll be looking at this in more depth when I next caption something.

Stanford Captioning Service

John Folliot pointed me to Stanford Captioning Service which looks like an excellent service. All you need to do is upload a video file which then is put in multiple formats – FLV, MP4, MP3. These are then transcribed by Stanford contractors for a small fee. When the transcription is done Stanford do automatic timestamp generation to turn transcript into various formats – this part is free.

For my short video I was happy to transcribe and caption the audio myself but if I had longer videos to get caption I’d almost certainly use these guys. Victor Tsaran, head of accessibility at Yahoo!, used the Stanford Captioning service to caption a video about himself recently.

dotSUB

Lastly I dug out my login to dotSUB, who’s main selling point is enabling subtitling of videos on the web into, and from, any language. It’s also a collaborative tool so you can crowdsource community input and/or work collaboratively with your team to get the captions done. Of the tools tested this was by far simplest and easiest to use. 

Captioning tips

As soon as I got started I realised that I needed to have a process as to how I approached doing the actual work. Here are a couple of things that worked for me – let me know if you have any more worth adding to the list:

• Transcribe text before you start captioning – you can do this yourself, pay a professional to do it or use voice recognition. Even though the last two options are less labour intensive you will need to edit and double check text – especially with voice recognition.
• Break it down – once you have your transcript you’ll have a clear idea of the volume of words and quality. You can then break text into short sentences that fit on screen without obscuring too much of the screen real estate. All I did was use a text file and hit return after short sentences or natural breaks in a sentence. Once I started adding text to the timeline this had to be reworked as I went along but having it already drafted was a big help.
• Editing text - if you have a text that works verbatim then great, but this is unlikely and there’s nothing wrong with removing repetitions or false starts to sentences. The key is to keep it succinct while maintaining the original meaning and flavour of the language as well as the character of the speaker.
• Punctuation – I found that less is more. Obviously you want full stop at the end of sentences but Andrew Kirkpatrick, head of accessibility at Adobe, recommends removing commas at the end of lines. We don’t ‘see” punctuation when we hear people so visually breaking text down like this makes sense to me.
• Timing – you can create a bit of drama, suspense and humour by remaining faithful to how people speak and using timing to replace tone. For example, someone getting excited may talk in short sentences so break the transcript down so that it is given in short segments rather than having longer segments.

Check out captioning tips from the WGHB Media Access Group, captioning tips and tools from NCDAE and W3C Multimedia FAQ for more.

How long did the whole process take?

Captioning the 4.27 minute video took be the best part of 10 hours BUT this included researching tools, false starts as well as a bit of reading around the subject. If it’s a long video you definitely want it to be transcribed for you but if a short one like this you could estimate 1 to 2 hours depending on your typing speed and how audible the sound is.

After that, once you have the hang of adding text to a timeline you should be ok. I added text and allocated times as I went along but you can add text then allocate time second if breaking the two tasks work better for you. This probably took me about 1.5 hours.

All in all I’d average out a 4 minute video at 3 hours – but this will no doubt get better as it becomes more familiar.

It’s a bit fiddly to start with but smooth running once you get the hang of it and seeing the end result is completely worthwhile. It’s satisfying to know that the captions will help not just deaf users but also non-native English speakers as well a people looking at video on their mobile phone.

Update 20 November 2009

Google have just announced automated captioning of YouTube video which will include automatic time stamping as well as transcripts. This should be available soon and will have a huge impact for many users as well as influence in promoting captioning overall.

Tags: captions, tools, video

WebAim released their 2009 Screen Reader Survey last week, a follow up from last years Screen Reader survey. Very good reading it makes too but of particular interest are results around screen reader choice on the desktop and increased screen reader access on mobile.

For years it’s felt like screen reader users have mainly used IE on the desktop in combination with the major screen readers Jaws by Freedom Scientific and WindowEyes by GW Micro. It’s not that other platforms don’t support screen readers (we have Orca on Linux, VoiceOver on Mac) it’s just that IE seems to have dominated.

As such what types of content and web technologies users can and can’t access has very much been driven by what the three software vendors Microsoft, Freedom Scientific and GW Micro have supported. This has made access to the open web a bit lopsided cutting down on choice for the end user, competition and by extension innovation. SVG is an example of a web technology that has possibly suffered by not being supported by IE and in turn by Jaws and WindowEyes.

What’s interesting to see in this year’s survey is that Jaws and WindowEyes – while still the most used – have some stiff competition at snapping at their heels from open source, free screen readers (NVDA and  SAToGo ) and VoiceOver which is available with Mac:

• JAWS 75.2%
• Window Eyes 23.5%
• VoiceOver 14.6%
• System Access or System Access To Go 22.3%
• NVDA 25.6%

While this year’s stats show little shift for Jaws and WindowEyes usage overall there is a significant leap forward for NVDA (NonVisual Desktop Access) and VoiceOver:

Of the 1121 respondents, 74% use JAWS, 23% use Window-Eyes, 8% use NVDA, and 6% use VoiceOver. While several other screen readers were reported, these were the most prominently reported.

The upsurge in VoiceOver could be explained in part by iPhone now providing VoiceOver support; all of a sudden there is a very real reason to switch to Mac if you can use a screen reader you are familiar with on both your desktop and mobile.

This could also explain the increase of screen reader users on mobile reported this year with 53% of survey respondents with disabilities confirming they use a screen reader on a mobile device. This is up from 12% last year (although last year’s survey doesn’t distinguish disabled from non-disabled users).

I wonder how much this is to do with the ‘iPhone Factor’ but also can’t help thinking that social networking has done for the mobile web what Kylie Minogue did for Agent Provocateur – everybody wants some. And for me at least 2009 feels like the year that we all sat up and paid attention to the potential of mobile for people with disabilities.

We’re still faced with one massive problem with mobile access however and that’s the lack of an open, cross platform accessibility API that mobile screen readers can hook into. On desktop we have IAccessible2, MSAA and UI Automation (amongst others) but on mobile users are tied into one platform often only supporting one browser (such as iPhone, Blackberry RIM and others) so while desktop has opened up we find ourselves in a 1990′s type impasse with users left with little room to choose on mobile. Opera works well with VoiceOver but we have no way of telling if it works on the iPhone as it’s not supported. My hope is that with more users there’ll be more momentum behind breaking this stand off and opening up the market and ultimately giving users not only choice but portability between platforms.

It’s good to also see the free, open source NVDA on the up. They’ve worked hard to include WAI-ARIA support and are becoming a key tool for web developers when testing. The Jaws demo version used to be popular among developers but with the license becoming less developer friendly NVDA is becoming a safer option.

It’s early days but the rise of VoiceOver and NVDA combined with alternative browsers such as Opera, Safari and Firefox may break the hold that screen reader giants Jaws and WindowEyes have over the market, helping to open up competition and with it how fast screen readers innovate in supporting new technologies such as HTML5, SVG and so on. This will be a win all round for both users and developers.

Update 12 November, 2009

Jared’s presentation The Legend of the Typical Screen Reader User summarises many of the points above. He also includes quotes from screen reader users at the end in response to the question “What suggestions do you have for developers/manufacturers of screen readers?” which he mentions in his comments below.

Mobile accessibility resources:

• Fluid mobile accessibility wiki
• Open Letter Initiative

Tags: mobile, screenreaders