dotMobimobiThinkingmobiForgemobiReadyDeviceAtlasgoMobi
background image

Why mobile Web accessibility matters - best practices to make your mobile site accessible

Drawing of hand in dark reaching for bright light
Posted by soederquist - 13 Sep 2012
Twitter share icon Facebook share icon Google Plus share icon

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Tim Berners-Lee, 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). 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 W3C’s Web Content Accessibility Guidelines (WCAG); and adoption of the principles of Semantic Web (semantic markup describes the purpose of code and is very useful for screen readers as we will see in Tip 5).

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. There’s 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 <anchor>s and <button>s for click events – which make it obvious to screen readers what is a clickable link – events are bound to list items and <div> elements – 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.
(See W3C on similarities between accessibility and mobile Web)

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

The most important application, however, from a mobile Web developer’s 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 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.

graph shows: 71 percent of screen reader users, use a mobile screen reader. 48.7 percent use VoiceOver, 17.9 percent use Nuance Talks and 8.5 percent use Mobile Speak
Figure 1: Use of screen readers on mobile devices.

12 simple tips to help make your site more accessible

Developing an accessible mobile site isn’t 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

Image shows: Contrast ratio calculator, which helps Web developers choose accessible color schemes.Many users, even those without any severe visual impairment struggle 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 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 (pictured) from MSF&W. See W3C and Speckyboy 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:

<meta name="viewport" value="initial-scale=1.0, user-scrollable=no">
Or:
<meta 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 what’s 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:

<meta 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 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 the base font-size of its parent element. It’s 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{ 
	font-size: 100%; /*Defaults to 16px*/ 
} 
small{ 
	font-size: 0.75em; /* 12px/16px = 0.75 */ 
}

3) Specify language

One of the most common and annoying mistakes, I’ve found using a screen reader myself, is when developers forget to specify the language of the page using the lang attribute within the <html> 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: <html lang="en">. To specify UK English with British pronunciation, use: <html lang="en-GB"> and US English with US pronunciation: <html lang="en-US">.

4) Content first

Before adding any style and graphics to your design make sure everything is understandable without images and CSS. No semantic elements (i.e. the ones that describe what they do, such as <a>link</a> and <p>paragraph</p>) should never be empty. All images should have alt attributes describing the purpose/function of the image (rather than a description of what is displayed). If the image doesn’t 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 design intends 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:
• 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{ 
	position: relative; 	
	text-indent: -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{ 
	position: absolute; 
	left: -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 of new semantic elements, which enable developers to mark up the DOM (the Document Object Model defines the structure, style and operation of a Web page) in a more structural and comprehensible manner.

Using the <nav> element to designate the main navigation and <article> 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 <div> element is overused and used for almost every purpose. This isn’t necessarily due to the direct action of the Web developer, but the choice of framework (more on this in Tip 11 below). The markup is your toolkit, use it wisely.

For <form>s 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: <label for>.

6) Structure your rich Internet applications

To further enrich the semantics of you site, the W3C’s Web Accessibility Initiative for Accessible Rich Internet Applications [WAI-ARIA] provides a set of roles to define the meaning and purpose of elements commonly used in Web apps.

Image shows: majority of screen reader users use ARIA landmarks.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, 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, banner, complementary, contentinfo, form, main, navigation and search (i.e. role="banner").

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" on the link will make a screen reader interpret it as a button. Similarly set the widget roles as alert, dialog, option, or 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 as their own elements, such as tab, tabpanel, treeitem and timer.

• 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 W3C’s solution to this issue is to use WAI-ARIA attributes. 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 of tablist, 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 every interaction with the component.

<ul role="tablist" class="tabs"> 
	<li><a role="tab" class="selected" href="#area1" id="tab1">Area 1</a></li> 
	<li><a role="tab" href="#area2" id="tab2">Area 2</a></li> 
</ul> 
<article class="selected" id="area1" role="tabpanel" aria-hidden="false" aria-labeledby="tab1">...</article> 
<article id="area1" role="tabpanel" aria-hidden="true" arialabeledby="tab2">...</article>
When using more advanced AJAX functionality, containers of regularly updated content should be defined as live regions. The aria-live attribute sets the rules as to how screen-reader users are notified of updated content.
<section aria-live="polite" aria-busy="true">Loading</section>
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 stop 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 should be able to make any mobile Web application accessible.
Get started by reading: Introduction to WAI ARIA.

7) Outline your document

The document outline 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 <h1> to <h6> 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.

HTML5 made document outlines clearer by introducing the <article> and <section> elements (the difference between the <article> and <section> is explained here).

<article>
 	<h1>Mobile accessibility</h1>
 	<p>Mobile sites should be accessible…</p>
 	<section>
		<h2>12 simple tips</h2>
  		<p>Follow these carefully.</p>
  		<section>
   			<h3>Tip 1: readability</h3>
       		<p>Think about font size and color contrast.</p>
  		</section>
		<section>
   			<h3>Tip 2: Allow zooming</h3>
       		<p>Let people enlarge the text.</p>
  		</section>
	</section>
	<section>
		<h2>Further reading</h2>
  		<p>Check out these articles…</p>
	</section>
</article>

In HTML5, you could theoretically create documents using the <h1> 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 <h1> to <h6> with <section>s as demonstrated in the example above.

8) Redirect, don't disrespect

Image shows: Guardian mobile site with options to switch to desktop site.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) Don’t 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), meaning that the site/app’s custom touch events might be ignored. There’s nothing wrong with touch interaction, just make sure there’s always an easy alternative way to interact.

10) Progressively enhance

Progressive Enhancement 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 people with 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 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 is one of the most popular user interface (UI) frameworks, providing developers with a library of ready-made components (e.g. dialogue boxes, toolbars and buttons) CSS transitions (e.g. fade, pop, flip, slide) widgets (e.g. accordion, autocomplete, slider). JQuery mobile was built, in collaboration with Filament Group, to the highest accessibility standards, incorporating all aspects of W3C's WAI-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, 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 there’s an ocean of <div> 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 is impossible 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. To activate VoiceOver, go to Settings > General > Accessibility. Now start 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 doesn’t 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 (free 30-day trial version available).
The Nokia Screen Reader (free app).
Mobile Speak for Nokia and Windows Mobile (free 30-day trial version available).
Nuance TALKS (trial version available).


Big Thanks to Artur Ortega @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

Posted by soederquist - 13 Sep 2012

soederquist's picture

Web enthusiast, web developer, web user
working at Swedish mobile agency Mobiento

Posted by ebo 1 year ago

Hi, i'm a wordpress user, i used wp touch plugin for my mobile visitor. Do you think this is enough, or i have to do something else (installing another plugin?). yours, Berita Terkini