Applying UAAG to Mobile Phones

Status

This is a report of a subgroup of the User Agent Accessibility Guidelines Working Group that is examining whether the UAAG guidelines and success criteria apply to mobile devices. It has no official standing with the W3C.

Executive Summary

This document examines each of the UAAG 2.0 success criteria and their applicability to known mobile phone accessibility issues. The goal was to determine if UAAG 2.0 applied to the mobile platform. The principles and guidelines of UAAG 2.0 should apply to any platform, but there may be instances when it does not, or where finding existing implementations could be a challenge.

Perceivable - Most of the guidelines and success criteria supporting the principle of Perceivable apply, with some exceptions in the areas of multiple viewports, because today's mobile devices typically display one viewport at a time. Style sheets, element information, source or outline views could be implemented. Of these guidelines 1.1 Alternative Content, 1.3 Highlight Active Content, 1.5 Volume Configuration, and 1.6 Synthesized Speech are compatible and are implemented in select current products. Limitations in the visual user interface of mobile devices may inhibit complete implementation of 1.3 Highlight Active Content, 1.4 Text Configuration and 1.7 Style Profiles. 1.8 Windows and Viewports may not apply because mobile devices tend to have one active viewport at a time. 1.2 Repair Missing Content, 1.10 Alternative Views and 1.11 Element Information are not currently implemented, but achievable because they depend on deterministic information associated with WCAG 2.0 Level A conforming content.

Operable - The guidelines for Operable user agents are: 2.1 - Keyboard Access is partially implemented, because mobile phones virtual keyboards today do not support accesskey; 2.2, 2.3, 2.5 - Sequential, Direct and Structural navigation respectively, 2.4 Text Search, 2.6 Event Handlers, 2.7 Preference Settings, 2.8 Toolbar Configuration, 2.9 Time Independence, 2.10 Flash Induced Seizures, 2.11 Control of Problematic Content. Physical keyboards are frequently absent, and touch screens replace mice and pointers in mobile devices. Although none of these guideline features are out of reach for computer programs applied to WCAG conforming data, the UI of mobile devices differs so much from general computers that significant development will be needed to meet this entire principle. 2.8 Toolbar Configuration, 2.9 Time Independence, 2.10 Flash Induced Seizures, 2.11 Control of Problematic Content are not currently implemented.

Understandable - Guidelines that support understandability are: 3.1 Unnecessary Messages, 3.2 Avoid and Correct Mistakes, 3.3 UI Documentation Including Accessibility 3.4 Predictable Behavior. None of these features are beyond current mobile technology, but examples may be scarce.

Programmatic Access - Without accessibility APIs, mobile platforms are ill equipped to support programmatic access. Some mobile platforms implement their own accessibility support, which provides some programmatic access. 4.1 Programmatic Access to Assistive Technology cannot be satisfied by current mobile technology. 4.2 Programmatic Access to Nested User Agents is also a future goal, however, development of a powerful plugin capability, may ease pressure to develop more extensive accessibility APIs.

Specifications and Conventions - Support for compliance with specifications and conventions may be the most difficult. 5.1 Non-Web-based Functionality is Accessible, 5.2 Web-based Functionality is Accessible, 5.3 Accessibility feature Support and 5.4 Render Specification Support are important future developments. This principle has little existing support on mobile platforms. 5.4 might not even be desirable for mobile devices because a rendering that an author specifies for a computer screen may be inappropriate for a mobile display.

Considerable research, development and creativity will be required to implement user agent accessibility on mobile devices. The encouraging kernel we can derive from this investigation is that the problem is tractable (both programatically and institutionally) and that significant comparability already exists.

Introduction

UAAG 2.0 guidelines are based on five principles. The first three principles are the same as the WCAG 2.0 principles: perceivable, operable and understandable. In UAAG the principles that address robustness are split in into two parts: programmatic access and compliance with existing specifications and conventions. Some guideline functionality is already present in mobile user agents today. Others are possible but not implemented. Finally, some guideline functionality appears to be incompatible with current mobile technology. In the main body of this document we explore how each success criterion with each guideline fits into this analysis.

The User Agent Working Group was asked to answer the question, "does UAAG 2.0 apply to mobile phones?"

Issues unique to mobile phones

• screen size (navigation, low vision magnification, UI control size)
• limited device memory (less memory for programs, especially assistive technology apps)
• no accessibility APIs for the platform
• touch screen interfaces also make it similar to tablet
• battery life issues (apps that run the battery down, refreshable braille device, projectors? )
• touch screens and users with prosthetic fingers
• more gestures required for navigation on small screen. This becomes significant for users with RSI.
• variations in on-screen keyboards
• no keyboard shortcuts or control keys
• no windows, each application is typically full screen.

Other Reference Documents

• Mobile Web Best Practices
• JTC 1/User Needs Summary

UAAG Success Criteria that Apply to Mobile Devices

Principle 1 - Perceivable

note: quotes are from the UAAG 2.0 Editors' Drafts of 11/4/2012 and 12/13/2012.

Guideline 1.1 - Provide access to alternative content.

1.1.1 Configurable Default Rendering: The user can specify which types of alternative content to render by default. (Level A)

1.1.2 Browse and Render: When a rendered element has alternative content, the user can render alternatives according to the following: (Level A) synchronized alternatives for time-based media (e.g. captions, audio descriptions, sign language) can be rendered at the same time as their associated audio tracks and visual tracks, and non-synchronized alternatives (e.g. short text alternatives, long descriptions) can be rendered as replacements for the original rendered content.

1.1.3 Identify Presence of Unrendered Alternative Content: The user can specify that content be rendered with an adjacent indicator when unrendered alternative content is present (e.g. an icon to indicate an image has a short text alternative). (Level A)

1.1.4 Rendering Alternative Cascade Order: The user can specify the cascade order in which to render alternative content. (Level AA)

UAAG 2.0 applies to mobile – can use a few mobile examples for relevance, but otherwise good. Finding mobile implementations may be a challenge.

Guideline 1.2 - Repair missing content.

1.2.1 Repair Missing Alternatives: The user can specify whether or not the user agent should generate and render repair text (e.g. file name) when it recognizes that the author has not provided alternative content. (Level A)

1.2.2 Repair Empty Alternatives: The user can specify whether or not the user agent should generate and render repair text (e.g. file name) when it recognizes that the author has provided empty alternative content. (Level AAA)

1.2.3 Repair Missing Associations: The user can specify whether or not the user agent should attempt to predict associations from author-specified presentation attributes (i.e. position and appearance). (Level AAA)

1.2.4 Broken Alternative Content: The user can be notified when the user agent cannot render alternative content (e.g. when captions are broken). (Level AAA)

This guideline is particularly relevant to mobile, as early mobile browsers made modifications to the web page, so the ability to modify is there. Display of captions will be limited by the capabilities of the platform to display video content.

Guideline 1.3 - Provide highlighting for selection, keyboard focus, enabled elements, visited links.

1.3.1 Highlighted Items:

The user can globally specify that the following be highlighted so that each class is uniquely distinguished. It is not the intention that all recognized enabled elements be uniquely distinguished, just that they be distinguished from disabled elements. (Level A) (a) selection (b) active keyboard focus (indicated by focus cursors and/or text cursors) (c) recognized enabled elements (d) presence of alternative content (e) recently visited links

1.3.2 Highlighting Options: When highlighting classes specified by 1.3.1 Highlighted Items and 1.3.3 Highlighted Input Controls, The user can specify highlighting options that include at least: (Level A) (a) foreground colors, (b) background colors, and (c) border (configurable color, style, and thickness)

1.3.3 Highlighted Input Controls: The user can have the following highlighted when they are recognized: (Level AA) (a) enabled controls that take input (e.g. push buttons, radio buttons, check boxes, and text input fields, but not groupings or static text and images) regardless of whether they are read-write or read-only, and (b) elements with scripted input handlers (e.g. images or text ranges that have onClick or onKeyPress events) regardless of whether the current state allows them to operate.

Mobile may not have the configurable options in 1.3.2, so it may be worthwhile to look at changing it to level AA. More research needed to find examples in the mobile space.

Guideline 1.4 - Provide text configuration.

1.4.1 Configure Rendered Text: The user can globally set any or all of the following characteristics of visually rendered text content, overriding any specified by the author or user agent defaults: (Level A) (a) text scale (i.e. the general size of text) , (b) font family, (c) text color (i.e. foreground and background), (d) line spacing, and (e) character spacing.

1.4.2 Preserving Size Distinctions: The user can specify whether or not distinctions in the size of rendered text are preserved when that text is rescaled (e.g. headers continue to be larger than body text). (Level A)

This section could be problematic (to find implementations) since most mobile devices deal with text magnification through zoom capabilities, and not changing characteristics of rendered text. 1.4.2 will be particularly valuable to Low Vision users.

Guideline 1.5 - Provide volume configuration.

1.5.1 Global Volume: The user can independently adjust the volume of all audio tracks, relative to the global volume level set through operating environment mechanisms. If the global setting is mute, the user agent may override a global mute on explicit user request that cautions the user about the implication. (Level A)

not a feature in current mobile devices.

Guideline 1.6 - Provide synthesized speech configuration.

1.6.1 Speech Rate, Volume, and Voice: If synthesized speech is produced, the user can specify the following: (Level A) (a) speech rate, (b) speech volume (independently of other sources of audio), and (c) voice, when more than one voice option is available

1.6.2 Speech Pitch and Range: If synthesized speech is produced, the user can specify the following: (Level AA) : (a) pitch (i.e. the average frequency of the speaking voice), and (b) pitch range (i.e. specifies a variation in average frequency)

1.6.3 Advanced Speech Characteristics: The user can adjust all of the speech characteristics offered by the speech synthesizer. (Level AAA)

1.6.4 Synthesized Speech Features: If synthesized speech is produced, the following features are provided: (Level AA) (a) user-defined extensions to the synthesized speech dictionary, (b) "spell-out", where text is spelled one character at a time, or according to language-dependent pronunciation rules, (c) at least two ways of speaking numerals: one where numerals are spoken as individual digits and punctuation (e.g. "one two zero three point five" for 1203.5 or "one comma two zero three point five" for 1,203.5), and one where full numbers are spoken (e.g. "one thousand, two hundred and three point five"). (d) at least two ways of speaking punctuation: one where punctuation is spoken literally, and one where punctuation is rendered as natural pauses.

Applies, and even includes mobile examples.

Guideline 1.7 - Enable Configuration of Style Profiles.

1.7.1 Author Style Sheets:

The user can turn off the use of author style sheets, and for every author style sheet defined the user can choose whether or not it should be applied to: (Level A)

(a) the current page, or (b) all pages for which it is defined.

1.7.2 User Style Sheets: The user can turn on the use of user style sheets, and for every user style sheet defined the user can choose whether or not it should be applied to: (Level A) (a) the current page, or (b) all pages on specified web sites, or (c) all pages.

1.7.3 Save copies of style sheets: The user can save copies of the style sheets referenced by the current page, so that they can edit and load them as user style sheets. (Level AA)

Problematic: no known mobile device supports style profiles in the browser. They may be supported as part of the operating platform, but not at the granularity of the stylesheet.

Guideline 1.8 - Help users to use and orient within windows and viewports.

1.8.1 Highlight Viewport: The viewport with the input focus (including nested viewports and their containers) is highlighted, and the user can customize attributes of the highlighted mechanism, including, but not limited to, shape, size, stroke width, color, and blink rate (if any). (Level A)

1.8.2 Move Viewport to Selection and Focus: When a viewport's selection or input focus changes, the viewport's content moves as necessary to ensure that the new selection or input focus location is at least partially in the visible portion of the viewport. (Level A)

1.8.3 Resize Viewport: The user can make viewports resizable, within the limits of the display, overriding any values specified by the author. (Level A)

1.8.4 Viewport Scrollbars: Graphical viewports include scrollbars if the rendered content (including after user preferences have been applied) extends beyond the viewport dimensions, overriding any values specified by the author. (Level A)

1.8.11 Indicate Viewport Position: (will be renumbered) The user can determine the viewport's position relative to the full extent of the rendered content. (Level A)

1.8.5 Viewport History: For user agents that implement a viewport history mechanism (e.g. "back" button), the user can return to any state in the viewport history, restoring the prior point of regard, input focus and selection.(Level A)

1.8.6 Open on Request: The user can specify whether author content can open new top-level viewports (e.g. windows or tabs). (Level A)

1.8.7 Do Not Take Focus: If new top-level viewports (e.g. windows or tabs) are configured to open without explicit user request, the user can specify whether or not top-level viewports take the active keyboard focus when they open. (Level AA)

1.8.10 Same UI: The user can specify that all top-level viewports (e.g. windows or tabs) follow the current user interface configuration. (Level AA)

Problematic. It does not apply to current mobile technology, which typically operates in full screen mode only.

Guideline 1.10 - Provide alternative views.

1.10.1 Source View: The user can view all source text that is available to the user agent. (Level AA)

1.10.2 Outline View: An outline view of rendered content is provided, composed of labels for important structural elements (e.g. heading text, table titles, form titles, and other labels that are part of the content). (Level AA) Note: The outline constitutes the important structural elements for the user (See 1.10.3). A label is defined by each markup language specification. For example, in HTML, a heading (H1-H6) is a label for the section that follows it, a CAPTION is a label for a table, and the title attribute is a label for its element.

1.10.3 Configure Elements for Outline View: The user can configure the set of important elements for the outline view, including by element type (e.g. headers). (Level AAA)

Applies and includes a mobile example in 1.10.3

Guideline 1.11 - Provide element information.

1.11.1 Access Relationships: The user can access explicitly-defined relationships based on the user's position in content (e.g. show form control's label, show label's form control, show a cell's table headers). (Level A)

1.11.2 Extended Link Information: The user agent provides for each link: (Level AAA) : link title technology type (of the linked Web resource) internal/external: (whether the link is internal to the resource e.g. the link is to a target in the same Web page)

• 1.11.1 could be problematic for mobile phones to display, but it should be capable of providing it. Perhaps the level (A) should be considered.

Principle 2 - Operable

Guideline 2.1 - Ensure full keyboard access.

2.1.1 Keyboard Operation: All functionality can be operated via the keyboard using sequential or direct keyboard commands that do not require specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints (e.g. free hand drawing). This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation. (Level A)

2.1.4 Specify preferred keystrokes: : The user can override any keyboard shortcut including recognized author supplied shortcuts (e.g. accesskeys) and user interface controls, except for conventional bindings for the operating environment (e.g. arrow keys for navigating within menus). (Level A)

2.1.7 Follow Text Keyboard Conventions : Views that render text support the standard text area conventions for the operating environment, such as character keys, Backspace/Delete, Insert, arrow key navigation (e.g. caret browsing), Page Up/Page Down, navigate to start/end, navigate by paragraph, shift-to-select mechanism. (Level A)

2.1.1 and 2.1.4-2.1.9 are keyboard specific. Keyboard accessibility is the gold standard for making things generally accessible, but different on mobile, which often lacks control keys. Touch is the mouse of mobile, what is the keyboard of mobile? What is the common denominator for access? We need to get in the underlying principles, especially of the above three, i.e. a standard way of accessing controls, configure to accommodate different abilities, and basic navigation conventions.

2.1.2 Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times and (Level A)

• applies, but lacks mobile example

2.1.3 Viewport Navigation: The user can move the active keyboard focus to any viewport. (Level A)

• applies, but lacks mobile example

Guideline 2.2 - Provide sequential navigation; Guideline 2.3 - Provide direct navigation and activation; Guideline 2.5 - Provide structural navigation

• These doesn't exist on mobile browsers -- it's all done by touch. Other means of navigation are lacking a browsers, including keyboard and to some extent speech. This is a problem. Note that some speech services like Siri provide some functionality, but there is a gap. Today's mobile speech does not allow users to directly access and control interface elements.

Guideline 2.4 - Provide text search

• applies, lacks mobile examples

Guideline 2.6 - Provide access to event handlers

applies, lacks mobile examples

Guideline 2.7 - Configure and store preference settings

• applies, lacks mobile examples

Guideline 2.8 - Provide toolbar configuration

• applies, lacks mobile examples

Guideline 2.9 - Allow time-independent interaction

• applies, lacks mobile examples

Guideline 2.10 - Help users avoid flashing that could cause seizures

• applies, lacks mobile examples

Guideline 2.11 - Provide control of content that may reduce accessibility

• applies, lacks mobile examples

Principle 3 - Understandable

Note: comments by Jeanne Spellman using UAAG Editor's Draft of 22 September 2011

Guideline 3.1 - Help users avoid unnecessary messages.

3.1.2 Option to Ignore: The user can turn off rendering of non-essential or low priority text messages or updating/changing information in the content based on priority properties defined by the author or the user agent. (Level AA)

• 3.1.2 applies, no mobile example

Guideline 3.2 - Help users avoid and correct mistakes.

3.2.1 Form Submission: The user can specify whether or not recognized form submissions must be confirmed. (Level AA)

• Important area - mobile browsers are inconsistent in form submissions. I don't know of any mobile browswer allowing this much granularity of control.

Guideline 3.3 - Document the user agent user interface including all accessibility features.

3.3.1 Accessible documentation: The product documentation is available in a format that meets success criteria of WCAG 2.0 Level "A" or greater. (Level A)

• 3.3.1 applies, no mobile example

3.3.2 Document Accessibility Features: All user agent features that benefit accessibility are documented. (Level A)

• 3.3.2 applies, no mobile example

3.3.3 Changes Between Versions: Changes to features that benefit accessibility since the previous user agent release are documented.

• 3.3.3 applies, no mobile example

3.3.4 Centralized View: There is a dedicated section of the documentation that presents a view of all features of the user agent necessary to meet the requirements of User Agent Accessibility Guidelines 2.0. (Level AAA)

• 3.3.4 applies, no mobile example

3.3.5 Context Sensitive Help: There is context-sensitive help on all user agent features that benefit accessibility. (Level AAA)

• I'm not sure how context sensitive help would work on current mobile devices

Guideline 3.4 - The user agent must behave in a predictable fashion.

3.4.1 Avoid unpredictable focus: The user can prevent focus changes that are not a result of explicit user request. (Level A)

• 3.4.1 applies, no mobile example
• I don't know of any mobile browser that allows this level of granularity in control of the page, particularly with focus changes to incoming phone calls or text messages.

3.4.2 Avoid Side Effects of Navigation: The user can move the keyboard focus without causing the user agent to take any further action, other than the presentation of information (e.g. scrolling or pop-ups that do not change the focus or selection). (Level A)

• applies, no mobile example

PRINCIPLE 4: Facilitate programmatic access

Guideline 4.1 - Facilitate programmatic access to assistive technology

4.1.1 Platform Accessibility Architecture: The user agent supports a platform accessibility architecture relevant to the operating environment. (Level A)

Problematic: current mobile technologies do not have platform accessibility architectures.

4.1.2 Name, Role, State, Value, Description: For all user interface components including user interface, rendered content, generated content, and alternative content, the user agent makes available the name, role, state, value, and description via a platform accessibility architecture. (Level A)

Problematic: current mobile technologies do not have platform accessibility architectures.

4.1.3 Accessible Alternative: If a component of the user agent user interface cannot be exposed through the platform accessibility architecture, then the user agent provides an equivalent alternative that is exposed through the platform accessibility architecture. (Level A)

Applies. Needs a mobile example.

4.1.4 Programmatic Availability of DOMs: If the user agent implements one or more DOMs, they must be made programmatically available to assistive technologies. (Level A)

4.1.5 Write Access: If the user agent keeps an internal representation of the user content in terms of element structure, relationships between elements, element meaning, or some combination thereof, it must expose this internal representation via an appropriate means (normally by using the platform accessibility architecture or a programmatically available DOM). (Level A)

Problematic: current mobile technologies do not have platform accessibility architectures. More research needed on mobile use of a DOM.

4.1.6 Expose Accessible Properties: If any of the following properties are supported by the platform accessibility architecture, make the properties available to the accessibility platform architecture: (Level A) a. the bounding dimensions and coordinates of onscreen elements b. font family of text c. font size of text d. foreground color of text e. background color of text. f. change state/value notifications g. selection h. highlighting i. input device focus j. direct keyboard commands

Problematic: current mobile technologies do not have platform accessibility architectures.

4.1.7 Timely Communication: For APIs implemented to satisfy the requirements of UAAG 2.0, ensure that programmatic exchanges proceed at a rate such that users do not perceive a delay. (Level A)

Problematic: current mobile technologies do not have APIs.

Guideline 4.2 - Facilitate programmatic access to nested user agents

4.2.1 Hand-Off Focus [former 1.9.5]: The user agent programmatically notifies any nested user agent(s) (e.g. plug-ins) when active input focus moves to a nested agent. (Level A)

4.2.2 Retrieve Focus [former 1.9.6, before that 3.11.6]: At any time, the user is able to retrieve input focus from a nested viewport (including a nested viewport that is a user agent).(Level A)

4.2.3 Return Focus [former 1.9.7, before that 3.11.7]: At any time, the user agent can retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A)

Possibly applies to future mobile technology that supports nested user agents.

PRINCIPLE 5: Comply with applicable specifications and conventions

Guideline 5.1 - Ensure that non-Web-based functionality is accessible.

5.1.1 Follow Accessibility Guidelines (Level A) : Non-web-based user agent user interfaces follow user interface accessibility guidelines for the platform.(Level A)

Guideline 5.2 - Ensure that Web-based functionality is accessible.

5.2.1 Web-Based Accessible (Level A) User agent user interfaces that are rendered using Web standard technologies conform to WCAG Level "A". (Level A)

5.2.2 Web-Based Accessible (Level AA) : User agent user interfaces that are rendered using Web standard technologies conform to WCAG Level "AA". (Level AA)

5.2.3 Web-Based Accessible (Level AAA) : User agent user interfaces that are rendered using Web standard technologies conform to WCAG Level "AAA". (Level AAA)

Problematic: Lack of accessibility guidelines for mobile platforms – web or non -Web.

Guideline 5.3 - Support accessibility features of technologies.

5.3.1 Implement accessibility features of content specs: Implement and cite in the conformance claim the accessibility features of content specifications. Accessibility features are those that are either (Level A) : identified as such in the specification or allow authors to satisfy a requirement of WCAG.

5.3.2 Implement Accessibility Features of platform: Implement and cite in the conformance claim the accessibility features of content and platform technology specifications. Accessibility features are those that are either (Level A) : identified as such in the specification or allow authors to satisfy a requirement of WCAG.

Need research in accessibility features of different mobile platforms

Guideline 5.4 - Render content according to specification.

5.4.1 Follow Specifications: The user agent renders content according to the technology specification, except where it would actually harm overall accessibility. (Level A)

5.4.2 Handle Unrendered Technologies: If the user agent does not render a technology, the user can choose a way to handle content in that technology (e.g. by launching another application or by saving it to disk). (Level A)

5.4.3 Alternative content handlers: The user can select content elements and have them rendered in alternative viewers. (Level AA)

Problematic: Heavily desktop oriented.