Why Mobile Web Accessibility Matters - Best Practices to Make Your Mobile Site Accessible |...

7/30/2019 Why Mobile Web Accessibility Matters - Best Practices to Make Your Mobile Site Accessible | MobiForge

1/8

09/10/12 Why mobile Web accessibility matters best practices to make your mobile site accessible | mobiF

1/8mobiforge.com//whymobilewebaccessibilitymattersbestpracticesmakeyourmobilesiteac

Home (/) About (/page/about-mobiforge) Contribute (/page/write-us-0) Contact (/page/contact) Advertise (/webform/advertise-mobiforge) Latest (/tracker)

(http://www.addthis.com/bookmark.php?v=250&pub=ruadhan)

See also...

Location, Location, Location

(/developing/blog/location-location-

location)

Getting started with the

ready.mobi API

(/testing/story/getting-started-with-

ready-mobi-api)

Kind of a "sunshine

transcoder story"

(/developing/blog/kind-a-sunshine-

transcoder-story)

The Best and Worst of the

Mobile Web (/designing/blog/the-

best-and-worst-mobile-web)

Low Fat or Full Fat, it's still

One Web (/developing/blog/low-fat-

or-full-fat-its-still-one-web)

Why mobile Web accessibility matters - best practicesto make your mobile site accessible

The power

of the Web is in its universality.

Access by everyone regardless of

disability is an essential aspect.

Tim Berners-Lee

(http://www.w3.org/standards/Webdesign/accessibility) , W3C Director and

inventor of the World Wide Web.

This mantra is as true for the mobile Web as it is for the desktop Web. Over

a billion people worldwide live with some kind of disability, and 285 million

have visual impairments (39 million are blind and 246 have low vision),

according to World Health Organization (WHO)

(http://www.who.int/mediacentre/factsheets/fs282/en/index.html) . Given these numbers, what excuses are

there for bad design practices that shut users out who are visually impaired and/or rely on assistive

technologies?

Making your site more accessible is partly about design such as avoiding color schemes that make things

difficult for short-sighted or color-blind people to decipher and partly about developing sites that can be

decoded and easily navigated by screen-readers. People with more severe visual impairments rely on

screen readers (on mobile and desktop devices) to read aloud the content of Websites.

Over the last 10 years we have seen much improvement in accessibility of desktop sites. Table-layouts,

spacer gifs, image headers and flash-only sites none of which worked well with screen-readers are

relatively rare these days and most Websites follow the Web standards of the W3C. Several things have

contributed to this improved situation including adoption of CSS3 and HTML5 adherence to accessibility

standards, including the W3Cs Web Content Accessibility Guidelines (WCAG)

(http://www.w3.org/TR/WCAG/) and adoption of the principles ofSemantic Web (

http://www.w3.org/standards/semanticweb/) (semantic markup describes the purpose of code and is very

useful for screen readers as we will see in Tip 5 (#semantic) ).

The mobile Web needs to be accessible to all disabled people whether it is mobile Websites, embedded

Web views in apps or responsive mobile-optimized sites. While some experienced mobile developers

incorporate these Web best practices into their mobile sites, others are making similar mistakes to those

made by Web developers a decade ago. Theres a worrying trend towards designing sites for a particular

type or brand of handset, rather than catering to all and/or becoming too focused on emulating the snappy

look and feel of native apps in mobile Web development, even if that means forsaking Web standards and

principles of accessibility.

Instead of using s and s for click events which make it obvious to screen readers what is

a clickable link events are bound to list items and elements

(http://www.w3schools.com/html/html_elements.asp) which makes their functionality invisible to keyboard

and screen-reader users. Swipe events and fancy effects are commonly used for core navigation, without

regard for the complications this causes for assistive technologies that may not be able to trigger touch

events or could override them in order to control the screen reader.

In many ways, best-practice mobile sites share many of the same strengths and goals as best-practice

accessibility-enhanced Websites:

Web design should be simple with an intuitive single-column interface, following a similar layout and

navigation commonly found on other mobile sites.

Web pages should be light-weight, avoiding large images, to ensure quick-load times.

The content should usually short and to the point.

Navigation should not be reliant on hover states and mouse events.

The content should, where possible, be geographically relevant to the visitors current location.

POSTED BY SOEDERQUIST 3 WEEKS 4 DAYS AGO
http://www.w3schools.com/html/html_elements.asphttp://www.w3.org/standards/semanticweb/http://www.w3.org/TR/WCAG/http://www.who.int/mediacentre/factsheets/fs282/en/index.htmlhttp://mobiforge.com/designing/blog/the-best-and-worst-mobile-webhttp://www.w3.org/standards/Webdesign/accessibilityhttp://mobiforge.com/developing/blog/kind-a-sunshine-transcoder-storyhttp://www.w3.org/standards/Webdesign/accessibilityhttp://mobiforge.com/testing/story/getting-started-with-ready-mobi-apihttp://www.w3.org/standards/Webdesign/accessibilityhttp://mobiforge.com/testing/story/getting-started-with-ready-mobi-apihttp://mobiforge.com/webform/advertise-mobiforgehttp://mobiforge.com/trackerhttp://mobiforge.com/webform/advertise-mobiforgehttp://mobiforge.com/webform/advertise-mobiforgehttp://www.w3schools.com/html/html_elements.asphttp://mobiforge.com/developing/story/why-mobile-web-accessibility-matters-best-practices-make-your-mobile-site-accessibl#semantichttp://www.w3.org/standards/semanticweb/http://www.w3.org/TR/WCAG/http://www.who.int/mediacentre/factsheets/fs282/en/index.htmlhttp://www.w3.org/standards/Webdesign/accessibilityhttp://mobiforge.com/developing/blog/low-fat-or-full-fat-its-still-one-webhttp://mobiforge.com/designing/blog/the-best-and-worst-mobile-webhttp://mobiforge.com/developing/blog/kind-a-sunshine-transcoder-storyhttp://mobiforge.com/testing/story/getting-started-with-ready-mobi-apihttp://mobiforge.com/developing/blog/location-location-locationhttp://www.addthis.com/bookmark.php?v=250&pub=ruadhanhttp://mobiforge.com/trackerhttp://mobiforge.com/webform/advertise-mobiforgehttp://mobiforge.com/page/contacthttp://mobiforge.com/page/write-us-0http://mobiforge.com/page/about-mobiforgehttp://mobiforge.com/


2/8



(See W3C on similarities between accessibility and mobile Web

(http://www.w3.org/WAI/mobile/overlap.html) )

There have been many advances in cell phone accessibility. Voice activation from the commonplace: Call

Dad to the more sophisticated voice-activated search tools such as Siri

(http://www.apple.com/iphone/features/siri.html) orVlingo ( http://www.vlingo.com) . Increasingly we are

seeing mobile applications developed that make living with disabilities easier everything from finding the

closest accessible restroom or using image recognition to read the content of image captured by your

camera, to apps that aim to include many features into a single app, such as Georgie

(http://www.sightandsound.co.uk/shop/products.php?product=GEORGIE) .

The most important application, however, from a mobile Web developers point of view, is the screen reader.

These apps help visually impaired people access your site, by reading the text aloud. They will even tell you

what you are pointing at as your finger pans across the screen they can be used with touch-screen

devices and, when combined with swipe gestures, can make touch-screen devices as accessible as those

with a physical keyboard. Mobile screen readers have seen rapid adoption. A recent survey by WebAIM

(http://Webaim.org/projects/screenreadersurvey4/#mobile) of 1782 screen reader users found that 71.8 percent

of respondents now use a mobile screen reader, a 600 percent increase from 2009. The most commonly

used were VoiceOver (iOS) 48.7 percent Nuance Talks (Symbian) 17.9 percent Mobile Speak (Symbian

and Windows Mobile) 8.5 percent TalkBack (Android) 5.4 percent Mobile Accessibility (Android) 3.8

percent.

Figure 1:Use of screen readers on mobile devices.

12 simple tips to help make your site more accessible

Developing an accessible mobile site isnt difficult when you apply best-practice guidelines and consider the

needs of all the people who are visiting the site, including those who are older or have disabilities, such as

visual impairments. The following tips will help you make your mobile site more accessible for visitors with

visual impairments, particularly those using screen readers.

1) MAKE THE SITE EASY TO READ

Many users, even those without any severe visual impairmentstruggle to read small letters and make out text on colored

backgrounds (particularly on smaller devices, which you might be

attempting to read while outside, in motion, in bad light etc).

Consider the font size and the contrast between the text color and

the background. WCAG 2.0 (http://www.w3.org/TR/WCAG/)

provides some good guidelines on this, but as a rule of thumb, I

recommend setting the default browser font size to 1em (16px) for

content text and never set any font-size smaller than 0.75em

(12px). (See tip 2 to find out why you should use em rather than

px).

There are plenty of Web-based tools to help you choose

accessible color schemes, such as this Contrast ratio calculator

(http://www.msfw.com/accessibility/tools/contrastratiocalculator.aspx) (pictured) from MSF&W. See W3C

(http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-

contrast-examples-head) and Speckyboy (http://speckyboy.com/2011/01/21/20-essential-tools-and-tips-to-an-
http://speckyboy.com/2011/01/21/20-essential-tools-and-tips-to-an-accessible-website/http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html#visual-audio-contrast-contrast-examples-headhttp://www.msfw.com/accessibility/tools/contrastratiocalculator.aspxhttp://www.w3.org/TR/WCAG/http://webaim.org/projects/screenreadersurvey4/#mobilehttp://www.sightandsound.co.uk/shop/products.php?product=GEORGIEhttp://www.vlingo.com/http://www.apple.com/iphone/features/siri.htmlhttp://www.w3.org/WAI/mobile/overlap.html


3/8



accessible-website/) for more tools.

2) ALLOW ZOOMING

Most devices Web browsers allow you to zoom in on the content to make it bigger. Unfortunately this feature

is commonly disabled on mobile sites using:

name="viewport"value="initial-scale=1.0, user-scrollable=no"

Or:

name="viewport"value="initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0 "

This might ensure that the site looks good on mobile devices, but whats the good of that if some of your

visitors are unable to read it? Instead you can restrict the degree of zooming, perhaps limiting it to x2 for

instance, this makes it possible to double the size of text, but stops the visitor from losing themselves by

over-zooming:

name="viewport"value="initial-scale=1.0, minimum-scale=1.0, maximum-scale=2.0"

Some users prefer to show bigger text, without needing to zoom in on every element. This function exists on

many devices, but is only possible when sites define font-sizes in em

(http://webdesign.about.com/od/typemeasurements/qt/how-big-is-an-em.htm) or percentages rather than in

pixels. Setting font-sizes in em is as easy as setting them in pixels, but you need to be aware that child

elements will inherit (http://www.w3.org/TR/CSS2/cascade.html) the base font-size of its parent element. Its a

good recommendation only to set font-sizes to elements which varies from the default font-size set on the

HTML element, and never set it to container which can mess up the font-size when nested. To calculate

font-size in ems from a pixel perspective you divide your target size (in pixels) with the parent font-size (in

pixels):

html{

:100%;/*Defaults to 16px*/

}

small{

:0.75em;/* 12px/16px = 0.75 */

}

3) SPECIFY LANGUAGE

One of the most common and annoying mistakes, Ive found using a screen reader myself, is when

developers forget to specify the language of the page using the lang attribute

(http://www.w3.org/TR/html4/struct/dirlang.html) within the element. This will result in screen readers

attempting to read the text in its default language in my case, that would be Swedish.

Can you imagine how incomprehensible it is having an English Web page read as though it is Swedish

vocabulary? All it would take to put it right would be: . To specify UK English with British

pronunciation, use: and US English with US pronunciation: .

4) CONTENT FIRST

Before adding any style and graphics to your design make sure everything is understandable without

images and CSS. No semantic elements (http://www.w3.org/TR/WCAG20-TECHS/G115) (i.e. the ones that

describe what they do, such as link and

paragraph
) should never be empty. All images
should have alt attributes (http://www.w3.org/TR/WCAG20-TECHS/H37) describing the purpose/function of the

image (rather than a description of what is displayed). If the image doesnt have any purpose the alt-attribute

is allowed to be empty, but consider setting the image as a background-image in CSS instead. If your designintends to use an image asset instead of text on a menu button, always make sure you add the text content

first and then hide the content and add the image using CSS.

There are two options for hiding content from sighted-visitors, while still allowing screen readers to pick up

on them:
http://www.w3.org/TR/WCAG20-TECHS/H37http://www.w3.org/TR/WCAG20-TECHS/G115http://www.w3.org/TR/html4/struct/dirlang.htmlhttp://www.w3.org/TR/CSS2/cascade.htmlhttp://webdesign.about.com/od/typemeasurements/qt/how-big-is-an-em.htmhttp://speckyboy.com/2011/01/21/20-essential-tools-and-tips-to-an-accessible-website/


4/8



The text-indent, moves the text-content of an element out of the way, but still holds the semantic meaning

of the element. The element needs to be positioned relative or absolute. Setting a high negative value moves

the text off screen to the left, for right aligned elements you will have to set a high positive value instead:

.menubutton{

:relative;

: -9999px;

}

The alternative method is to set text-content in a sub-element, moving the entire element offset. The

element needs to be positioned absolute and then moved out of sight by setting a high negative value. This

approach is recommended when the image asset is set as an image element instead of background-image,

for instance for logotypes.

.logotype.alt-logo{

:absolute;

: -9999px;

}

The downside of the latter approach is that it will only be recognized by screen readers when jumping between

elements, but not accessed when pointing to the element.

5) USE SEMANTIC MARKUP

HTML5 provides developers with a lot ofnew semantic elements

(http://www.w3schools.com/html5/html5_new_elements.asp) , which enable developers to mark up the DOM

(the Document Object Model (http://www.w3schools.com/htmldom/default.asp) defines the structure, style

and operation of a Web page) in a more structural and comprehensible manner.

Using the (http://www.w3schools.com/html5/tag_nav.asp) element to designate the main navigation and

(http://www.w3schools.com/html5/tag_article.asp) element to designate text-based content not only

makes it easier for developers to write and describe the code so it is easier for other developers to

understand, but it also makes it easier for disabled users using screen readers to understand the purpose of

elements and quickly jump between different types of elements.

Too often, mobile sites suffer from what I call "divitus", i.e. where the (http://www.w3schools.com/html5/tag_div.asp) element is overused and used for almost every purpose. This

isnt necessarily due to the direct action of the Web developer, but the choice of framework (more on this in

Tip 11 (#frameworks) below). The markup is your toolkit, use it wisely.

Fors there are a bunch of new input types defined in HTML5, setting the correct type makes it easier

for all users to input data using the appropriate keyboard, and getting a better sense of which data to enter.

Always make sure to associate input fields with appropriate labels, using the for-attribute

(http://www.w3schools.com/tags/att_label_for.asp) : .

6) STRUCTURE YOUR RICH INTERNET APPLICATIONS

To further enrich the semantics of you site, the W3Cs Web Accessibility Initiative for Accessible Rich

Internet Applications [WAI-ARIA] (http://www.w3.org/WAI) provides a set of roles to define the meaning

and purpose of elements commonly used in Web apps.

Landmark roles (http://www.w3.org/TR/wai-

aria/roles#landmark_roles) define the main sections of the

document to aid navigation. These make it possible for screen

reader users to jump directly into the main content or to the main

navigation for instance. According to a recent survey by WebAIM

(http://webaim.org/projects/screenreadersurvey4/#landmarks), ARIA

landmarks are used by the majority of screen reader users 24.6

percent use them when available, 15.8 percent use them often,

25.5 percent use them sometimes, while 34.1 percent use them

rarely or never.

The landmark roles are application (http://www.w3.org/TR/wai-

aria/roles#application) , banner (http://www.w3.org/TR/wai-aria/roles#banner) , complementary

(http://www.w3.org/TR/wai-aria/roles#complementary) , contentinfo (http://www.w3.org/TR/wai-

aria/roles#contentinfo) , form (http://www.w3.org/TR/wai-aria/roles#form) , main (http://www.w3.org/TR/wai-
http://www.w3.org/TR/wai-aria/roles#mainhttp://www.w3.org/TR/wai-aria/roles#formhttp://www.w3.org/TR/wai-aria/roles#contentinfohttp://www.w3.org/TR/wai-aria/roles#complementaryhttp://www.w3.org/TR/wai-aria/roles#bannerhttp://www.w3.org/TR/wai-aria/roles#applicationhttp://webaim.org/projects/screenreadersurvey4/#landmarkshttp://www.w3.org/TR/wai-aria/roles#landmark_roleshttp://www.w3.org/WAIhttp://www.w3schools.com/tags/att_label_for.asphttp://mobiforge.com/developing/story/why-mobile-web-accessibility-matters-best-practices-make-your-mobile-site-accessibl#frameworkshttp://www.w3schools.com/html5/tag_div.asphttp://www.w3schools.com/html5/tag_article.asphttp://www.w3schools.com/html5/tag_nav.asphttp://www.w3schools.com/htmldom/default.asphttp://www.w3schools.com/html5/html5_new_elements.asp


5/8



aria/roles#main) , navigation (http://www.w3.org/TR/wai-aria/roles#navigation) and search

(http://www.w3.org/TR/wai-aria/roles#search) (i.e. role="banner").

Widget roles (http://www.w3.org/TR/wai-aria/roles#widget_roles) are used to specify an element that has is

being used in an unusual fashion. For example, if JavaScript has been used to alter the behavior of a link,

then by setting role="button" (http://www.w3.org/TR/wai-aria/roles#button) on the link will make a screen

reader interpret it as a button. Similarly set the widget roles as alert (http://www.w3.org/TR/wai-

aria/roles#alert) , dialog (http://www.w3.org/TR/wai-aria/roles#dialog) , option (http://www.w3.org/TR/wai-

aria/roles#option) , orslider (http://www.w3.org/TR/wai-aria/roles#slider) to define the nature of custom-built

components. Widget roles can also be used to extend the functionality to objects which do not yet exist astheir own elements, such as tab (http://www.w3.org/TR/wai-aria/roles#tab) , tabpanel

(http://www.w3.org/TR/wai-aria/roles#tabpanel) , treeitem (http://www.w3.org/TR/wai-aria/roles#treeitem) and

timer (http://www.w3.org/TR/wai-aria/roles#option) .

Mobile Web applications that rely heavily on JavaScript and changes to the DOM can be a big problem for

screen readers, as they only read one part of the Web page at a time and may not be able to catch changes

in other parts of the DOM. The W3Cs solution to this issue is to use WAI-ARIA attributes

(http://www.w3.org/TR/wai-aria) . These use JavaScript to define the current state of the site and the

relationship between the different elements. The following example builds a tab list with associated tab

areas. First the semantic roles oftablist, tab and tabpanel are defined. Then each tab area is associated

with the tab controlling it using the ARIA and labeled by attribute. Finally, the state of the DOM is defined,

specifying which tabareas are currently visible using the aria-hidden attribute, and updating this for everyinteraction with the component.

role="tablist"class="tabs"

role="tab"class="selected"href="#area1"id="tab1" Area 1

role="tab"href="#area2"id="tab2" Area 2

class="selected"id="area1"role="tabpanel"aria-hidden="false"aria-labeledby="tab1"

id="area1"role="tabpanel"aria-hidden="true"arialabeledby="tab2" ...

When using more advancedAJAX

(http://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.php) functionality,

containers of regularly updated content should be defined as live regions (http://www.w3.org/WAI/PF/aria-

practices/#LiveRegions) . The aria-live attribute sets the rules as to how screen-reader users are notified of updatedcontent.

aria-live="polite"aria-busy="true" Loading

Setting the value as "polite" notifies the user what is happening, as soon as the screen reader finishes whatever it is

currently doing. Setting the value "assertive", the screen reader will s top whatever it is doing to deliver the update. It

is good practice to set the aria-busy attribute to "true" as the live region is being updated, and to "false" as soon as

the content is loaded.

Anyone with a good understanding of how to use the WAI-ARIA roles and attributes s hould be able to make

any mobile Web application accessible.

Get started by reading: Introduction to WAI ARIA (http://dev.opera.com/articles/view/introduction-to-wai-

aria/) .

7) OUTLINE YOUR DOCUMENT

The document outline (http://www.w3.org/TR/html5/headings-and-sections.html#headings-and-sections) is the

map of the Web page, using headings and landmark sections. This helps screen readers and other

automated programs such as search engines, for that matter to parse (segment/index) the document. A

structured outline allows screen-reader users to easily jump between the hierarchical elements of the DOM.

Traditional best practice was to create a hierarchy using headers to according to the importance of

each section relative to each other i.e. root (main), branches (sections) and leaves (subsections)

making it clear which are the parent and child/sibling nodes in the DOM tree

(http://www.w3schools.com/htmldom/dom_nodetree.asp) .

HTML5 made document outlines clearer by introducing the (http://www.w3.org/TR/html5/the-article-

element.html#the-article-element) and (http://www.w3.org/TR/html5/the-section-element.html#the-

section-element) elements (the difference between the and is explained here

(http://www.brucelawson.co.uk/2010/html5-articles-and-sections-whats-the-difference) ).
http://www.brucelawson.co.uk/2010/html5-articles-and-sections-whats-the-differencehttp://www.w3.org/TR/html5/the-section-element.html#the-section-elementhttp://www.w3.org/TR/html5/the-article-element.html#the-article-elementhttp://www.w3schools.com/htmldom/dom_nodetree.asphttp://www.w3.org/TR/html5/headings-and-sections.html#headings-and-sectionshttp://dev.opera.com/articles/view/introduction-to-wai-aria/http://www.w3.org/WAI/PF/aria-practices/#LiveRegionshttp://www.openajax.org/whitepapers/Introduction%20to%20Mobile%20Ajax%20for%20Developers.phphttp://www.w3.org/TR/wai-ariahttp://www.w3.org/TR/wai-aria/roles#optionhttp://www.w3.org/TR/wai-aria/roles#treeitemhttp://www.w3.org/TR/wai-aria/roles#tabpanelhttp://www.w3.org/TR/wai-aria/roles#tabhttp://www.w3.org/TR/wai-aria/roles#sliderhttp://www.w3.org/TR/wai-aria/roles#optionhttp://www.w3.org/TR/wai-aria/roles#dialoghttp://www.w3.org/TR/wai-aria/roles#alerthttp://www.w3.org/TR/wai-aria/roles#buttonhttp://www.w3.org/TR/wai-aria/roles#widget_roleshttp://www.w3.org/TR/wai-aria/roles#searchhttp://www.w3.org/TR/wai-aria/roles#navigationhttp://www.w3.org/TR/wai-aria/roles#main


6/8



Mobile accessibility

Mobile sites should be accessible

12 simple tips

Follow these carefully.

Tip 1: readability

Think about font size and color contrast.

Tip 2: Allow zooming

Let people enlarge the text.

Further reading

Check out these articles

In HTML5, you could theoretically create documents using the heading throughout and structure them

in a hierarchical outline. But until we are certain that all screen readers (and search engines) support HTML5

and hierarchical outlines, I recommend using a belt and braces approach of both hierarchical headings

to with s as demonstrated in the example above.

8) REDIRECT, DON'T DISRESPECT

It is common practice for Websites that have separate desktop and mobile versions to detect and redirect

mobile visitors to the desktop site to the mobile site (and visa versa). This is good practice it makes the

mobile visitor aware the existence of a mobile site, but visitors needs to be given a choice.

Usually on these sites, there is a link in the footer allowing mobile users to access the desktop site. In the

same manner, the desktop site should add a link to the header (or footer), allowing desktop users to choose

the mobile experience, without being redirected back to the desktop site.

Mobile sites can be preferable for visually-impaired visitors (other visitors also) whether they are viewing via

a mobile, tablet, desktop and/or using a screen reader as mobile sites are often more concise, streamlined,

light-weight, using less flash and images and often with larger text.

9) DONT RELY EXCLUSIVELY ON TOUCH EVENTS

It has become increasingly popular for native apps and Web apps

to rely heavily on gestures and swipe events for user interaction.

For a savvy consumer this might be really cool, but for others who

are unaccustomed to touch-screens and gestures or for people

who are less dexterous, it can be an inconvenience. On touch-

based devices, screen readers are controlled using swipe

patterns and gestures (see tip 12 for details (#controls) ),

meaning that the site/apps custom touch events might be ignored.

Theres nothing wrong with touch interaction, just make sure

theres always an easy alternative way to interact.

10) PROGRESSIVELY ENHANCE

Progressive Enhancement (http://www.alistapart.com/articles/understandingprogressiveenhancement) is a

popular development methodology. The Progressive Enhancement philosophy states that you start very

basics, building a functional core, adding levels of CSS and JavaScript progressively to enhance the

experience. This makes it easier to build advanced applications that will work on different devices and

browsers with different capabilities. Of course Progressive Enhancement is not the only approach to

building mobile sites/apps, but it is really good practice when building accessible sites to start from the core,

adding functionality step by step making sure at each level that the site/app remains accessible to peoplewith disabilities, including screen-reader users.

11) USE A GOOD FRAMEWORK

There are many frameworks for building mobile sites, all of which make it easier for developers to create
http://www.alistapart.com/articles/understandingprogressiveenhancementhttp://mobiforge.com/developing/story/why-mobile-web-accessibility-matters-best-practices-make-your-mobile-site-accessibl#controls


7/8



CONTENT:

cutting-edge mobile apps. However, while different frameworks create apps that look and behave pretty

similarly, behind the scenes there are big differences in terms of accessibility.

jQuery Mobile (http://jquerymobile.com/test/index.html) is one of the most popular user interface (UI)

frameworks, providing developers with a library of ready-made components

(http://www.ibm.com/developerworks/web/library/mo-jquery-mobile-components/index.html) (e.g. dialogue

boxes, toolbars and buttons) CSS transitions (http://jquerymobile.com/test/docs/pages/page-transitions.html)

(e.g. fade, pop, flip, slide) widgets (http://jqueryui.com/demos/accordion) (e.g. accordion, autocomplete,

slider). JQuery mobile was built, in collaboration with Filament Group, to the highest accessibility

(http://jquerymobile.com/test/docs/about/accessibility.html) standards, incorporating all aspects of W3C'sWAI-ARIA specification such as HTML attributes. This means that apps built on JQuery will perform well

with screen readers.

This, in my opinion, makes JQuery preferable to rival frameworks, such as Sencha Touch

(http://www.sencha.com/products/touch) , for creating accessible applications. Sencha Touch creates Web

apps with a native look and feel using JavaScript. While Sencha Touch creates nice-looking apps in a

relatively painless way, when you look behind the scenes theres an ocean of elements and no

semantic elements at all. Neither of which is great for screen readers.

12) TEST, TEST AND TEST AGAIN

The last tip, and by far the most important one, is to test the accessibility of your site/app for yourself. It isimpossible to develop a fully accessible Web site of any kind without testing it on all leading browsers,

mobile devices and screen readers. If you have an iPhone 3GS or newer you have no excuse for not

testing, as this device comes with a sophisticated multi-language screen reader, VoiceOver

(http://www.apple.com/ accessibility/voiceover) . To activate VoiceOver, go to Settings > General >

Access ibility. Now s tart testing. By setting the Triple click Home option to VoiceOver you can activate and

deactivate VoiceOver while browsing with three clicks on the home button.

First practice the controls:

Swipe your finger across the screen to hear what is beneath your finger.

Swipe right to skip to the next element.

Rotate with two fingers to select landmark sections.

Swipe up or down to jump between landmarks.

Swipe with two fingers down to read the entire content. Tap two fingers to pause and play.

Swipe with three fingers to scroll.

Now shut your eyes (or hold your device under your desk) and test your favorite sites/apps. It doesnt take

long to see how hard it is to use most sites and thus why mobile Web accessibility matters.

Ensure that your sites/apps work with other popular screen readers for different devices (some of

these are available as trial versions):

Mobile Accessibility for Android (http://www.codefactory.es/en/products.asp?id=415) (free 30-day trial

version available).

The Nokia Screen Reader(http://store.ovi.com/content/224364) (free app).

Mobile Speak for Nokia and Windows Mobile (http://www.codefactory.es/en/products.asp?id=316) (free

30-day trial version available). Nuance TALKS (http://www.nuance.com/for-individuals/by-solution/talks-zooms/index.htm) (trial version

available).

Big Thanks to Artur Ortega@DesignedByBlind (https://twitter.com/DesignedByBlind) for sharing the great insights into

using the Web through a screen reader and making it look easy.

Recommended reading:

20 Essential Tools and Tips to an Accessible Website (http://speckyboy.com/2011/01/21/20-essential-tools-and-tips-

to-an-accessible-website)

RELATED

Location, Location, Location (/developing/blog/location-location-location)

Getting started with the ready.mobi API (/testing/story/getting-started-with-ready-mobi-api)

Kind of a "sunshine transcoder story" (/developing/blog/kind-a-sunshine-transcoder-story)

The Best and Worst of the Mobile Web (/designing/blog/the-best-and-worst-mobile-web)

Low Fat or Full Fat, it's still One Web (/developing/blog/low-fat-or-full-fat-its-still-one-web)
http://mobiforge.com/developing/blog/low-fat-or-full-fat-its-still-one-webhttp://mobiforge.com/designing/blog/the-best-and-worst-mobile-webhttp://mobiforge.com/developing/blog/kind-a-sunshine-transcoder-storyhttp://mobiforge.com/testing/story/getting-started-with-ready-mobi-apihttp://mobiforge.com/developing/blog/location-location-locationhttp://speckyboy.com/2011/01/21/20-essential-tools-and-tips-to-an-accessible-websitehttps://twitter.com/DesignedByBlindhttp://www.nuance.com/for-individuals/by-solution/talks-zooms/index.htmhttp://www.codefactory.es/en/products.asp?id=316http://store.ovi.com/content/224364http://www.codefactory.es/en/products.asp?id=415http://www.apple.com/%20accessibility/voiceoverhttp://www.sencha.com/products/touchhttp://jquerymobile.com/test/docs/about/accessibility.htmlhttp://jqueryui.com/demos/accordionhttp://jquerymobile.com/test/docs/pages/page-transitions.htmlhttp://www.ibm.com/developerworks/web/library/mo-jquery-mobile-components/index.htmlhttp://jquerymobile.com/test/index.html


8/8



TAGS:

POSTED BY SOEDERQUIST 3 WEEKS 4 DAYS AGO

Web enthusiast, web developer, web user

working at Swedish mobile agency Mobiento

Why Mobile Web Accessibility Matters - Best Practices to Make Your Mobile Site Accessible |...

Documents

Transcript of Why Mobile Web Accessibility Matters - Best Practices to Make Your Mobile Site Accessible |...