Mobile And Accessibility: Why You Should Care And What You Can Do About It

Advertisement

Mobile has revolutionized the way we use the web. This is especially true of disabled users, for whom mobile devices open the door to a whole new spectrum of interactions.

And they are taking advantage of it. A July 2013 survey1 (PDF) of adults with disabilities done by the Wireless Rehabilitation Engineering Research Center2 found that 91% of people with disabilities use a “wireless device such as a cell phone or tablet.” Among these users, screen reader usage is common, even on mobile devices.

A study of 1782 screen reader users3 done by Web Accessibility in Mind4 (WebAIM) in 2012 showed that 71.8% used screen readers on their mobile devices. And we’re not talking about only a handful of people. The 2010 U.S. Census found that nearly one in five people have a disability5!

Graphical representation of WebAIM's survey results

The results of WebAIM’s study of screen reader users (Source: WebAIM6)

Despite this, many basic best practices for accessibility are forgotten on mobile websites. Developers implement complex solutions such as responsive design and responsive images, yet forget about basic techniques such as image replacement. Therefore, disabled users — who have a difficult enough time on the desktop — are frequently presented with interfaces that are at best frustrating, and at worst, impossible to use.

While accessibility can be a complex topic, following a few best practices goes a long way towards building accessible sites and applications. In this article we’ll discuss a few practical measures that address the most common issues disabled users encounter. Specifically, we’ll look at the importance of the following:

  • making sure everything works with a keyboard,
  • marking up forms semantically,
  • providing plenty of contrast,
  • ensuring that screen readers know what your controls do,
  • testing your website on an actual screen reader.

We’ll see that following these best practices leads to a better experience for everyone, not just disabled users. Let’s get started by looking at a piece of hardware rarely considered in the mobile space: the keyboard.

1. Make Sure Everything Works With The Keyboard

While we usually associate keyboards with traditional desktops and laptops, the situation is no longer that simple. Microsoft’s Surface tablet has a keyboard built into the cover, Bluetooth keyboards are made to work seamlessly on iOS and Android, and some keyboards can even be rolled up7 for traveling.

Keyboard navigation on mobile websites has become increasingly important also because more websites are built responsively. Because these websites serve the same markup to all devices, the keyboard must function correctly, even if the vast majority of visitors use a touchscreen.

Image of a keyboard
Keyboard support is important, even on mobile. (Image: Shane Pope8)

Try putting your mouse away and visiting your website. Can you perform all tasks using only your keyboard? If not, then neither can keyboard users. Two main problems break keyboard navigation on the web. Let’s discuss each.

Not Using the Correct Element for the Task

Web browsers are really good at making keyboard navigation work automatically, as long as you use semantically appropriate elements. In particular, the following elements are focusable by default: <button>, <a> (with an href attribute), <input>, <select> and <textarea>. For these elements, keyboard navigation just works without any extra effort. However, developers frequently fail to use these elements appropriately, specifically <button> and <a>.

Buttons should be used for controls that perform actions, whereas links should be used for controls that navigate users to other documents. However, developers often incorrectly use generic elements, such as <span> and <div>, for controls that perform these actions. Consider the iPhone landing page of Fidelity9, a banking institution.

Fidelity's home page

Are those buttons on Fidelity’s iPhone landing page or not?

The two controls on this page sure look like buttons, but they’re actually generated by the following markup.

<div id="download_button">
	<div id="download_text" onclick="goToStore();">Download the Fidelity App</div>
</div>

<div id="no_thanks_button" onclick="goHome();">
	<div id="no_thanks_text" onclick="goHome();">No thanks</div>
</div>

Because of this, keyboards will not navigate to these controls. They would, however, if the controls were marked up as actual <button> elements.

<div id="download_button">
	<button id="download_text" onclick="goToStore();">Download the Fidelity App</button>
</div>

<div id="no_thanks_button" onclick="goHome();">
	<button id="no_thanks_text" onclick="goHome();">No thanks</button>
</div>

While this most commonly happens with buttons, links are often misused as well. Consider the popup that people see when visiting American Express’ home page10 on an iPad:

American Express' home page

American Express shows this popup to iPad users on its home page.

Despite the “Click here to download the American Express app” being a simple link, American Express uses the following HTML:

<div class="asl-link" role="link">
	<div class="asl-app-store" title="...">
		Click here to download the American Express® App
	</div>
</div>

The linking is done in JavaScript, with a click handler that changes window.location. Because a <div> is used, keyboards cannot access the control, but they would be able to if an <a> element were used.

<div class="asl-link">
	<a href="..." class="asl-app-store">
		Click here to download the American Express® App
	</a>
</div>

(On a related note, the “close” button in American Express’ popup is also a <div>, so keyboard users can neither perform that action in the popup nor close it.)

American Express could also have used the Apple approved11 method of informing users that an app is available with an apple-itunes-app <meta> tag.

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

In general, browsers provide keyboard access automatically for semantic elements. But what if you’re using elements more complex than a simple <button> or <a>?

Writing Your Own Complex Widgets

As web developers, we often use widgets for complex interactions in our interfaces. We do this sometimes to work around deficiencies in a platform (for example, to build a more customizable <select> element) and sometimes to build a powerful UI element (for example, a grid, tab or chart).

Let’s look at replacing a <select> element. On the surface, this seems like an easy widget to write:

  1. Create a <div>.
  2. Create a <ul>, with an <li> element for each replacement <option>.
  3. On a click of the <div>, open the menu.
  4. On a click of an <li> element, transfer the value back into the <div>.

Easy.

However, consider all of the keyboard controls that a native <select> element has:

  • The space bar opens the menu of options.
  • The up and down arrows open the menu and cycle between options.
  • The page-up and page-down keys cycle through whole pages of options in long lists.
  • The “Escape” key closes the menu.
  • Typing in values while the element has focus will trigger autocompletion options.

Suddenly, replicating the native <select> element has gotten significantly harder. Not to mention that we have to ensure that screen readers can access the options and read them at the appropriate time.

To make these complex interactions possible, a special set of HTML attributes is available to provide the necessary context to screen readers. These are known as Accessible Rich Internet Applications12, or ARIA attributes.

The main ARIA attribute, role, tells browsers and assistive devices the general type of an object — for example, dialog, slider or alert. From there, a number of aria-* attributes are used to provide more detailed information about an element’s state. Below is a boilerplate for developing an accessible <select> replacement.

<span tabindex="0" id="button" role="combobox"
	aria-expanded="false" aria-autocomplete="list" aria-owns="menu"
	aria-haspopup="true" aria-activedescendant="option-1"
	aria-labelledby="option-1" aria-disabled="false">
		One
</span>

<ul aria-hidden="true" aria-labelledby="button" id="menu"
	role="listbox" tabindex="0" aria-activedescendant="option-1"
	style="display: none;">
		<li id="option-1" role="option" tabindex="-1">One</li>
		<li id="option-2" role="option" tabindex="-1">Two</li>
		<li id="option-3" role="option" tabindex="-1">Three</li>
</ul>

Screen readers use these ARIA attributes to help keyboard users operate these controls. For example, because this example’s <span> has a role of "combobox", VoiceOver on OS X reads “You are currently on a combo box, type text or, to display a list of choices, press Control-Option-Space.” VoiceOver knows what choices are available because the <span> has an aria-owns attribute set to "menu", the id of the <ul> that contains the options.

But as you can see, there are a whole lot of ARIA attributes to account for; therefore, because of the difficultly of getting this right, most developers are better off using a JavaScript UI library for such controls rather than building them themselves. Many big libraries ensure that these controls are accessible by applying appropriate ARIA roles13 and keyboard shortcuts automatically. For example, jQuery UI’s upcoming selectmenu14 and Kendo UI’s DropDownList15 both generate accessible <select> replacements.

This concludes our look at supporting keyboard navigation on the web. While this set of guidelines is by no means comprehensive, it should help you get the most important parts of your website working properly. For a more thorough list of keyboard accessibility, see the W3C’s complete guidelines16.

Next, we’ll look at another often abused best practice: building semantic forms.

2. Mark Up Forms Semantically

With the proliferation of single-page applications — especially mobile ones — a diminishing number of websites use native HTML form submissions. Instead, data is submitted to the server by JavaScript-initiated XMLHttpRequests. While nothing is inherently wrong with this, using the same semantic markup that you would use if the data were to be sent with a native HTML form submission is still important.

Most screen readers have entire modes dedicated to form interaction that require forms to be marked up correctly. Consider this log-in form:

Username: <input type="text" id="username" name="username">
Password: <input type="password" id="password" name="password">
<button>Submit</button>
<script>
	document.querySelector( "button" )
		.addEventListener( "click", function() {
			// Send AJAX request to log user in
		});
</script>

While this form will log users in, it has a few problems that would make it painful for power users and impossible for impaired users to complete. Let’s look at the issues in turn.

Associating Labels With Inputs

Most screen readers require that form elements — <input>, <select> and <textarea> — be associated with <label> elements that describe them. Each <label> element should have a for attribute that corresponds to the appropriate form element’s id attribute, as shown here:

<label for="field">Field:</label>
<input id="field">

As is, our log-in form does not have this association, which would trip up assistive devices. Below is the user name <input> that we’re currently using. Note that there is no <label>.

Username: <input type="text" id="username" name="username">

When this user name <input> gets focus, the screen reader NVDA4117 simply reads “Edit text, blank.”

This is common in the wild, unfortunately. Amazon, for instance, has a trimmed-down website, amazon.com/access18, that is “optimized for screen readers and mobile devices.”

The website is appropriately simple, with a single search box and a short list of links. Ironically, though, despite directing screen reader users to this page, Amazon has not given its search <input> a <label>; thus, many screen reader users will have no idea that the <input> can be used to search.

Image showing that amazon.com/access does not have a label for its search field.
Amazon’s accessible website does not associate the “Search” label with the text box.

(Note: As with browsers, screen readers vary in their support of markup patterns. In the example above, VoiceOver does read the “Search” text, but NVDA does not. We’ll discuss compatibility testing later in this article.)

We can easily solve this problem in our sample form with a few <label> elements:

<label for="username">Username:</label>
<input type="text" id="username" name="username">

<label for="password">Password:</label>
<input type="password" id="password" name="password">

<button>Submit</button>
<script>
	document.querySelector( "button" )
		.addEventListener( "click", function() {
			// Send AJAX request to log user in
		});
</script>

Now all screen readers will associate each form element with a label that describes it. This practice is beneficial to more than users of assistive devices. All browsers are smart enough to transfer clicks on <label> elements to their associated <input>, <select> or <textarea> elements.

Ever had trouble clicking a 10 × 10-pixel checkbox to accept a service’s terms of use? On websites with semantic markup, you can click a checkbox’s far larger label instead. On mobile devices, bigger targets help fat fingers hit them:

Image showing the effect of using labels on form elements19
Clicking a label gives focus to the corresponding control.

This solves one problem with our log-in form. But there’s still one more issue to discuss.

Handling the “Enter” Key

Have you ever noticed that some log-in forms on the web can be submitted by pressing the “Enter” key in a textbox and some cannot? What makes the “Enter” key work for a submission?

Submitting with the “Enter” key is known as an implicit submission20, and it is supported by all browsers — even mobile ones. There are only two requirements to making implicit submission work.

  1. All <input> elements need to be in a <form>.
  2. If the form has more than one element — <input>, <select> or <textarea> — then the <form> must have a “Submit” button.

Our sample form already has a “Submit” button (the default type of <button> is submit). Therefore, we only need to add a <form>.

<form method="POST">
	<label for="username">Username:</label>
	<input type="text" id="username" name="username">

	<label for="password">Password:</label>
	<input type="password" id="password" name="password">

	<button>Submit</button>
</form>
<script>
	document.querySelector( "button" )
		.addEventListener( "click", function( event ) {
			// Prevent the default form submission
			event.preventDefault();

		// Send AJAX request
	});
</script>

A couple of things to note:

  • When implicit submission occurs, the browser performs a click on the <form>’s “Submit” button. Therefore, listening for click events on the “Submit” button to perform submit actions is still safe. You could, alternatively, listen for a submit event on the <form>.
  • Even though JavaScript will intercept the form’s submission, method="POST" is still explicitly declared. In case JavaScript fails (because of unsupported browsers, network issues, etc.), we don’t want the browser to submit a GET request that would place the user-supplied user name and password in the query string.

Enabling implicit submission saves mobile users some clicking. The image below shows two <input> elements, one in a <form> and one not. Note that the <form>-based example can be submitted while the <input> has focus — no need for additional taps or hunting for a “Submit” button.

This image shows two input elements, one in a form and one not. The one in the form has a Go button that submits the form, and the one not in the form has a Return button that does not submit the form.
Implicit form submission works only with true form elements.

This concludes our look at building accessible forms. As with keyboard access, these guidelines are far from comprehensive, but they address some of the most common problems with forms today. For a more complete list of best practices, check out the W3C’s guidelines for collecting input from users21.

Next, we’ll look at a problem that most smartphone owners have experienced at some point: low contrast.

3. Provide Plenty Of Contrast

If you’ve ever used your phone outdoors, especially in harsh sunlight, then you’ve struggled to read the screen at some point. This is not unlike what some users with vision disabilities experience all of the time.

When designing any website, remember that most users will not be visiting it indoors on a high-end monitor like yours. This is especially critical for mobile websites because of the wide variety of contexts in which people use their phone.

How do you make your website adapt to these contexts? Unlike more subjective aspects, contrast ratio can be calculated, and the W3C puts numeric guidelines for these ratios in its “Web Content Accessibility Guidelines22” (WCAG), a series of recommendations for making web content more accessible to individuals with disabilities.

The WCAG defines three levels of conformance: Level A, Level AA and Level AAA. According to the specification23, for a website to conform, Level A requirements must be met, Level AA requirements should be met and Level AAA requirements may be met.

The Level A contrast ratio is set at 3:1; Level AA is set at 4.5:1; and Level AAA is set at 7:1. As a point of reference, the specification recommends24 a contrast ratio of 4.5:1 for users with 20/40 vision, which is common among elderly people.

This means that we should make our contrast ratios at least 3:1 and, ideally, 4.5:1 or greater. But, how exactly do we calculate this?

Calculating Contrast Ratio

Luckily, Lea Verou25 has created a tool to calculate contrast ratio26 easily.

It’s simple to use. Input a background color and a text color, and the tool will output the contrast ratio:

Image showing how Lea Verou's tool can be used to calculate contrast ratio.
Lea Verou’s tool determines the contrast ratio between text and its background.

A couple of things to note:

  • The tool supports any CSS color that the browser supports. So, keywords (e.g. white), HEX, RGB, RGBa, HSL and HSLa are all accepted.
  • The tool generates unique URLs as you input valid values. For developers, this feature is perfect for telling designers that their gray on light-gray design is a bad idea27.

While high contrast seems like common sense, plenty of poor contrast can be found in the wild, even on major websites. Square’s28 footer fails Level A:

The footer on squareup.com
Square’s footer has very low contrast.

The footer text on squareup.com has a contrast ratio of 2:4.
Square’s footer fails Level A.

Even Facebook29 is guilty. The links in its header on the desktop fail to meet Level A as well:

The header on facebook.com's desktop page
The text in Facebook’s header has very low contrast.

The header text on facebook.com has a contrast ratio of 2:4.
Facebook’s header fails Level A.

To summarize, giving all of your text a contrast ratio of at least 3:1 (and, ideally, 4.5:1 or greater) will make it accessible to people with vision impairments, as well as make it more readable for everyone. Lea Verou’s tool is perfect for calculating contrast ratios and sharing the results with others.

To find out more about conformance levels, the WCAG has a formatted checklist of criteria30 for each level.

Next, we’ll return to discussing screen readers — specifically, making sure they can understand our websites.

4. Ensure That Screen Readers Know What Your Controls Do

Earlier, we looked at a WebAIM study that shows that 71.8% of screen reader users also use a reader on their mobile device. In this same study, users were asked for the most common problems they experience on the web31. Third and fourth on this list are the following:

  1. links or buttons that do not make sense,
  2. images with missing or improper descriptions (alt text).

(First and second on the list are Flash and CAPTCHAs. Please don’t use either.)

The following snippet shows both of these problems.

<style>
	button {
		background: url('search.png') no-repeat;
	}
</style>
<button></button>

<img src="ABC123.jpg">

The <button> would not make sense to a user on a screen reader; nothing would be read. For the <img>, screen readers would literally read ABC123.jpg, which is not very helpful.

The fixes for these problems are well documented. For the <button>, we can add text to our control and use one of many image-replacement techniques32 to make the text invisible to sighted users. The snippet below shows one of these techniques: applying a large negative text-indent rule.

<style>
	button {
		background: url('search.png') no-repeat;
		text-indent: -9999px;
	}
</style>
<button>Search</button>

The fix for the <img> is as simple as adding an alt attribute that describes the image.

<img src="ABC123.jpg" alt="A view of the trees outside my window in Lansing, Michigan">

Despite these problems being well known and easy to fix, they continue to be abundant across the web. To prove this, let’s look at some actual websites. I live in the great US state of Michigan, known for its association with the “Big Three” automakers: Ford, GM and Chrysler. Surely, these large companies have produced accessible mobile websites that don’t violate these practices… right?

Case Study: The Big Three Automakers

Let’s start with GM. Its mobile website33 is shown below. The appended text in quotation marks shows what VoiceOver on OS X actually reads when the corresponding element is selected.

Visual display of m.gm.com's accessibility issues34
GM’s mobile website has accessibility issues. Items in quotation marks are what VoiceOver on OS X actually reads.

As you can see, GM’s website relies heavily on large images that serve as links to additional content. Unfortunately, GM provides no text for these links, so screen readers are limited to the information they can find in the images. GM does provide alt attributes for these images; but, strangely, they are set to the images’ file names. For example, here is the source for the Cadillac image:

<img title="HomepageBrand_Cadillac_290x170.jpg" height="85"
alt="HomepageBrand_Cadillac_290x170.jpg" class="side-gutters"
src="/content/dam/gm/Global/master/mobilesite/en/home/Homepage/HomepageBrand_Cadillac_290x170.jpg">

Thus, when this image is selected, VoiceOver literally reads “Homepagebrand underscore Cadillac underscore two nine zero x one seven zero dot jpeg.”

GM fails our tests, then. Next, let’s try Ford, whose mobile website35 is shown below.

Visual display of m.ford.com's accessibility issues36
Ford’s mobile website also has accessibility issues. Items in quotation marks are what VoiceOver on OS X reads.

Ford has some of the same problems as GM. Its banner is a link that has no text and an image with no alt attribute; so, VoiceOver reads “index.html image.”

Below this, Ford has a fancy 3-D cube effect with images of its vehicles. Unfortunately, this is implemented with a number of <div>s, with background-images and JavaScript that takes the user away on click. Therefore, screen readers have absolutely no idea what’s going on in this large portion of the screen. VoiceOver on iOS just beeps when you touch this “cube” that takes up half the screen.

Finally, the “links” at the bottom of the screen are not actually links; they are <div>s with onclick attributes that change window.location to navigate the user. Thus, these controls are inaccessible from the keyboard and are confusing for screen readers.

Just when you thought things couldn’t get any worse, let’s look at the last of the Big Three automakers, Chrysler. Its mobile website37 is shown below.

Visual display of m.chrysler.com's accessibility issues38
Chrysler’s mobile website, too, has accessibility issues. Items in quotation marks are what VoiceOver on OS X reads.

You can see that almost nothing on Chrysler’s website provides any context for screen readers. We are reminded of the importance of meaningful alt attributes. Here, the one alt attribute that is provided — “This Is the Hero Carousal” — is less than helpful. Worse, all images in the carousel have the exact same alt attributes; so, screen reader users would have no idea that different links are being presented. To add insult to injury, the word “carousel” is spelled incorrectly (“carousal”), causing it to be mispronounced.

These carousel images occupy over half the space on an iPhone screen and are almost certainly the most clicked-on items on the screen. An alt attribute should tell users something about the image they’re seeing, as well as where they will go if they click the link. For example:

<img src="/path/to/TnC.jpg" alt="Learn more about the J.D. Power 2013 award-winning Chrysler Town & Country">

This tells screen reader users what the link is for and what they will see if they select it.

Unfortunately, examples like these are far too common. Even though many accessibility best practices are well documented, they are frequently forgotten — even on big websites and especially on mobile.

Why?

One reason is that the consequences of violating these best practices are not obvious. To sighted touch users, all of these websites operate fine. Secondly, no good way exists to automate your website’s accessibility. The W3C’s validator39 will warn of missing alt attributes, but it cannot test for more complex scenarios, such as icon buttons and lack of keyboard functionality. It also cannot test whether the alt attributes are actually meaningful.

Because of this, we must trust all web developers to learn and remember to use accessibility practices that have no apparent benefit. As we’ve seen in this case study, frequently they don’t.

But all is not doom and gloom. We’ve seen that applying a few easy-to-implement best practices can drastically improve the accessibility of your sites, and open them to a new, surprisingly large audience. That building accessible sites builds a better experience for everyone.

But if the W3C validator cannot catch accessibility issues, how do you verify that you’re applying these best practices correctly? As it turns out, the best way to test the accessibility of your site is also a great way to gain insight into how disabled users interact with it — by using a screen reader.

5. Test Your Website On An Actual Screen Reader

Most web developers have a slew of browsers and devices to test their websites, yet few know how to use a single screen reader. Unfortunately, this has led most developers to treat accessibility guidelines as some sort of voodoo. They conjecture about what’s best for impaired users without actually testing their theories.

This is a shame, because the best way to discover whether your website is accessible is to try it out as an impaired user would. Personally, I’m not sure why screen readers are shrouded in mystery; they’re actually quite easy to use.

If you’re on a Mac, type Command + F5 to activate VoiceOver. Navigate around this page with the Tab key and see what’s read. You can also press Control + Option plus the left and right arrow keys to target content that is not in the tab order. There are more advanced controls available40, but you can get the idea with these basics.

If you’re on Windows, you can download and use NVDA4117 for free. JAWS42 is the most popular paid reader; it has a demo mode that you can try for free.

Mobile devices are a tad different because there is no keyboard by default. Therefore, using a screen reader forces you to reconsider how you interact with your device. Let’s explore this by looking at the screen readers built into iOS and Android — VoiceOver and TalkBack, respectively.

Using VoiceOver on iOS

VoiceOver is iOS’ primary accessibility aid for all applications, not just the Web. Because most users don’t use it, VoiceOver is disabled by default. To enable it, go to Settings → General → Accessibility → VoiceOver. You’ll see the screen shown below.

VoiceOver’s settings screen
The settings screen for VoiceOver on iOS

Be warned — once you turn it on, VoiceOver will fundamentally change the way you interact with the phone. Therefore, you must learn the basics; otherwise, you won’t be able to turn VoiceOver back off.

Once VoiceOver is on, a single tap on the screen will select an item but will not activate it. For example, if you tap on the Safari icon, VoiceOver will read “Safari” but will not launch the application. After a selection, a double tap is needed to actually start the application. This makes sense if you consider the perspective of someone who cannot see the icon. They would need confirmation that they’ve selected the correct item before activating it.

The other important difference with VoiceOver is that you have to use three fingers to scroll. Why? Because while in VoiceOver mode, iOS listens for one-finger “flick” gestures in all four directions:

  • “Up”
    Move to previous item based on rotor setting
  • “Down”
    Move to next item based on rotor setting
  • “Right”
    Move to previous item
  • “Left”
    Move to next item

What’s this “rotor”? We’ll get to that in a moment. First, try flicking left and right on the screen to move between available items. These flicks let vision-impaired users discover what’s on the screen without having to tap around.

Things get more interesting with VoiceOver’s rotor, a means of configuring how to navigate between items on the screen.

To activate the rotor, rotate two fingers on the screen as if you were turning a dial. The rotor and its default options are shown below.

VoiceOver's rotor with the various settings: words, lines, speech rate, containers, headings, links, form controls, and characters - annotated.
The rotor control in VoiceOver for iOS

By setting the rotor, you can change how up and down flicks navigate the page. For instance, if the rotor is set to “Links,” then up and down flicks will cycle between links on the page and nothing else. In this sense, the rotor acts as a filter, enabling users to sift through the type of content that they’re interested in.

The rotor shows the importance of semantic markup. If your links are not actually <a> tags, then they won’t show up in the rotor setting for “Links.” If your form’s controls are not actual form elements, then they won’t show up in the rotor setting for “Form Controls.”

As you can see, using a screen reader forces you to fundamentally change how you use and approach the web on a mobile device. Play around with any websites you maintain to see how well you can navigate and accomplish tasks. As an added challenge, once you’re familiar with VoiceOver, try closing your eyes and see what you can get done.

Using TalkBack on Android

Like VoiceOver, TalkBack is an accessibility service for vision-impaired users that is native to Android devices. Because most people do not need the service, it is also disabled by default. To enable it, go to Settings → Accessibility → TalkBack and tap the switch shown below.

TalkBack's settings page
The settings page for TalkBack on Android

Again, be warned. Once TalkBack is activated, you’ll at least need to know the basic controls to turn it off.

TalkBack’s controls are extremely similar to VoiceOver’s. One tap selects an item, and a double tap activates it. Scrolling with TalkBack requires two fingers (recall that VoiceOver requires three), and TalkBack listens for the same flick actions to move between items on the page.

While TalkBack has nothing comparable to VoiceOver’s rotor, it does support a number of additional gestures43 to customize the navigation.

Wrapping Up

In this article, we’ve discussed a number of best practices to improve the accessibility of your websites. How do you apply this information to your existing or new websites? Here are a few action items:

  • Keyboard
    • Make sure that all tasks can be performed using only the keyboard.
    • Use semantic elements — <button> for buttons and <a> for links.
    • If you’re having trouble making complex widgets keyboard-friendly, consider using a framework.
  • Forms
    • Use the actual <form> element.
    • Associate all form elements (<input>, <select> and <textarea>) with a <label>.
    • Make sure the “Enter” key can be used to submit the form.
  • Contrast
    • Ensure that all text has a contrast ratio of at least 3.0, using Lea Verou’s Contrast Ratio44. Ideally, all text should meet this criterion, but focus on the main content first.
  • Images
    • Include alt attributes that describe the images.
  • Links and buttons
    • Always give these controls readable content. If the content should not be shown to sighted users, then use an image-replacement technique to hide it.

While this list is not comprehensive, it does provide a number of practices that are easy to implement and that address the most common problems affecting disabled users. Furthermore, we’ve seen that adhering to these guidelines benefits everyone, not just the disabled.

Finally, the best way to test your website is on an actual screen reader. By taking mere minutes to learn some commands, you will gain insight into how a good portion of the population interacts on the web.

Resources

(al, il)

Footnotes

  1. 1 http://www.wirelessrerc.org/sites/default/files/publications/SUNspot_2013-03_Wireless_Devices_and_Adults_with_Disabilities_2013-07-12%5B1%5D.pdf
  2. 2 http://www.wirelessrerc.org/
  3. 3 http://webaim.org/projects/screenreadersurvey4/#mobile
  4. 4 http://webaim.org/
  5. 5 http://www.census.gov/newsroom/releases/archives/miscellaneous/cb12-134.html
  6. 6 http://webaim.org/projects/screenreadersurvey4/#mobile
  7. 7 https://www.google.com/search?site=&tbm=isch&source=hp&biw=1600&bih=1008&q=roll-up+keyboard&oq=roll-up+keyboard
  8. 8 http://www.flickr.com/photos/24285431@N04/2375499336
  9. 9 http://www.fidelity.com/interstitial/index.shtml
  10. 10 https://www.americanexpress.com/
  11. 11 https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html
  12. 12 https://developer.mozilla.org/en-US/docs/Accessibility/ARIA
  13. 13 https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques
  14. 14 http://wiki.jqueryui.com/w/page/12138056/Selectmenu
  15. 15 http://demos.kendoui.com/web/dropdownlist/index.html
  16. 16 http://www.w3.org/WAI/WCAG20/quickref/#keyboard-operation
  17. 17 http://www.nvaccess.org/
  18. 18 http://amazon.com/access
  19. 19 http://www.smashingmagazine.com/wp-content/uploads/2013/10/label-focus.png
  20. 20 http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#implicit-submission
  21. 21 http://www.w3.org/WAI/WCAG20/quickref/#minimize-error
  22. 22 http://www.w3.org/TR/WCAG/
  23. 23 http://www.w3.org/TR/WAI-WEBCONTENT/#wc-priority-1
  24. 24 http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
  25. 25 http://lea.verou.me/
  26. 26 http://leaverou.github.io/contrast-ratio/
  27. 27 http://leaverou.github.io/contrast-ratio/#gray-on-lightgray
  28. 28 https://squareup.com/
  29. 29 http://facebook.com
  30. 30 http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html
  31. 31 http://webaim.org/projects/screenreadersurvey4/#problems
  32. 32 http://css-tricks.com/css-image-replacement/
  33. 33 http://m.gm.com
  34. 34 http://www.smashingmagazine.com/wp-content/uploads/2013/10/gm.png
  35. 35 http://m.ford.com/
  36. 36 http://www.smashingmagazine.com/wp-content/uploads/2013/10/ford.png
  37. 37 http://m.chrysler.com/
  38. 38 http://www.smashingmagazine.com/wp-content/uploads/2013/10/chrysler.png
  39. 39 http://validator.w3.org/
  40. 40 http://www.apple.com/voiceover/info/guide/_1131.html
  41. 41 http://www.nvaccess.org/
  42. 42 http://www.freedomscientific.com/products/fs/jaws-product-page.asp
  43. 43 https://support.google.com/nexus/answer/2926960?hl=en
  44. 44 http://leaverou.github.io/contrast-ratio/
  45. 45 http://www.w3.org/TR/WCAG/
  46. 46 http://www.w3.org/WAI/mobile/experiences
  47. 47 http://jzaefferer.github.io/talk-to-me/
  48. 48 http://contrastrebellion.com/
  49. 49 http://help.apple.com/voiceover/info/guide/10.8/English.lproj/
  50. 50 http://a11yproject.com/
  51. 51 http://www.nczonline.net/blog/2013/01/29/you-cant-create-a-button/

↑ Back to topShare on Twitter

TJ VanToll is a web developer, speaker, and writer living in Lansing, MI and working as a developer advocate for Telerik. He is an open source advocate that is on the jQuery UI team and publishes his blog open source. He is also the author of an upcoming book from Manning: jQuery UI in Action. When not online, TJ is generally found chasing his twin sons in circles.

Advertising

Note: Our rating-system has caused errors, so it's disabled at the moment. It will be back the moment the problem has been resolved. We're very sorry. Happy Holidays!

  1. 1

    Daniel Schwarz

    May 21, 2014 3:49 pm

    Wow, this article was more like a short book than an article *hint* – really awesome stuff. Mobile first is definitely the way to go, thanks for mentioning all the semantics. I’m big on using the right HTML5 tag for the right component, but have yet to try out the aria roles. It seems there is much more to accessibility than UI as technology evolves. I’m trying these techniques out on http://airwalk-design.com, search is one of the areas where it needs most work and I’m interested to try out designspiration’s method of “type to search” – would love to hear some thoughts on how that could be handled for mobile.

    • 2

      Hi Daniel,

      Thanks for the compliments on the article. I had never seen the “type to search” implementation on designspiration; it’s slick. From an a11y perspective their implementation is pretty good. They focus a textarea element when you click search, and the textarea is in a true form (with a true submit button), so the Enter key works. The one thing they’re missing is a label element that describes the textarea. Other than that it looks pretty good though.

  2. 3

    The hamburger icon doesn’t cut it. Make sure it includes text that says “Menu”.

    • 4

      Daniel Schwarz

      May 21, 2014 4:45 pm

      Tim,
      A really interesting study (with metrics) about the use of the hamburger icon: http://exisweb.net/mobile-menu-abtest.
      (nobody else liked it either)

    • 5

      Hi Tim. Personally I don’t necessarily think the “Menu” text has to be visually present, but if it isn’t, it absolutely needs to be included for screen reader users — either as an alt attribute or through an image-replacement technique.

      • 6

        Senior citizens need text to identify what icons do. Based on studies the company I work for has done, it is recommended to include text along with icons where possible.

        • 7

          keyword senior citizens. we should pay attention to accessibility, but sometimes it’s ok to compromise a little. the key is to know your audience.

        • 8

          But if “menu” is displaying in such a small font in or around the hamburger, do you really think a senior citizen will be able to read it?

  3. 9

    As far as contrast ratio is concerned, the requirements are a bit more complex than what is explained in this great article.

    At level A, there is no requirement for a minimum contrast ratio between the background behind text and the text. At level AA, the minimum contrast ratio between the background and the text is 4.5:1 for text which is less than 18 point (or 14 point if it is bold) and 3:1 for text which is at least 18 point (or 14 point if it is bold). At level AAA, the minimum contrast ratio between the background and the text is 7:1 for text which is less than 18 point (or 14 point if it is bold) and 4.5:1 for text which is at least 18 point (or 14 point if it is bold).

    At level A, the only requirement for a minimum contrast ratio concerns links which are indicated by colour alone. In this case, the contrast ratio between the link and the surrounding text must be at least 3:1.

    If you wonder about the equivalent to the thresholds in points in a screen-usage compatible unit, you can consider the 18-point threshold to be equivalent to 150% of the default font size (or 1.5rem) and the 14-point threshold (if the text is bold) to 120% of the default font size (or 1.2rem).

    • 10

      Hi Victor,

      Thanks for commenting and clarifying this. I focused on the background contrast, because—at least in my experience—that guideline is more egregiously violated. I probably should’ve mentioned that the requirements are more complex for those that need to adhere to the conformance levels.

      I actually didn’t know some of these details, such as the different requirements for bolded text. For anyone else curious (I at least can never remember this), assuming the user has not altered their browser’s default font-size from 16px, then 18pt = 24px = 1.5rem, and 14pt = 19px = 1.2rem.

      Thanks again Victor.

  4. 11

    Gurmukh Panesar

    May 22, 2014 2:18 pm

    Very useful and well laid writeup, thank you :)

  5. 12

    This is an excellent article, even for those of us who are a bit lots by all the technical details. I’m fascinated to learn more about VoiceOver and TalkBack, and I’ll definitely be noticing when I see sites that violate these rules.

    I hope this isn’t bad form, but for a more general look at why accessibility is important, my company published a blog a while back by our designer Dennis Kardys: http://www.wsol.com/the-accessibility-objective/ This article makes a good follow-up for those who want more technical details, so I’ll be sure to save it to link to whenever I need to let somebody know about the importance of accessibility.

  6. 13

    Kind of ironic: your captions (which are rgba(0,0,0,.4) on a white background) fail to meet the contrast requirements.

  7. 14

    Rafael Carrasco

    May 23, 2014 2:29 pm

    I have a doubt about contrast ratio. The recommendations always set mininum contrast and people usually assumes that the more contrast ratio, the better. But I’ve read somewhere (don’t remember exactly where), that too much contrast ratio is actually bad for dyslexics, since they will see the two colors “vibrating”. Is there a maximum recommended contrast that accounts for dyslexics? Or is this color vibrating thing an entirely different issue?

    • 15

      Jonathan Hassell

      June 1, 2014 9:32 pm

      You’re right Rafael. The colour contrast accessibility issue is more complex than just providing minimum levels, and people who are dyslexic or on the autistic spectrum much prefer pastel colours which are the complete reverse of the hi-contrast colours that people with vision impairments prefer.

      The idea that high colour contrast helps everyone is actually an ‘accessibility myth’, which is why personalisation of the text colours of a website is very useful.

      You can find a simple real-world example in my ‘accessibility myths’ slides at: http://www.slideshare.net/jonathanhassell/accessibility-myths-for-a-mobile-generation/61.

      Or, for those of you who want deeper research on this, check out http://www.tader.info.

  8. 16

    Neither can Google+ pass this, nor can even Smashing Magazine.
    http://leaverou.github.io/contrast-ratio/#rgb%28153%2C153%2C153%29-on-%23fff

    • 17

      Hey there Joan,

      our text-color here at Smashing is #333 and the background-color value is #fff.
      Where did you find the rgb Value you posted with the link? Is it the image-captions?

      I know we have parts of the website where we do not hit the ideal contrast-ratio but the overall content and articles should be just fine. =)

      Greetings, Marco.

  9. 19

    First, thank you for the deep dive and thorough article.

    Just wanted to point out that the automobiles of the big three are probably not designed well for the visually impaired, either.

    This brings up the question: When is it ok for a site to be less accessible than it could be?

    • 20

      Design for your target user right… visually impaired users probably can’t or won’t drive a car…

  10. 21

    Adrian Roselli

    May 26, 2014 5:02 pm

    TJ,

    I think your article does a great job of highlighting accessibility issues on mobile devices and rightly points out that “desktop” best practices apply.

    One feature of “mobile” devices (phones, tablets, phablets, or most touch devices) that is not shared in the same way as with desktops is pinch-to-zoom (really spread-to-zoom). As such, I think it bears special mention in your article.

    The general rule is: DO NOT disable zooming. When web developers do that, it becomes impossible for users to overcome cases where the text is too small, hit targets are too small, or contrast is poor.

    As you note, this doesn’t just affect disabled users, but even normal-vision users in sunlight.

  11. 22

    Web development company

    May 29, 2014 1:54 pm

    First, thank you for the deep dive and thorough article.

    Just wanted to point out that the automobiles of the big three are probably not designed well for the visually impaired, either.

    This brings up the question: When is it ok for a site to be less accessible than it could be?

  12. 23

    Gunnar Bittersmann

    May 30, 2014 8:42 am

    Very informative article. Thanks a bunch.

    One minus though: Why still propagate the -9999px image replacement when there are better ways? http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/

  13. 24

    Thanks for the article TJ. Well thought out and written. I’d add the following for the keyboard list:

    – Properly manage keyboard focus

    This is essential for keyboard only users, including screen reader users and usually deals with widgets. For example, if a dialog window is activated, throw focus to the dialog. When it is closed, focus the control that activated it.

    Example:
    dojotoolkit.org/reference-guide/1.10/dijit/Dialog.html

    Basically, direct screen reader users to and from widgets in the same way you do for visual users, but with focus.

  14. 25

    Just wanted to thank you for an excellent dive into mobile accessibility, and all the more so for pushing semantic tagging! Without articles like this one, you end up feeling like a lone voice in the wind sometimes.

    As to the mobile gaffes of the Big Three, can I just say that “Hero carousal” sounds like a fantastic idea? Very Beowulf of them… :-)

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top