Mobile Accessibility Best Practices

The generic term “mobile” refers to wide range of applications, content, and wireless technology that is easily portable and user-friendly in a variety of environments, including the outdoors.  Examples of mobile devices include laptops, tablets, netbook computers, and the full range of small, handheld technology or smartphones.  The term also applies to wearable technology, such as “smart” watches, “smart” eyewear, “smart” jewelry, “smart” clothing, virtual technology, and even fitness trackers.  Mobile technology can also be embedded inside household appliances, medical implants, airplane seating compartments, and the dashboards of automobiles. 

Many view mobile design to be a separate discipline from that associated with traditional desktop or laptop technology, perhaps requiring different accessibility, display, and navigational configurations.  However, the theoretical divide between “mobile” and “desktop” is merging into a single, more streamlined and interconnected interface.

• Many manufacturers of laptops and desktops now incorporate touchscreen gesture controls into many of their products.

• Many consumers now maximize the efficiency of mobile technology by occasionally connecting a keyboard or mouse for increased user-friendliness.

• Developers and webmasters are now focusing on responsive design techniques which allow for easy transitioning from the smaller screen size of a mobile device to the larger display requirements of a desktop or laptop.

• Mobile operating systems are even appearing in laptops, tablets, and netbook computers.

Furthermore, a large percentage of user interface patterns commonly found in desktop and laptops are now appearing in mobile applications.  Examples might include buttons, toggles, checkboxes, dropdown lists, pop-up menus, tables, sliders, and hyperlinks. Therefore, it should come as no surprise that developers of mobile-responsive applications and content are now applying a substantial number of WCAG 2.0 techniques.  To be clear, WCAG 2.0 is now highly relevant to both web and non-web mobile applications and content.

Even with these concepts in mind, there are still multiple accessibility issues of mobile technology that differ from those of conventional laptops and desktops.  The next section entitled “Considerations of Mobile-Related Design” will discuss how to address these many issues as they relate to WCAG 2.0 while offering additional best practices guidelines. The information presented in this training applies to mobile web applications, hybrid web-native applications, mobile website design, and mobile-responsive content.  Much of the provided guidance also applies to conventional applications or “mobile apps”, as well. 

Note:  For some mobile-related issues, WCAG 2.0 does not provide systematic testing criteria for success or failure.  A continuing primary objective of the WCAG Task Force is to develop new techniques and best practices in these areas on an on-going basis. In cases where the WCAG testable success criteria are not supported by existing techniques or best practices, no designation of sufficient, failure, or advisory is provided.  However, the lack of a designation does not mean that these issues are relevant to the creation of mobile-responsive content.  It simply means that the WCAG Task Force is currently working to resolve the designation issue and anticipates a resolution in future iterations of WCAG. 

This training presents existing WCAG 2.0 techniques applicable to mobile platforms while providing current best practices that directly address emerging challenges associated with mobile accessibility, including touch and gesture interface, issues of smaller screen size, and varying screen orientations associated with different mobile devices.

The primary objective of this training is to provide insights, guidance, and tutorial information regarding the interpretations and applications of the Web Content Accessibility Guidelines 2.0 (WCAG).   The WCAG merely offers recommendations. It does not set requirements.  As a result, developers can choose which recommendations to implement and which to ignore.

UAAG 2.0 and Accessible Mobile Web Browsers

The User Agent Accessibility Guidelines 2.0 (UAAG 2.0) offers techniques, best practices, and other strategies for developers of user agents, such as web browsers and media players, regardless of their intended use with either laptops, desktops, or mobile-responsive devices.  Mobile content, apps, and websites adhering to UAAG 2.0 techniques and guidelines will:

• Improve accessibility through its own user interface.

• Improve accessibility through provided options for rendering, navigating, and interacting with content.

• Improve accessibility through enhanced capabilities of intercommunication with other technologies, including assistive technologies.

Meanwhile, an additional resource entitled the UAAG 2.0 Reference contains several mobile-responsive examples specifically designed to assist developers of mobile web browsers. These examples are also available in a secondary list, which is consistently updated and maintained by the User Agent Accessibility Guidelines Working Group (UAWG).

ATAG 2.0 and Mobile-Related Authoring Tools

The Authoring Tool Accessibility Guidelines (ATAG 2.0) offers techniques, best practices, and other guidelines for the developers, regardless of the tool’s intended use with either laptops, desktops, or mobile devices. 

• Tools designed following ATAG best practices will be more mobile-responsive for use by authors with visual impairments and other disabilities.

• Tools designed following ATAG best practices will enable, promote, and support the production of mobile-responsive web content by all suppliers and authors.

The supportive document entitled Implementing ATAG 2.0 contains several mobile-responsive examples specifically designed to assist developers of authoring tools. 

The many different and substantially smaller screen sizes of mobile technology are perhaps the most common challenge associated with responsive web design. Even though today’s handheld technology offers exceptional resolution capabilities that hypothetically allow the quick and easy rendering of large chunks of metadata clearly, the smaller screen displays still limit the amount of information that can appear on-screen at one time.  When the user implements magnification tools for easier reading, perhaps due to visual impairments or difficulties, the problem only becomes more challenging.

Examples of best practices techniques for maximizing the potential of smaller screen sizes include the following:

• Minimize the amount of information displayed on each web page by providing a dedicated, secondary mobile-responsive page of the same content that is separate from the conventional laptop/desktop version. 

• A dedicated, secondary mobile version will contain web content that is tailor-made to complement the smaller screens of mobile devices.

  • For example, the web content might include fewer images or shortened content modules.

  • The web content might be reformatted to focus on issues related to mobile-responsive usage and features.

  • By using responsive design techniques, the web content will display consistently regardless of the mobile device or screen size.  Optimum CSS strategies will automatically adjust the rendered data according to the unique widths of the individual screens of the related mobile device. For example, the navigation menus may remain hidden from view on slimmer screens until the user clicks a space-saving menu button.

• Minimize the need for users with visual difficulties to zoom-in and zoom-out by providing a reasonable default size for content and touch controls (refer to section 3.2 Touch Target Size and Spacing Features).

• Minimize the length of included hyperlink text to adapt to the width limitations of smaller screens.

• Consider repositioning form fields below their labels rather than beside them.

Several available techniques allow users to manipulate and control content size on the smaller screens of mobile devices. At the web browser level, these strategies are generally useful for a wide variety of users. At the platform level, these methods are useful in managing accessibility features designed to assist people with cognitive disabilities or visual impairments. The different techniques include the following:

• Browser-level techniques 

• Set a reasonable default text size of text for rendering within the viewport of the web browser. 

  • Reading mode should allow content renderings at a user-specified text size.

  • Magnify the viewport of the web browser (Pinch Zoom).  

  • Note: This setting requires vertical or horizontal panning of the screen by the user.

    • Note: Some web browsers have included features that might further modify this type of magnification.  For example, the browser may have features that automatically override author attempts to magnify the viewport (Pinch Zoom) or that reflow the content at a pre-defined magnification level.

• Platform-level techniques 

• Set a reasonable default text size (typically maintained via the Display Settings). 

  • Note: System text size is often not supported by mobile browsers.

  • Magnify the entire screen of the mobile device (typically maintained via the Accessibility Settings). 

  • Note: Using this setting requires the user to pan horizontally and vertically.

  • Magnify the lens view located underneath the user's finger (also typically maintained via the Accessibility Settings)

The WCAG 2.1 WCAG testable success criterion that is most related to zoom and magnification features includes the following:

• 1.4.4 Resize text (Level AA)

SC 1.4.4 requires text to be resizable up to 200% without the need to for assistive technology. To meet this SC 1.4.4 requirement, the developer cannot prevent the user from manipulating the magnification features for the mobile-responsive web content.  The following techniques and methods may be useful:

• Do not allow the viewport metadata of a web page to block the Pinch Zoom of the web browser.  Always ensure that the text can be easily resized up to 200% by the user.

• Avoid values limitations for maximum-scale and user-resizable attributes of these meta elements. 

• Note: Relying on full-screen zooming (for example, making sure that the Pinch Zoom feature of the web browser remains unblocked) requires the user to pan vertically as well as horizontally. While this technique meets the testable success criterion, most users consider the additional panning to be less than practical.  As an alternative solution, manipulate the supporting text resizing features designed to reflow web content according to the unique screen size of the related mobile device chosen by the end user.  Best practices dictate the use of techniques that support text resizing without the need for horizontal panning.

• Use appropriate system fonts that adhere to the platform’s text size user preferences.

• Leverage relative font sizing units such as EMs instead of absolute values (PX). Relative units will allow the viewport to effectively scale to accommodate user font sizing needs. 

Accessibility features that are designed specifically for users with visual impairments and other disabilities fall under the definition of “assistive technology,” according to WCAG.  Furthermore, these features will not always meet the parameters of WCAG testable success criteria.  For example, a platform-specific zoom feature that magnifies related content while also having features that support users with visual impairments is likely considered an assistive technology.

Because mobile devices are more portable than laptops or desktops, they are also far more likely to be used outdoors where issues of sunlight and glare can easily arise or in different environments with extreme variances in ambient or power-generated lighting sources.  For this reason, the use of excellent screen contrast manipulation is crucial to responsive web design.  The challenges are only compounded for visually impaired users accessing content with poor contrast on mobile devices.

The WCAG testable success criteria related to contrast issues include the following:

• 1.4.3 Contrast (Minimum) (Level AA) 

• Requires a minimum screen contrast ratio of 4.5:1 for standard text

  • Requires a minimum screen contrast ratio of 3:1 for larger text.

1.4.6 Contrast (Enhanced) (Level AAA) 

• Requires a minimum screen contrast ratio of 7:1 for standard text

• Requires a minimum screen contrast ratio of 4.5:1 for larger text.

SC 1.4.3. allows for different contrast ratios for large-scale text, which is very useful because larger text with wider individual text characters is often easier to read at a lower contrast. This technique offers designers increased flexibility for contrast of large-scale text, such as titles, subtitles, and calls-to-action.

SC 1.4.3 considers 18-pt text or 14-pt bold text to be just large enough to enable a lower contrast variance for web pages viewed on a standard 15-inch monitor utilizing a 1024 x 768 resolution and from a viewing distance of up to 24-inches.  However, web content appearing on the smaller screens of mobile devices, from shorter viewing distances, and in varying levels of lighting and other environmental conditions requires the developer to carefully consider these contrast-associated allowances for large-scale text of mobile-responsive content.

For example, the default font-point sizes may vary significantly for mobile devices compared to those of laptops and desktops. When determining the most appropriate contrast notations, a good general guideline is to apply the reduced contrast ratio only when the related text is approximately 150% (or 120% bold) that of the default text size.

However, it is also important to note that just because the text size may be pre-defined at 150% of the default text size, this does not necessarily mean that the text will be automatically readable by a user that is visually impaired.  People with visual difficulties may still require additional platform-specific accessibility features for screen zooming or text size manipulation before they can access the mobile content.  They may even need third-party assistive technology, as well. 

Designers of mobile technology are transitioning away from built-in, slide-out, or other forms of keyboarding hardware.  They are instead moving towards devices with included touchscreen technology with keyboard controls that display on-screen.  In most cases, the touchscreen keyboard only appears when the user engages with an attribute or interface mechanism that requires textualized input, such as a web browser, data field, or text box.

Even though most of the predominant operating systems used on mobile devices are now trending towards touchscreen keyboards, this does not diminish the importance of keyboard accessibility via physically connected external keyboards hardware, such as Bluetooth or USB-connected options.  Furthermore, consumer demand is growing for mobile technology that is easily adaptable to alternative touchscreen keyboard solutions, as well.

Designing mobile-responsive web content that supports these various types of keyboard interfaces also benefits users with visual impairments and other disabilities. 

• Some users with visual impairments prefer the use of physical, hardware keyboards over touchscreens, which can occasionally be more difficult to see clearly and to manipulate.  Physical keyboards also contain the raised “nibs” on the individual letter keys that are also sometimes curved, and the associated key layouts are infinitely more consistent that the wide array of formats found in touchscreen alternatives.

• Some users with mobility or dexterity impairments can benefit significantly from physical keyboards specially designed to minimize the effects of accidental or inadvertent keystrokes. Some of the individual keys may be oddly shaped, unevenly spaced, or protected with a special keyboard guard. 

• Some users can find the dynamic nature of touchscreen keyboards somewhat confusing and prefer the consistency and familiarity of a physical keyboard.

• Many users consider the typing of longer documents via a physical keyboard to be infinitely faster and easier as compared to a touchscreen alternative.

Several WCAG testable success criteria are pertinent to effective touchscreen and keyboard controls, including:

• 2.1.1 Keyboard (Level A)

• 2.1.2 No Keyboard Trap (Level A)

• 2.4.3 Focus Order (Level A)

• 2.4.7 Focus Visible (Level AA)

Thanks to the high-resolution capabilities of mobile technology, even the smaller screens can easily display multiple interactive elements at the same time.   However, the developer must be sure that the individual elements are large enough with enough space in-between so that users can safely and accurately engage with them at the touch of a finger (and not accidentally engage with a neighboring interactive element instead).

WCAG best practices related to touch target size and spacing features include the following:

• Touch targets should be a minimum size of 9 mm x 9 mm.

• Touch targets at the lower end of the minimum size should be surrounded by a small area of inactive space – approximately 2mm – to ensure adequate spacing between objects, eliminating unwanted target activation

Note: These minimum size requirements for touch targets are not dependent on the screen size or resolution of the mobile device.  The user should never be required to increase screen magnification to engage with these touch targets because the screen magnification process often results in the additional need for the user to pan vertically or horizontally, which further reduces user-friendliness.

Designers and manufacturers of mobile technology generally require users to engage with their devices by way of simple gestures or interactions of “finger contact” with a touchscreen. These gestures can be as simple as the tap or swipe of a finger, or they can be as complex as requiring the drawing of a shape or the initiation of multiple finger taps. 

WCAG best practices regarding touchscreen gestures include, but are not limited to, the following:

• Touchscreen gestures must be as quick and easy to manipulate as possible. This rule is especially significant for mobile app design involving the replacement of touchscreen manipulation with screen reader interaction alternatives.   For example, users with mobility or dexterity impairments or who rely on a stylus or head pointer to engage with a mobile app can find the initiation of multiple touchscreen gestures challenging or perhaps even impossible.  Widgets requiring complex touchscreen gestures can also be too complicated for users relying on screen readers, too.  For reasons such as these, many mobile app and interface designers often provide multiple ways to implement a specific action.  For example, rather than having to tap a button or change settings to engage with an interactive element, perhaps the user can manipulate the mobile app with the swipe of a finger or stylus instead.

• To prevent or reduce the chances of accidental or inadvertent keystrokes during touchscreen and mouse interactions, use the mouseup or touchend event for activating elements or triggering interactions with buttons, links, and other input submissions.  For users who choose to engage with the mobile app via a USB-connected mouse, the user should be able to position the mouse over the interface element without it being automatically activated.  Users should be allowed to hover over the element and perhaps change their minds before committing to an action.   Furthermore, this same scenario should also apply to touchscreen engagements.  For example, placing a finger on a button should not automatically trigger the action.  Instead, the action should only take place once the user lifts the last portion of the finger from the touchscreen, and only in cases where the finger is still located within the button icon.

Another common challenge related to touchscreen gestures is that the developer can sometimes fail to provide onscreen indicators reminding the user when and how to initiate them. For example, without a noticeable onscreen indicator, the user may not be aware that the opening of a menu requires a swipe-from-the-left touchscreen gesture.  For more information, see Touchscreen Gesture Instructions.

Along with touchscreen gestures, many operating systems of mobile technology offer developers additional control and manipulation options that can be triggered by physically maneuvering, tilting, or shaking the device.  While these alternative options of device manipulation gestures can open a new world of innovation in user interfaces for forward-thinking developers, they can also pose new challenges for users with mobility and dexterity difficulties. 

Some mobile operating systems provide alternative work-around solutions that allow the user to simulate these device tilts, shakes, and other maneuvers from a convenient onscreen menu.

Consequently, developers will still need to provide alternative touchscreen and keyboard controls options in cases where these work-around solutions are available.

Developers of mobile content, apps, and websites must pay careful attention when positioning interactive buttons and other elements.  They should be placed in locations that are easily viewable and easily manipulated when the device is held in varying positions. 

When designing mobile content, apps, and websites, many developers tend to focus on optimization of usage with a single hand, which can significantly benefit users with mobility and dexterity disabilities who may have the use of only one hand.  However, developers should also be aware that placing a button in an easy-to-manipulate location may be beneficial for some users while resulting in additional, unforeseen challenges for others. Therefore, flexibility of use should always be a primary objective of mobile design.  Issues to consider might involve thumb range of motion and left-handed vs. right-handed usage.

Some (but not all) mobile operating systems offer certain work-around features that allow the user to temporarily pan the screen display horizontally or vertically in a simpler, easier-to-manipulate, one-handed operation.

Developers of some mobile applications often preset the screen orientation display to either landscape or portrait, with perhaps the underlying assumption that the user will automatically respond by rotating the device accordingly by-hand.  However, this type of mobile design can prove challenging for users with mobility or dexterity issues, particularly in cases where the users must mount their mobile devices in a fixed orientation to a stabilizing component, such as on the arm of a wheelchair, for example. 

Therefore, developers of mobile content, apps, and websites should strive to support both orientations equally. If supporting both orientations is not feasible, then the developer should ensure that the user can change the screen orientation as quickly and easily as possible. 

The developer must also ensure that the mobile content, apps, and websites are programmatically exposed to facilitate detection of the orientation changes by assistive technology, such as screen readers. For example, if a visually impaired person using screen reader technology is unaware that the screen orientation has changed, then the user might perform navigation commands that are inaccurate.

hen developers are repeating components across multiple web pages, they should take special care to present them in a consistent layout and format.  Responsive web design involves the placement and arrangement of interactive elements, navigational components, and other content based on the unique screen size, shape, and orientation of the mobile device.  Placement should be consistent, although consistency between the varying screens sizes and orientation of different mobile devices is not a requirement of WCAG 2.0.

Examples:

• A mobile site usually contains a title, a logo, a search feature, and a navigational menu. Since these elements likely appear at the top of every page, they should also appear in the same relative order for consistency purposes.  If for some reason an individual web page does not require one or more of the components (perhaps the “search” feature is not required, for example), then the other components should still appear in the same relative order as the other pages.  Meanwhile, when a user views the content on a mobile device with a smaller screen in portrait mode, the navigational menu likely collapses into a single icon, and a drop-down list displays the other entries.  These entries should also appear in the same relative order.

• When viewing a mobile site in different orientations and on devices of varying screen sizes, some components may remain hidden. However, those components that display (or are “not hidden”) will maintain a consistent order and format regardless of screen size or orientation.

The WCAG testable success criteria related to issues of layout consistency include:

• 3.2.3 Consistent Navigation (Level AA)

• 3.2.4 Consistent Identification (Level AA)

The smaller screen sizes of mobile devices create limitations on the amounts of content that are viewable by the user without scrolling.  Placement of important interactive elements and key information so that they display without scrolling benefits all users, but particularly those with visual and cognitive impairments.

For example, if a visually impaired user initiates screen magnification features to view the mobile content, apps, and websites, then the screen automatically responds by displaying a smaller portion of the page at any given time.  Placement of important information and interactive elements before the need to page scroll allows the user to locate pertinent content without performing a secondary interaction. 

This best practice technique also assists users with cognitive impairments, such as short-term memory disorders. Placement of important interactive elements and key information before the page scroll also helps with layout consistency from page to page, which is another added benefit for users with visual and cognitive impairments, as well. 

When multiple interactive elements link to the same destination or perform the same action, best practice techniques dictate that they should be contained within the same actionable element. This technique increases the touch target size for all users while benefitting users with mobility and dexterity impairments.  The subsequent reduction in the number of redundant focus targets also benefits those using physical keyboard controls and screen readers. 

The WCAG 2.0 testable success criterion related to optimum grouping of interactive elements includes:

• 2.4.4 Link Purpose (In Context) (Level A)

• 2.4.9 Link Purpose (Link Only) (Level AA)

For additional information, refer to H2: Combining adjacent image and text links for the same resource technique.

Elements designed to trigger actions and changes should be appropriately distinct and obviously distinguishable from non-actionable elements, such as status information displays and conventional blog content.

Providing clear indications that elements such as hyperlinks or buttons are indeed actionable is critical for responsive web design, especially in cases where users most commonly detect these interaction modes and actionable elements visually (touchscreen and mouse usage).  Interactive elements must also be programmatically exposed to facilitate detection by assistive technology, such as screen readers.

Visual users interacting with the mobile content by way of touchscreens or handheld visual cursors, such as a joystick, mouse, stylus, or keypad, must be able to differentiate actionable elements from non-actionable elements clearly and easily.   The principle of redundant coding ensures that actionable elements are always clearly indicated by more than a single distinguishing visual feature. Adhering to these best practices benefits all users, but especially those with visual impairments.

Examples of distinguishing visual characteristics that make an actionable element truly stand out might include modifications to color, shape, style, positioning, or iconography.

1. Colors: Examples might include elements with different background colors from that of the page or different text colors from that of the conventional content.

2. Shapes: Examples might include buttons with rounded corners or drop shadows, creative usage of checkboxes, and arrows pointing to important calls-to-action.

3. Styles: The most common examples include colored and/or underlined text for hyperlinks.

4. Positioning: Examples might include the conventional method of placing the backspace button at the top-left of the page (iOS) or positioning menu items within drop-down menus and left-aligned lists for more efficient navigation.

5. Iconography: Examples might include home icons, question marks for search queries, the creative use of burger icons for menus, or floppy disk icons for saves.

The WCAG testable success criteria do not directly address issues related to the clear indication of actionable elements, but the following criteria may be helpful:

• 3.2.3 Consistent Navigation (Level AA)

• 3.2.4 Consistent Identification (Level AA)

Developers can enhance their creative endeavors regarding new and efficient user interfaces by including additional control capabilities for custom touchscreen and device manipulation gestures. However, users can sometimes face unforeseen challenges regarding the discovery, performance protocols, and even the remembering that these custom gestures exist.

Therefore, developers should provide instructional information such as tutorials, tooltips, and overlays which explain clearly and succinctly how best to use these custom gestures to control a given interface and whether there are additional alternatives. To be optimally effective, the instructions must be both easy-to-find and easy-to-access by the user of the mobile device. They should also be easily and readily available at any time the user needs them.  While the developer may want to ensure that the instructions are most highly visible upon the user’s initial engagement through some form of highlighting or other clear indication mechanism, the instructions should also be easily accessible from nearly every web page.    

The WCAG 2.0 testable success criteria related to instructional information regarding custom touchscreen and device manipulation gestures include the following;

• 3.3.2 Labels or Instructions (Level A)

• 3.3.5 Help (Level AAA)

Some forms of mobile technology allow for customization via the device settings of the standard keyboard, and some even allow for the installation of additional customized keyboards.  Others also provide opportunities to use different virtual keyboards based on the type of data being entered and the associated required protocols for standard data entry. 

For example, modifying form field controls in HTML5 (see Method Editor API) will cause automatic appearances of different keyboards depending on the specific form fields that the user is currently entering data.  Setting and coordinating the various types of keyboards in advance can reduce or prevent errors while ensuring that formats are correct.  However, when subtle changes occur in the keyboard, these techniques can sometimes be challenging or confusing for users with visual or cognitive impairments using screen readers. 

There are several ways that users can enter data into mobile devices.  They can enter data by touchscreen, voice recognition software, conventional keyboards, and Bluetooth keyboards, just to name a few.  Even with so many available options, data entry can still be somewhat time-consuming and even challenging in certain situations.  Developers can reduce the amount of data entry required by providing specialized menus, checkboxes, radio buttons, and other time-saving components.  They can also offer elements that automatically enter known information, such as the current date, time, and location.

Mobile technology provides several features which assist users with visual, cognitive, and physical disabilities to interact with content more efficiently. Platform-specific characteristics and properties such as zoom, captions, and larger fonts may differ depending on the mobile device and its related operating system and version. For example, most platforms have capabilities to use larger fonts, but not all applications honor larger fonts for all textualized elements. Furthermore, some applications might increase font size but lack the capabilities to wrap text, which may result in unforeseen demands to scroll horizontally.

The world of mobile technology and responsive design is advancing at a rapid pace.  In fact, most designers today no longer separate “web design” from “responsive design” because online properties that are not automatically mobile-responsive are almost obsolete. By following the many available best practices and recommendations as set forth by the WCAG and its consistently evolving reiterations yet to come, developers can transform content, apps, and websites that are currently only superficially mobile into maximally responsive online properties that appeal to the broadest range of users