Variety and affordability have made mobile devices ubiquitous. But as with any other form of popular technology adoption, it’s important to see if the adoption has been as wide as it is deep. As designers of mobile applications, it is important that we keep our designs accessible to individuals with disabilities as well keeping in mind their need and reliance on technology.
The majority of mobile devices are now touch screens. Therefore, we are now going to examine the top 10 guidelines for mobile accessibility considering touch screens.
1. All the interactive elements must be large enough for the users to interact with. The recommended size for touch targets is 7 mm to 10 mm. This is also the size range of the average finger. So in fact, developers must ideally make sure that all actionable elements are larger than 9.6 mm across and provide sufficient padding around all links or touch targets/actionable elements.
2. The zoom feature of the browser/platform must not be suppressed. Zoom must be allowed for all HTML content in all mobile browsers and for embedded HTML content in native apps. If for some reason zooming is not supported by the platform then, as an alternative, users must be able to resize the fonts of the content up to at least twice the standard font size. (Naturally, any font size changes should reflect on all the pages and content should reflow properly on the screen.)
Content should also be scrollable. Developers must ensure that relative size units are used for content and containers to avoid content cut-off issues. If drag and drops are used, we must make sure that a secondary method is provided to change page size since the drag and drop functionality may cause mobile browsers to disable zoom.
3. Content and background must have sufficient contrast and meet the WCAG 2.0 AA level requirements. Remember, the WCAG gives these recommendations for text background contrast:
- Contrast ration of 4.5:1 for normal text (less than 18 point or 14 point bold).
- Contrast ration of 3:1 for large text (at least 18 point or 14 point bold)
Good color contrast helps users with visual impairments, color blindness, color deficiencies, and cognitive impairments. Good color contrast is also essential when using color as differentiator. Color contrast can be checked with Color Contrast Checker or Tanaguru Contrast-finder. The latter suggests similar but better contrasting colors.
If color is used to convey meaning, do ensure that accessible alternatives are provided. This could be underlined text for links, visible text on buttons, alt text labels and so on. Also, make sure that visual formatting alone is not used to convey meaning.
4. When it comes to visibility of the elements, developers must make sure that they use proper content hiding techniques. Techniques such as zero opacity, z-index order, and off-screen placement must not be used as this will disrupt the order. Techniques like the use of hidden attribute or visibility or display style property should be used to make the elements truly invisible. The aria-hidden attribute can be used to emulate that the element is hidden but it should not be used unless it is absolutely unavoidable.
5. Content must support alternative input methods, such as external keyboard or Braille display, as some users do not use the default input methods, like touch screen or using a mouse, provided with devices. If a device or platform supports alternative forms of input and navigation then the content must also support these.
It should be possible to act on content elements such as objects, elements, and controls to navigate, activate, and manipulate them in appropriate ways using the alternative input methods. The different gestures must be supplemented with standard navigation methods like focus, key presses, buttons, links, or other controls. For example, the carousel widget that supports touch gestures to swipe left or right should be supplemented with other input methods like buttons on both sides or by specific keys.
6. How gestures and events are implemented is very important. Actions must be triggered only when appropriate for the particular type of user interaction. The actions could be moving a mouse over an element, touching a screen, swiping or pressing a key. The events that actions trigger must only be initiated when the user finishes activation (for example, when the finger is lifted from the actionable element) and not at the start of activation (when the finger is placed on the actionable element).
This allows users to change their mind without being forced to commit to an action. It also allows users with disabilities to move their finger or stylus over items to locate the precise elements without triggering actions unintentionally.
For HTML content, if default events like ‘onClick’ or ‘onKeyPress’ are not used for some reason, then instead of using ‘onTouchStart’ or ‘onKeyUp’ events, the ‘onTouchEnd’ or ‘onKeyDown’ events should be used.
7. Audio or video must not play automatically, as it can conflict with screen reader audio and be disruptive. It may also distress users with cognitive or sensory sensitivities. If there is a specific reason for making content autoplay, we should at least design an accessible pop up to allow first time users to set their preferences to always autoplay or never autoplay content.
All content that moves, updates, scrolls, or blinks must be stopped or paused to allow users to view the content before it changes. It is also important that we provide buttons to pause, stop, or mute and that these must be fully and immediately accessible. (Exceptions can be made for content like multimedia or games in which media may play without any other surrounding content.)
Metadata including the duration, subtitles, sign-language, or transcript should be provided for media elements. This will help people find what they require, understand media, and locate alternate versions.
8. The structure of the content should be logical and in order to support a clear flow of information. Content should be coded in the order it is shown. This will help keyboard-only users, voice input users, or screen reader users, access all the content without missing any of it.
The content must provide a logical and hierarchical heading structure. Each page or screen must be uniquely identifiable through the heading. As it is the first thing users see, this will help them confirm where they are in the content structure.
If you decide not to use HTML5 semantics, then ARIA landmarks roles must be assigned to containers, which should be used to structure the content. The containers help people understand the content structure and help assistive technologies such as screen readers to describe the group of elements so that people who cannot see the visual layout can still understand the content structure. For example, you can group all the navigational elements in one container and assign the landmark role as ‘navigation’. This helps screen reader users to quickly navigate within a page or screen.
9. Some users may only use a keyboard, voice controls, or switch devices for navigation and input. In order to operate interactive elements, user must first able to focus that element. So, all activitable elements must be focusable and non-interactive elements must not be focusable. Standard controls such as buttons, links, and form fields are focusable by default. Non-standard controls must have appropriate ARIA roles assigned to them, such as buttons, links, or checkboxes. It is recommended that developers use the standard HTML elements, which also provide keyboard access automatically.
All the actionable elements must have visible state change. This includes hover, focus, active, selected, and disabled states for mouse and keyboard as well as touch states. The non-interactive elements (disabled) must not be focusable. The changes of state must be communicated visually and audibly.
It is also important to implement the focus order properly. For example, a modal popup that opens for a user action should have the focus within the component and must be accompanied by the option to close the popup.
Keyboard and screen reader users depend on the focus order provided by the content. Usually content order dictates focus order; however, this may not always be the case. Actionable content must follow a logical sequence that will maintain the meaning and operation of the content.
10. The screen reader users are often vision impaired and unable to perceive non-textual content. So, textual equivalents must be provided for every non-textual element. The alt attribute can be used to provide the alternatives for images. Titletext is not supported on mobiles for links but it is partly supported for form elements.
There is a good guide by Steve Faulkner about Using the HTML title attribute. If you think that the alt or title attribute is not applicable then appropriate ARIA properties such as aria-label, aria-labelledby, or aria-describedby can be used.
Images of text should be avoided as they can become blurred and difficult to read when scaled up to support different resolution devices, take time to download, and the text in images of text cannot be easily changed to the user’s desired color settings or translated to different languages.
Hidden or inactive content or decorative images should not be accessible to users of assistive technology. Also, not all users will see tooltips so these must not be used to convey pertinent information.
Background images that convey information or meaning must have alternatives as alt text cannot be directly assigned to CSS background images. The alternative could be an image or a suitable replacement technique in CSS to provide visual and textual information.
We have now covered important standards and guidelines which should be followed to make content on phones and tablets more accessible to people with disabilities. WAI-ARIA’s work in this area addresses accessibility considerations for designers who want to support a wide range of browsers and devices, so do check it out as well.
After implementing these standards and guidelines, the next step will be to test the content and verify that your eLearning content complies with them. The testing can be manual or automated. Tanaguru’s automated accessibility testing service provides a way to uncover some of the accessibility related issues.
Let’s end with a simple recap of the 10 standards and guidelines for mobile accessibility:
1. Interactive elements must be large enough.
2. Zoom must be allowed.
3. Content and background must have sufficient contrast.
4. We must use proper content hiding techniques.
5. We must support alternative input methods.
6. Events must be initiated only when the user finishes activation.
7. Audio or video must not play automatically.
8. The structure of the content should be logical.
9. All activitable elements must also be focusable.
10. Images of text should be avoided.
References:
