While demand for the mobile web is growing, mobile web content is yet to mature, with many problems of usability and accessibility that are reminiscent of desktop web content ten years ago. Added to this are the specific problems associated with mobile browsing such as size of screen display (viewport), handset capability context (being outside, in noisy places, differing light, time restricted), and technology support (lack of JavaScript, Flash, CSS cascading stylesheets and so on).

Grab a copy of the article in one of the following formats (sorry, no HTML):

• Word (new window)
• PDF (new window)
• ODT (new window)

Daniel-san very sweetly dedicated to this to me (thank you!) which I’d like to in turn dedicate to Jack Pickard who passed away over the weekend. He was a great advocate for accessibility, a voice of reason on Accessify Forum not to mention a thoughtful story teller, family man and Newcastle FC supporter. Ian Cuddy has written a tribute to Jack.  You’ll be missed.

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!

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