The Inclusive Design Research Centre (IDRC) was commissioned by the CRTC to provide an assessment of the accessibility needs and requirements of persons who are blind, have moderate-to-severe mobility disabilities, or have cognitive disabilities in regards to mobile wireless handsets. The needs of persons with other disabilities, including those related to hearing and speech are not within the scope of the present work. This report also does not provide in-depth information regarding the state of accessibility of web-based information or third-party applications on mobile wireless handsets.

This assessment is related to: Broadcasting and Telecom Regulatory Policy CRTC 2009-430, Accessibility of telecommunications and broadcasting services (http://www.crtc.gc.ca/eng/archive/2009/2009-430.htm).

1.1 Assessment Timing

This assessment was compiled between November 2010 and March 2011 primarily on the basis of information regarding mobile wireless handsets that was provided to the CRTC by Wireless Service Providers (WSPs) between April and November of 2010. However, in order for the assessment to be as useful as possible with respect to the rapidly changing handset market, the assessment does include some additional information up to March 2011. In particular:

Handsets that have been discontinued by their developers are not included in the analyses.
The WSP offerings that have been updated from their product websites.
Some important recent accessibility developments are referenced.

2. Executive Summary

This report finds that the state of accessibility in late-2010 of the Canadian market for mobile wireless handsets (hereafter, simply “handsets”) was mixed, with effective accessibility features existing for some groups of people with disabilities, alongside substantial accessibility gaps for some other groups.

Section 3 defines the important terms used in this assessment. In particular, the various impairments are defined functionally rather than medically.

Section 4 introduces some background information regarding the accessibility of handsets, emphasizing that interacting technological and human factors need to be taken into account.

Section 5 describes the market assessment approach, in which two analyses were conducted, a Needs/Preferences Analysis and a Persona Analysis.

Section 6 reports the results of these analyses, with links to appendix tables for the Needs/Preferences Analysis results and a separate document containing the Persona Analysis results.

Section 7 discusses the gaps revealed by these analyses. While many accessibility features were found to be widely available in the market (e.g. voice dialling, photo associated contacts), and other accessibility features (e.g. screen readers, external keyboards) were not standard yet had high-quality implementations on some handsets in the market; some important accessibility gaps remained. Persons with mobility impairments (see definition in paragraph 3.1) were most affected by the accessibility gaps, which included a lack of support for switch control via alternative input devices, limitations on what functions could be controlled by short cuts or movement saving controls, and limitations on supports for lack of dexterity including tremors or spasmodic movements. Persons with moderate visual impairments (see definition in paragraph 3.1) and severe cognitive impairments (see definition in paragraph 3.1) also experienced some gaps.

Section 8 discusses developments in the handset market that are likely to either improve or challenge accessibility.

Section 9 introduces best practices for Wireless Service Providers (WSPs) in evaluating handsets for accessibility needs. These best practices are then discussed in relation to an existing handset industry initiative called the Global Accessibility Reporting Initiative (GARI) of the Mobile Manufacturer’s Forum (MMF)[1].

Section 10 briefly introduces best practices for communicating requirements to handset developers (see definition in paragraph 3.2).

Finally, Section 11 includes the appendices: Appendix A: Detailed Results of Needs/Preferences Analysis; Appendix B: Features/Technologies Supporting Accessibility Needs/Preferences; and Appendix C: Detailed Results of Persona Analysis.

3. Definitions

3.1. Impairment Definitions

It is important to note that the impairment definitions in this report take a functional approach that considers disability to be a mismatch between the needs of the individual and the task or environment that he or she is attempting to access. This contrasts with a medical approach that would focus on the names and details of diagnostic categories, which are often insufficient and/or irrelevant to the process of feature design and therefore to handset developers and wireless service providers. For example, simply knowing that a user is blind does not indicate whether that person needs or prefers speech output or Braille output. In contrast, the chosen functional approach takes user needs and preferences into consideration, regardless of the reasons behind them. For example, a person may prefer speech output because they are not able to see or because another activity, such as driving, is consuming their visual attention.

Cross-cutting Needs/Preferences:

In some cases, needs/preferences can potentially apply to persons in more than one of the defined groups of impairments (i.e. visual, mobility, and cognitive). For example, the need/preference “To have controls that are not activated when they receive focus” is shared by people with a severe visual impairment and people with a mobility impairment, because they both use sequential keyboard navigation, in which the focus is moved through the controls on the user interface until the desired control is reached. In order to avoid repetition, and to highlight areas in which improvements can increase accessibility to multiple user groups simultaneously, these needs/preferences have been given the label “Cross-cutting”.

Visual Impairments:

According to the functional approach, explained above, visual impairments may be defined as the permanent or temporary experience of one or more functional limitations related to the sense of sight. For details on specific visual limitations that may arise in the context of mobile wireless handset use see Appendix A (Table 1: Visual needs/preferences related to the use of mobile devices and Table 4: Cross-cutting needs/preferences related to the use of mobile devices).

Moderate visual impairments are expressed as needs/preferences that require modification of visual information to varying degrees (e.g. magnification, colour enhancement, etc).
Severe visual impairment (or Blindness) is expressed as needs/preferences that require complete replacement of visual information with information provided through an alternative sensory modality (e.g. visual alerts replaced by auditory or tactile alerts).

Mobility Impairments:

According to the functional approach, explained above, mobility impairments may be defined as the permanent or temporary experience of one or more functional limitations related to movement of the body. For details on specific mobility limitations that may arise in the context of mobile wireless handset use see Appendix A (Table 2: Mobility needs/preferences related to the use of mobile devices and
Table 4: Cross-cutting needs/preferences related to the use of mobile devices).

Moderate mobility impairments are expressed as needs/preferences that require modification of the input methods typically available in handsets, to varying degrees (e.g. bounce tolerance, larger onscreen buttons, key locks when holding down multiple keys, disambiguation and prediction of keys, etc.).
Severe mobility impairments are expressed as needs/preferences that require complete replacement of the input methods that are typically available in handsets (e.g. physical keyboard to be replaced by alternative input devices with sequential scanning[2] or coded input) or that require handsets to be used without direct body contact (e.g. to be mounted on an electric wheelchair or placed on a surface and then used with an external keyboard, alternative input device, or with a stylus/mouthstick rather than with fingers).

Cognitive Impairments:

According to the functional approach, explained above, cognitive impairments may be defined as the permanent or temporary experience of one or more functional limitations related to perceiving, recognizing, understanding, interpreting, and/or responding to information. For details on specific cognitive limitations that may arise in the context of mobile wireless handset use see Appendix A (Table 3: Cognitive needs/preferences related to the use of mobile devices and Table 4: Cross-cutting needs/preferences related to the use of mobile devices).

Moderate cognitive impairments are expressed as needs/preferences that require modification of handsets’ user interface to some degree (e.g. more time, simplified labels, speaking text aloud, definition of terms etc.).
Severe cognitive impairments are expressed as needs/preferences that require replacement of major components in handsets’ user interface (e.g. alphabetic keyboard replaced by symbolic communication keyboard, text explanation by video or images, customized to purpose selections, etc.).

3.2. Other Definitions

Handset Developers:

Entities that integrate the handset hardware and platform software into handset products (e.g. Apple, RIM, HTC, LG, Motorola, Samsung, etc.).

Mobile Application Stores:

Online software distribution services from which consumers can download new mobile applications and manage upgrades. Stores exist for all of the major mobile platforms (e.g. iPhone App Store[3], Android Market[4], BlackBerry App World[5], Nokia Ovi Store[6], Windows Marketplace for Mobile[7], etc.) and third-party stores also exist[8]. Software options are free or paid, with purchases typically handled through a variety of mechanisms, including in some cases integrated with WSP billing. The stores include varying application approval processes, from more restrictive (e.g. iPhone App Store[9]) to less (e.g. Android Market[10]).

Platform Accessibility API (Application Programming Interfaces):

Software services (usually part of an operating system) that enable communication between applications and assistive technologies. Platform accessibility APIs exist for Blackberry OS, iOS, and Android.

Platform Developers:

Entities that develop the operating software that is used to run handsets (e.g. Android Open Source Project in the case of Android[11], Nokia in the case of Symbian[12], Apple in the case of iOS[13], etc.). In some cases, platforms are developed by a handset developer for exclusive use on their own devices, such as iOS and Blackberry OS. In other cases, software platforms are used by multiple handset developers, such as Windows Mobile and Android. However, when the same platform is used by multiple handset developers they sometimes make modifications in order to differentiate their products[14].

Third-Party Developers:

Entities that develop software for handsets other than the Handset Developer, Platform Developer and WSPs. Software developed by third-party developers may be pre-loaded on handsets by the Handset Developer or the WSP or it may be loaded by the end user at a later date, either directly from the web via a browser or from mobile application stores (see definition above).

4. Background: Factors Influencing Handset Accessibility

In order to provide an accurate and useful assessment of the state of accessibility in the Canadian handset market it was important to take into account the variety of factors complicating such an assessment.

4.1 Technological Factors

In some cases, comparisons will be made between the handset market and the desktop computer market. These are intended as illustrations only.

4.1.1 Technological Diversity

Feature Phones versus Smartphones:

An important distinction for accessibility within the handset market is the difference between low-end devices (typically referred to as “feature phones”[15]) and high-end devices (typically referred to as “smartphones”[16]). The greater memory and processing power of smartphones allow them to offer more sophisticated operating systems that can include platform accessibility APIs (see definition in paragraph 3.2). Smartphones also include more support for third-party application development and they tend to include more capable web browsers able to run advanced web applications. As a result, smartphones may provide higher levels of built-in accessibility features than feature phones, but smartphones are also more dependent on the accessibility of third-party software and content.

Platform Diversity:

In contrast to the desktop market, in which there are only a few major platforms, the handset market is more fragmented. Within the smartphone segment, alone, there are five major players: Android, BlackBerry OS, iOS, Symbian[17] and Windows Mobile/Phone.

Moreover, hardware implementations are also more diverse and are thus a more significant factor for the accessibility of handsets than of desktop systems. For example, desktop systems are all sold with very similar hardware keyboards, however in the handset market physical keyboards vary greatly in layout and other design variables or physical keyboards may be completely absent.

Finally, there are sometimes substantial differences in the way platforms are used on various handsets. For example, due to the open source nature of the Android operating system, many hardware developers have chosen to customize it[18], and since there are no enforceable accessibility guidelines for such customizations, they may ignore or conflict with the accessibility features originally built-into the platform and thus may render them unusable.

This fragmentation presents a challenge to third-party assistive technology developers, since their already small markets may be further sub-divided. However, too much market consolidation is also a problem for accessibility, because it can reduce competition and the introduction of new features to benefit smaller market segments.

4.1.2. “Accessibility Features” vs. “End-to-End” Accessibility

While it is useful to employ the term “accessibility feature”, as this assessment report does, it is important to note issues caused by the term’s flexibility.

For example, a “screen reader” feature is obviously a much more involved feature than a “nib on the 5 key”. The nib will always be available, but it is not as easy to assess how well a screen reader provides access.

Also, while a few features might be considered “stand alone”, in that they could potentially make a handset accessible on their own to some people with some disabilities in some contexts (e.g. the nib on the 5 key can enable eyes-free calling by some people on standard landline phones), most often features must work together to enable end-to-end access (e.g. on a mobile handset the nib on 5 key can enable access eyes-free phone calls only in concert with a tactilely discernible “talk” button). The latter example is analogous to a ramp with a single step in the middle of it. A missing or inconsistent feature can render the other features useless.

There are also important differences between hardware features and software features that need to be highlighted. Hardware features (e.g. large keypad buttons) are “always on” and therefore are obvious to all users, even those who do not need them. Software features (e.g. platform accessibility APIs), on the other hand, can exist invisibly on all handsets. These software accessibility features can be turned off by default, but able to be turned on at any time by someone who needs them.

4.1.3. Rapid Technological Change

The competitive nature of the handset market has meant that new versions of handset platforms tend to be released more often than in the less competitive desktop market. This can be either positive or negative for accessibility. For example, the newly released Windows Phone 7 dropped some assistive technology support that was present in Windows Mobile 6[19], while iOS, which had been inaccessible to users who are blind, became one of the most accessible platforms to this user group with the release of version 3.0, which included the VoiceOver screen reader[20].

An important trend in the recent technological development is the move away from handsets as special-purpose telephony appliances towards “smartphones” that fulfill many of the functions of general-purpose computers. So, for example, a person might own a handset, but never use the built-in calling feature, preferring instead to install a third-party VOIP application (e.g. Skype) that allows cheaper long distance calls to be made. If such third-party applications lack accessibility features, it complicates the accessibility picture for the handset in general.

4.1.4. Role of Third-Party Developers

Many mobile platform developers (see definition in paragraph 3.2) are now adding built-in accessibility features, such as keyboard navigation and screen readers. However, effective operation of these features is increasingly dependent on decisions and implementations made by handset developers, who may modify a platform (e.g. ship Android handsets with custom user interfaces), and third-party application developers (see definition in paragraph 3.2), whose content provides much of the advertised functionality of smartphones (e.g. social networking, etc.). If the handset developers or third-party application developers fail to “do the right things” to support the built-in accessibility features, then the realized accessibility of the handset as a whole is compromised.

4.2. Human Factors

It is important to avoid thinking of disabilities and accessibility as a binary condition (e.g. that someone is either totally disabled or non-disabled or that something is either totally accessible or inaccessible). Instead, human ability can be more usefully viewed as a multi-dimensional spectrum, such that everyone may experience a disability given the context, goal and environment. For example, deafness is a disability in the context of a voice-only telephone call, but not in the context of watching television in a noisy restaurant with the volume off and closed captioning on.

In order to determine the accessibility of a situation, it is necessary to consider the needs and abilities of the individual, their context and their goal.

4.2.1. Diversity of User Abilities and Needs

As stated above, human ability is a multi-dimensional spectrum rather than a binary choice between disabled and non-disabled. Some factors that further contribute to diversity in human abilities include:

In the context of handset use, many people have multiple disabilities, so it is important to minimize assumptions about what other abilities might be available when implementing accessibility features.
People’s abilities can change over time, even within the course of a day as fatigue sets in.
People will use handsets in the context of other devices and coping strategies with which they are already comfortable. So, for example, a person with a severe motor impairment may already have a customized alternative input device setup to control their electric wheelchair that may be leveraged to provide access to a handset.

As a result, users will have diverse needs, even if they have been grouped into the same diagnostic category, or one person’s needs may differ given a different context or goal. Sometimes these needs are expressed at a very high level (e.g. to operate all functionality using only tactilely discernable controls coupled with non-visual feedback, i.e., audio or video) that can be decomposed into lower-level needs and that leaves room for a variety of different solutions. In other cases, needs are more straightforward (e.g. to silence audio output).

Moderate impairments are often more complicated to characterize:
In general, the needs/preferences of users with severe impairments are the easiest to state because they tend to involve the complete replacement of the handset’s regular user interface. On the other hand, users with moderate impairments will need or prefer various adjustments to the usual functions and therefore the possible features required become more varied.

4.2.2. Task Dependence

The accessibility of a system depends on the task to be performed. For example, if a person with a severe visual impairment wishes to use a feature phone handset solely as an appliance for making and receiving calls, she may find that a wide variety of handsets may be quite accessible to her, despite the inaccessibility of other handset features (e.g. messaging, calendar, etc.).

On the other hand, a person with a moderate mobility impairment who wishes to play games with the handset may find no accessible options despite the fact that the handset supports external keyboards and is keyboard accessible for other tasks.

Gaming accessibility:
Gaming is a popular activity on handsets, especially smartphones, but games are rarely designed for accessibility. In part, this is due to the fact that games are often graphical, time-based, and pointer-controlled, which presents significant accessibility challenges. However, a lack of incentives for game developers to build accessibility into their products is also a factor.

5. Assessment Approach

This market accessibility assessment was completed in two stages.

First, a Needs/Preferences Analysis was performed that sought to broadly identify user needs relevant to handset use and determine the degree to which those needs are addressed by features currently available in the Canadian handset market.

Then a Persona Analysis was performed with four specific personas, formulated to be usefully representative of people in the user groups scoped for this assessment (persons who are blind, have moderate-to-severe mobility disabilities, or cognitive disabilities). This analysis sought to assess the end-to-end accessibility of particular handsets to these personas.

5.1. Needs/Preferences Analysis

The method for the needs/preferences analysis was as follows:

The needs/preferences were collected. The wording of the needs/preferences is based primarily on the needs detailed in an ISO document entitled “ISO/IEC TR 29138-1:2009 Information technology — Accessibility considerations for people with disabilities — Part 1: User needs summary”[21]. This document was compiled for ISO by an international group of accessibility experts. Since this document is intended to apply to all IT, some of the wording was changed or simplified to apply more specifically to handsets.
A list of features was collected. The sources for features included those supplied by the WSPs, those listed in the Global Accessibility Reporting Initiative (GARI) of the Mobile Manufacturer’s Forum (MMF)[22] and features from other IT domains, e.g. desktop computers.
For each need/preference, the relevant feature(s) were listed.
Finally the market availability of the features on feature phones versus smartphones was added. This is in the form of a general discussion of the Canadian market availability for the features/technologies meeting the identified needs/preferences, with representative examples where necessary.

5.2. Persona Analysis

The method for the persona analysis was as follows:

Representative personas were formulated (see sub-section 5.2.1).
The handsets identified by a WSP in their CRTC submissions were researched. If a handset was discontinued as of March 2011 by the handset developer, it was marked as such and not evaluated.
The handset offerings on the WSP websites were examined. Where handsets identified by one WSP were also offered by other WSPs, this was noted. If the handset was still in production but was no longer offered by the WSP that had identified it (on their product websites), then the handset was still evaluated, in case the websites were not fully representative of in-store offerings.
Each handset was considered from the perspective of each persona.
Information provided by the WSPs, the handset developers, the platform developers and by other online sources was used. In most cases, direct testing was not performed, working under the assumption that features were reported accurately.
Tasks were listed as Y (the task could be performed), N (the task could not be performed), or P (the task might potentially be performed). In many cases, comments provide additional details.

5.2.1. Personas

The following four personas were used for the analysis:

Persona with Severe Visual Impairment:

Alexia (age 42) is a consultant who has been blind since birth. She uses a PC laptop with a screen reader on a daily basis for her job, which involves editing documents, email and searching the Web. To process documents, she uses a scanner, Optical Character Recognition (OCR) software, and a Braille embosser. In her spare time, she plays in a band and enjoys listening to music. Her company would like to provide her with a handset as they do for their other employees. Alexia has heard about OCR software for mobile phones and is also looking forward to using it as a portable music player.
Tasks: All listed tasks.
Adapted from: “Paulina” (http://www.aegis-project.eu/images/docs/Personas/PaulinaHQacc.pdf)

Persona with Severe Mobility Impairment:

Bill (age 18) is a high school student who lives with his parents. Due to Cerebral Palsy, Bill has severe motor impairments that prevent him from controlling his hands or speaking clearly. He uses an electric wheelchair that he controls via an alternative input device consisting of three head switches attached to his wheelchair. Bill uses the alternative input device, in a different mode, to communicate via AAC (Augmentative and Alternative Communication) software on his PC laptop. The system lets him type words using a scanning keyboard that are then spoken aloud by text-to-speech software. Bill likes to be out and about, but his PC laptop is bulky and his portable AAC unit does not make phone calls. He is hoping that a handset like those his friends have will be able to keep him connected.
Tasks: All listed tasks(see paragraph 5.2.2).
Adapted from: “Jane” (http://www.aegis-project.eu/images/docs/Personas/JaneHQacc.pdf)

Persona with Moderate Mobility Impairment:

Christine (51) is a university professor. Due to Multiple Sclerosis, she experiences muscle weakness and spasms in her arms and legs. She does most of her work on a desktop PC and uses a trackball mouse due to difficulty controlling a conventional mouse. While she sometimes uses speech input, she wants to make productive use of her bus commute to work so she is also interested in a model that allows external keyboard input.
Tasks: All listed tasks (see paragraph 5.2.2).
Adapted from: “Peter” (http://www.aegis-project.eu/images/docs/Personas/PeterHQacc.pdf)

Persona with Severe Cognitive Impairment:

Dave (age 26) lives with his parents. He has an intellectual disability that makes it difficult for him to understand more than simple texts and affects his ability to manage time. Dave enjoys using his desktop computer to visit websites where he can play games and watch videos. Dave and his family hope that a handset will let him keep in touch with his family and friends via voice calls and symbolic SMS messages. Dave finds it easier to make calls when he can identify the person he wishes to call from their picture. They are also interested in the ability to set automatic reminders that will help Dave manage his time.
Tasks: All tasks (see paragraph 5.2.2).except for “(5) Using social networking”.
Adapted from: “Adam” (http://www.aegis-project.eu/images/docs/Personas/adamHQacc.pdf)

5.2.2. Tasks

Making phone calls
Receiving phone calls
Sending text messages
Receiving text messages
Using social networking
Using calendar
Taking pictures
Watching videos or listening to music

5.2.3. Wireless Service Providers

Bell Aliant Regional Communications, Limited Partnership Bell Aliant Communications régionales, société en commandit (and Bell Canada)
Saskatchewan Telecommunications
MTS Allstream Inc.
Quebecor Media Inc. au nom de Vidéotron ltée
Rogers Communications Inc.
TELUS Communications Company

Shaw, Bragg and Cogeco Cable all indicated in their responses that they are not wireless service providers.

6. Assessment Results

6.1 Results of the Needs/Preferences Analysis

The needs (or preferences) of people in the scoped user groups (persons who are blind, have moderate-to-severe mobility disabilities, or cognitive disabilities) that are related to handsets are reported in a series of four tables in Appendix A. For each need/preference, the features/technologies that meet each need are listed as well as a discussion of the market availability of those features in Canada.

6.2. Results of Persona Analysis

Detailed results of the Persona Analysis are reported in “Handset Persona Analysis”. Overall results are reported below:

6.2.1. Results for Persona with Severe Visual Impairment

Screen readers are critical to effective handset use by this persona. Market-tested screen readers exist for iOS 3+ (VoiceOver), Symbian Series 60 (Mobile Speak, Nuance Talks), and Windows Mobile 6 (Mobile Speak). The TalkBack screen reader for Android is a promising solution that is still in development[23].
All of the WSPs identified handsets based on these platforms, except Videotron, which identified the HTC Google Nexus One (Android 2.2), the Motorola XT720 (Android 2.1) and the LG Wink (LG Proprietary). However, a check of the Videotron website (16 March 2011) shows that they do also offer the Nokia 5230 (Symbian Series 60) handset, which would enable the use of a screen reader.

6.2.2 Results for Persona with Severe Mobility Impairment

None of the WSPs provide handsets capable of fully meeting the needs of this persona. At this time, it appears that the Android 2+ platform and possibly the iOS 4+ platforms are the closest to having market-ready solutions for severe mobility impairment.
Only MTS lacked an identified Android handset, but a check of the MTS website (16 March 2011) shows that they also offer the Motorola Milestone A854 (Android 2.1) handset. Sasktel, MTS and Videotron do not currently offer any iPhone models.

6.2.3 Results for Persona with Moderate Mobility Impairment

For relatively simple tasks, such as making a phone call, this persona benefits from a built-in physical keyboard as opposed to a touchscreen. For tasks requiring more text-entry, the persona requires the ability to add an external keyboard.
All of the WSPs offer handsets with these capabilities, notably the iPhone, BlackBerry, LG, and Nokia E-Series handsets.

6.2.4 Results for Persona with Severe Cognitive Impairment

This persona benefits from the ability to call and receive calls and use other handset features where the user interface is relatively simple and graphical supports are available.
All of the WSPs offer handsets with the option to display images in the contact list and many of the smartphone handsets provided the option to download graphic-enhanced reminder application.
None of the handsets appeared to support an easy mechanism to compose and send messages from a user interface comprised of graphical symbols. This feature could conceivably be provided by a third-party application.

7. Discussion of Accessibility Gaps in the Canadian Handset Market

While many accessibility-related needs/preferences are indeed met by handsets in the Canadian market, some accessibility-related needs/preferences are not met by current features of handsets in the market, in which case accessibility gaps are deemed to exist.

High threshold for gaps?
Remember that this section refers to accessibility gaps in the Canadian market as a whole, rather than gaps in individual handsets or even gaps within the handsets that use a particular platform
(e.g. Blackberry OS, Android, etc.). As a result, a need/preference will not be considered a gap as long as it is met by a feature that might be present on even just a few handsets.

In fact, all of the handset platforms and handset developers have both accessibility strengths and weaknesses. For more detailed results, see “6. Assessment Results”.

7.1 Gaps in Meeting Visual-Related Needs/Preferences

Our analyses highlight this visual-related need/preference for which handsets are lacking accessibility features:

[MV3] To change the colours of visually conveyed information (including clear focus indicators, and non-distracting background): While on most platforms it is possible to change some visual properties or install complete visual “themes”, the ability to change the visual display properties of handsets in a fine-grained way is often lacking. For example, the ability to set preferred foreground and background colours to be used throughout the user interface. This additional functionality must be added by platform developers and must be respected by the software that is added by handset developers (e.g., when developing Android flavours) and by third-party application developers.

7.2 Gaps in Meeting Mobility-Related Needs/Preferences

Our analyses highlight several mobility-related needs/preferences for which handsets are lacking accessibility features:

[SM3] To have handset be compatible with assistive technology (AT) – alternative input device input: People who use alternative input devices to control appliances such as electric wheelchairs, computers, and environmental controls also need to be able to use these same devices to operate their handsets. This involves (1) connecting the alternative input device input to the handset (e.g. via Bluetooth, etc.) and (2) the ability to effectively control all aspects of the handset user interface with the alternative input device signals (e.g. via an onscreen scanning keyboard to traverse the user interface, edit text, etc.). While some relevant third-party products exist (e.g. “Click to Phone”[24] for Windows Mobile 6 that enables some access to calls and text messaging, Tekla[25] (in alpha) an onscreen scanning keyboard and Bluetooth connector for Android 2.x), this gap nonetheless remains for most tasks and requires platform developer attention.
[SM4] To operate all functionality using only speech: Speech control of certain tasks, such as dialling is very common. And other speech functions do exist (e.g., “Voice Actions for Android”). However, complete control of a handset’s functionality by voice, without any tactile input, is not currently available. Ideally, platform developers would add the built-in ability for handsets to respond to a wide range of voiced actions. However, more basic built-in or third-party systems might potentially be developed that could provide access via the relatively simple actions available through a scanning onscreen keyboard (see [SM3], above).
[MM2] To operate controls with limited accuracy of movement or with tremor or spasmodic movements: If a person has severe tremors, alternative input device access may be required (see [SM3], above). However, people with less severe tremors may be able to benefit from a combination of features such as customizable key sensitivity, guarded/recessed hardware controls, and large hardware controls, except that these are not widely available. Another possibly in the smartphone segment would be onscreen scanning keyboards, in which the touchscreen itself can be used to render buttons up to the entire size of the screen, but these are also not currently available.
[MM11] To have visual indication of keyboard shortcuts: Keyboard shortcuts exist on smartphones and are typically listed in the documentation. However, people with mobility impairments who type slowly would benefit from the built-in ability to easily determine the keyboard shortcuts for the current controls, for example by means of an overlay.
[BC2] To operate all functionality without use of hands (e.g. stylus, mouthstick): People who use a stylus or mouthstick to access handsets may find it easier to use touchscreens than to attempt to target physical buttons. However, handsets that use capacitive touchscreens[26] require an electrical connection to the body. While, this is not an issue if the stylus or mouthstick is conductive and is attached directly to the body, problems will occur if the stylus is connected to a prosthetic[27]. In order to prevent the need for homemade solutions, WSPs should ensure that they provide stylus products for operating any touchscreen-equipped handsets, without direct body contact.

An important theme here is the need for operational control that is not tied to the location of a pointer or fingertip. Instead, the option of controlling all operations programmatically via a “keyboard interface”, which might be an external keyboard or an onscreen scanning keyboard, should be available.

7.3 Gaps in Meeting Cognitive-Related Needs/Preferences

Our analyses highlight these cognitive-related needs/preferences for which handsets are lacking accessibility features:

[SC1] To have alternatives to textual information: While screen readers are available for some platforms (notably iOS), they are lacking in others (e.g., Android) and screen reader support may not extend to all core functionality (e.g. web browsing), let alone third-party applications. Another important alternative to text, symbolic communication systems, has even less support. Some third-party symbolic communication applications (e.g. Proloquo2Go) show potential, but currently do not support communication by text messaging, email, etc.
[MSC4] To slow audio, video, or animated information down slightly: Mobile players for audio, video and animations do not typically allow these media to be slowed down slightly. These features must be added by the application developers.

General UI design for cognitive-related needs/preferences:
Many of the needs/preferences related to cognitive impairments are important general UI design principles that need to be met by all of the applications on a handset that a person wishes to use (e.g. “To have cues to assist them in multi-step operations”, “To have feedback be predictable”).

8. Developments in Handset Accessibility

8.1. Developments Likely to Benefit Accessibility

The following developments are, on balance, likely to improve the accessibility of handsets in the Canadian handset market.

8.1.1. Accessibility APIs for Smartphone Platforms

Platform accessibility APIs (Application Programming Interfaces) are programmatic interfaces that are specifically engineered to provide communication between the applications running on a platform and any assistive technologies, such as screen readers. These accessibility APIs broker information such as the roles, labels and states of controls that assistive technologies need in order to provide an accurate view of the system. For example, a control appearing in an application might have the role of “checkbox” with the label “Share location” and the current state “unchecked”. As long as applications are programmed to provide the platform accessibility API with the requisite information, details such as the programming language of the software become irrelevant and there is no need for assistive technology developers to arrange custom communication with each application, which is a practical impossibility.

Platform accessibility APIs are already standard on desktop platforms (e.g. MSAA and UI Automation for Windows, AXAPI for Mac OSX, Gnome Accessibility Toolkit API for Gnome, Java Access for Java applications, etc.), but the additional processing demands of these APIs had been judged too high for the low-powered processors typical of feature phones. However, the more powerful processors built into smartphone handsets have made accessibility APIs viable and, in the last several years, they have emerged on BlackBerry OS[28], iOS[29], and Android[30]. In most cases, the APIs can be turned on or off so that people not using assistive technologies will not experience any reduction in system or battery performance.

Supporting this development is critical. Practical steps that WSPs might take either individually or in concert with other WSPs include:

Encouraging developers of platforms lacking accessibility APIs to add them. It may be useful here to adopt a policy of only offering smartphones with accessibility APIs.
Encouraging developers of platforms with accessibility APIs to further improve them.
Encouraging smartphone handset developers to use platforms that include accessibility APIs. It may be useful here to adopt a policy of only offering smartphones with accessibility APIs.
Ensuring that applications developed by or for the WSP (e.g. account management application etc.) implement communication with existing accessibility APIs.
Encouraging smartphone handset developers to ensure that applications developed by or for the handset developer (e.g. calendar application, social portal application, etc.) implement communication with existing accessibility APIs.
Encouraging application market managers to support third-party application developers in implementing communication with existing accessibility APIs. For example, the managers might: (a) include how-to information on making use of accessibility APIs, (b) include accessibility API supports such as prompting in software development kits (SDKs), and (c) include accessibility checks in the mobile application store approval processes.
Working with mobile assistive technology developers to ensure that assistive technologies (e.g. screen readers) are available on all platforms that the WSP offers. Ideally, the assistive technologies might then be offered free of charge to the WSP’s customers.

8.1.2. WAI-ARIA Support on Mobile Browsers

WAI-ARIA, which stands for “Accessibility for Rich Internet Applications”, is a W3C markup language for adding accessibility information to the complex web-based user interfaces that have become increasingly common in today’s web applications. WAI-ARIA enables web developers to communicate the information needed by the platform accessibility API (see sub-section 8.1.1), such as the role, label and state of controls to the browser. Browsers that support WAI-ARIA, pass the information on to the accessibility API, where it becomes available to assistive technologies. ARIA 1.0 became a W3C Candidate Recommendation in January 2011[31], meaning that implementations are encouraged.

Currently, ARIA support among mobile browsers is not as mature as it is on browsers for desktop systems. ARIA is only partially-implemented for iOS Safari, Opera Mini (iOS, Android), Opera Mobile (iOS, Android) and the Android Browser[32]. BlackBerry OS is moving in the direction of WAI-ARIA support with the new Webkit-based browser in BlackBerry 6.

Supporting this development is critical. Practical steps that WSPs might take either individually or in concert with other WSPs include:

Taking the steps listed in 8.1.1 to encourage platform accessibility API development, which is a pre-condition to meaningful WAI-ARIA implementation by mobile browsers.
Encouraging developers of platforms to include browsers with full ARIA support.
Ensuring that web applications developed by or for the WSP (e.g. account management websites, etc.) implement WAI-ARIA.
Encouraging handset developers to ensure that web applications developed by or for the handset developer (e.g. software update portal, etc.) implement WAI-ARIA.
Working with mobile assistive technology developers to ensure that assistive technologies (e.g. screen readers) are available that work with WAI-ARIA supporting browsers on all of the platforms that the WSP offers. Ideally, the assistive technologies might then be offered free of charge to the WSP’s customers.

8.1.3 Built-In vs. Third-Party Assistive Technology

Assistive technology (e.g. screen readers, screen magnifiers, onscreen keyboards, etc.) can be implemented as built-in platform features or as third-party applications. There are advantages and disadvantages to both approaches.

The potential advantages of built-in assistive technologies include the assistive technology being available at the time of purchase with no further downloads, no additional cost, and tight integration with the platform, including the platform accessibility API (see sub-section 8.1.1).

The VoiceOver screen reader, which is part of iOS, demonstrates the potential of built-in assistive technology when a platform developer is willing to sustain a commitment to maintenance. Because of this commitment, VoiceOver is currently the market leader in smartphone screen reader functionality and the dependability of this feature has encouraged other application developers to design their applications to support VoiceOver[33].

The main potential disadvantage of built-in assistive technologies is the reliance on platform developers, who have many other priorities and who may lack accessibility experience and/or a commitment to future maintenance.

The advantages and disadvantages of third-party assistive technology are the inverse. The assistive technology requires a separate download, may have a cost and may not be as tightly integrated with the platform. For example, there may be a lag before new platform features are supported by the assistive technologies. On the other hand, third-party assistive technology developers tend to be committed to the populations that they serve and they represent a valuable knowledge base.

Practical steps that WSPs might take either individually or in concert with other WSPs include:

Encouraging platform developers to build-in as many assistive technologies as practically possible (especially considering that maintenance of these features must be sustained).
Encouraging platform developers to work with third-party assistive technology developers (e.g. to share pre-release information), so that the assistive technology will support new platform features at the time of release.
Bundling third-party assistive technology free of charge for customers who need it.

8.1.4. Touchscreen Accessibility

Prior to the arrival of VoiceOver[34] on the iPhone 3G, the standard accessibility advice to people with severe visual disabilities was to avoid handsets with touchscreens in favour of those with hardware keyboards. Now, iPhone is the established market leader in accessibility to this user group.

VoiceOver enables access by allowing users to explore the touchscreen in a tactile manner, receiving auditory feedback of labels, etc. without actually activating the controls, which instead require a double tap to activate. This interaction model is further supported by other simple gesture controls, such as “The Rotor” in which a “virtual” dial is “turned” with two fingers to change settings, etc.

It is likely that other smartphone platforms (or third-party applications for those platforms) will add similar mechanisms to increase the accessibility of touchscreens. For example, Code Factory’s “Mobile Access”[35] application for Android takes a similar approach to exploring the touchscreen.

However, it is important to emphasize that while VoiceOver-style screen readers will increase the accessibility of touchscreen handsets to some people with visual impairments, people with visual disabilities who also have moderate to severe mobility impairments will have difficulty performing the required gestures. For these people, it will still be important to ensure external keyboard and switch access is supported.

Practical steps that WSPs might take either individually or in concert with other WSPs include:

Monitoring the development of touchscreen accessibility mechanisms by platform developers or third-party assistive technology developers.
Consider providing third-party assistive technologies that enable access to touchscreens free of charge to the WSP’s customers.
Ensuring that access to touchscreens is also provided by non-gesture-based methods (e.g. keyboard access, switch access)

8.1.5. Alternative Input Device Access

Alternative input device access is the most critical gap identified by this assessment report. However, the report also identifies some hopeful signs that potential solutions are under development.

Supporting this development is critical. Practical steps that WSPs might take either individually or in concert with other WSPs include:

Offering Bluetooth alternative input devices or Bluetooth hardware for connecting existing alternative input devices setups to handsets in the same way that other handset accessories are offered.
Encouraging handset developers and platform developers to support relevant Bluetooth profiles[36] in order to allow control via wireless keyboards and alternative input devices.
- Human Interface Device Profile (HID): Provides support for devices such as mice, joysticks, keyboards, as well as sometimes providing support for simple buttons and indicators on other types of devices.
- Serial Port Profile (SPP): This profile emulates a serial cable.
- Hands-Free Profile (HFP): Commonly used to allow car hands-free kits to communicate with mobile phones in the car. Extra features in HFP for use with handsets include last number redial, call waiting and voice dialling.
- Headset Profile (HSP): This is the most commonly used Bluetooth profile, providing support for the popular Bluetooth headsets to be used with mobile phones. It includes the ability to ring, answer a call, hang up and adjust the volume.
Encouraging platform developers to ensure full keyboard access to all the user interface functions of handsets, including: menus, status bar functions (battery charge, Wi-Fi, GPS, etc.), overlays etc.
Encouraging handset developers and platform developers to ensure handsets have a mode in which they can be turned on (or “woken up”) by a wireless alternative input device.
Encouraging application market managers to support third-party application developers in implementing full keyboard accessibility. For example managers might: (a) include how-to information on keyboard accessibility, (b) include keyboard accessibility supports such as tools for setting the order of navigation steps in software development kits (SDKs), and (c) include accessibility checks in the mobile application store approval processes.

8.2. Developments Likely to Challenge Accessibility

The following developments are likely to present at least temporary challenges to the accessibility of handsets in the Canadian handset market.

8.2.1. Platform Overhauls

The history of IT has shown that accessibility tends not to be a high priority in the early releases of new technologies. In these early releases, the focus is typically on breaking into the market against established technologies. Then, as new technologies mature, accessibility features are added in subsequent releases. A prime example of this was the addition of VoiceOver to iOS 3 after accessibility had been completely lacking in earlier releases.

A similar situation often occurs when technology is given a major overhaul. Accessibility features in the mature technology may be purposefully or inadvertently removed or disabled in the effort to ship the new product. This is currently occurring in the handset market, with the newly released Windows Phone 7, which is such a complete overhaul of Microsoft’s mobile offering that “...no applications from earlier Microsoft mobile operating systems will run on WP7...” [37], including those that provided accessibility features in earlier releases, such as the Mobile Speak screen reader application.

Practical steps that WSPs might take either individually or in concert with other WSPs include:

Clearly stating the importance of accessibility to platform and handset developers so that the issue is considered during platform overhauls.
Ensuring that the existing accessibility features of a platform are clearly documented, so that they can serve as minimum requirements to platform developers considering an overhaul.

Accessibility is compatible with innovation:
Accessibility should not be used as an argument against a platform overhaul or any other type of innovation. Rather, accessibility should simply be one of the core requirements of the new system. In fact, taking accessibility into account can help drive innovation, because ensuring flexibility and system interoperability are key aspects of accessibility and they also enable functionality that benefits all users.

8.2.2. Increasing Reliance on Third-Party Application Developers (Applications and Web Sites)

On feature phones, most of the useful functionality is provided by built-in applications developed by or for the platform developer or handset developer. As a result, the handset developer is in a position to mandate accessibility requirements.

While smartphones still include built-in applications, a much greater proportion of the functionality that customers expect is provided by third-party applications downloaded from application markets or accessed via the more capable web browsers present on smartphones. In this way, the smartphone application market is more similar to the desktop computer market in that it requires third-party applications to comply with basic accessibility principles in order to ensure a consistent and fully accessible experience for users across all handset functions. However, since compatibility with access features is not required or even explicitly recommended for mobile application store approval, many of the applications published through the official markets inadvertently conflict with built-in accessibility features, thus preventing access to many potential users.

Practical steps that WSPs might take either individually or in concert with other WSPs include:

Clearly stating the importance of accessibility to application market managers.
Encouraging platform developers and application market managers to provide accessibility supports in their resources for third-party application developers. (e.g. developer documentation, SDKs).
Encouraging mobile application store managers to take accessibility into account in their approval processes (e.g. policies for developers, approval procedures, automated software scans, etc.).

8.2.3. Lack of Coordination by Wireless Service Providers

The number of WSPs in the market has grown steadily in the past several years. While the increased competition caused by the entry of the new WSPs benefits customers in terms of cost and availability of choice, a lack of coordination may undermine efforts to increase handset accessibility for the following reasons:

The influence of any particular WSP individually approaching handset developers with feature requests may be limited.
With numerous WSPs there is increased potential for divergent or contradictory requests to handset developers.
Smaller WSPs may simply not have as many financial resources to pursue accessibility as larger WSPs.

These potential problems may be mitigated if WSPs can agree to common action. For example, multiple WSPs might agree on a common position regarding the priority with which handset developers or platform developers should address various accessibility features.

In terms of customer communication, multiple WSPs might coordinate on the development of a common tool or wizard that is able to help users determine which features they need and help them select the most appropriate handset(s). An example of this type of common effort is the Global Accessibility Reporting Initiative (GARI) of the Mobile Manufacturer’s Forum (MMF)[38], an international association of telecommunications equipment manufacturers that includes Apple, Cisco, Ericsson, Intel, Motorola, Nokia, Samsung, Nokia Siemens Networks, Sony Ericsson and TCTmobile. The MMF operates a customer-oriented website called Mobile Accessibility that allows users to “Find Phones” on the basis of select handset accessibility features[39]. While the features listed do not fully cover those identified in this report, the site provides an excellent starting point for the development of a comprehensive tool that facilitates the evaluation and compilation of accessibility requirements by WSPs.

9. Best Practices for Evaluating Handsets for Accessibility Needs

The following are best practices that should lead to improvements in the accessibility of handsets in the Canadian market, generally, and also improve the likelihood that individuals are able to select handsets that are accessible to them.

9.1 Evaluate All Handsets

WSPs should ensure that all handsets have been evaluated for accessibility prior to entering the Canadian market, not simply certain “accessible phones”. While, it should be left to WSPs to decide how to proceed on the basis of the evaluations, the information is necessary to support customer choice and inform communication with handset developers.

9.2 Collaborative Effort

Since many of the handsets are carried by multiple WSPs, it would make sense for the WSPs to cooperate on the evaluations, possibly through an industry association. This would reduce duplicative effort and help to ensure that the evaluation results are provided in a format that makes them easy to compare.

With basic handset accessibility in place, the WSPs could then compete on price, service coverage, customer service support, etc.

9.3 Nature of Evaluation

Handsets should be evaluated on the basis of whether or not a standardized list of accessibility features is present (see Appendix B for a list of features/technologies supporting accessibility or see sub-section 9.7 for GARI example). For straightforward features such as “Identifiable nib on '5' key”, a “yes” or “no” will suffice. For more involved features such as “screen readers”, it may be necessary to identify the known limitations (e.g. whether it is limited to built-in applications or usable with any properly developed third-party application, etc.)

Then a persona analysis should be performed in order to understand whether the features present in a handset are capable of providing end-to-end accessibility to users in various groups, wishing to perform various tasks. The details of analysis might be similar to the Persona Analysis performed for this assessment report, with the proviso that accessibility for additional personas would need to be added for moderate visual impairment and moderate cognitive impairment and impairments of hearing and speech, which were not in the scope of this assessment.

Future features:
In the future as new features emerge, the list of standardized accessibility features should be updated. Similarly, as new tasks become commonly performed on handsets, the tasks in the persona analysis should be updated.

9.4 Independent Verification

In order to minimize bias and increase the reliability of evaluations, an independent entity should be responsible for verifying all, or at least a random sample, of the reports. Ideally, this process would also include contributions from user advocacy groups, through a mechanism for repeatable and independent testing.

9.5 Public Reporting

The evaluation results should be made public.

9.6 Support for Customer Choice

The evaluation results should be made available to customers in a way that usefully supports purchase decisions. For example, an interactive guide might be designed for use on-line or in-store that could lead customers through a series of questions about their needs/preferences. The customer’s answers could be used by such a system to tailor the questions asked at the next step and would ultimately narrow the field of potential products to those that would most suit their personal needs/preferences.

Such an interactive guide would require some design effort in order to ensure customers were not overwhelmed by the lists of needs/preferences, but comparable systems have been developed, such as GARI’s “Find Phones” webpage (see example below), the Web-4-All wizard[40], and the OATsoft assistive technology repository’s “Browse software based on the need that it meets” feature[41].

9.7 Example: Global Accessibility Reporting Initiative (GARI)

The Global Accessibility Reporting Initiative (GARI) of the Mobile Manufacturer’s Forum (MMF)[42], introduced above, represents a promising first step in the development of a comprehensive strategy for the evaluation of handsets for accessibility.

The GARI is based on voluntary reporting by members of the Mobile Manufacturer´s Forum (MMF) on features MMF have deemed relevant to accessibility. The GARI incorporates three essential components:

A standard form for reporting on the availability of accessibility features. The form is completed for each handset model.
A centralized database storing all of the data collected from each report, and
A customer-oriented website (http://www.mobileaccessibility.info/) that uses the collected information to allow potential users to search for handsets that may offer the required accessibility features.

In its current form, the GARI may help Canadian WSPs to identify handsets that may fulfill the needs and preferences of specific groups of users with disabilities. However, in order to increase its effectiveness as a centralized resource for evaluation of handsets according to accessibility needs, several improvements would be required:

Mandatory reporting for all handsets on the Canadian market:

Currently, the GARI does not include information from several of the handset developers that serve the Canadian market, such as Blackberry, DORO and others. Also, it appears that some of the developers that are part of the MMF do not participate in GARI (e.g. Apple).

Independent verification:

Currently, the GARI does not include independent verification.

Additional fields:

Currently, the GARI is quite comprehensive in terms of the physical characteristics of the handsets with respect to the features that may be required by various groups of people with disabilities. However, the system lacks the same level of detail and breath when dealing with the features that may be required from the operating systems and built-in software. All of the features identified in the evaluation may be relevant, but especially the following:

Adjustable colours
Alternatives to multi-touch
Alternatives to orientation control
Audible touchscreen control discovery without activation
External keyboard support
High contrast mode
Magnification
Onscreen scanning keyboard
Screen reader
Stylus/mouthstick support
Supports external Braille display
Supports software-based (programmatic) control
Alternative input device accessible

Additional supports for helping customers determine features that address needs:

The GARI is based on handset features rather than accessibility needs and preferences. It is left to the user to interpret the features and the extent to which they may be related to his or her particular need or preference. A search wizard based on Needs/Preferences Analysis in this assessment report might help users better understand the connection between their needs and preferences and the available features.

10. Best Practices for Communicating Requirements to Handset Developers

10.1 Collaborative Effort

Some of the WSPs have reported that they communicate with handset developers on a relatively regular basis regarding accessibility requirements.

The effectiveness of these communications may be increased once a standardized evaluation mechanism for accessibility is in place (see section “9. Best Practices for Evaluating Handsets for Accessibility Needs”), especially if the mechanism is a collaboration of all or most Canadian WSPs (see sub-section 9.2).

It is important that accessibility feature requests also communicate the requirement for end-to-end accessibility. The goal is effective accessibility to as many tasks on handsets as possible, not simply the addition of more features.

10.2 International Standards

In order to further garner the attention of the handset and platform developers, many of whom are large multi-national companies, it may be worth exploring the creation of an international standard, similar to “ISO/IEC TR 29138-1:2009 Information technology — Accessibility considerations for people with disabilities — Part 1: User needs summary” but specific to the identification and assessment of user needs and preferences in relation to handsets.

11. Appendices

11.1 Appendix A: Detailed Results of Needs/Preferences Analysis

How to Read the Tables:

Accessibility Need/Preference: A short description of the need or preference.
Related User Need IDs (from ISO-IEC TR 29138-1:2009): The ID number of the need in the ISO document. In order to ensure effective applicability to handsets, some needs have been combined and others split.
Relevant Features/Technologies (from Appendix B): Needs or preferences may sometimes be fulfilled by different handset features and/or technologies.
Discussion of Market Availability: A general discussion of the Canadian market availability for the features/technologies meeting the identified needs/preferences, with representative examples where possible. To aid with comparisons, the market availability of features has been categorized as follows (Note: The colours refer to these categories):
- [A] Typically Available
- [B] Likely Available (requires user research)
- [C] Available With Limitations
- [D] Not Typically Available
- n/a Not Applicable
Feature phones: Availability in lower-end handsets.
Smartphones: Availability in higher-end smartphones.
Notes: Other relevant information

Table 1: Visual needs/preferences relevant to the use of mobile wireless handsets

Notes:

This list contains individual needs/preferences (based on ISO-IEC TR 29138-1:2009) primarily related to visual disabilities. Most people with disabilities will have multiple needs/preferences simultaneously, at different times or in different contexts.
In some cases, needs/preferences are labelled "[End-to-End]". These are needs/preferences that can be usefully decomposed into constituent needs/preferences.
In some cases a need is actually a “[General UI Design Principle]” that must be met by the handset as well as all or most software on the handset to enable access. In these cases, a discussion of market availability is typically omitted.
Many of the “Cross-Cutting Needs” in Table 4 will apply. Those that do apply will be marked with the label “visual” in the notes.

Accessibility Need/Preference	Related User Need IDs (from ISO)	Relevant Features/Technologies (from Appendix B)	Discussion of Market Availability		Notes
			Feature Phones	Smartphones
Needs/Preferences Related to Severe Visual Impairment
[End-to-End] SV1. To operate all functionality using only tactilely discernable controls coupled with non-visual feedback (i.e., audio or video)	6-1	Especially: - Screen reader; - Includes hardware controls; - Identifiable nib on 'J' & 'F' key (qwerty keypad only); - Audible touchscreen control discovery without activation	[C] Due to lack of screen readers in feature phones, users are generally limited to making calls (by dialling numbers) and receiving calls by opening the phone when it rings, but little else (e.g. messaging, use of WAP browsers).	[B] Screen readers exist for several smartphone platforms, but there are some important differences. The older generation, including Nuance Talks for Symbian S60[43] and Mobile Speak for Symbian S60 and Windows Mobile 6 do not make use of a platform accessibility API. Instead the screen readers include direct communication with certain included applications. The newer generation, including Voiceover for iOS, BlackBerry’s Oratio (which is not yet available in Canada[44]) and TalkBack for Android (which is not yet a market-tested solution) use platform accessibility APIs. Using platform accessibility APIs opens the possibility of wider screen reader support but also requires software developers (built-in and third-party) to make their software accessible to the screen readers by properly exposing information to the accessibility API.	Touchscreen handsets can be made accessible with screen readers as long as the act of orienting to the controls does not cause inadvertent actions. However, it may still be time-consuming to type text, so the ability to connect an external keyboard is preferred.
SV2. To have all information (including labels, status, feedback, etc.) conveyed visually (e.g. by text, icons, images, LEDs) also be available in auditory and/or spoken form	1-1, 4-1, 5-1, 13-7, 14-2	- Includes speaker or headphone connection; - Includes headphone connection; - Sonic alerts and notifications; - Spoken alerts and notifications; - Digital dial read-out; Screen reader; - Supports software-based (programmatic) control	[C] Many feature phones include at least some sonic alerts. Textual information typically is not available in a spoken form.	[B] Many smartphones include at least some sonic alerts. Screen-readers are required for textual information (e.g. Voiceover for iOS, Nuance Talks for Symbian S60, etc.)	Headphone connectivity is important here for privacy.
SV3. To have all information (including labels, status, feedback, etc.) conveyed visually (e.g. by text, icons, images, LEDs) also available in tactile form	1-2, 4-1, 4-8, 5-1, 5-2	- Includes vibration; - Customizable vibration; - Vibration alerts and notifications; - Includes Braille display; - Supports Braille display	[C] Many feature phones include at least some vibration alerts. No Braille display support.	[B] Many smartphones include at least some vibration alerts. For Braille support see SV7, below.	This need is best met for complex information by Braille displays, since information content of vibration is quite limited.
SV4. To locate, identify and re-locate physical controls by touch without activating them	3-1, 3-3, 3-5, 8-1	- Includes hardware controls; - Standard keypad layout; - Individual controls tactilely discernible; - Identifiable nib on 'J' and 'F' key (qwerty keypad only); - Hardware QWERTY keypad	[A] Many feature phones have hardware controls with required nibs.	[A] Many smartphones have hardware controls with required nibs.	This need refers to physically discernible controls. See SV5 for touchscreens.
SV5. To locate and identify touchscreen controls by touch without activating them	3-1, 3-5, 8-1	- Audible touchscreen control discovery without activation	[D]	[B] Voiceover on iOS is the only market tested solution in the smartphone market. There are potential developments on Android as well.	For example, exploring the touchscreen by touch reads control labels, with a double tap required to activate controls.
SV6. To have non-actionable elements (logos, decorative details) not feel like buttons or controls	3-2	N/A (not a feature per se)	[A]	[A]	This is not an issue on most handsets.
SV7. To have handset be compatible with assistive technology (AT) (e.g. Braille Displays, CCTV)	15-1, 15-2, 15-3	- Braille display compatibility; - Video/TV out port	[D]	[B] There is Braille display support via Bluetooth on iOS, Symbian S60 (via Mobile Speak and Nuance Speak) and Windows Mobile 6 (via Mobile Speak). Video/TV out is available on iPhone and select Android handsets.
*Audio Needs/Preferences of People with Visual Disabilities* (Note: While needs relating the hearing disabilities is not a report deliverable, a subset of needs is included here because effective audio interfaces are important for non-visual access)
AV1. To adjust the volume to a suitable level	2-3	- Volume controls	[A]	[A]	Most handsets provide volume control.
AV2. To have audio information of sufficient quality (e.g. volume, direction, clarity, frequency)	4-7, 5-8	- Sonic alerts and notifications; - Spoken alerts and notifications	[A]	[A]	This would also apply to screen reader output for handsets that include one.
AV3. To perceive foreground audio information in the presence of background (regular audio, device noise, ambient noise)	2-8, 14-3	- Screen reader; - Volume controls; - Includes headphone connection	[A]	[A]	Most handsets provide headphone connections and other features that help reduce ambient noise. Device noise is not an issue with most handsets.
AV4. To have different auditory patterns when audio is used as an alert for different events	4-4, 5-4	- Sonic alerts and notifications; - Spoken alerts and notifications	[A]	[A]	Most handsets provide different alerts for calls versus messages, etc.
AV5. To increase the rate (speed) of audio alternatives	12-3	- Screen reader	[D] Since screen readers for reading the alternatives are not available.	[B] When screen readers are present, but not all smartphone platforms include market tested screen readers (e.g. Android).
AV6. To silence audio output	14-11	- Volume controls; - Mute	[A]	[A]
AV7. To have private listening capability, when using audio alternatives to visual information in public places	10-1	- Includes headphone connection	[A]	[A]	Most handsets provide a headphone connection and in many cases Bluetooth headphone connection capability.
*Vibration Needs/Preferences*
VV1. To have different vibration patterns when vibration is used as an alert for different events	2-5, 4-4, 5-4	- Customizable vibration	[C]	[C]	Vibration really only offers a limited number of discernible alternatives
Needs/Preferences Related to Moderate Visual Impairment
[End-to-End] MV1. To have all information conveyed visually be visible with low vision	1-6, 4-5, 5-5	Especially: - High contrast focus indicators; - Adjustable colours;	[C] Most feature phones include limited on-screen display customization options.	[B] Customization options are often available at the level of built-in presets such as high-contrast themes. More fine-tuned customization such as changing the size and color of certain types of information is often not possible or cumbersome and third-party software often does not respect the settings.
MV2. To have focus and pointing indicators that are visible with low vision	3-7	- High contrast focus indicators	[B]	[B]	Focus indicators tend to be fairly visible, especially in handsets that do not include touchscreens, because all users need to see the location of focus. Most handsets do not include pointing indicators. Visibility also depends on the currently selected theme.
MV3. To change the colours of visually conveyed information (including clear focus indicators, and non-distracting background)	1-5, 1-11, 3-4, 3-7, 5-7	- Adjustable colours; - Customizable themes	[C] May require add-on or non-trivial customization	[B] Most smartphones have the ability to change text colours, but sometimes this is via overall themes rather than granular customization. iOS has a white on black high-contrast mode.	Some third-party applications remove the user's ability to customize the UI, and some OEMs (e.g. Samsung, HTC) do this on a system-wide basis.
MV4. To have information and controls that visually contrast with their surroundings	1-11, 3-4	- Backlit controls; - Individual controls visually discernible; - Large hardware controls; - Large control labels; - High contrast control labels; - High contrast mode	[B]	[B] Many smartphones includes at least some of these features. iOS has a white on black high-contrast mode.
MV5. To have visually conveyed information be sufficiently large	1-7, 14-9	- Magnification (with panning); - Magnification (with wordwrap); - Adjustable font size	[C] Some feature phones offer adjustable font size	[B] iOS and Android offer system-wide magnification. In addition Magnifier software is available (e.g. Code Factory Mobile Magnifier for Symbian S60 and Windows Mobile 6).	Limitations inherent to small screen sizes may apply.
MV6. To have sufficient brightness for visually conveyed information (e.g. luminance for displays, illumination for printed)	1-3	- Adjustable brightness; - Backlit controls	[A]	[A]	Luminance for displays and keypads is a standard feature.
MV7. To avoid glare (due to reflection or excessive brightness)	1-8, 1-9	- Anti-glare screen; - Adjustable brightness	[A]	[A]	Glare reduction features are common.
MV8. To have information conveyed through colour (other than the colour itself) also conveyed in another way that does not rely on colour.	1-4, 4-6, 5-6	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality (e.g. For example, answer/hang-up icons are often green/red)	[A] This design principle is typically upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MV9. To have non-actionable elements (logos, decorative details) not look like buttons or controls	3-2	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality.	[A] This design principle is typically upheld by the basic handset functionality.	But third-party developers must follow the same principle.

Table 2: Mobility needs/preferences relevant to the use of mobile wireless handsets

Notes:

This list contains individual needs/preferences (based on ISO-IEC TR 29138-1:2009) primarily related to mobility disabilities. Most people with disabilities will have multiple needs/preferences simultaneously, at different times or in different contexts.
In some cases, needs/preferences are labelled "[End-to-End]". These are needs/preferences that can be usefully decomposed into constituent needs/preferences.
In some cases a need is actually a “[General UI Design Principle]” that must be met by the handset as well as all or most software on the handset to enable access. In these cases, a discussion of market availability is typically omitted.
Many of the “Cross-Cutting Needs” in Table 4 will apply. Those that do apply will be marked with the label “mobility” in the notes.

Accessibility Need/Preference	Related User Need IDs (from ISO)	Relevant Features/Technologies (from Appendix B)	Discussion of Market Availability		Notes
			Feature Phones	Smartphones
Needs/Preferences Related to Severe Mobility Impairment
[End-to-End] SM1. To operate all functionality from an alternative interface (e.g. voice, alternative keyboard, alternative input devices) with only visual feedback	6-4	Especially: - Alternative input device accessible; - Onscreen scanning keyboard; - External keyboard support; - Supports software-based (programmatic) control	[C] Only basic functionality is available and usually this is by voice. Access via external alternative input devices is lacking.	[C] BlackBerry, iPhone, and Symbian smartphones provide the most consistent external keyboard support. Many smartphones include voice input capabilities for select functions. Access via external switches is not extremely limited.
SM2. To have handset be compatible with assistive technology (AT) – keyboard input	15-1, 15-2, 15-3	- External keyboard support;	[B] Feature phones are available that support external keyboards via Bluetooth (Human Interface Device Profile– HID)	[B] BlackBerry, iPhone, and Symbian smartphones provide the most consistent external keyboard support via Bluetooth (Human Interface Device Profile– HID). On Android, third-party applications usually must be installed.	External keyboards facilitate custom placement and the use of key guards.
SM3. To have handset be compatible with assistive technology (AT) – switch input	15-1, 15-2, 15-3	- Alternative input device accessible; - Onscreen scanning keyboard; - Supports software-based (programmatic) control	[C] Overall, access is fairly limited. There are input device access kits available for feature phones supporting Bluetooth (Handset Profile - HSP) that may allow only dialling and call answering (e.g. VoiceBT product).	[C] Overall, access is fairly limited. Switch access to dialling and text messaging is available on Windows Mobile 6 via a product called “Click To Phone”[45], but interaction is via specialized software. Another product is the VoiceBT which allows dialling and answering calls on smartphones supporting Bluetooth (Headset Profile HSP). On Android 2.x, the Tekla[46] (alpha) onscreen scanning keyboard and Bluetooth shield hold some potential for access to wider functionality. Switches are available for iPhone, but once again the switch needs to be specifically supported by each application.	Many users who would have this need/preference will have switches setup to control a electric wheelchair. Ideally the same switches should be able to be repurposed to control the mobile device.
SM4. To operate all functionality using only speech	6-19	- Includes voice control; - Customizable voice control - Speakerphone (full duplex)	[C] Voice dialling is offered by many feature phones, but other functionality is generally not accessible via voice.	[C] All major smartphone operating systems offer some form of voice control (e.g., Voice Actions for Android[47]). None of the current implementations allow for full control.	Voice control cannot be assumed for all users with severe mobility impairments, due to the added possibility of speech impairments.
SM5. To mount handset within viewable range of those seated in wheelchairs	1-7, 3-6, 4-9, 6-10	- Custom mounting	[A]	[A]	Third-party mounting option products are available.
4-3, 5-3	- Textual alerts and notifications; - Graphical alerts and notifications	[A]	[A]	Important since the user is not holding the device.
SM7: To have auditory alternative to subtle tactile feedback	4-3, 5-3	- Sonic alerts and notifications; - Spoken alerts and notifications	[A]	[A]	Important since the user is not holding the device.
Needs/Preferences Related to Moderate Mobility Impairment
MM1. To operate all functionality without using a touchscreen or other pointing device (e.g. trackball)	6-2, 6-3	- Includes hardware controls; - Hardware QWERTY keypad; - External keyboard support; - Includes D-Pad; - External mouse support;	[A] Many feature phones are available with hardware keypads and QWERTY keyboard controls. Also, feature phones are available that support external keyboards via Bluetooth (Human Interface Device Profile– HID).	[B] Relatively more smartphones (than feature phones) rely on touchscreens or trackballs for primary input. However, smartphones are available with hardware keypads and QWERTY keyboards for the various smartphone platforms except iPhone. Many BlackBerry handsets include non-touchscreen pointer input (from a trackball). But, these handsets typically include keyboard alternatives for the same functionality. Many smartphones have external keyboard (and in some cases external mouse) support via Bluetooth (Human Interface Device Profile– HID). However, with Android, third-party applications are usually required to support external keyboards[48].	Having to rely on an external keyboard or mouse makes the handset less convenient. And of course some users are not able to operate an external mouse effectively.
MM2. To operate controls without much accuracy of movement or with tremor or spasmodic movements	6-15, 8-2	- Customizable key sensitivity; - Guarded/recessed controls; - Large hardware controls; - External keyboard support; - Onscreen scanning keyboard;	[C]	[C]	Customizable key sensitivity is not typically offered. Guarded/recessed and large hardware controls help in some cases but are largely insufficient due to significant size limitations in handsets. Having to rely on an external keyboard makes the handset less convenient. An onscreen scanning keyboard is part of Tekla[49] (alpha) for Android 2.x.
MM3. To operate all functionality without simultaneous actions	6-6	- StickyKeys; - Alternatives to multi-touch	[A]	[B] Touchscreen based smartphones may use multi-touch. Sometimes alternatives are limited.
MM4. To operate all functionality without much force	6-7, 6-8	- Includes touchscreen	[A] Touchscreens equipped feature phones are available.	[A] Many smartphones include touchscreens.	In contrast to the needs above, here a touchscreen is considered an accessibility enhancing feature because they typically demand less force. However, users should be able to try a wide range of handsets in order to make a selection.
MM5. To operateall functionality without much stamina (includes sustained or repeated activity without sufficient rest)	6-9	- Includes voice control; - Includes touchscreen; - Includes hardware controls; - Hardware QWERTY keypad;	[A] Many feature phones include one or more of these features.	[A] Many smartphones include one or more of these features.	While touchscreens may require less force for some operations they may be harder to type on than sufficiently-sized hardware QWERTY keyboards. Users should be able to try a wide range of handsets in order to make the best selection.
MM6. To operate all functionality without tight grasping	6-11	- Non-slip surfaces; - Flat back for table top operation	[A]	[A]	Wide range of third-party cases facilitating grip are available. Requires market research by users, but may be facilitated by vendors.
MM7: To operate all functionality without pinching	6-12	- Alternatives to multi-touch	[A] Multi-touch is not common on feature phones.	[B] Some actions (e.g. zoom) will not be available when no alternative is provided
MM8: To operate all functionality without twisting of the wrist	6-13	- Flat back for table top operation	[A]	[A]
MM9. To adjust the speed and acceleration of input devices	6-16	- Customizable pointer sensitivity	n/a (Feature phones typically do not support pointers)	[B] Available for the trackball in BlackBerry devices. Other smartphones assume pointer input is from the touchscreen.
MM10. To operate all functionality with only a left or only a right hand	6-17	- Single-hand operation	[A]	[A]
MM11. To have visual indication of keyboard shortcuts	6-23	- Includes keyboard shortcuts - Keyboard shortcut indicators	n/a (Feature phones typically do not support keyboard shortcuts)	[C] Smartphones with keyboards often include shortcuts, but these may not be indicated.	Screen size restrictions limit the availability of on-screen shortcuts
MM12. To have controls that are not activated by a slight touch	8-3	- Customizable key sensitivity; - Audible touchscreen control discovery without activation	[A] Most handsets with hardware keyboards meet this.	[A] Although most smartphones with hardware keyboards also meet this, only the iOS offers touch-based discovery without activation.
Needs/Preferences Related to use with Prosthetics
BC1. To operate all functionality without requiring direct body contact (e.g. prosthetic hand)	6-14	- Includes hardware controls; - Includes touchscreen; - Touchscreen does not require body contact	[B] Most handsets with hardware keyboards meet this. Capacitive or heat-activated touchscreens are problematic if they require direct operation with the body (or an electrical connection with a body part).	[B] Most handsets with hardware keyboards meet this. Capacitive or heat-activated touchscreens are problematic if they require direct operation with the body (or an electrical connection with a body part).
BC2. To operate the product without use of hands (e.g. stylus, mouthstick)	6-18	- Includes touchscreen; - Touchscreen does not require body contact	[C] Hardware buttons (including the power/wake-up button) may be too small to be targeted with a mouthstick or stylus. Touchscreens typically work for users, except in cases where body contact is required (see BC1).	[B] Hardware buttons (including the power/wake-up button) may be too small to be targeted with a mouthstick or stylus. Third-party applications may be available on some platforms to allow “waking up” the phone by touching the touchscreen. Touchscreens typically work for users, except in cases where body contact is required (see BC1).

Table 3: Cognitive needs/preferences relevant to the use of mobile wireless handsets

Notes:

This list contains individual needs/preferences (based on ISO-IEC TR 29138-1:2009) primarily related to cognitive disabilities. Most people with disabilities will have multiple needs/preferences simultaneously, at different times or in different contexts.
In some cases, needs/preferences are labelled "[End-to-End]". These are needs/preferences that can be usefully decomposed into constituent needs/preferences.
In some cases a need is actually a “[General UI Design Principle]” that must be met by the handset as well as all or most software on the handset to enable access. In these cases, a discussion of market availability is typically omitted.
Many of the “Cross-Cutting Needs” in Table 4 will apply. Those that do apply will be marked with the label “cognitive” in the notes.

Accessibility Need/Preference	Related User Need IDs (from ISO)	Relevant Features/Technologies (from Appendix B)	Discussion of Market Availability		Notes
			Feature Phones	Smartphones
Needs/Preferences Related Primarily to Severe Cognitive Impairments
SC1. To have alternatives to textual information	13-14, 14-10, 14-12	- Screen reader; - Text-to-speech; - Spoken alerts and notifications; - Sonic alerts and notifications; - Vibration alerts and notifications; - Graphical alerts and notifications; - Symbolic communication system support - Photo associated contacts	[C] Without screen readers, this is typically for voice calls only. Photo associated contacts are widely available.	[C] Screen readers are available on several smartphone platforms (Voiceover for iOS, Nuance Talks for Symbian S60 and Mobile Speak for Symbian S60 and Windows Mobile 6). Sonic and vibration alerts are available on many smartphone handsets. Symbolic communication is available as part of some third-party AAC applications. Photo associated contacts are widely available.
SC2. To have each function on its own key rather than having keys change their functions but look/feel the same	13-12	- Includes hardware controls; - Includes touchscreen - Simplified user interface	[C] Typically for voice calls only.	[B] Smartphones with touchscreens offer potential for applications to be developed with special-purpose user interfaces (e.g. proloquo2go for iPhone).	Given the range of functions that handsets can perform, it is not realistic that every function could have its own hardware key.
Needs/Preferences Related to Moderate and Severe Cognitive Impairments
*Needs/Preferences that relate to particular features*
MSC1. To have much more time to read displayed information and complete actions time pressure	7-1, 7-2	- Configurable screen timeouts; - Configurable system timeouts	[B] Feature phones typically include configurable screen timeout settings.	[B] Smartphones typically include configurable screen timeout settings.
MSC2. To avoid visual or auditory distractions that prevent focusing on a task	7-4	- Customizable layout; - Customizable themes; - Simplified user interface	[B] Feature phones tend to have smaller screens, less functions and less complicated interfaces.	[B] Smartphones typically include customization options (e.g. which indicators to display). In addition, the screens are still small compared to desktop systems so platforms typically show one screen at a time.
MSC3. To have navigation options that support different thinking styles (e.g. non-hierarchical)	13-5, 13-6	- Customizable navigation	[C] Limited navigation customization options.	[B] Smartphones provide more navigation customization options.	Support for custom device content layout and navigation is typically limited
MSC4. To slow audio, video, or animated information down slightly	14-6	- Configurable media playback	[C] May be available in some third -party media players.	[C] Screen readers include speed controls and some third-party media players include slowing features.
Needs/Preferences that relate to general UI design rather than particular features. However, in some cases applications may be available that can provide support in these areas.
MSC4. To have information necessary to plan their actions in advance	7-3	[General UI design principle]	[B] In many cases this design principle is upheld by the basic handset functionality or it is possible to restart the process if information must be gathered.	[B] In many cases this design principle is upheld by the basic handset functionality or it is possible to restart the process if information must be gathered.	But third-party developers must follow the same principle.
MSC5. To have steps for operations minimized and clearly described	13-8	[General UI design principle]	[B] In many cases this design principle is upheld by the basic handset functionality.	[B] In many cases this design principle is upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MSC6. To have interfaces that limit the memorization required of the user to operate them successfully	13-9	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality.	[A] This design principle is typically upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MSC7. To have cues to assist them in multi-step operations	13-10	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality.	[A] This design principle is typically upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MSC8. To have simple interfaces that only require them to deal with the controls they need (advanced or optional controls removed in some fashion)	13-11	[General UI design principle]	[B] In many cases this design principle is upheld by the basic handset functionality.	[B] In many cases this design principle is upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MSC9. To have feedback be predictable	5-12	[General UI design principle]	;[A] This design principle is typically upheld by the basic handset functionality.	[A] This design principle is typically upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MSC10. To have wording, symbols, and indicators that are as easy to understand as possible given the device, task and culture	13-2, 13-3, 14-1	[General UI design principle]	[B] In many cases this design principle is upheld by the basic handset functionality.	[B] In many cases this design principle is upheld by the basic handset functionality.	But third-party developers must follow the same principle.
MSC11. To have information conveyed without "figures of speech" (such as abbreviations, idioms, metaphors, etc.)	14-13	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality, since “figures of speech” are rare.	[A] This design principle is typically upheld by the basic handset functionality, since “figures of speech” are rare.	But third-party developers must follow the same principle.
MSC12. To have information be available regarding the meaning associated with colours and symbols	14-14	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality (e.g. icons explained in the manual).	[A] This design principle is typically upheld by the basic handset functionality (e.g. icons explained in the manual).	But third-party developers must follow the same principle.
Needs/Preferences Related to Avoidance of Seizures
AS1. To avoid visual patterns that causes them to have seizures	11-5	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality.	[B] This design principle is typically upheld by the basic handset functionality, however with larger screens, more media content and more third-party applications there is more potential for problems.	But third-party developers must follow the same principle.
AS2. To avoid auditory patterns that causes them to have seizures	11-6	[General UI design principle]	[A] This design principle is typically upheld by the basic handset functionality.	[A] This design principle is typically upheld by the basic handset functionality.	But third-party developers must follow the same principle.

Table 4: Cross-cutting needs/preferences relevant to the use of mobile wireless handsets

Notes:

Cross-cutting needs/preferences potentially apply to persons in more than one of the other groups (visual, mobility, cognitive).
In some cases a need is actually a “general UI design principle” that must be met by all or most software on a handset to enable access. In these cases, a discussion of market availability is omitted.

Accessibility Need/Preference	Related User Need IDs (from ISO)	Relevant Features/Technologies (from Appendix B)	Discussion of Market Availability		Notes
			Feature Phones	Smartphones
*Needs/Preferences that relate to particular features*
CC1. To see and hear text simultaneously	1-12	- Screen reader; - Text-to-speech	[D] Screen readers are not available.	[B] Screen readers exist for several smartphone platforms (Voiceover for iOS, Nuance Talks for Symbian S60 and Mobile Speak for Symbian S60 and Windows Mobile 6)	Cross-cutting: Visual(Moderate)-Cognitive
CC2. To pause, and re-play information presented using audio, video or animation.	1-10, 2-7, 14-7, 14-8	- Configurable media playback;	[B] Typically met by video players.	[B] Typically met by video players.	Cross-cutting: Visual-Cognitive
CC3. To have feedback alternatives differentiated to the same degree as the primary feedback modality (e.g. visual/tactile indicators for different ring tones)	4-4, 5-4	- Customizable visual alerts; - Customizable auditory alerts; - Customizable vibration	[B] Ring tones, auditory alerts, and visual alerts are most customizable.	[B] Ring tones, auditory alerts, and visual alerts are most customizable.	Cross-cutting: Visual-Mobility-Cognitive
CC4. To have clear feedback of hardware connector engagement (e.g. USB connector, etc.)	5-11	- Feedback upon connector; - Easy battery placement	[B] Typically met.	[B] Typically met.	Cross-cutting: Visual-Mobility-Cognitive
CC5. To have controls that are not activated when they receive focus	8-1, 8-3	- Focus navigation separate from activation	[A] This is typical in non-touchscreen handsets.	[B] This is generally supported but third-party developers may break focus consistency	Cross-cutting: Visual-Mobility
CC6. To have no hazards or hazards that are obvious, easy to avoid, and difficult to trigger	11-1	Case free of hazards	[A]	[A]	Cross-cutting: Visual-Mobility-Cognitive
CC7. To have handsets that do not rely on specific senses (e.g. seeing warning labels) or fine movement (e.g. gentle movements) to avoid injury	11-2, 11-3, 11-4	Case free of hazards	[A]	[A]	Cross-cutting: Visual-Mobility-Cognitive
CC8. To have system level accessibility preference settings that apply and are respected across applications	12-4, 12-5, 12-6, 16-2	System level accessibility preferences	[C] Limited set of preferences available	[B] Preferences are mostly respected but are ignored in some contexts	Cross-cutting: Visual-Mobility-Cognitive
CC9. To have accessibility preference settings that apply immediately (preferably without requiring system reboot)	12-7	System level accessibility preferences	[A]	[A]	Cross-cutting: Visual-Mobility-Cognitive
CC10. To save and restore individual accessibility preference settings	12-8	System level accessibility preferences	[A]	[A]	Cross-cutting: Visual-Mobility-Cognitive
CC11. To reset (to initial condition)	9-4	Factory reset	[A]	[A]	Cross-cutting: Visual-Mobility-Cognitive
*Needs/Preferences that relate to General UI design rather than particular features. However in some cases, applications may be available that provide support in these specific areas.*
CC12. To have consistent and predictable user interfaces	12-12, 3-9	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC13. To access the controls that allow them to turn on and adjust the built-in accessibility features	16-2	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive. Pre-configured handsets may be available from carriers, iPhone OS provides the simplest activation for users with visual impairments
CC14. To have their accessibility functions available at all times, without disruption	16-10	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC15. To have clear and easy activation mechanisms for any access features	13-4	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC16. To have information describing the layout of the operational parts	3-8, 13-1	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC17. To have visual or tactile feedback occur at the same location as the control	5-10	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC18. To have similar patterns of activation for similar actions	6-22	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC19. To have notifications when the product detects errors made by the user	9-1	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC20. To have unambiguous guidance on what to do in the event of a reported error	9-2	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC21. To have a means to go back and undo the last thing(s) they did	9-3	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC22. To have the privacy and security of their information protected, even if they are not able to do the “expected” things to protect it themselves	10-2, 10-3	[General UI design principle] - Screen curtain			Cross-cutting: Visual-Mobility-Cognitive
CC23. To have alternate modes of operation that are effective given the time constraints of the task	12-1	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC24. To have keyboard navigation that follows a meaningful sequence through form controls	12-2	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC25. To have visual information generated by access features (such as captions) not interfere with other visual information	14-4	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive
CC26. To have handsets be usable by those with multiple disabilities	16-7	[General UI design principle]			Cross-cutting: Visual-Mobility-Cognitive. This is a technical challenge in any domain, but is made more difficult when accessibility features are not interoperable.
*Needs/Preferences that relate to service provided by WSPs more than to handsets*
WSP1. To have timely access to trained customer service personnel (e.g. Help Desk)	16-4	Access to trained customer service people			Cross-cutting: Visual-Mobility-Cognitive.
WSP2. To have accessible training and support materials	16-5	Electronic documentation			Cross-cutting: Visual-Mobility-Cognitive.
WSP3. To have a means to provide feedback about improvements to accessibility to meet their particular needs	16-8	Access to trained customer service people			Cross-cutting: Visual-Mobility-Cognitive
WSP4. To have handset accessibility information to be disseminated to distributors, retailers, installers, system integrators, customer organizations, and people with disabilities	13-13, 16-9	Access to trained customer service people			Cross-cutting: Visual-Mobility-Cognitive
WSP5. To have electronic access to copyrighted and otherwise protected material	16-6				Cross-cutting: Visual-Cognitive. Refers to situations where one only one modality is available for purchased but another is required.

11.2 Appendix B: Features/Technologies Supporting Accessibility Needs/Preferences

This appendix provides the information about the features/technologies that appear in the “Relevant Features/Technologies” column in the Tables (1-4) within Appendix A.

Mobile Wireless Handset Features/Technologies	Short Description	Notes on Market Availability
Handset Shape
Handset shape-block	The screen and hardware keypad/keyboard (if any) are always exposed, so no additional movements are required.	Widely available in feature phones and smartphones.
Handset shape-flip/slide/swivel	The screen and/or hardware keypad/keyboard are to some extent hidden until the handset is opened. Often, the acts of opening and closing the handset are linked to certain actions (e.g. opening the handset answers a call, closing the handset hangs up a call).	Widely available in feature phones, less available in smartphones.
Features/Technologies Related to Screens
Includes screen	The handset includes a screen for displaying visual information.	Widely available.
Large screen	The screen is larger than average, sometimes covering most of the handset. Facilitates magnification.	Available in some handsets, especially smartphones.
Backlit screen	An additional source of illumination for screens that do not produce their own light. Enhances luminance and contrast.	Widely available.
Anti-glare screen	A coat or layer placed over screens to reduce reflection from external light sources. Enhances contrast and facilitates discerning foreground from background.	Widely available.
Adjustable screen brightness	A method for changing the illumination level of the screen. Enhances visibility.	Widely available.
Adjustable screen contrast	A method for changing the brightness ratio of the lightest to the darkest parts of all elements on the screen. Enhances visibility.	Available in some handsets (liquid crystal displays).
No visible screen flicker	Lack of fading between frames (greater than 60Hz). Enhances visibility.	Widely available.
Video/TV out port	A method for displaying the screen image on an external monitor or magnifying equipment.	Available in some handsets (iPhone, some Android).
Features/Technologies Related to Touchscreens
Includes touchscreen	The handset includes a screen that may receive tactile input. This enables software to set the size and visual appearance of controls.	Available in some feature phones and most smartphones.
Touchscreen does not require body contact	The touchscreen can be operated by a stylus, prosthesis etc. without electrical connection to the body.	May be available in some handsets.
Audible touchscreen control discovery without activation	The touchscreen enables eyes-free tactile exploration.	Available on some handsets (e.g. iPhone).
Alternatives to multi-touch	Alternatives are available for functions controlled through simultaneous interaction with two or more points of a touchscreen (e.g. pinching to zoom out).	Possible, but often application-dependent.
Alternatives to gesture control	Alternatives are available for functions controlled through tactile paths on a touchscreen.	Possible, but often application-dependent.
Features/Technologies Related to Visual Display Settings
High contrast mode	A method that instructs individual applications to display in high contrast (as opposed to “Adjustable screen contrast” which applies globally).	Available in some handsets (e.g. iPhone).
High contrast focus indicators	Highly visible indicators on onscreen elements that currently have focus.	Widely available.
Adjustable font size	A method for changing the default size of all displayed text.	Available in some handsets.
Adjustable fonts	A method for changing the font type of all displayed text.	Available in some handsets.
Adjustable colours	A method for changing the colours used in the display (text colours, background colours, etc.).	Not typically available.
Customizable themes	A method for changing the appearance of all elements on the screen (including font properties, colours, etc.).	Current implementations are limited to preset theme collections.
Panning	A method for navigating content larger than the screen.	Available in some handsets.
Magnification (with panning)	A method for increasing of the entire screen image, while allowing for navigation via panning the view that is visible on the screen.	Available in some handsets.
Magnification (with wordwrap)	A method for increasing of content on the screen while reflowing the content to avoid the need for panning.	Available in some handsets.
Textual alerts and notifications	A method for presenting all system alerts and notification in textual form.	Widely available.
Graphical alerts and notifications	A method for presenting system alerts and notification in graphical form (e.g. icons).	Widely available. Not all messages can effectively be communicated via simple graphics.
Customizable visual alerts	A method for changing the appearance of all visual (textual and graphical) system alerts and notifications.	Subject to theming limitations.
Screen curtain	Method for turning off the visual display for privacy and battery performance while a handset (including its touchscreen, if any) remains active.	Available on iOS.
Features/Technologies Related to Auditory Display
Includes speaker	The handset includes a speaker for displaying auditory information.	Widely available.
Includes headphone connection – plug	The handset includes a plug connection for external headphones.	Widely available.
Includes headphone connection – non-plug	The handset includes a non-plug connection for external headphones (e.g. Bluetooth).	Widely available.
Volume controls	The handset includes controls for changing the volume.	Widely available.
Mute	A method for muting all sounds.	Widely available.
Sonic alerts and notifications	A method for presenting all system alerts and notification in auditory form (e.g. beeps).	Widely available.
Spoken alerts and notifications	A method for presenting all system alerts and notification in spoken form (e.g. "new message").	Available in some handsets.
Customizable auditory alerts	A method for changing the properties of all auditory (sonic and spoken) alerts and notifications.	Available in some handsets.
Digital dial read-out	Numbers are read aloud when digits are dialled.	Available in some handsets.
Text-to-speech	A method to convert electronic text into synthesized speech. In contrast to more general-purpose screen reader features that work across applications and provide eyes-free access to all or most of the functionality of a handset, text-to-speech features may be limited to particular functions such as reading numbers as they are dialled or reading a text document.	Available in some handsets.
Screen reader	A method for receiving and navigating all handset functions, alerts, notifications and content through synthesized speech. For the difference between screen readers and text-to-speech, see text-to-speech.	Available on some smartphone platforms (iOS 3+, Windows 6, Symbian S60).
Features/Technologies Related to Tactile Display
Includes vibration	The handset includes one or more vibration motors for displaying tactile information.	Widely available.
Vibration alerts and notifications	A method for presenting all system alerts and notification in tactile form.	Current implementations are limited to a few preset vibration patterns. However, vibration really only offers a limited number of discernible alternatives.
Customizable vibration	A method for changing the properties (e.g. pattern, frequency, strength) of all vibration alerts and notifications.	Current implementations are limited to few parameters. However, vibration really only offers a limited number of discernible alternatives.
Includes Braille display	The handset includes a built in Braille display.	Not typically available. This would be a very specialized handset. Presently, there have only been concept models[50] developed.
Supports external Braille display	The handset is compatible with external Braille displays.	Available on some smartphone platforms (iOS, Windows 6, Symbian S60).
Features/Technologies Related to Hardware Controls (including numeric keypads, QWERTY keyboards, volume controls, other physical buttons)
Includes hardware controls	The handset includes physical controls (i.e., keys and buttons) for controlling all handset functions (even if a touchscreen is also present).	Available in many handsets, but less selection in smartphones.
Large hardware buttons	The handset includes large hardware keypad and/or keyboard buttons.	Available in some handsets.
Guarded/recessed controls	Guarded or recessed keys to prevent keys from being activated accidentally.	Available to some extent in most handsets.
Individual controls tactilely discernible	All keys and buttons may be identified tactilely. This may be done by the location of keys, nibs, ridges, gaps between keys, different sizes and/or shapes, etc.	Available in most handsets.
Hardware numeric keypad	The handset includes physical controls (i.e., keys and buttons) for entering numbers.	Available on many handsets, especially feature phones.
Identifiable nib on '5' key (standard numeric keypad only)	Nibs allow user to orient to the keys on a numeric keypad.	Widely available.
Hardware QWERTY keyboard	The handset includes physical controls (i.e., keys and buttons) for entering text.	Available on many handsets.
Identifiable nib on 'J' & 'F' key (qwerty keypad only)	Nibs allow user to orient to the keys on a QWERTY keyboard.	Widely available.
Backlit controls	All physical controls include additional sources of illumination to facilitate identification.	Available in many handsets.
Controls include physical feedback	All keys and buttons provide a means to identifying their activation tactilely.	Available in some handsets.
Includes D-Pad	Directional control (typically up, down, left, right) for navigating the user interface	Available in some handsets.
Features/Technologies Related to Both Hardware Keypads and Software Keyboards
Standard numeric keypad layout	The hardware keypad or onscreen keypad uses a standard numeric layout.	Widely available.
Standard QWERTY keyboard layout	The hardware keyboard or onscreen keyboard uses a standard QWERTY layout.	Widely available.
Individual controls visually discernible	Each control includes clear labels and outlines.	Widely available.
Large control labels	Larger than average labels, sometimes covering most of the control.	Available in some handsets.
High contrast control labels	Labels with the highest possible brightness ratio between the lightest to the darkest parts of the keypad or keyboard.	Available in some handsets.
Graphic labels for controls	Non-textual graphics describing the purpose of each control.	Available in some handsets. In some cases just for some controls (e.g., pick up, hang up icons)
Includes keyboard shortcuts	The ability to trigger controls through key combinations.	Available on some smartphone platforms (e.g. Blackberry OS).
Keyboard shortcut indicators	The ability to have keyboard shortcuts displayed with the controls they are associated with.	Not typically available.
Customizable feedback for controls (visual, auditory, and tactile)	A method for changing the appearance of visual, auditory and tactile feedback describing the state of a keypad or keyboard key.	Available in some handsets.
Customizable key sensitivity	A method for changing the amount of time required for a key to be continuously pressed before it is activated.	Not typically available.
Customizable pointer sensitivity	A method for changing the amount of movement required on a physical pointer to change the position of its on-screen equivalent.	Available on BlackBerry handsets.
StickyKeys	A method for enabling sequential activation of modifier keys.	Widely available.
Features/Technologies Related to Orientation Control
Alternatives to orientation control	Alternatives are available for functions controlled by tilting the handset	Application-dependent.
Customizable orientation control	A method for changing the sensitivity of orientation controls	Application-dependent.
Features/Technologies Related to Voice Control
Includes voice control	A method for controlling all phone functions through speech only	Available in some handsets (full-control not yet possible).
Customizable voice control	A method for changing the properties of voice control systems	Limited options available in some handsets with voice control.
Features/Technologies Related to Alternative Access
Supports software-based (programmatic) control	A method for controlling all phone functions through software only	Available in some handsets.
Focus navigation is separate from activation	The elements on the screen may receive input without being activated	Available in some handsets.
Alternative input device accessible	A method for controlling all phone functions through switches only	Some switch kits are available that allow handsets to make and receive calls (e.g. “Click To Phone”[51]). A potential solution, Tekla[52] (alpha) is under development for Android 2.x.
Onscreen scanning keyboard	An onscreen keyboard that reduces the need for accurate targeting by scanning. Related to “Switch accessible”, but may be used without switches (e.g. if a touchscreen is programmed to act as a switch)	Not typically available. Part of Tekla[53] (alpha), being developed for Android 2.x.
Stylus/mouthstick support	A method for controlling all phone functions through a stylus pen (no skin contact required)	Not typically available.
External keyboard support	A method for controlling all phone functions through an external keyboard only	Available in many handsets.
External mouse support	A method for controlling a cursor with an external mouse	Available in some handsets.
Other Hardware-Related Features/Technologies
Non-slip surfaces	The handset includes surfaces or other features that increase grip	Available in some handsets (and from third-parties).
Flat back for table top operation	The handset can be used reliably on a flat surface	Available in some handsets.
Single-hand operation	All handset functions can be used with either the left or right hands.	Widely available.
Ease of opening	The handset can be slid or flipped open/close easily.	Widely available.
Case free of hazards	The handset does not pose any hazards to users.	Widely available.
Lanyard connector	The handset includes a stable loop to affix a lanyard.	Available in some handsets.
Custom mounting	The handset can be affixed to wheelchairs, car dashboards, and other surfaces by means of an adapter or cradle.	Mounting kits available from third-parties.
Feedback upon connector engagement	The handset provides visual, tactile and/or auditory feedback indicating when a connector has been engaged/disengaged.	Widely available.
Easy battery placement	Battery placement includes visual, tactile and/or auditory indicators and feedback.	Widely available.
Factory reset	A method for restoring the handset to its original factory default state.	Widely available.
Call Features/Technologies
Speed dial (or one-touch dial)	A method for initiating a phone call with a single key, tap, or keypad shortcut.	Widely available.
Answer/end on open/close	A flip handset that automatically answers and ends a call when opened and closed, respectively.	Widely available.
Automatic redial	A method for redialling the last number with a single key, tap, or keypad shortcut.	Widely available.
Automatic answer	A method for automatically answering all incoming calls.	Available in some handsets.
Speakerphone (full duplex)	A loudspeaker and ambient microphone enabling voice calls at a distance from the handset.	Widely available.
Automatic speakerphone	Automatically use the speakerphone feature when answering any calls.	Available in some handsets.
Any key answer	Use any hardware key to answer the phone.	Widely available.
Voice dialling	A method for initiating a phone call using speech only.	Available in some handsets (may not be reliable).
Customizable call alert (by audio, visual and/or vibrating)	A method for displaying information incoming calls by visual, auditory and/or tactile means.	Available in some handsets.
Call alert profiles	A method for changing the alert patterns of incoming calls (e.g. ring, then vibrate).	Available in some handsets.
Customizable caller ID (by audio, visual)	A method for displaying caller information by visual or auditory means.	Audio and visual available in some handsets. Vibration does not have a sufficient number of discernible patterns.
Push to talk	Half-duplex, walkie-talkie-type communication.	Available in some handsets.
Text Input Features/Technologies
Speech recognition for text input	A method for entering text through speech only.	Available in some handsets.
Predictive text input (word suggestions)	The handset offers word alternatives when entering text.	Available in some handsets.
Automatic word completion	A method for suggesting the most likely word after the user inputs the first few letters.	Available in some handsets.
Adaptive word completion (user dictionary)	A method for including previously entered words by the user in automatic word completion.	Widely available in handsets with automatic word completion.
Word definition	A method for displaying the definition of words to be entered.	Not tightly integrated with input methods.
Other User Interface-Related Features/Technologies
System-wide accessibility preferences	A method for changing all accessibility-related settings.	Available in some handsets.
Configurable screen timeouts	A method for changing the screen timeout.	Widely available.
Configurable system timeouts	A method for changing the timeout of system alerts and notifications	Not typically available.
Symbolic communication system support	A method to support symbolic communication, especially via text messaging.	Available through third-parties in some handsets.
Simplified user interface	A simple, easy to use user interface.	Widely available (but dependent on third-party support).
Configurable media playback	A method for changing all playback properties (e.g. size, speed, etc..) of media players	Not typically available.
Customizable navigation	Ability to change the layout and sequence of navigation elements	Limited availability through shortcuts and application drawers in some handsets.
Customizable layout	A method for re-arranging user interface elements on the system.	Current implementations are limited to specific contexts (e.g. home screen).
Custom user interface labels	Ability to change the labels of any user interface element	Not typically available.
Photo associated contacts	Ability to associate photos with contacts in the contact list	Widely available.
Voice recording	Ability to record and play back voice.	Widely available.
Help and Support Features/Technologies
On-demand accessibility information	Different communication methods (electronic, in-person, by phone, etc.) exist for people with disabilities to obtain detailed information on the accessibility of handsets	Depends on WSPs.
Access to trained customer service people	People with disabilities have easy access to trained customer service personnel that provides information and support for any handset accessibility feature at purchase and afterwards.	Depends on WSPs.
Electronic documentation	All documentation is available electronically	Widely available (although the format may not be accessible).

11.3 Appendix C: Detailed Results of Persona Analysis

See the attachment entitled “Handset Persona Analysis [pdf]”.

12. Sources

AbleData. http://www.abledata.com/

Accessibility: iPhone: Vision. http://www.apple.com/accessibility/iphone/vision.html

Apple. http://www.apple.com

Apple Accessibility: iPhone: Vision. http://www.apple.com/accessibility/iphone/vision.html

Apple Accessibility: iPhone: Physical & Motor Skills. http://www.apple.com/accessibility/iphone/physical.html

Apps4Android. http://www.apps4android.org/

Bell: Smartphones, phones and Mobile Internet. http://www.bell.ca/shopping/PrsShpWls_PrdClpListView.page

BlackBerry Accessibility API. http://docs.blackberry.com/en/developers/deliverables/20100/Intro_
to_Accessibility_API_791538_11.jsp

BlackBerry Accessibility Overview. http://us.blackberry.com/support/devices/blackberry_accessibility/

Burton, Darren. “Can an Android Make Your Mobile Phone Accessible?”. AFB AccessWorld. May 2010. http://www.afb.org/afbpress/pub.asp?DocID=aw110202

Burton, Darren. “The Revolutionary New iPhone”. AFB AccessWorld. September 2009. http://www.afb.org/afbpress/pub.asp?DocID=aw100502

Cell Phones Etc. http://www.cellphones.ca/

Click to Phone - Switch Scanning Cell Phone Bluetooth Interface. http://www.broadenedhorizons.com/click_to_phone.htm

Colven, David and Judge, Simon. “Switch access to technology: A comprehensive guide”. ACE Centre Advisory Trust. 2006. http://www.ace-centre.org.uk/assets/Product%20Downloads/SwitchScanningMaster_8_472.pdf

Craig, James and Cooper, Michael. “Accessible Rich Internet Applications (WAI-ARIA) 1.0”. W3C. 18 January 2011. http://www.w3.org/TR/wai-aria/

Eyes-Free Project. http://code.google.com/p/eyes-free/

HTC. http://www.htc.com

iOS Accessibility API. http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual
/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html

ISO/IEC TR 29138-1:2009 Information technology — Accessibility considerations for people with disabilities — Part 1: User needs summary. International Organization for Standardization. 2009. http://standards.iso.org/ittf/PubliclyAvailableStandards/c045161_ISO_IEC_TR_29138-1_2009%28E%29.zip

ISO/IEC 24751-2:2008 Part 2: "Access for all" personal needs and preferences for digital delivery. International Organization for Standardization. 2008. http://standards.iso.org/ittf/PubliclyAvailableStandards/c043603_ISO_IEC_24751-2_2008.zip

LG. http://www.lg.com

Lysley, Andew and Colven, David. “Making software inclusive and digital publications accessible”. ACE Centre Advisory Trust. October 2005. http://www.ace-centre.org.uk/assets/inclusive_8_288.pdf

Mobile Accessibility for Android. http://www.codefactory.es/en/products.asp?id=415

Mobile Manufacturers Forum (MMF). http://mmfai.info/public/

MTS: Wireless Devices. http://www.mts.ca/portal/site/mts/menuitem.c5a4913ffc7f8abaa66d2523408021a0
/?vgnextoid=a919d3bdb703c210VgnVCM1000002a040f0aRCRD

Nokia. http://www.nokia.ca

Nuance Talks&Zooms. http://www.nuance.com/for-individuals/by-solution/talks-zooms/index.htm

Oratio for BlackBerry Smartphones. http://www.humanware.com/en-usa/products/blindness/oratio_for_blackberry_smartphones/_details/id_131
/oratio_for_blackberry_smartphones.html

Palm. http:///www.palm.com

RIM. http://us.blackberry.com

Rodriguez, Armando and Mies, Ginny. “Android Overlays: How Do They Compare?”. PCWorld. 13 January 2011. http://www.pcworld.com/article/216699/android_overlays_how_do_they_compare.html

Rogers: Phones and Devices. http://www.rogers.com/web/link/wirelessBuyFlow?forwardTo=PhoneThenPlan&
productType=normal

Samsung. http://www.samsung.com

Sasktel: Phones and Devices. http://www.sasktel.com/search/controller/_/N-a5Z1z140m8?Dim=Phones+and+Devices&Link=LOBMobilityPhonesDevices&campaign=Home

Schroeder, Paul W. and Burton, Darren. “Microsoft Backtracks on Accessibility in New Mobile Operating System, Commits to Accessibility in Future Windows Phone Platform”. AFB AccessWorld. December 2010. http://www.afb.org/afbpress/pub.asp?DocID=aw110802

Sony Ericsson. http://www.sonyericsson.com

Sorrel, Charlie. “Nokia Kills Symbian, Teams Up With Microsoft For Windows Phone 7”. Wired. 11 February 2011. http://www.wired.com/gadgetlab/2011/02/microsoft-and-nokia-team-up-to-build-windows-phones/

Telus: Phones. http://www.telusmobility.com/en/ON/phones/index.shtml?INTCMP=HomeQLCC4phones

Utilizing Android Accessibility APIs to Provide Alternative and Complementary UI Feedback. https://sites.google.com/site/gdevelopercodelabs/android/accessibility

Videotron: Wireless Devices. http://www.videotron.com/service/mobile/appareils/accueil.do?lang=ENGLISH
&target=mobileAppareils

Voice Actions for Android. http://www.google.com/mobile/voice-actions/index.html

VoiceOver Application Support. http://www.apple.com/accessibility/voiceover
/applications.html

When can I use WAI-ARIA Accessibility features?. http://caniuse.com/wai-aria

Wikipedia. http://en.wikipedia.org/

[1] “Welcome to the internet site of the Mobile Manufacturers Forum (MMF)”. http://mmfai.info/public/

[2] “Switch access scanning”. http://en.wikipedia.org/wiki/Switch_access_scanning

[3] “Apps for iPhone”. http://www.apple.com/iphone/apps-for-iphone/

[4] “Android Market”. https://market.android.com/

[5] “BlackBerry App World”. http://appworld.blackberry.com/webstore/

[6] “Nokia Ovi Store”. http://store.ovi.com/

[7] “Windows Marketplace for Mobile”. http://marketplace.windowsphone.com/Default.aspx

[8] “List of digital distribution platforms for mobile devices”. http://en.wikipedia.org/wiki/List_of_digital_distribution_platforms_for_mobile_devices

[9] “Approval of iOS Apps”. http://en.wikipedia.org/wiki/Approval_of_iOS_apps

[10] “Android Market Developer Program Policies”. http://www.android.com/us/developer-content-policy.html

[11] “Android (operating system)”. http://en.wikipedia.org/wiki/Android_(operating_system)

[12] “Symbian”. http://en.wikipedia.org/wiki/Symbian

[13] “iOS (Apple)”. http://en.wikipedia.org/wiki/IOS_(Apple)

[14] Rodriguez, Armando and Mies, Ginny. “Android Overlays: How Do They Compare?”. PCWorld. 13 January 2011. http://www.pcworld.com/article/216699/android_overlays_how_do_they_compare.html

[15] “Feature Phone”. http://en.wikipedia.org/wiki/Feature_phone

[16] “Smartphones” http://en.wikipedia.org/wiki/Smartphone

[17] Note that Nokia recently announced it would be moving from the Symbian platform to Windows Phone 7. Sorrel, Charlie. “Nokia Kills Symbian, Teams Up With Microsoft For Windows Phone 7”. Wired. 11 February 2011. http://www.wired.com/gadgetlab/2011/02/microsoft-and-nokia-team-up-to-build-windows-phones/

[18] Rodriguez, Armando and Mies, Ginny. “Android Overlays: How Do They Compare?”. PCWorld. 13 January 2011. http://www.pcworld.com/article/216699/android_overlays_how_do_they_compare.html

[19] Schroeder, Paul W. and Burton, Darren. “Microsoft Backtracks on Accessibility in New Mobile Operating System, Commits to Accessibility in Future Windows Phone Platform”. AFB AccessWorld. December 2010. http://www.afb.org/afbpress/pub.asp?DocID=aw110802

[20] Burton, Darren. “The Revolutionary New iPhone”. AFB AccessWorld. September 2009. http://www.afb.org/afbpress/pub.asp?DocID=aw100502

[21] “ISO/IEC TR 29138-1:2009 Information technology — Accessibility considerations for people with disabilities — Part 1: User needs summary”. http://standards.iso.org/ittf/PubliclyAvailableStandards/c045161_ISO_IEC_TR_29138-1_2009%28E%29.zip

[22] “Welcome to the internet site of the Mobile Manufacturers Forum (MMF)”. http://mmfai.info/public/

[23] Burton, Darren. “Can an Android Make Your Mobile Phone Accessible?”. AFB AccessWorld. May 2010. http://www.afb.org/afbpress/pub.asp?DocID=aw110202

[24] “Click to Phone - Switch Scanning Cell Phone Bluetooth Interface”. http://www.broadenedhorizons.com/click_to_phone.htm

[25] Disclosure: Tekla is an IDRC research and development project.

[26] “Touchscreens, Capacitive”. http://en.wikipedia.org/wiki/Touchscreen#Capacitive

[27] Lambert, Terry. “Toward Using a Prosthesis with a TouchPad/TouchScreen”. http://openprosthetics.ning.com/profiles/blogs/toward-using-a-prosthesis-with

[28] BlackBerry Accessibility API: http://docs.blackberry.com/en/developers/deliverables/20100
/Intro_to_Accessibility_API_791538_11.jsp

[29] iOS Accessibility API: http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual
/iPhoneAccessibility/Accessibility_on_iPhone/Accessibility_on_iPhone.html

[30] “Utilizing Android Accessibility APIs to Provide Alternative and Complementary UI Feedback”. https://sites.google.com/site/gdevelopercodelabs/android/accessibility

[31] “Accessible Rich Internet Applications (WAI-ARIA) 1.0”. 18 January 2011. http://www.w3.org/TR/wai-aria/

[32] “When can I use WAI-ARIA Accessibility features?”. http://caniuse.com/wai-aria

[33] “VoiceOver Application Support”. http://www.apple.com/accessibility/voiceover/applications.html

[34] “Accessibility: iPhone: Vision”. http://www.apple.com/accessibility/iphone/vision.html

[35] “Mobile Accessibility for Android”. http://www.codefactory.es/en/products.asp?id=415

[36] “Bluetooth profile”. http://en.wikipedia.org/wiki/Bluetooth_profile

[37] Schroeder, Paul W. and Burton, Darren. “Microsoft Backtracks on Accessibility in New Mobile Operating System, Commits to Accessibility in Future Windows Phone Platform”. AFB AccessWorld. December 2010. http://www.afb.org/afbpress/pub.asp?DocID=aw110802

[38] “Welcome to the internet site of the Mobile Manufacturers Forum (MMF)”. http://mmfai.info/public/

[39] “Mobile Accessibility: Find Phones”. http://mobileaccessibility.info/findphones.cfm?lang=eng

[40] “Web-4-All Preferences Wizard Demo”. http://www.web4all.ca/html/english/W4A_manual%2803,31,06%29.pdf
Disclosure: IDRC staff were involved with the development of Web-4-All.

[41] “OATSoft: Browse software based on the need that it meets”. http://www.oatsoft.org/Software/browse/Repository/Need

[42] “Welcome to the internet site of the Mobile Manufacturers Forum (MMF)”. http://mmfai.info/public/

[43] “Nuance Talks&Zooms”.http://www.nuance.com/for-individuals/by-solution/talks-zooms/index.htm

[44] “Oratio for BlackBerry Smartphones”. http://www.humanware.com/en-usa/products/blindness/oratio_for_blackberry_smartphones/_details/id_131
/oratio_for_blackberry_smartphones.html

[45] “Click to Phone - Switch Scanning Cell Phone Bluetooth Interface”. http://www.broadenedhorizons.com/click_to_phone.htm

[46] Disclosure: Tekla is an IDRC research and development project.

[47] Voice Actions for Android. http://www.google.com/mobile/voice-actions/index.html

[48] Android: Bluetooth FAQ. https://sites.google.com/a/android.com/opensource/projects/bluetooth-faq

[49] Disclosure: Tekla is an IDRC research and development project.

[50] “SAMSUNG’s Braille [Concept] Mobile Phone Wins Gold Award at the IDEA 2006 Awards”. http://www.samsung.com/us/news/newsRead.do?news_seq=3204&page=2

[51] “Click to Phone - Switch Scanning Cell Phone Bluetooth Interface”. http://www.broadenedhorizons.com/click_to_phone.htm

[52] Disclosure: Tekla is an IDRC research and development project.

[53] Disclosure: Tekla is an IDRC research and development project.

Handset Persona Analysis

For information on how this Persona Analyis was performed, see Section "5.2. Persona Analysis" in the main report document.

Handset Information

Names (Submitted to CRTC by WSPs)	Discont. by Developer (Mar 2011)	Specs (OEM)	Other Information	Physical Numeric Keypad (Y/N)?	Physical QWERTY Keyboard (Y/N)?	Feature Phone or Smartphone?	Operating System/ Platform
Apple iPhone 3GS		Specs	Accessibility	No	No	Smartphone	iOS4
Apple iPhone 4		Specs	Accessibility	No	No	Smartphone	iOS4
BlackBerry Bold 9650		Specs	Accessibility	Yes	Yes	Smartphone	Blackberry OS 6.0
BlackBerry Bold 9700		Specs	Accessibility	Yes	Yes	Smartphone	Blackberry OS 6.0
Blackberry Curve 3G		Specs	Accessibility	Yes	Yes	Smartphone	Blackberry OS 6.0
BlackBerry Curve 8330	Discont.						Blackberry OS 5.0
BlackBerry Curve 8350i		Specs	Accessibility	Yes	Yes	Smartphone	Blackberry OS 5.0
BlackBerry Curve 8530		Specs	Accessibility	Yes	Yes	Smartphone	Blackberry OS 5.0
BlackBerry Pearl 8130	Discont.						Blackberry OS 4.5
BlackBerry Pearl Flip 8230	Discont.						Blackberry OS 4.6.1
BlackBerry Storm 9530		Specs	Accessibility	No	No	Smartphone	Blackberry OS 5.0
BlackBerry Storm2 9550		Specs	Accessibility	No	No	Smartphone	Blackberry OS 5.0
BlackBerry Tour 9630		Specs	Accessibility	Yes	Yes	Smartphone	Blackberry OS 5.0
BlackBerry World 8830	Discont.						Blackberry OS 4.5
Doro 410GSM		Specs		Yes	Yes	Feature Phone	Doro Proprietary
HTC Google Nexus One		Specs	Other	No	No	Smartphone	Android 2.2
HTC Hero	Discont.	Specs					Android
HTC Snap	Discont.	Specs					Windows Mobile 6.1
HTC Touch Diamond	Discont.	Specs					Windows Mobile 6.1
HTC Touch Pro 2	Discont.	Specs					Windows Mobile 6.1
HTC Touch Pro 7279	Discont.	Specs					Windows Mobile 6.1
LG 5500	Discont.	Specs					Java
LG Banter (AX265)		Specs	Other	Yes	Yes	Feature Phone	Java
LG Bliss (UX700)	Discont.	Specs					Java
LG IQ (GW825)	Discont.	Specs					Windows Mobile 6.5
LG Keybo (LG9100)	Discont.	Specs					Java
LG Keybo2 (LG9200)	Discont.	Specs					Java
LG Masterpiece (LG7100)	Discont.	Specs					Java
LG Reveal (LGCX600)	Discont.	Specs					Java
LG Rumour (LG260)		Specs	Other	Yes	Yes	Feature Phone	Java
LG Rumour2 (LG265)		Specs	Other	Yes	Yes	Feature Phone	LG Proprietary
LG Shine Touch (KM555)		Specs	Other	Yes	No	Feature Phone	LG Proprietary
LG Versa (LG9600)		Specs					LG Proprietary
LG Wine (LG280)	Discont.	Specs					Java Feature
LG Wink (GU297)		Specs		No	Yes	Feature Phone	LG Proprietary
LG Xenon (GR500)		Specs	Other	Yes	Yes	Feature Phone	LG Proprietary
Motorola DEXT (CLIQ in US)		Specs	Other	Yes	No	Smartphone	Android 1.5
Motorola Extreme (VA76r) (Tundra in US)		Specs	Manual	Yes	No	Feature Phone	Motorola Proprietary
Motorola M800 Bag Phone		Specs	Manual	Yes	No	Feature Phone	Motorola Proprietary
Motorola M800 Car Phone		Specs		Yes	No	Feature Phone	Motorola Proprietary
Motorola XT720 (Milestone in US)		Specs	Other	No	No	Smartphone	Android 2.1
Nokia C6		Specs	Other	Yes	Yes	Smartphone	Symbian S60 5th ed.
Nokia 2730		Specs	Other	Yes	No	Feature Phone	Symbian S40
Nokia 3710		Specs	Other	Yes	No	Feature Phone	Symbian S40 version 9.1
Nokia 6350		Specs	Other	Yes	No	Feature Phone	Symbian S40 6th ed.
Nokia 6790 (compatible with Nuance Talks)	Discont.	Specs					Symbian, S60 rel. 3.2
Nokia 7230		Specs	Other	Yes	No	Feature Phone	Symbian S40
Nokia E71		Specs	Other	Yes	Yes	Smartphone	Symbian S60 rel 3.1 E-series
Nokia E71 RVI (with Nuance Talks)		Specs	Other	Yes	Yes	Smartphone	Symbian S60 rel 3.1 E-series
Nokia E72		Specs	Other	Yes	Yes	Smartphone	Symbian S60 rel 3.2
Nokia N86 (compatible with Nuance Talks)	Discont.	Specs					Symbian S60 3rd edition
Nokia N97 Mini		Specs	Other	Yes	Yes	Smartphone	S60 5th edition
Palm Treo Pro		Specs	Other	Yes	Yes	Smartphone	Windows Mobile 6.1
PCD 8635		Specs	Other	Yes	No	Feature Phone	Java
Samsung Ace (SPH-i325)		Specs	Other	Yes	Yes	Smartphone	Windows Mobile 6
Samsung Advance (SGH-a885)		Specs	Other	No	No	Feature Phone	Java Samsung (MIDP 2.1)
Samsung Cleo (SCH-u440)		Specs	Other	Yes	Yes	Feature Phone	Java (MIDP 2.0 )
Samsung CorbyPro (GT-b5310r)		Specs	Other	Yes	Yes	Feature Phone	Samsung Proprietary OS
Samsung Galaxy S Captivate (SGH-i896)		Specs	Other	No	No	Smartphone	Android 2.1
Samsung Galaxy S Fascinate		Specs	Other	No	No	Smartphone	Android 2.1
Samsung Galaxy S Vibrant (GT-i9000)		Specs		No	No	Smartphone	Android 2.1
Samsung Galaxy Spica (GT-i5700)		Specs	Other	No	No	Smartphone	Android 2.1
Samsung Gravity 3 (SGH-T479)		Specs	Other	Yes	Yes	Feature Phone	Samsung Proprietary OS
Samsung Gravity Touch (SGH-t669)		Specs	Other	Yes	Yes	Feature Phone	Samsung Proprietary OS
Samsung Impact (SGH-t746)		Specs	Other	No	No	Feature Phone	Samsung Proprietary OS
Samsung Intensity (SCH-u450)	Discont.	Specs	Other	Yes	Yes	Feature Phone	Java (CLDC 1.1 / MIDP 2.0 )
Samsung Link (SCH-r351)		Specs	Other	Yes	Yes	Feature Phone	L4 REX
Samsung m320 (SPH-M320)		Specs	Other	Yes	No	Feature Phone	Samsung Proprietary OS
Samsung m530		Specs	Other	Yes	No	Feature Phone	Java
Samsung Omnia (SCH-i910)	Discont.	Specs	Other	No	No	Smartphone	Windows Mobile 6.1
Samsung R540 (SCH-r540)		Specs	Other	Yes	No	Feature Phone	Java (MIDP 2.0 )
Samsung Reclaim	Discont.	Specs					L4
Samsung Rugby (SGH-A836)	Discont.	Specs	Other	Yes	No	Feature Phone	Samsung Proprietary OS
Samsung U430 (SCH-U430)		Specs	Other	Yes	No	Feature Phone	Java (MIDP 1.0, CLDC 1.0 )
Samsung Vice		Specs	Other	Yes	No	Feature Phone	Samsung Proprietary OS
Sanyo Pro 700		Specs	Other	Yes	No	Feature Phone	Java Feature
Sony Ericsson U8a Vivaz		Specs					Symbian Series 60, 5th ed.
Sony Ericsson X10a		Specs	Other	No	No	Smartphone	Android 2

Wireless Service Provider (WSP) Handset Availability

Legend:

Yes: Handset was identified in the WSP's CRTC submissions and was still offered by March 2011..
No: Handset was identified in WSP's CRTC submissions, but was no longer offered by March 2011.
Added: Handset was not identified in WSP's CRTC submissions, but the WSP carried the handset as of March 2011 and the handset was identified by another WSP in their CRTC submissions.
Refurb.: THe handset is only offered as a refurbished model.

Names (Submitted to CRTC by WSPs)	Discont. by Developer (Mar 2011)	Bell Canada/ Bell Aliant	SaskTel	MTS Allstream	Quebecor Media/ Videotron	Rogers	TELUS
Apple iPhone 3GS		Yes				Yes	Yes
Apple iPhone 4		Yes				Yes	Added
BlackBerry Bold 9650				Yes
BlackBerry Bold 9700			Yes		Added
Blackberry Curve 3G		Yes			Added
BlackBerry Curve 8330	Discont.		No	No
BlackBerry Curve 8350i							Yes
BlackBerry Curve 8530			Added	Yes			Yes
BlackBerry Pearl 8130	Discont.		No	No			No
BlackBerry Pearl Flip 8230	Discont.		No	Yes			Yes
BlackBerry Storm 9530			Yes	No			No
BlackBerry Storm2 9550			No	Yes			No
BlackBerry Tour 9630			No	No			No
BlackBerry World 8830	Discont.		No
Doro 410GSM						Yes
HTC Google Nexus One					Yes
HTC Hero	Discont.						No
HTC Snap	Discont.						No
HTC Touch Diamond	Discont.			No
HTC Touch Pro 2	Discont.						No
HTC Touch Pro 7279	Discont.						No
LG 5500	Discont.						No
LG Banter (AX265)							Yes
LG Bliss (UX700)	Discont.		No
LG IQ (GW825)	Discont.						Refurb.
LG Keybo (LG9100)	Discont.						No
LG Keybo2 (LG9200)	Discont.						Refurb.
LG Masterpiece (LG7100)	Discont.						Refurb.
LG Reveal (LGCX600)	Discont.		No
LG Rumour (LG260)			No
LG Rumour2 (LG265)		Yes	No
LG Shine Touch (KM555)						Yes
LG Versa (LG9600)							No
LG Wine (LG280)	Discont.		No
LG Wink (GU297)					Yes
LG Xenon (GR500)						Yes
Motorola DEXT (CLIQ in US)		Yes
Motorola Extreme (VA76r) (Tundra in US)						No
Motorola M800 Bag Phone		Added	Yes	Added
Motorola M800 Car Phone			No	Added
Motorola XT720 (Milestone in US)					Yes
Nokia C6		Yes	Added
Nokia 2730		Yes
Nokia 3710							Yes
Nokia 6350		Yes	Yes
Nokia 6790 (compatible with Nuance Talks)	Discont.					No
Nokia 7230		Added	Yes
Nokia E71							No
Nokia E71 RVI (with Nuance Talks)						Yes
Nokia E72							Yes
Nokia N86 (compatible with Nuance Talks)	Discont.					No
Nokia N97 Mini						Yes
Palm Treo Pro			Yes
PCD 8635				Yes
Samsung Ace (SPH-i325)				No
Samsung Advance (SGH-a885)							Yes
Samsung Cleo (SCH-u440)			No
Samsung CorbyPro (GT-b5310r)						Yes
Samsung Galaxy S Captivate (SGH-i896)						Added
Samsung Galaxy S Fascinate							Added
Samsung Galaxy S Vibrant (GT-i9000)		Yes	Yes
Samsung Galaxy Spica (GT-i5700)						No
Samsung Gravity 3 (SGH-T479)			Yes
Samsung Gravity Touch (SGH-t669)			Yes
Samsung Impact (SGH-t746)		Yes
Samsung Intensity (SCH-u450)	Discont.						Yes
Samsung Link (SCH-r351)			No
Samsung m320 (SPH-M320)			No
Samsung m530			No
Samsung Omnia (SCH-i910)	Discont.		Yes				No
Samsung R540 (SCH-r540)							No
Samsung Reclaim	Discont.		No
Samsung Rugby (SGH-A836)	Discont.					No
Samsung U430 (SCH-U430)							Yes
Samsung Vice			No
Sanyo Pro 700		Yes	No	Added
Sony Ericsson U8a Vivaz						No
Sony Ericsson X10a						Yes

Persona with Severe Visual Impairment ("Alexia")

Legend:

Yes: Accessible (see comments)
Yes*: Accessible, but requires third-party hardware or software (see comments)
No: Not accessible (see comments)
Potential: Potentially accessible (see comments)
na: Handset does not include features to support this task

Names (Submitted to CRTC by WSPs)	Discont. by Developer (Mar 2011)	Making phone calls	Receiving phone calls	Sending text message	Receiving text messages	Using social net-working on browser	Using calendar	Taking pictures	Watching videos or listening to music	Notes on Screen reader availability?
Apple iPhone 3GS		Yes	Yes	Yes*1	Yes	Yes*1	Yes	Yes	Yes	Voiceover built in
Apple iPhone 4		Yes	Yes	Yes*1	Yes	Yes*1	Yes	Yes	Yes	Voiceover built in
BlackBerry Bold 9650		Yes2	Yes	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry Bold 9700		Yes2	Yes	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
Blackberry Curve 3G		Yes2	Yes	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry Curve 8330	Discont.
BlackBerry Curve 8350i		Yes2	Yes	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry Curve 8530		Yes2	Yes	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry Pearl 8130	Discont.
BlackBerry Pearl Flip 8230	Discont.
BlackBerry Storm 9530		No4	No	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry Storm2 9550		No4	No	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry Tour 9630		Yes2	Yes	No3	No	No	No	No	No	Oratio (but not available in Canada on this model)5
BlackBerry World 8830	Discont.
Doro 410GSM		Yes2	Yes	No3	No	na	No	na	No
HTC Google Nexus One		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access
HTC Hero	Discont.
HTC Snap	Discont.									MobileSpeak
HTC Touch Diamond	Discont.									MobileSpeak
HTC Touch Pro 2	Discont.									MobileSpeak
HTC Touch Pro 7279	Discont.									MobileSpeak
LG 5500	Discont.
LG Banter (AX265)		Yes7	Yes	No	No	No	No	No	No
LG Bliss (UX700)	Discont.
LG IQ (GW825)	Discont.
LG Keybo (LG9100)	Discont.
LG Keybo2 (LG9200)	Discont.
LG Masterpiece (LG7100)	Discont.
LG Reveal (LGCX600)	Discont.
LG Rumour (LG260)		Yes8	Yes	No	No	No	No	No	No
LG Rumour2 (LG265)		Yes8	Yes	No	No	No	No	No	No
LG Shine Touch (KM555)		No	No	No	No	No	No	No	No
LG Versa (LG9600)
LG Wine (LG280)	Discont.
LG Wink (GU297)		Yes8	Yes	No	No	No	No	No	No
LG Xenon (GR500)		No9	No	No	No	No	No	No	No
Motorola DEXT (CLIQ in US)		Yes8	Yes	No10	No	No	No	No	No
Motorola Extreme (VA76r) (Tundra in US)		Yes8	Yes	No	No	No	No	No	No
Motorola M800 Bag Phone		Yes8	Yes	No	No	No	No11	na	na
Motorola M800 Car Phone		Yes8	Yes	No	No	No	No11	na	na
Motorola XT720 (Milestone in US)		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access
Nokia C6		Yes12	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak
Nokia 2730		Yes8	Yes	No13	No	No	No	No	No
Nokia 3710		Yes8	Yes	No13	No	No	No	No	No
Nokia 6350		Yes8	Yes	No13	No	No	No	Potential14	No
Nokia 6790 (compatible with Nuance Talks)	Discont.
Nokia 7230		No9	No	No13	No	No	No	Potential14	No
Nokia E71		Yes15	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak, Nuance Talks
Nokia E71 RVI (with Nuance Talks)		Yes15	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak, Nuance Talks
Nokia E72		Yes15	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak, Nuance Talks
Nokia N86 (compatible with Nuance Talks)	Discont.
Nokia N97 Mini		Yes16	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Nuance Talks
Palm Treo Pro		Yes12	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak
PCD 8635		Yes8	Yes	No	No	No	No	No	No
Samsung Ace (SPH-i325)		Yes12	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak
Samsung Advance (SGH-a885)		No9	No	No	No	No	No	No	No
Samsung Cleo (SCH-u440)		Yes8	Yes	No	No	No	No	No	No
Samsung CorbyPro (GT-b5310r)		Yes8	Yes	No	No	No	No	No	No
Samsung Galaxy S Captivate (SGH-i896)		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access
Samsung Galaxy S Fascinate		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access
Samsung Galaxy S Vibrant (GT-i9000)		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access
Samsung Galaxy Spica (GT-i5700)		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access
Samsung Gravity 3 (SGH-T479)		Yes8	Yes	No	No	No	No	No	No
Samsung Gravity Touch (SGH-t669)		Yes8	Yes	No	No	No	No	No	No
Samsung Impact (SGH-t746)		No9	Yes	No	No	No	No	No	No
Samsung Intensity (SCH-u450)	Discont.	Yes8	Yes	No	No	No	No	No	No
Samsung Link (SCH-r351)		Yes8	Yes	No	No	No	No	No	No
Samsung m320 (SPH-M320)		Yes8	Yes	No	No	No	No	No	No
Samsung m530		Yes8	Yes	No	No	No	No	No	No
Samsung Omnia (SCH-i910)	Discont.	Yes12	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Mobile Speak
Samsung R540 (SCH-r540)		Yes8	Yes	No	No	No	No	No	No
Samsung Reclaim	Discont.
Samsung Rugby (SGH-A836)	Discont.	Yes8	Yes	No	No	No	No	No	No
Samsung U430 (SCH-U430)		Yes8	Yes	No	No	No	No	No	No
Samsung Vice		Yes8	Yes	No	No	No	No	No	No
Sanyo Pro 700		Yes8	Yes	No	No	No	No	No	No
Sony Ericsson U8a Vivaz
Sony Ericsson X10a		Potential6	Potential	Potential	Potential	Potential	Potential	Potential	Potential	Potential: TalkBack/ Soundback/ Kickback, Mobile Access

Persona with Severe Mobility Impairment ("Bill")

Legend:

Yes: Accessible (see comments)
Yes*: Accessible, but requires third-party hardware or software (see comments)
No: Not accessible (see comments)
Potential: Potentially accessible (see comments)
na: Handset does not include features to support this task

Names (Submitted to CRTC by WSPs)	Discont. by Developer (Mar 2011)	Making phone calls	Receiving phone calls	Sending text message	Receiving text messages	Using social net-working on browser	Using calendar	Taking pictures	Watching videos or listening to music
Apple iPhone 3GS		No17	No	No	No	No	No	No	No
Apple iPhone 4		No17	No	No	No	No	No	No	No
BlackBerry Bold 9650		No18	No	No	No	No	No	No	No
BlackBerry Bold 9700		No18	No	No	No	No	No	No	No
Blackberry Curve 3G		No18	No	No	No	No	No	No	No
BlackBerry Curve 8330	Discont.
BlackBerry Curve 8350i		No18	No	No	No	No	No	No	No
BlackBerry Curve 8530		No18	No	No	No	No	No	No	No
BlackBerry Pearl 8130	Discont.
BlackBerry Pearl Flip 8230	Discont.
BlackBerry Storm 9530		No18	No	No	No	No	No	No	No
BlackBerry Storm2 9550		No18	No	No	No	No	No	No	No
BlackBerry Tour 9630		No18	No	No	No	No	No	No	No
BlackBerry World 8830	Discont.
Doro 410GSM		No18	No	No	No	na	No	na	No
HTC Google Nexus One		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential
HTC Hero	Discont.
HTC Snap	Discont.
HTC Touch Diamond	Discont.
HTC Touch Pro 2	Discont.
HTC Touch Pro 7279	Discont.
LG 5500	Discont.
LG Banter (AX265)		No18	No	No	No	No	No	No	No
LG Bliss (UX700)	Discont.
LG IQ (GW825)	Discont.
LG Keybo (LG9100)	Discont.
LG Keybo2 (LG9200)	Discont.
LG Masterpiece (LG7100)	Discont.
LG Reveal (LGCX600)	Discont.
LG Rumour (LG260)		No18	No	No	No	No	No	No	No
LG Rumour2 (LG265)		No18	No	No	No	No	No	No	No
LG Shine Touch (KM555)		No18	No	No	No	No	No	No	No
LG Versa (LG9600)
LG Wine (LG280)	Discont.
LG Wink (GU297)		No18	No	No	No	No	No	No	No
LG Xenon (GR500)		No18	No	No	No	No	No	No	No
Motorola DEXT (CLIQ in US)		No20	No	No	No	No	No	No	No
Motorola Extreme (VA76r) (Tundra in US)		No18	No	No	No	No	No	No	No
Motorola M800 Bag Phone		No18	No	No	No	No	No11	na	na
Motorola M800 Car Phone		No18	No	No	No	No	No11	na	na
Motorola XT720 (Milestone in US)		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential
Nokia C6		No18	No	No	No	No	No	No	No
Nokia 2730		No18	No	No	No	No	No	No	No
Nokia 3710		No18	No	No	No	No	No	No	No
Nokia 6350		No18	No	No	No	No	No	No	No
Nokia 6790 (compatible with Nuance Talks)	Discont.
Nokia 7230		No18	No	No	No	No	No	No	No
Nokia E71		No18	No	No	No	No	No	No	No
Nokia E71 RVI (with Nuance Talks)		No18	No	No	No	No	No	No	No
Nokia E72		No18	No	No	No	No	No	No	No
Nokia N86 (compatible with Nuance Talks)	Discont.
Nokia N97 Mini		No18	No	No	No	No	No	No	No
Palm Treo Pro		Yes*21	Yes*21	Yes*21	Yes*21	No	No	No	No
PCD 8635		No18	No	No	No	No	No	No	No
Samsung Ace (SPH-i325)		Yes*21	Yes*21	Yes*21	Yes*21	No	No	No	No
Samsung Advance (SGH-a885)		No18	No	No	No	No	No	No	No
Samsung Cleo (SCH-u440)		No18	No	No	No	No	No	No	No
Samsung CorbyPro (GT-b5310r)		No18	No	No	No	No	No	No	No
Samsung Galaxy S Captivate (SGH-i896)		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential
Samsung Galaxy S Fascinate		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential
Samsung Galaxy S Vibrant (GT-i9000)		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential
Samsung Galaxy Spica (GT-i5700)		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential
Samsung Gravity 3 (SGH-T479)		No18	No	No	No	No	No	No	No
Samsung Gravity Touch (SGH-t669)		No18	No	No	No	No	No	No	No
Samsung Impact (SGH-t746)		No18	No	No	No	No	No	No	No
Samsung Intensity (SCH-u450)	Discont.	No18	No	No	No	No	No	No	No
Samsung Link (SCH-r351)		No18	No	No	No	No	No	No	No
Samsung m320 (SPH-M320)		No18	No	No	No	No	No	No	No
Samsung m530		No18	No	No	No	No	No	No	No
Samsung Omnia (SCH-i910)	Discont.	Yes*21	Yes*21	Yes*21	Yes*21	No	No	No	No
Samsung R540 (SCH-r540)		No18	No	No	No	No	No	No	No
Samsung Reclaim	Discont.
Samsung Rugby (SGH-A836)	Discont.	No18	No	No	No	No	No	No	No
Samsung U430 (SCH-U430)		No18	No	No	No	No	No	No	No
Samsung Vice		No18	No	No	No	No	No	No	No
Sanyo Pro 700		No18	No	No	No	No	No	No	No
Sony Ericsson U8a Vivaz
Sony Ericsson X10a		Potential19	Potential	Potential	Potential	Potential	Potential	Potential	Potential

Persona with Moderate Mobility Impairment ("Christine")

Legend:

Yes: Accessible (see comments)
Yes*: Accessible, but requires third-party hardware or software (see comments)
No: Not accessible (see comments)
Potential: Potentially accessible (see comments)
na: Handset does not include features to support this task

Names (Submitted to CRTC by WSPs)	Discont. by Developer (Mar 2011)	Making phone calls	Receiving phone calls	Sending text message	Receiving text messages	Using social net-working on browser	Using calendar	Taking pictures	Watching videos or listening to music
Apple iPhone 3GS		Yes22	Yes	Yes*23	Yes	Yes*23	Yes	Yes	Yes
Apple iPhone 4		Yes22	Yes	Yes*23	Yes	Yes*23	Yes	Yes	Yes
BlackBerry Bold 9650		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry Bold 9700		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
Blackberry Curve 3G		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry Curve 8330	Discont.
BlackBerry Curve 8350i		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry Curve 8530		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry Pearl 8130	Discont.
BlackBerry Pearl Flip 8230	Discont.
BlackBerry Storm 9530		Potential24	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry Storm2 9550		Potential24	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry Tour 9630		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
BlackBerry World 8830	Discont.
Doro 410GSM		Yes	Yes	Potential25	Yes	na	Potential25	na	Yes26
HTC Google Nexus One		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
HTC Hero	Discont.
HTC Snap	Discont.
HTC Touch Diamond	Discont.
HTC Touch Pro 2	Discont.
HTC Touch Pro 7279	Discont.
LG 5500	Discont.
LG Banter (AX265)		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
LG Bliss (UX700)	Discont.
LG IQ (GW825)	Discont.
LG Keybo (LG9100)	Discont.
LG Keybo2 (LG9200)	Discont.
LG Masterpiece (LG7100)	Discont.
LG Reveal (LGCX600)	Discont.
LG Rumour (LG260)		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
LG Rumour2 (LG265)		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
LG Shine Touch (KM555)		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
LG Versa (LG9600)
LG Wine (LG280)	Discont.
LG Wink (GU297)		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
LG Xenon (GR500)		Yes	Yes	Yes1	Yes	Yes1	Yes	Yes	Yes
Motorola DEXT (CLIQ in US)		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
Motorola Extreme (VA76r) (Tundra in US)		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Motorola M800 Bag Phone		Yes	Yes	No28	Yes	No28	No28	na	na
Motorola M800 Car Phone		Yes	Yes	No28	Yes	No28	No28	na	na
Motorola XT720 (Milestone in US)		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
Nokia C6		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
Nokia 2730		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Nokia 3710		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Nokia 6350		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Nokia 6790 (compatible with Nuance Talks)	Discont.
Nokia 7230		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Nokia E71		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
Nokia E71 RVI (with Nuance Talks)		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
Nokia E72		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
Nokia N86 (compatible with Nuance Talks)	Discont.
Nokia N97 Mini		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
Palm Treo Pro		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
PCD 8635		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Samsung Ace (SPH-i325)		Yes	Yes	Yes29	Yes	Yes29	Yes29	Yes	Yes
Samsung Advance (SGH-a885)		Potential30	Yes	No11	Yes	No11	No11	Potential30	Potential30
Samsung Cleo (SCH-u440)		Yes	Yes	No11	Yes	No11	No11	Yes	Yes
Samsung CorbyPro (GT-b5310r)		Yes	Yes	No11	Yes	No11	No11	Yes	Yes
Samsung Galaxy S Captivate (SGH-i896)		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
Samsung Galaxy S Fascinate		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
Samsung Galaxy S Vibrant (GT-i9000)		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
Samsung Galaxy Spica (GT-i5700)		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27
Samsung Gravity 3 (SGH-T479)		Yes	Yes	No11	Yes	No11	No11	Yes	Yes
Samsung Gravity Touch (SGH-t669)		Yes	Yes	No11	Yes	No11	No11	Yes	Yes
Samsung Impact (SGH-t746)		Potential30	Yes	No11	Yes	No11	No11	Potential30	Potential30
Samsung Intensity (SCH-u450)	Discont.	Yes	Yes	No11	Yes	No11	No11	Yes	Yes
Samsung Link (SCH-r351)		Yes	Yes	No11	Yes	No11	No11	Yes	Yes
Samsung m320 (SPH-M320)		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Samsung m530		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Samsung Omnia (SCH-i910)	Discont.	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Samsung R540 (SCH-r540)		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Samsung Reclaim	Discont.
Samsung Rugby (SGH-A836)	Discont.	Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Samsung U430 (SCH-U430)		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Samsung Vice		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Sanyo Pro 700		Yes	Yes	No28	Yes	No28	No28	Yes	Yes
Sony Ericsson U8a Vivaz
Sony Ericsson X10a		Potential27	Yes	Potential27	Yes	Potential27	Potential27	Potential27	Potential27

Persona with Severe Cognitive Impairment ("Dave")

Legend:

Yes: Accessible (see comments)
Yes*: Accessible, but requires third-party hardware or software (see comments)
No: Not accessible (see comments)
Potential: Potentially accessible (see comments)
na: Handset does not include features to support this task

Names (Submitted to CRTC by WSPs)	Discont. by Developer (Mar 2011)	Making phone calls	Receiving phone calls	Sending text message	Receiving text messages	Using calendar	Taking pictures	Watching videos or listening to music
Apple iPhone 3GS		Yes*31	Yes	No32	Potential33	Yes*34	Yes	Yes
Apple iPhone 4		Yes*31	Yes	No32	Potential33	Yes*34	Yes	Yes
BlackBerry Bold 9650		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry Bold 9700		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Blackberry Curve 3G		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry Curve 8330	Discont.
BlackBerry Curve 8350i		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry Curve 8530		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry Pearl 8130	Discont.
BlackBerry Pearl Flip 8230	Discont.
BlackBerry Storm 9530		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry Storm2 9550		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry Tour 9630		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
BlackBerry World 8830	Discont.
Doro 410GSM		No37	Yes	No36	No	Potential39	na	Yes26
HTC Google Nexus One		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
HTC Hero	Discont.
HTC Snap	Discont.
HTC Touch Diamond	Discont.
HTC Touch Pro 2	Discont.
HTC Touch Pro 7279	Discont.
LG 5500	Discont.
LG Banter (AX265)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
LG Bliss (UX700)	Discont.
LG IQ (GW825)	Discont.
LG Keybo (LG9100)	Discont.
LG Keybo2 (LG9200)	Discont.
LG Masterpiece (LG7100)	Discont.
LG Reveal (LGCX600)	Discont.
LG Rumour (LG260)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
LG Rumour2 (LG265)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
LG Shine Touch (KM555)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
LG Versa (LG9600)
LG Wine (LG280)	Discont.
LG Wink (GU297)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
LG Xenon (GR500)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Motorola DEXT (CLIQ in US)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Motorola Extreme (VA76r) (Tundra in US)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Motorola M800 Bag Phone		No37	Yes	No36	No	Potential39	na	na
Motorola M800 Car Phone		No37	Yes	No36	No	Potential39	na	na
Motorola XT720 (Milestone in US)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Nokia C6		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Nokia 2730		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Nokia 3710		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Nokia 6350		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Nokia 6790 (compatible with Nuance Talks)	Discont.
Nokia 7230		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Nokia E71		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Nokia E71 RVI (with Nuance Talks)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Nokia E72		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Nokia N86 (compatible with Nuance Talks)	Discont.
Nokia N97 Mini		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Palm Treo Pro		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
PCD 8635		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Samsung Ace (SPH-i325)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Advance (SGH-a885)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Cleo (SCH-u440)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung CorbyPro (GT-b5310r)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Galaxy S Captivate (SGH-i896)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Galaxy S Fascinate		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Galaxy S Vibrant (GT-i9000)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Galaxy Spica (GT-i5700)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Gravity 3 (SGH-T479)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Gravity Touch (SGH-t669)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Impact (SGH-t746)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Intensity (SCH-u450)	Discont.	Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Link (SCH-r351)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung m320 (SPH-M320)		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung m530		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung Omnia (SCH-i910)	Discont.	Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung R540 (SCH-r540)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Samsung Reclaim	Discont.
Samsung Rugby (SGH-A836)	Discont.	Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Samsung U430 (SCH-U430)		Yes35	Yes	No36	Potential33	Potential39	Yes	Yes
Samsung Vice		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Sanyo Pro 700		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes
Sony Ericsson U8a Vivaz
Sony Ericsson X10a		Yes35	Yes	No36	Potential33	Yes*38	Yes	Yes

Notes:

Easier with external Bluetooth keyboard.
Dialling, not from contacts since this handset has a physical keypad.
Screen reader not available.
Touchscreen.
Oratio was not available in Canada on this model. (http://www.humanware.com/en-usa/products/blindness/oratio_for_blackberry_smartphones
/_details/id_131/oratio_for_blackberry_smartphones.html)
Touchscreen-"Mobile Access" application released in March 2011 shows potential.
Dialling since this handset has a physical keypad or from voice dialling.
Dialling, not from contacts since this handset has a physical keypad.
Touchscreen dialling with no screen reader.
Android v1.5 does not support text to speech.
Bluetooth keyboard not available.
With MobileSpeak screen reader.
No screen reader for Symbian S40.
Camera button.
With Nuance Talks and MobileSpeak screen readers.
With Nuance Talks screen reader.
Switch access is quite limited. Apps need to be designed to use switches so they cannot provide full system access. e.g. Blue2 Bluetooth switch (http://www.ablenetinc.com/AssistiveTechnology/MobileDeviceAccess
/Blue2BluetoothSwitch/tabid/880/Default.aspx) can be used to operate the Soundingboard AAC app, but it does not make calls etc."Predictable" app is now available, but to use messaging, Facebook requires the user to directly touch the screen (http://therapy-box.co.uk/predictable.aspx).
Currently switch access is not possible.
"Tekla" application/hardware (alpha) shows potential.
Android v1.5 does not allow "Tekla" to be used.
Click to Go is a 3rd party device and software is available for Windows Mobile 6, but users can only use that software and it only handles calls and text messages. (http://www.broadenedhorizons.com/click_to_phone.htm)
Keyboard navigation started with iOS 4.1 - Sept 2010.
With external Bluetooth keyboard.
Touchscreen makes task more difficult.
No Bluetooth keyboard support.
FM Radio
Touchscreen makes task difficult and external Bluetooth keyboards are not easily available since Bluetooth HID (Human Input Device) or SPP Profiles are not supported natively in Android (https://sites.google.com/a/android.com/opensource/projects/bluetooth-faq). However, there are some apps available that may allow certain handsets to be paired with certain keyboards.
Bluetooth keyboard not available and no QWERTY keyboard.
Touchscreen makes this more difficult but there is external bluetooth keyboard support.
Touchscreen makes task difficult and external Bluetooth keyboards are not available since Bluetooth HID (Human Input Device) or SPP Profiles are not supported .
Photo based contact manager apps available but not standard (e.g. PhotoPhone).
Currently symbolic communication apps not SMS enabled (e.g. Proloquo2go).
Could receive symbolic communication via image sending functions.
Graphic reminder apps available (e.g. iPrompt) (http://abilitynet.wetpaint.com/page/iPhone,+Ipod+Touch+-+Accessibility+&+Apps).
Contact manager can include images.
Currently symbolic communication apps with SMS etc. not available.
No photo-based contact manager.
Graphic reminder apps available.
Includes calendar but only text-based.

Date modified:: 2011-06-07

Mobile Wireless Handset Accessibility Assessment

While the enclosed study was commissioned by the Commission, the observations and conclusions are those of the author alone. The Commission makes this study available for reference by the wireless industry and other potentially interested persons.

Status

Contents

1. Scope

1.1 Assessment Timing

2. Executive Summary

3. Definitions

5. Assessment Approach

6.2.2 Results for Persona with Severe Mobility Impairment

7.1 Gaps in Meeting Visual-Related Needs/Preferences

7.2 Gaps in Meeting Mobility-Related Needs/Preferences

Table 4: Cross-cutting needs/preferences relevant to the use of mobile wireless handsets

11.2 Appendix B: Features/Technologies Supporting Accessibility Needs/Preferences

11.3 Appendix C: Detailed Results of Persona Analysis

12. Sources

Handset Persona Analysis

Handset Information

Wireless Service Provider (WSP) Handset Availability

Legend:

Persona with Severe Visual Impairment ("Alexia")

Legend:

Persona with Severe Mobility Impairment ("Bill")

Legend:

Persona with Moderate Mobility Impairment ("Christine")

Legend:

Persona with Severe Cognitive Impairment ("Dave")

Legend:

Notes: