Thoughts around universal access on mobile from Accessibility 2.0

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.

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

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

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

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

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

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

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

  11. Keyboard access
  12. 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).

9 thoughts on “Thoughts around universal access on mobile from Accessibility 2.0

  1. I’m struggling to see how personalisation could be a solution here. From what I’ve seen, people don’t personalise or customise their experiences on websites. Mainstream users of Facebook don’t customise their activity streams or have any applications. The same with My Yahoo. The yahoo homepage also doesn’t see much personalisation happening.

    Twitter noticed that their site wasn’t catching on well with newer members because logging in for the first time it’s a real boring website – so they introduced the Suggested Users List – which has all the long-tail-fail of suggesting celebrity/broadcast over dialogue and conversation.

    Maybe that’s where personalisation is being done wrongly – starting from a clean slate rather than a well chosen set of defaults, or maybe the defaults are good enough.

    One of the points I wanted to make during the mobile panel is that mobile-specific websites are not evil or bad. Sites running off .mobi extensions are not bad. What is bad is when the mobile website doesn’t share the same content/data sources as the non-mobile website. When the mobile website becomes a stand-alone website – that’s when it’s bad. The mobile and non-mobile websites should just be views on the same data-model.

    The flexibility needs to be done on the HTML layer – limiting or filtering the content there. As was rightly pointed out, a mobile CSS isn’t enough, because the document size is a big part of the problem.

  2. But widgets…. I see value in widgets. Small chunks of content. I look at portal sites like iGoogle, netvibes, pageflakes, my yahoo, and I see little widgets, each one mobile phone screen big, stacked.

    Mike

  3. newsgator.com, (rss aggregator) did personalisation beautifully, the ability to set-up “loacations” so you could choose what content to see depending on where or from what device you logged in from was just the ticket, you could set it up yourself but importantly you could override it too. I get really frstrated for example with sites that make decisions on your behalf because you are on mobile e.g when you want to download software, and he site detects your device and tells you that it is not supported so won’t let you proceed, just because the sites own device list isn’t up to date…. I can go to the same site from a desktop, download, install and all works perfectly… so yes personalisation but the peramiters must be controlled by the person. Mike is right that most people don’t do it even where they have the option but probably because most of the time the only personalisation features present are style, or how much extra Email the site will generate, not about how you are presented with content. Maybe there is some answers in persistant identities, if sites can deliver content according to preference contained in your identity so you don’t have to personalise each and every site. hell I’m sure I’m not alone in not even registering on most of the so-called community sites I visit.

  4. Hi Mike – interesting points about personalisation and what you’ve seen over at Yahoo! – I’m going to factor this into my thinking as it’s important learning. Did you find this was in relation to desktop or mobile or both? I’m thinking that it may be that while we don’t see personalisation taking off in the desktop context as expected that it really becomes relevant in the mobile context. From what you’re saying it seems that there needs to be substantial work in making it intuitive, quick and easy in the mobile context.

    I think we are also more than in agreement with your statement that “The mobile and non-mobile websites should just be views on the same data-model” too.

    Agreed on the widget front – these are a huge step forward and cut out a lot of the problems people have around using the mobile browsers, paying for time online and so on.

    I think Adrian’s got some good points about personalisation and how it works fro him. It obviously hits the right note but I wonder (given Mike’s comments) how we can ensure that everyone finds this easy to use. For me it comes back to the same thing which is making it easy to set up and use and I’m not sure we have a sure way of doing that yet.

  5. Hi Henny, yes these are mainly what we are seeing on the desktop. I have no idea about mobile – that’s something you could have a chat to Ricardo about tomorrow, he’s our mobile guru.

    Maybe we can learn something from the XMPP/Jabber guys. Everyone using XMPP uses something that looks like an email as their identifier: username@jabberserverdomain. But for every device/client you have, each of those can be targetted specifically with some client identifier tagged on to the end of the jabber id, so something like exampleuser@example.com/home would be an IM client at home. Then preferences can be applied at the user level or at the device specific level – so you’d have a shorter contacts/friends list on a mobile than a desktop client. (cf: http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol#Decentralization_and_addressing )

    I think this goes back to the concepts of global user profiles, with aliases/subdivisions for devices/clients/useragents. Maybe this is something to be done in conjunction with OpenId and aliases. Being able to configure both a personal preference and a device/browser specific preference.

  6. Pingback: The Tink Tank » Blog Archive » Accessibility 2.0

  7. Pingback: Will mobile innovate desktop browsing? | SMLXL - Engagement Marketing and Communication principles from Alan Moore

  8. Pingback: Screen reader software usage shifts on desktop and mobile » iheni :: making the web worldwide

  9. Pingback: The Tink Tank » Accessibility 2.0

Comments are closed.