[fcb-l] FW: [acb-l] Windows Phone 8 (Apollo) Accessibility

[Edwards, Paul]

Paul Edwards, Director
North Campus Access Services
11380 Northwest 27 Avenue
Miami FL33167
PHONE: (305) 237-1146
FAX: (305) 237-1831
CELL PHONE: (305) 984-0909
HOME PHONE: (305) 692-9206

ABILITY COUNTS


-----Original Message-----
From: acb-l-bounces at acb.org [mailto:acb-l-bounces at acb.org] On Behalf Of Pratik Patel
Sent: Friday, February 03, 2012 9:14 PM
To: iac at acb.org; leadership at acb.org; acb-l at acb.org; acbny-board at lists.ezfire.net; bits at acb.org
Subject: [acb-l] Windows Phone 8 (Apollo) Accessibility

Dear all,

Please see an update from me regarding Windows Phone accessibility. The link
will allow you to comment. I am also pasting the full text below.

http://goo.gl/C0bFQ

Regards,

Pratik

In a market that had not seen the touch screen as a ubiquitous method of
interaction, Apple introduced the iPhone in 2007 with a level of popularity
never before seen in the United States.  With an operating system solely
designed to elevate touch-based interaction to a consistent metric of
performance and user interface design, Apple set a standard that other
companies have attempted to emulate till today.  The introduction of
Google's Android mobile phone operating system has brought a different set
of philosophical and design perspectives to the users.  Research in Motion
and Microsoft, while having somewhat popular operating systems of their own,
have had to play catch up to these two mobile juggernauts by attempting to
refresh their operating systems.  Despite these attempts, Microsoft-in
particular-had steadily lost the world-wide market share of its operating
system to a meager five percent.  The company's failures to take advantage
of its resources and market opportunities have been documented in other
publications.  Suffice it to say that, with its introduction of Windows
phone 7 operating system and the associated ecosystem, Microsoft entered the
mobile arena with enormous disadvantages.

Windows Phone 7 represented an entirely new venture for Microsoft as it not
only meant a clean break from the old UI design paradigm but a completely
new codebase.  In the space of little more than a year, Microsoft appears to
have delivered an operating system that received some praise from reviewers.
Considering the short time for development, the first few iterations of the
operating system seem to deliver A UI that is well thought-out and provide
new concepts for communicating information to users.  While doing so,
however, Windows Phone 7 and 7.5 have also been marked by well-known
reviewers as lacking in basic capabilities that users take for granted in
modern mobile operating systems.  It is clear that Microsoft has combine two
philosophical and practical approaches utilized by Google and Apple in
working with hardware manufacturers, mobile operators, and application
developers.  While not ceding direct control over hardware design like
Google, Microsoft chose to provide chassis specifications which will be used
by manufacturers to develop handsets.  Unlike Apple, on the other hand,
Microsoft's application development process appears to be less restrictive
for developers.  These approaches appear to place the company on a tight
rope that may lead to a successful increase in its market share of mobile
phones.

The community representing blind and visually impaired people heard rumors
in the summer of 2010 that this tight-rope strategy that Microsoft planned
to use at launch would most probably not include the accessibility needs of
the community in Windows Phone 7, leaving a large population behind when it
came to having access to the new devices powered by Microsoft's operating
system.  To respond to this need and to ensure that the organization was
able to work closely with Microsoft to resolve such a lack, the American
Council of the Blind (ACB) passed a resolution at its 2010 convention to
empower its staff and the Information Access Committee  which would
collaborate with Microsoft to ensure that accessibility was implemented
properly.  To ACB's regret, Code Factory's public revelation and a
subsequent conversation with Microsoft revealed that the first iteration of
Windows Phone 7 would not deliver accessibility for people who are blind or
visually impaired-not even to the extent that accessibility existed under
previous Windows Mobile 5.x and 6.x iterations.

While providing basic support, Microsoft's previous approach to
accessibility under older mobile operating systems meant that third-party
developers such as the aforementioned Code Factory and Dolphin were required
to make changes to the underlying code and achieve accessibility via means
that these screen reader and magnification software developers devised on
their own.  This also meant that individual consumers with visual
disabilities and businesses with blind or visually impaired employees
acquiring Windows Mobile powered devices were required to pay in excess of
$300 in additional funds in order to be able to access their phones.  While
neither an ideal nor an economical solution, it was one way that blind and
visually impaired people were able to access their phones during the days
when Windows Mobile shared a significant market with Symbian and RIM
devices.  This changed in the middle of 2009 when Apple introduced the
iPhone 3GS phone along with 3.0 version of what is now known as iOS.  By
introducing a built-in screen reader that could be operated by nothing other
than customized touch gestures, Apple proved, once and for all, that
accessibility could not only be considered as innovation in and of itself
but that cost for accessibility could and should be included as a part of a
manufacturer's business operation without it being passed on to consumers.
A parallel effort by Google to create a screen reader for Android by using
its philosophical approach has led to partial accessibility, which-even
though relying on the open source developer community-has shown some
traction and the understanding that-when complete-it will provide full
access to the Android operating system for people who are blind and visually
impaired without additional cost.

This being the historical backdrop under which Microsoft had introduced a
product without any possibility of having full access for consumers who are
blind or visually impaired in the immediate future, the company chose to
hold a roundtable discussion in Redmond to consider the state of
accessibility for its Windows Phone 7 operating system.  I, as the Chairman
of ACB's Information Access Committee, along with Eric Bridges, ACB's
Director of Advocacy and Governmental Affairs, represented the organization
for this roundtable discussion in October of 2010.  The gathering consisted
of representatives from ACB, AFB, CNIB, NFB, RNIB, Once, and Vision
Australia.  The Group met at the Microsoft campus with Rob Sinclair and
representatives of the company's Trustworthy Computing Group that works with
accessibility across various initiatives and projects.  Most of the day,
however, was spent in dialogue with the Windows Phone 7 team to discuss
challenges and solutions regarding accessibility to the new platform.  Along
with providing information about the current state of the platform as it
relates to accessibility, understanding the community's views as they relate
to built-in access as well as third-party solutions, and gaining an
understanding regarding day-to-day utility of mobile for blind and visually
impaired people, the Windows platform group provided an opportunity to have
discussions with Andy Lees, the President of Mobile Communications Business
at Microsoft.

These discussions made it clear that Microsoft regretted its place in the
mobile space and is unpleased at the choice of not having an accessible
solution for the Windows Phone 7 platform.  The technical details regarding
the implementation of various solutions revealed that accessibility was not
possible on the Windows phone 7 platform without significant underlying
changes.  In order to deliver a usable platform on time-though be it with
limitations, Microsoft chose to remove complexity from the platform.  This
necessarily meant that, if an accessibility solution was going to be
implemented, it would have forced Microsoft to remove the simplicity,
delaying the entire launch of this new platform and-as some might
argue-leaving Microsoft's market position to be even further vulnerable to
erosion by company's competetors.  The delivery of a fully accessible
Windows 7 experience would have required Microsoft to remedy three
particular choking points(at least for a third-party to provide an
accessibility solution): 1) multitasking; 2) interprocess communication; and
3) focus.

Multitasking

Multitasking is a process by which an operating system permits more than one
program to run simultaneously.  For current generation of mobile devices
whose hardware capacity is limited, multitasking requires a careful design
to ensure that the system does not freeze when more than one process is
running.  Although hardware design has come a long way since 2007, Apple did
not deliver a version of its multitasking design until the summer of 2010,
more than three years following the initial launch of the operating system.
User experiences with Android suggest that its multitasking design often
freezes phones and is attributed with unnecessary drain in battery.  It is,
therefore, unsurprising that Microsoft chose to leave multitasking for
third-party software until some unspecified time in the future.  Because of
this reason, developers of screen readers and screen magnifiers such as Code
Factory and Dolphin were unable to approach the operating system to develop
a screen reader for it during the first year.  This is not to suggest,
however, that Microsoft could not have used an approach similar to the one
employed by Apple when it first released Voiceover and Zoom.  As the primary
developer, apple had the opportunity to bypass multitasking restrictions
placed on third-party developers, making screen reader and magnification
utilities available one year prior to releasing multitasking. While
certainly a significant hindrance to third parties, the lack of multitasking
was not a sole deterrence to having access for Windows Phone 7.

Inter-process communication

Inter-process communication (IPC or intersec) allows hardware or software
processes to talk to one another, enabling better data and memory
management.  As Microsoft explained during our meeting, the initial Windows
Phone 7 platform did not have an elegant intersec model which could be used
by applications to communicate with various processes on the phone.  This,
once again, would hamper third-party software from accessing core parts of
the operating system to enable full access.  An in depth technical
discussion of intersec being outside the purview of this article, it is
sufficient to say that the lack of intersec certainly jeopardized the
ability to build an access solution.

Focus

With traditional interaction models-models that use keyboard cursor keys,
focus on various parts of the screen is established by using arrow keys or
other programmatic methods.  Focus is often vital for users needing to
magnify objects and parts of the screen; it is also quite necessary in order
to effect keyboard-only navigation.  An operating system solely designed to
utilize touch as a method of interaction can be argued to not need focus for
each element on the screen since most modern touch screens require users to
interact directly with given objects by using their fingers.  Touchscreen
based navigation can employ other methods of accessing object information
for manipulating screen elements.  One such method for achieving focus is to
utilize a secondary layer of gestures specifically defined for accessing
elements; this technique is used quite successfully by Apple in implementing
Voiceover.  Focus or other programmatic techniques are essential in order to
identify and manipulate objects for magnification purposes.  Not having any
method to do this consistently across the entire operating system limits the
ability to magnify.  While limited magnification capabilities are available
in the browser and some other parts of the os by using the pinch-to-zoom
gesture, they do not carry across all functions of Windows Phone 7.  Without
having keyboard-based  focus, virtual focus like that defined by Apple, or
focus based on navigation cursor as implemented in Android, pose significant
challenges in creating the level of accessibility needed by third-party or
built-in solutions.

At the conclusion of our meeting in October of 2010, we left Microsoft with
a strong message-namely that the market could no longer support a
third-party product for achieving access. In particular, the community could
no longer tolerate paying hundreds of dollars for after-market
accessibility. Yet we also were left with the distinct sense that what was
desired could not be achieved in a year. If we were to expect something that
was usable, it would not come until 2012 at the very least.

Despite our hopes to the contrary, it became clear at the launch of Windows
Phone 7.5-otherwise known as Mango-that accessibility was indeed not fully
included. A few text to speech events and a few more speech to text
activities were demonstrated to us when we gathered to follow up with the
Windows Phone team in November of 2011. Along with me and Eric, same
organizations were represented at the event and given information about the
progress that Microsoft had made during the year. In his remarks to us,
however, Andy Lees gave us some information about the underlying changes
that are coming to the next version of Windows Phone platform-changes that
we were not free to discuss until now.

Quite a bit of information has been released about  Windows Phone 8-commonly
referred to as Apollo-in the past few days. What were only rumors have been
confirmed by Microsoft sources an journalists who work closely  with
Microsoft. These confirmations have to do with Microsoft making the core of
Windows Phone 8/Apollo the same as Windows 8 that is used on the desktop.
For more information about the revelations that have been made available,
see the following:

http://arstechnica.com/microsoft/news/2012/02/leaked-windows-phone-8-vid-win
dows-8-kernel-and-integration-multiple-cores.ars

According to Paul Thurrott writing at
http://www.winsupersite.com/article/windows8/windows-phone-8-preview-142154,
"Windows Phone 8, as its name suggests, will also be tied closely to the
desktop version of Windows 8 in other ways. They'll be launched closely to
each other, and will share integrated ecosystems, thanks to the shared
underlying code, components, and user experiences. Windows Phone 8 is part
of the "Windows Reimagined" campaign that Microsoft announced for Windows 8.
This makes sense as they're companion products in every sense of the word."

How does this affect accessibility? In many ways, the shared code will allow
Windows Phone to share the inherent accessibility framework that Windows 8
will rely on heavily. Microsoft phone team has spent not only overcoming the
three challenges that were described above, but the team has spent the time
to incorporate UI Automation into native components. This means that
everything that is built by the Phone team has accessibility  properties
attached to it so that it can be read by a screen reader or a magnifier.

The most anticipated question indeed is whether or not Microsoft will
incorporate a screen reader into Apollo. The answer is yes. The components
are there. There are quite a few challenges that remain about which we know
nothing. Most blind and visually impaired people who are familiar with
Apple's and Google's implementation of touch screen access will know that
presenting information on a screen is complex; the interaction is
necessarily different than how sighted people use touch screen devices. Yet,
compared to Apple devices, the Metro interface that Windows Phone devices
use is  significantly different. Interface elements such as animated bubbles
and live tiles that present constantly updating information will present
challenges that are unanticipated.


Based on our discussion with Microsoft, it is clear that those applications
that rely on Silverlight development will have the means to be made
accessible by applying UI Automation. Questions remain about the framework
known as XNA that Microsoft uses for game development. No definitive
information is available about how or whether Microsoft plans to integrate
UIA into this framework so that games could be made accessible as they are
on Apple's iOS. Rumors also suggest the eventual demise of Silverlight. If
this is the case, how will Windows Phone app development be affected? If I
were to predict based on the recent revelations about common components
between the phone and the desktop operating systems, I can anticipate an
approach that will have UI Automation at the center of any new development
framework. However, since XNA is used quite a bit by XBox and XBox-like
games-and, since I know of no major effort to make the XBox accessible, this
framework will continue to pose problems for developers wishing to make
their apps accessible when using it.

The relationship between XNA and XBox suggests another pernitious problem
that is likely to plague the Windows Phone accessibility effort. It is clear
that not all components of the phone are developed by the Windows phone
team. In fact, one of the major aspects of the phone experience that a
modern mobile device relies upon, the browser, is controlled by the Internet
Explorer team. Whatever version of IE will accompany Apollo is unlikely to
include UI Automation support, rendering a core experience entirely
inaccessible. I anticipate a similar problem to occur with other apps or
experiences that the Windows Phone team does not directly control. These
include Office and, perhaps, Skype.

Until we have had an opportunity to test devices with Apollo, I cannot say
much more about what kind of access will be included. Will there be support
for Braille? I anticipate not. Screen enlargement and high contrast support?
Most probably. I am reminded that It took Apple several years to get to
where it is when it comes to its accessibility. That said, however, Apple
will have had four years of lead by the time Microsoft releases Apollo.
While I continue to reserve judgment, I do not anticipate the first version
of the Windows Phone accessibility to satisfy our standards and needs.


_______________________________________________
acb-l mailing list
acb-l at acb.org
http://www.acb.org/mailman/listinfo/acb-l