This covers issues around universal access as well as testing tools such as the Opera Widget Emulator and Opera Dragonfly.

1. Universal access across
devices: can the mobile
Web be made
accessible? Henny Swan
Web Evangelist
hennys@opera.com
Twitter: @iheni
Web Evangelist Opera
Formally RNIB - Royal National Institute o Blind People as a Senior Web Accessibility Consultant
Felt constrained when discussing accessibility in isolation as I felt that there was not only a strong relationship with mobile but also
localisation and internationalisation
I wanted to explore this more hence my move to Opera

2. “Mobile phone users struggle
mightily to use websites, even on
high-end devices. To solve the
problems, websites should
provide special mobile versions.”
Jakob Nielsen, Mobile Web 2009 = Desktop Web 1998
“When our test participants used sites that were designed specifically for mobile devices, their
success rate averaged 64%, which is substantially higher than the 53% recorded for using "full" sites
— that is, the same sites that desktop users see.”
From this Nielson concludes mobile sites should be built. While the fact users struggle is not
debatable advising .mobi sites is: why not advise better web design on the original site? A site
optimised for accessibility already goes some way to doing this...

3. Who is restricted:
• 8.6 million UK residents
• 1 in 7 people here
• Visual, cognition, deaf, cognition, mobility
• Older users (Hello Mum!)
• You and me...
...no-one plans on dying young right?

4. Issues
1. Variable viewport size
2. JavaScript and plugin support
3. Colour, images and font
4. Keyboard access
5. Accessibility API
6. Context
7. Testing

5. How do we build websites that
work for mobile users with
disabilities?
(Hint: you already know it)

6. Main ingredients are
web standards:
- HTML
- CSS
- JavaScript
- XML

7. Flavoured with W3C
guidelines:
- Mobile Web Best Practices (MWBP) 1.0
- Mobile Web Application Best Practices (MWABP)
- Web Content Accessibility Guidelines (WCAG) 2.0
- Widgets 1.0
UAAG 1.0 is not intended for mobile browsers however there are aspects that obviously relate to
mobile browsing.

8. Cross over between MWBP and WCAG
There is a significant cross over between MWBP and WCAG. Some of the underlying factors are the
same or similar however how you accomodate for them does not map completely. Good news
however is that if you have optimised your site for one set of guidelines you are already a fair way
to meeting the other.

9. Relationship between Mobile Web Best Practices (MWBP)
and Web Content Accessibility Guidelines (WCAG)
Our example here flags “large pages or images” as a problem for both disabled and mobile users
and maps the solutions:
• Disabled users - blind, colour blind users perceives colour incorrectly or not at all. WCAG 2.0
1.4.1 Use of colour, 1.3.1 Info and relationships and 1.4.3 Contrast (minimum), 1.4.6 Contrast
(Enhanced)
• Mobile users - Many screens have limited colour palette and colour difference is not presented.
Device is used in poor lighting (for example outdoors), so colours may not clearly be perceived.
MWBP “use of colour and contrast

10. Applying standards and
guidelines to the issues

11. 1. Variable viewport
There are multiple viewport sizes in mobile, more so than on desktop making it hard to know what
resolutions to accomodate for. The image shows a chart of variable screen sizes.

12. CSS 2.1: Media types
Print, screen, aural, braille, handheld, projection, tty, tv, and all.
Via style sheets:
<link rel="stylesheet" type="text/css" media="screen"
href="sans-serif.css">
Declared using @media:
@media print {
body { font-size: 10pt }
}
@media screen {
body { font-size: 13px }
}
@media screen, print {
body { line-height: 1.2 }
}

13. CSS 3: Media queries
Extends media types: width, height, device-width, device-height,
orientation, aspect-ratio, device-aspect-ratio, color, color-index,
monochrome, resolution, scan, and grid.
Used in linked stylesheets or delivered using the @import-at rule
or @media attribute:
- styles depending on browser width
- one page for all devices (yay!)
So far supported on Opera Mobile, Opera Mini 4, Opera on the
Nintendo Wii, iPhone, Bolt, Iris and the Nokia s60 browser.

14. @media all and (max-width: 300px) {
div#container {
// special styles for small displays
}
}
Media queries demo

15. One content source
multiple delivery
mechanisms
Detect, adapt, deliver

16. 2. JavaScript and
plugin support
The image shows a metal fence that you can see through but can’t access as it is locked.

17. JavaScript: varying support by mobile
browsers
Flash: Varying support across mobile
browsers and platforms
(Blackberry and Android to add full Flash soon)
Fallback and alternatives needed

18. Looking ahead
• HTML5
- Forms validation with no JavaScript
- Offline storage
- <audio> and <video>
• WAI-ARIA
- Could benefit mobile
- Provides better keyboard access

19. 3. Colour, images and font
The image shows calligraphy brushes lined up on a bamboo mat.

20. Colour
Not all mobile browsers support colour, not all users see
colours:
• Don’t rely on colour alone
• Provide good contrast (ratio 4.5:1 WCAG 2, Level A)
• MWBP: use 8-bit (256 colors) as a minimum
• Test pages in a monochrome environment
WCAG 2.0: 1.4.1 use of colour, 1.3.1 Info and
relationships, 1.4.3 + 1.4.6 Contrast
MWBP: 5.3.6 Use of Color and Colour Contrast

21. Images
• MWBP: Baseline image format JPEG and
GIF 89a
• Avoid large images - file sizes and
dimensions
• Provide alternatives
• Careful use of background images - CSS
can be stripped out in some mobile
devices

22. Fonts
• Bold and italic not accessible to
blind users on desktop, often
unsupported on mobile
• Avoid font related styling for
meaning
• Use media queries for targeted
device styling
• Use MWBP Default Delivery
Context
• Test* - Opera Mini Emulator,
Opera DragonFly
*In both desktop and mobile mode as CSS support varies
between the two

23. 4. Keyboard access

24. Ensure keyboard access:
• Give logical tab cycle - normally source order
and beware tabindex (WAI-ARIA tabindex OK)
• Avoid updates on focus (popups, form
submissions etc)
• Avoid hidden content with CSS (often intended
for screen readers on desktop)
• Avoid form field focus
• Beware lightboxes
• Don’t suppress outline

25. Identifying focused links
• If you have :hover use:
- :active (keeps mobile and IE happy)
- :focus
• iPhone suppresses :hover so if you click a link
hover is activated first. Can cause confusion.
Remember: don’t design for behaviour of one
platform/browser.

26. Keyboard access and the browser
• Pan and zoom
• Text resizing
• Single column layout
• Password managers
• Auto complete
• Tabbed browsing
• Syncing links - Opera Link
• History and bookmarks
• Speed - Opera Turbo
Check out Opera Mini 5 beta
mini.opera.com
The screen shot is of a mobile showing font, font-style and other types of text support. Always
worth creating a page with styles and testing it in your mobile browser to see how it renders.

27. Opera Fingertouch
Zooms clickable options such as links or form elements so you
can choose the correct link:
• Easier browsing on small screens
• Reduces errors
• Plenty of visual feedback
• Available in Vodafone 360 H1
Mobile browser innovation could inform desktop innovation
The three screen at the bottom show the steps needed to use Fingertouch:
1. Tap the area of the screen to highlight the three form elements you wish to choose from, in this
case radio buttons for Yes, No and Maybe.
2. Tap the zoomed in area to select your preferred option.
3. Select.

28. 5. Cross platform accessibility APIs
We’re at a cross roads in mobile web development hence the arial shot of the busy cross roads
taken in Tokyo, Japan.

29. Accessibility API: hooks screen readers into content
• Desktop - some cross platform:
• IAccessible2
• Microsoft Active Accessibility (MSAA)
• Microsoft UI Automation
• Apple Accessibility API
• AT-SPI
• Java Access Bridge
• Mobile - platform specific:
• VoiceOver - iPhone
• Mobile Speak - Symbian OS, Windows Mobile
• Pocket Hal - Windows Mobile, PDA and PDA phones
• Talks - Symbian OS Series 60 or 80

30. No cross platform accessibility API
Walled gardens and closed platforms
A walled garden high up on the side of a mountain. No easy visible exit apart from throwing
yourself off the edge.

31. What platform should I design for?

32. Don’t design for specific
platforms and browsers
Use web standards:
HTML, CSS, JavaScript,
XML

33. AEGIS
Open Accessibility Everywhere
“...to develop a set of user agents for desktop and mobile devices
which leverage and translate a cross-platform accessibility API...”.
BONDI - could text to speech be
included in the API?

34. 6. Context
Speedometers - different speeds different contexts.

35. Context beats assumptions of desktop design:
• people are indoors
• people are sitting down
• people have light
• people can hear
people have time
• people have certain screen sizes
No longer a single web interface but multifaceted

36. Geolocation
• Gathers co-ordinates of the user and maps to web services:
- Maps (Google,Yahoo!)
- Search (accessible restaurants)
- Social networking (Twitter, Facebook, Dopplr...)
• Personalisation and targeted information
• Wayfinding
• Works in Opera 10 experimental build, Firefox 3.5
• Coming soon to mobile
• W3C Geolocatin API Specification

37. This is a screenshot of a geolocation mashup by Shwetank Dixit showing realtime Twitter updates in
Brighton and your location. No input required as your browser knows where you are. Incredibly
useful when on a mobile, more so than desktop I think.

38. Personalisation
• Provide adaptation preferences based on
- Location
- Device
- Style
- Ask if user wants a mobile version (don’t
assume)
• Global user profiles, with aliases/subdivisions
for devices/clients/useragents

39. Widgets make
everything better
Mobile magic packed with web standards goodness

40. Opera Widgets
• Available on Opera 9.x up
• Cross platform: Windows, OSX, Linux, WinMob, TV, Nintendo..
• Developer resources: http://dev.opera.com/articles/widgets/
• Opera Widget store: http://widgets.opera.com/
• Opera Widget Manager: http://www.opera.com/products/
mobile/download

41. Creating Opera widgets
• Develop your widget on desktop
- scripts/
- style/
- config.xml
- index.html
• Test spatial navigation
- by clicking Shift + <arrow keys>
- form controls, links and elements with onclick
handlers are picked up by spatial navigation
• Click, drag and reload
- click and drag the config.xml of your widget to an
Opera window and the widget will start
- saves time zipping files
- when hacking the HTML, CSS or JavaScript right click the
widget, click “Reload”, and the changes will be visible

42. Test using the Widget Emulator
• Cross device testing from your desktop of:
- Screen sizes - presets for TVs and mobile in
landscape and portrait mode
- Customize the screen size
- Slow net connections and transfer rates
- Preference store sizes
- Timeout based framerates

43. Test using the widget emulator
1. Unpack the widget emulator:
- emulator_files/
- plugins/
- widgets/
- config.xml
- default_device.js
- index.html
2. Add the following to the head of index.html before
your JavaScript (allows you to test variable device size):
<script type="text/
javascript">if(parent.emulator)parent.emul
ator.begin(window);</script>"
3. Register your widget directory to dir.js
4. Click and drag the config.xml file of the emulator (not
the config.xml of your emulated widget) to Opera

44. A screen shot of the Opera Widget Emulator showing the:
1. Device list
2. Device information panel
3. Emulated device
4. Emulated toolbar
5. Widget information panel

45. Widget emulator: supported devices
You can also add your own via
the Device Information Panel by
selecting ‘New’ and adding
relevant values.
Supported devices include: Desktop, VGA Mobile, QVGA Mobile, WVGA Mobile and TV. The Device
information Panel is also shown.

46. Test on your phone
• Add to a device by
- via USB, and run it from the file system (varies from
mobile to mobile)
- Make the widget downloadable from the web. Opera
recognizes any .zip or .wgt file served with the
application/x-opera-widgets MIME type. Visit
the URL with your mobile phone to load the widget.
• Test: fonts, dragging, input mechanism, Dots Per Inch (DPI) and
colour depth
• Add to widgets.opera.com when tested and ready

47. The wonders of widgets
• Faster updates -
the site every time
no need to download JS, CSS and HTML for
• Less browsing time
• Cheaper
• Easier to use
• Syndicated content
Mobile = widgets = web

48. 5. Testing and debugging
A rainbow spraying aerosol can for debugging

49. Set a baseline of technologies
• MWBP 1.0 Device Delivery Context (minimum delivery context for
a reasonable experience, not the target):
- Usable screen width: 120 px minimum
- Markup Language Support: XHTML Basis 1.1
- Character Encoding: UTF-8
- Images format support: JPeG, GIF 89a
- Page weight: 20 KB max
- Colours: 256 minimum
- Style Sheets: CSS1 and media types
- HTTP/1.0 or HTTP1.1
• Have a device plan - graded mobile browser support
• Progressive enhancement and graceful degradation

50. Test with Opera Dragonfly
Screen grab of a web page with Opera Dragonfly open at the bottom showing the DOM screen and
Computed Styles.

51. Opera Dragonfly
• Inbuilt debugging tool: Tools > Advanced >
Developer Tools
• CSS, DOM, and JavaScript debugging
• Console for entering JavaScript commands
• Live HTML and CSS editing
• Support for multiple languages
• Works alongside the Opera debug menu
• Released on an open source BSD license
• Remote debugging - mobile, TV, widgets

52. Opera Dragonfly support
• Opera 9.5+ features a protocol called Scope
• Scope exposes the current state of web pages loaded in the
browser
• Supported on:
- Opera 9.5 and above
- Opera Mobile 9.5 beta 1 and above
- Opera Widgets Manager for Windows Mobile and S60
- Opera Devices SDK 9.7 and above
Opera Mini and Nintendo Wii not supported

53. Mobile debugging
• Install Opera Mobile 9.5 on your phone (Windows
Mobile)
• Point your desktop instance of Opera Dragonfly to
your Opera Mobile browser (opera:config)
• Loads a web page to be debugged in Opera Mobile
• Refresh and view in Opera Dragonfly
• Debug as expected
• Try for yourself

54. Can the mobile web be made accessible?
This shot taken by Ann McMeekin is of outsides steps and Brunswick Square in London where the
sloped ramp for wheel chairs and prams is seamlessly included with the steps diagonally.

55. “One Web means making, as far as is
reasonable, the same information and
services available to users irrespective of
the device they are using. However, it does
not mean that exactly the same
information is available in exactly the same
representation across all devices.”
Mobile Web Best Practices 1.0

56. “Mobile phone users struggle
mightily to use websites, even on
high-end devices. To solve the
problems, websites should
provide special mobile versions.”
Jakob Nielsen, Mobile Web 2009 = Desktop Web 1998

57. x
“Mobile phone users struggle
mightily to use websites, even on
high-end devices. To solve the
problems, websites should
provide special mobile versions.”
Jakob Nielsen, Mobile Web 2009 = Desktop Web 1998

58. One content source, multiple
delivery mechanisms

59. Tomorrow’s innovations come from today’s
investments
1. Use web standards - HTML, CSS, JavaScript
2. Provide fallback - JavaScript, plugins
3. Set a baseline - use progressive
enhancement and unobtrusive JavaScript
4. Test - debug using Opera Dragonfly
Image of compatible plug sockets for maximum power

60. Look ahead at emerging technologies
1. CSS3 Media queries
2. HTML5 - an alternative to JavaScript and
plugins
3. WAI-ARIA
4. Geolocation
Image of looking out to see with telescopes by the sea side.

61. Universal access beyond the desktop is a
challenge but we have the standards (existing and
emerging) to make it happen. Let’s not make the
same mistakes of the desktop in 1998.

62. Thank you and
questions
Opera Developer Network - www.opera.com/developer
Email: hennys@opera.com
Blog: www.iheni.com
Twitter: @iheni

63. Credits
Images
• Questioned proposal http://www.flickr.com/photos/eleaf/2536358399/
• Walled gardens - http://vanelsas.wordpress.com/2008/05/05/would-you-be-willing-to-pay-for-
a-web-20-service-that-provides-value/
• Speedometer: http://www.flickr.com/photos/adc/391594014/
• Opera Mobile Settings http://www.techhail.com/mobiles/download-opera-mobile-9-7-beta-for-
windows-mobiles/437
• Shodo brushes: http://www.flickr.com/photos/petitshoo/8058238/
• Access denied http://www.flickr.com/photos/urbanphotographer/1302908143/
• Super Timor: http://www.ickr.com/photos/felixjacksonjr/2280660104/
Resources and links
• Mobile Web 2009 = Desktop Web 1998 http://www.useit.com/alertbox/mobile-2009.html
• Geolocation example from Shwetank Dixit http://experimenting.in/other/
demo_geo_twitter_mashup.htm
• Mobile Web Best Practices 1.0 http://www.w3.org/TR/mobile-bp/
• Web Content Accessibility Guidelines 2.0 http://www.w3.org/TR/WCAG/
• Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines
(WCAG) http://www.w3.org/TR/mwbp-wcag/
• Opera Developer Network http://www.opera.com/developer
• Opera Developer Network Blog http://my.opera.com/ODIN/blog/
• Opera Dragonfly http://www.opera.com/dragonfly/
• Opera Web Standards Curriculum http://www.opera.com/company/education/curriculum/
•