The document discusses whether a "one web" approach can accommodate diverse mobile users, including those with disabilities. It argues that while the same information may not be available across all devices, the web should provide reasonable access. Key points include:
- Web standards like HTML, CSS and JavaScript can help create an accessible experience across devices when combined with guidelines like WCAG and MWBP.
- Emerging technologies like CSS media queries, HTML5 and WAI-ARIA have the potential to further improve accessibility on mobile.
- Developers should use progressive enhancement and set an accessible baseline first before advanced features to ensure an inclusive web.
2. Can ‘one web’ work for mobile
users with disabilities?
3. “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
Defining “one web” is a bit like asking accessibility advocates to recommend alt text for a photo of a
CEO on a website - often there are many interpretations.
MWBP captures it best. One website to work across multiple devices, it doesn’t need to be exactly
the same experience but a reasonable one.
While it doesn’t specifically flag disabled users this group ARE users and as such I include them
here.
With this in mind can ‘one web’ accomodate diverse users across multiple devices?
4. “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. W
hy not advise better web design on the original site? A site optimised for accessibility already goes
some way to doing this...
5. Issues
1. Variable viewport size
2. JavaScript and plugin support
3. Colour, images and font
4. Keyboard access
5. Debugging and testing
6. Accessibility API
7. Context
6. How do we build websites that
work for mobile users with
disabilities?
(Hint: you already know it)
8. Flavoured with W3C
guidelines:
MWBP 1.0,WCAG 2.0, UAAG 1.0
The World Wide Web Consortium publishes guidelines on how to optimise web content for mobile
phones and people with disabilities.
MWBP - Mobile Web Best Practices
WCAG - Web Accessibility Guidelines
The User Agent Accessibility Guidelines (UAAG) are guidelines for browsers, media player (things
that render content) on how to render accesible content. While not intended for mobile browsers
there are aspects that cross over and are relevant to mobile accessibility.
9. Cross over between MWBP and WCAG
There is a significant cross over between MWBP and WCAG. Some of the underlying factors are
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.
10. 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
12. Widgets!
But not just any old widget....
Widgets make everything better - but what on earth are widgets?
13. Mobile magic packed with web standards goodness
W3C Widgets: http://www.w3.org/TR/widgets
14. 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
Mobile magic packed with
web standards goodness
16. 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.
17. 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 }
}
18. 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 stylsheets 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.
19. @media all and (max-width: 300px) {
div#container {
// special styles for small displays
}
}
Media queries demo
20. 2. JavaScript and
plugin support
The image shows a metal fence that you can see through but can’t access as it is locked.
21. JavaScript:
• Desktop: varying support for JavaScript by access
technologies
• Mobile: varying support for Javascript by browsers
Flash
• Desktop: Lack of keyboard support on desktop browsers
(only IE)
• Mobile:Varying support across mobile browsers and
platforms
22. WCAG 2.0: Accessibility supported technologies
Use web technologies (HTML, CSS,
JavaScript) that support accessibility i.e.
asstistive technologies (screen readers,
screen magnifiers, refreshable braille
displays, voice input) are able to read
the content.
Or
Provide fallback and alternatives
23. Looking ahead
• HTML5
- Forms validation with no JavaScript
- Offline storage
- <audio> and <video>
• WAI-ARIA
- Helps with keyboard access
24. 3. Colour, images and font
The image shows calligraphy brushes lined up on a bamboo mat.
25. 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
26. Images
• MWBP: Baseline image format JPEG and
GIF 89a
• Avoid large images - file sizes and
dimensions
• Provide alternatives
• Avoid information in background images
- CSS can be stripped out in some mobile devices
- CSS not visible to screen reader users and low
vision users
27. Fonts
• Bold and italic not accessible to
blind users on desktop, often
unupported 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
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.
28. 4. Keyboard access
The tattooed arm is Christian Heilmann’s and shows a Play, Stop and On/Off button.
29. • Give logical tab cycle - normally source order
and beware of tabindex unless used with WAI-
ARIA
• 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
Ensure keyboard access:
30. If you have :hover use:
- :active (keeps mobile and IE happy)
- :focus
Don’t design for behaviour of one platform/
browser:
iPhone suppresses :hover so if you click a link
hover is activated first. Can cause confusion.
Identifying focused links
32. • Pan and zoom
• Text resizing
• Single column layout
• Password managers
• Auto complete
• Tabbed browsing
• Syncing links - Opera Link
• History and bookmarks
• Speed - Opera Turbo
Keyboard access and the browser
The image on the right shows the settings page in Opera Mobile where you can enable and disable Opera Turbo s well as set font sizes, single
column layout and other options.
33. Mobile browser innovation could inform desktop innovation
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
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.
34. 5. Debugging and testing
A rainbow spraying aerosol can for debugging
35. Set a baseline
• For desktop:
- accessibility supported technologies
- fallback content
• For mobile use the 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 CSS2 media types
- HTTP/1.0 or HTTP1.1
Use progressive enhancement: fine tune with media queries
36. • Opera Mini Emulator
• Debug menu - stay tuned for a new improved toolbar
• Opera DragonFly (9.5+)
- CSS, DOM, and JavaScript debugging
- Console for entering JavaScript commands
- Live HTML and CSS editing
- Built into the browser (Tools > Advanced > Developer
Tools), and updated automatically
- Multilingual
- Mobile debugging!
Tools
37. 6. 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.
38. • 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 Mobiles
• Pocket Hal - Windows Mobile, PDA and PDA phones
• Talks - Symbian OS Series 60 or 80
• Blackberry
Accessibility API: hooks screen readers into content
39. 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.
42. The future of a mobile cross platform
API?
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 this include text to speech
support rolled out across mobile
platforms?
44. 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
45. 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
46. 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.
48. Can ‘one web’ work for mobile users with disabilities?
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.
49. “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
50. “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
51. “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
x
Multiple different content sources and websites doesn’t work. One content source multiple delivery
mechanisms does.
52. 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
Compatible plug sockets for maximum power
53. Look ahead at emerging technologies
1. CSS3 Media queries
2. HTML5 - an alternative to JavaScript and
plugins
3. WAI-ARIA
4. Geolocation
Looking out to see with telescopes by the sea side.
54. Accessibility 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.
55. Opera Developer Network - www.opera.com/developer
Email: hennys@opera.com
Blog: www.iheni.com
Twitter: @iheni
Thank you and
questions
56. 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/
• Brunswick Square steps by Ann McMeekin http://www.flickr.com/photos/pixeldiva/2109688648/
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/