Is the mobile web enabled or disabled by design?

Is the mobile web enabled or disabled by design? Henny Swan Web Evangelist hennys@opera.com Twitter: @iheni

Can ‘one web’ work for mobile users with disabilities?

“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?

“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 speciﬁcally 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...

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

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

Main ingredients web standards: HTML, CSS, JavaScript, XML...

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.

Cross over between MWBP and WCAG There is a signiﬁcant 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.

Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG) Our example here ﬂags “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

Wait there’s more...

Widgets! But not just any old widget.... Widgets make everything better - but what on earth are widgets?

W3C Widgets: http://www.w3.org/TR/widgets Mobile magic packed with web standards goodness

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

Applying standards and guidelines to the issues

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.

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

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.

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

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

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

WCAG 2.0: Accessibility supported technologies Use web technologies (HTML, CSS, JavaScript) that support accessibility i.e. asstistive technologies (screen readers, screen magniﬁers, refreshable braille displays, voice input) are able to read the content. Or Provide fallback and alternatives

Looking ahead • HTML5 - Forms validation with no JavaScript - Ofﬂine storage - <audio> and <video> • WAI-ARIA - Helps with keyboard access

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

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

Images • MWBP: Baseline image format JPEG and GIF 89a • Avoid large images - ﬁle 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

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.

4. Keyboard access The tattooed arm is Christian Heilmann’s and shows a Play, Stop and On/Off button.

Ensure keyboard access: • 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 ﬁeld focus • Beware lightboxes

Identifying focused links 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 ﬁrst. Can cause confusion.

Mobile accessibility should be a collaboration between browser and web page author

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

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

5. Debugging and testing A rainbow spraying aerosol can for debugging

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: ﬁne tune with media queries

Tools • 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!

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.

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 speciﬁc: • VoiceOver - iPhone • Mobile Speak - Symbian OS, Windows Mobiles • Pocket Hal - Windows Mobile, PDA and PDA phones • Talks - Symbian OS Series 60 or 80 • Blackberry

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.

What platform should I design for?

Don’t design for speciﬁc platforms and browsers Use web standards: HTML, CSS, JavaScript, XML

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?

7. Context Speedometers - different speeds different contexts.

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

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 • Wayﬁnding • Works in Opera 10 experimental build, Firefox 3.5 • Coming soon to mobile • W3C Geolocatin API Speciﬁcation

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.

Personalisation • Provide adaptation preferences - Set location - Set style preferences - Ask if user wants a mobile version (don’t assume)

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.

“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

“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 “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 Multiple different content sources and websites doesn’t work. One content source multiple delivery mechanisms does.

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 Dragonﬂy Compatible plug sockets for maximum power

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.

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.

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

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/

Is the mobile web enabled or disabled by design?

by Henny Swan on Sep 29, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 36

Statistics

Is the mobile web enabled or disabled by design? — Presentation Transcript

http://www.iheni.com	28
http://www.slideshare.net	8