Mobile technologies are developing in leaps and bounds changing the world around. So it’s no surprise they are now used in educational and rehabilitating programs for people with special needs based on accessibility. The whole thing seems pretty basic now, yet we have no doubts its future is bright.
The majority of mobile devices are now touch screens. Most of modern mobile apps are poorly adapted for use by disabled people. Touch devices come with some in built special Accessibility features built in, however to make them work properly the app interface should meet but not limited to the following requirements:
- 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.
- 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.
- 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 raio of 4.5:1 for normal text (less than 18 point or 14 point bold). Contrast ratio 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
After implementing these standards and guidelines, the next step will be to test the content and verify. The testing can be manual or automated. 1. Interactive elements must be large enough.
Resources:
Application of WCAG by W3C: https://www.w3.org/TR/mobile-accessibility-mapping/
BBC Guide: https://www.bbc.co.uk/guidelines/futuremedia/accessibility/mobile
Free PDF guide by TPG: https://developer.paciellogroup.com/blog/2017/11/mobile-accessibility-testing-guide-for-android-and-ios-free/
