There was an interesting mix of design, development and mobile covered at Accessibility 2.0 yesterday but for me I was most interested to hear people’s comments on mobile browsing for disabled users. Below are some quick thoughts of the day. Big thanks to AbilityNet and the other speakers and the Opera Developer Network who sponsored the podcasts and transcriptions which will be online soon.
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.
Will mobile innovate desktop browsing?
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.
- Native UI library
- 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.
- Inherit global settings from the OS
- Especially important on map applications
- Don’t conflict with user defined settings
- 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.
- 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:hoveris used also use
a:active(to keep IE and mobiles happy) as well as
- 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.
- 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.
- 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.
- 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.
- Keyboard access
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.
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).