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)

Read this article in Belarussian translated by Patricia Clausnitzer

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

Slides from my Techshare presentation is the mobile web enabled or disabled by design also provide background to this.

Panel on accessibility beyond the desktop and ‘one web’

• Lucy Dodd – BBC (Chair)
• Julian Hartly – Google
• Damon Rose – BBC Ouch!
• Veronika Jermolina – AbilityNet
• Greg Fields – Blackberry
• Me – Opera

Is one web possible with diverse users?

I enjoyed our panel which challenged the idea of ‘one web’ across devices whilst accommodating diverse users. Damon had some valid inputs saying that in the real world ‘one web’ doesn’t work for many disabled users who prefer .mobi sites not only on mobile but also on desktop due to their ease of use. This is an argument I hear often with m.facebook.com cited as a prime example as it’s less cluttered and more usable and accessible than it’s desktop counterpart.

My take is that because some disabled users prefer the mobile version of Facebook you can’t assume this is an argument against ‘one web’ as it could just as easily highlight the poor usability and accessibility of Facebook or <insert your site of choice here>. Instead we should be looking at better adaptation of content specific to delivery context using techniques such as progressive enhancement with media queries and adapting content with CSS.

I think Damon’s are important concerns and raise the real question which is how can we replicate what people like about mobile versions without resorting to versioning websites?

Step in personalisation. With the web everywhere we want to tailor content to suit context. Makes sense. This does not mean cutting or trimming actual content so that’s it not available but allowing users to choose what content they get on their device of choice. This can be done via the website itself and to an extent Facebook allows this by giving you options of what updates and notifications you receive in your timeline. If you allowed people to choose content order that would also help enormously on mobile.

The browser can also support personalisation by allowing you to set up different profiles when accessing content using the same browser of different devices. Opera Link allows users to sync bookmarks, speed dial, searches and notes touching on a respectable representation of what we can do to facilitate fast effective browsing. Imagine saving your fonts, colour combinations and other accessibility preferences that you could port across from desktop to mobile.

For this to truly work you’d need to be able to save different profiles to suit context. What I want in my Speed Dials on desktop, for example, may not be the same on mobile.

I’m beginning to see how innovations in mobile browsing to support universal access may just start influencing better desktop browsing and web design. On mobile you have to be more precise and targeted with content than on desktop as there is less accommodation for usability and accessibility error. The mobile context trumps assumptions of desktop such as a user is sitting down in a well lit place with no background noise and time on their hands to ‘browse’.

Maybe the convergence of mobile with desktop web design will have a positive influence on web design overall. Just as print informed web design when websites first appeared and desktop influenced mobile web design perhaps we’ll see mobile now inform desktop. Who knows.

Some very basic introductory slides and a transcript are available on slideshare.

Graded mobile browser support

Since looking into universal access on mobile what’s struck me is what little information there is out there for developers about deciding baseline technologies that are supported and what mobile platforms and browser support can be assumed. Unlike desktop where there is a finite amount of browsers to test for (although it may not seem like it at times) mobile is multiplied tenfold.

Yahoo’s! graded browser support helps developers framework what browsers and versions they should target on desktop. This got me wondering if we need something similar for mobile. Seeing as Chris Heilmann from Yahoo! was sat in the audience I thought I might direct the question at him during the panel (also mentioned over Twitter) and being the thoroughly top bloke he is he listened. I know many larger orgnisations will have this sot of information fed into the test plans but for the large majority of us we have to figure it out as we go along. Not only that it’s such a fast changing target that it’s impossible to keep up with on your own.

PPK seemed interested which gives me hope that I haven’t taken leave of my senses and I’d love to know what you think.

Check out Chris’s keynote Finite Incatatem – Accessibility is not black magic. Aside from being one of the funniest and most informative keynotes ever he flags some pretty cool innovations in the mobile and devices space from Wiihab, Nokia braille reader and iPhone accessibility.

Building universally accessible web apps – Greg Fields, Blackberry

I didn’t managed to take notes of the whole day but did capture some of Greg Fields presentation on making mobile web apps accessible. While not directly related to mobile browsing or the mobile browser I found a lot of what he had to say crossed over neatly with recommendations for making mobile content accessible and how we should look to the mobile browser to support access.

Below are a few bullet points of what he captured with a few comments from me – most of it is good common sense but never a bad thing to repeat.

1. Native UI library
2. Colour and contrast
   • Use of colour WCAG 2.0 1.4.1 – Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)
   • Colour contrast 1.4.3 WCAG 2.0 – 1.4.3 The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)
   • Avoid red green combinations
   • Don’t rely on colour alone for meaning
   • Use semantic colours

   I think use of colour coding can be hugely helpful in the same was grouping and layout can help sighted users.

3. Inherit global settings from the OS
   • Especially important on map applications
   • Don’t conflict with user defined settings

This reminded me of the work Brothercake presented and Standards.Next on HTML5 where he showed HTML5 forms could be stylable if browsers inherited the user’s settings from the OS. Styleable forms for HTML5 is something that we are asked about a lot at Opera and seems to have sparked a lot of opinion. If you have any ideas or suggestions then head over to Bruce Lawson’s blog and let him know what you think.

4. Error messages
   • Include description of the error and how to resolve it
   • Goal to prevent user making the same mistake again
   • Use active voice
   • Prompt a call to action

   No surprises here but always worth noting. Even WCAG have brought in provisions to version 2 outlining accessible and usable error messages and making sure they are accessible.

5. Focus placement
   • Use a visible focus outline
   • Align with the user’s mental model

   Important for all users across devices. I would add to this to not be tempted to suppress outline within the browser and where a:hover is used also use a:active (to keep IE and mobiles happy) as well as a:focus.

6. Contextual menus
   • Most used application of frequently used option is in focus
   • Builds trust and decreases time to access content
   • Good user perception “It just works”

   Again no surprises here as it is a core principle of good web design on desktop but something to consider when allowing users to personalise content perhaps.

7. Consistency
   • Navigation, presentation, interaction methods must be consitant
   • Make the mobile app familiar to the desktop experience

   Most sites are pretty good with consistent navigation but can slip when it comes to consistent user interaction I find. Making the experience familiar to the desktop also builds trust in the user and confidence in what they are doing on the mobile.

8. Progressive disclosure
   • Inform the user of the number of steps in a task

   Something as basic as this can help users calculate how long a task will take – essential when on expensive mobile payment plans as well as multi-task where needed.

9. Grouping and chunking
   • Organise info based on type, meaning and so on
   • Limit option to 3-5

   This should help users pre-process information and enable them to complete tasks without having to think.

10. Keyboard access

Greg skipped this slide due to time and went onto list resources which I thought was a bit of a shame (you can always reference resources after). Keyboard navigation is key and I do cover this in my Techshare presentation ‘Is the mobile web enabled or disabled by design’ (post following soon).

Earlier this year Jakob Neilson said that the the mobile web 2009 mirrors the desktop web 1998 highlighting how hard it is to browse on a mobile. He’s right of course, mobile browsing can be frustrating and tiresome at the best of times. His solution however is to design not just ‘different websites’ for desktop and mobile but in the case of ‘moderately rich sites’ build ‘two mobile designs: one for low-end cellphones and another for smartphones and big-screen phones’.

Sound like unnecessary hard work? I think so. It also hints at repeating the mistakes of desktop web design circa 1998 where we thought the answer was to design for one browser, use proprietary technology, build text only websites for disabled users…the list goes on.

So let’s not make that same mistake and instead fast forward to one of the principles of good web design that dug us out of the dark hole of 1998: progressive enhancement. Add to that one of the biggest problems we face on mobile today, varying viewport sizes, and we have a good case for one website fits all.

Accommodating the multitude of different screen sizes is tricky and unpredictable. Mobile browsers try to work around this by offering a desktop view (which renders the whole site and is zoomable) and a mobile view (where content is rendered as a single column with some CSS stripped out). You can try this for yourself using the Opera Mini Emulator or looking at the screen shots below.

The image above shows this site as seen in desktop mode on Opera Mini. The square on the top left can be activated (using either a keypad or touch screen phone)  so that the area within the square is scaled up to fill the viewport.

This second image shows my site rendered as a single column of content. Some of the CSS has been stripped out so that there is basic styling and limited images. Note: screen shots were taken using an emulator for Opera Mini 4.2 which doesn’t have as good CSS support as Opera Min 5 beta.

As a developer you should never rely on the mobile browser to fix content rendering problems that arise from design so you need to find ways to accommodate varying viewport sizes yourself using techniques such as CSS 2.1 media types.

Media types are style sheets or styles tailored for different media such as ‘print’, ‘screen’, ‘aural’, ‘braille’, ‘handheld’, ‘print’, ‘projection’, ‘screen’, ‘tty’, ‘tv’, and ‘all’. You’ll notice that not only do these include special outputs for handheld and mobile devices but also braille and tty making them a handy accessibility tool too.

Media types can be easily added using stylesheets as follows:

<link rel="stylesheet" type="text/css" media="screen" href="sans-serif.css">
<link rel="stylesheet" type="text/css" media="print" href="serif.css">


Alternatively you can declare that sections of your CSS apply to certain media types within existing stylesheets using @media:

@media print {
body { font-size: 10pt }
}
@media screen {
body { font-size: 13px }
}
@media screen, print {
body { line-height: 1.2 }
]

So far so good as Mobile Web Best Practices 1.0 recommends media types in their default delivery context – a base set of design guidelines for mobile. They also state you shouldn’t develop to only the DDC specification – and therefore limit design to the capabilities of low end phones – but adapt content to exploit the capabilities of higher end devices that can handle more robust styling and technologies.

Sound familiar? Step in progressive enhancement and CSS 3 media queries.

Media queries extend media types by using features such as ‘width’, ‘height’, ‘device-width’, ‘device-height’, ‘orientation’, ‘aspect-ratio’, ‘device-aspect-ratio’, ‘color’, ‘color-index’, ‘monochrome’, ‘resolution’, ‘scan’, and ‘grid’.

In short you get more for your money than you do with media types as you can specify things such as screen width that can target a style sheet to only apply to a screen which is 480px or less as shown in the example below:

@media screen and (max-device-width: 480px) {
// insert CSS rules here
}

You can check out a working example of media queries here (just resize the window to see content reflow) and read a write up of how it is done in the optimizing for mobile section of a developer’s look at Opera Mini 5 beta.

Media queries are still being adopted by desktop and mobile browsers alike with support at the time of writing as follows (as far as I could see): Opera Mobile, Opera Mini 4, Opera on the Nintendo Wii, iPhone, Bolt, Iris and the Nokia s60 browser.

Within that the full set of media query features may or may not be supported by any one browser however I would expect the key ones are such as  ’width’, ‘height’, ‘device-width’ and ‘device-height’ to be included. I’ve not been able to track down any up-to-date information here so let me know if you do.

The principles of good web design still seem to hold true when it comes to designing for mobile and we’d do well to learn from some of the mistakes from desktop rather than repeat them. Happily this makes our jobs a bit easier as the same rules apply:

• Set your baseline of supported web technologies
• Use web standards: HTML, CSS, JavaScript, XHTML etc
• Apply progressive enhancement
• Test, test, test

So much good came out of it such as Easy YouTube, a collaboration between the flame haired love-god of accessibility Christian Heilmann  and the delectable Antonia Hyde, as well as Scripting Enabled which took off in London and Seattle.

Thankfully it’s back this year and I definitely wont miss it as I’ll be there sharing a panel with Marco Zehe from Mozilla,  Damon Rose from BBC Ouch and Veronika Jermolina from AbilityNet on “Accessibility beyond the desktop”. The rest of the speaker line-up is pretty impressive too with Christian giving the keynote, the mighty Steve Faulkner talking about WAI-ARIA and Mark Boulton on accessible design – something that is rarely spoken about enough. We get so hung up with technical accessibility for screen readers that often we overlook deaf users and people with cognitive problems who thrive off good design.

Speaking of which, Lisa Herrod, one of a handful of people who has a focus on deafness and hard of hearing issues, will also be giving a pre-conference workshop on deafness awareness for webteams. Definitely one not to be missed and if you need any more convincing then check out her article on A List Apart: Deafness and User Experience.

The good people at AbilityNet are also putting together podcasts of the day that the Opera Developer Network will be sponsoring. If you want a flavour of what’s to come check out the podcasts and transcripts from last year.

So sign up and get your tickets while they last and follow Accessibility 2.0 on Twitter so that you can get updates before and during the day.

See you there – and come armed with questions on accessibility beyond the desktop as this is where it’s at right now.