Last week, a blind user in Turkey submitted a petition asking Microsoft to make Windows installation process completely accessible. According to the petitioner, current procedure for installing Windows is completely inaccessible. Subsequent comments posted to various mailing lists provided examples where the assumptions of the petitioner was contradicted, including ability to use USB headsets during installtion, invoking Narrator for latter half of the installation steps and usign talking Windows Preinstallation Environment (WinPE), scripting the installation process and so forth.
Although I agree with basic premise behind the petition, I would question the practicality of this idea. In order for a screen reader to even come onboard to help finish Windows installation via speech, basic infrastructure such as a generic sound driver must be developed. Second, making initial phase of clean Windows installation, or for that matter, access to early phase of installation accessible will require close colaboration between the sound card, operating system and firmware, and this raises a number of issues such as driver incompatibility. Lastly, although this petition may cover clean installation scenarios, because many users would install Windows on top of the existing installation with the initial phase being accessible, the argument that Windows installation is completely inaccessible will not hold.
Before we discuss why the idea proposed in the petition may not be practical, let us examine how Windows is installed. The following procedure applies for installing Windows Vista and later:
1. For a clean installation, the user will select to boot from the installation source (DVD, USB flash drive, etc.).
2. Once user selects language and other basic data, the installation program will copy a minimal set of boot files to the target hard drive. Once this is done, the computer will restart.
3. After the first restart, the newly installed boot programs will start and will search the source media looking for more files to copy. During this time, the screen will display various progress information regarding file copying, installation steps and so forth. Once the needed files are copied, the computer will be restarted to complete the initial setup phase.
4. Once the computer restarts, a more graphical part of the setup will be displayed. At this point a blind user can invoke Narrator to configure settings such as user name, installing updates and so on. Once this is done, Windows will launch the desktop or start screen depending on the version installed.
The part that blind users are asking for improved accessibility is the initial boot phase (booting from the installation media and going through initial setup screens). at this point, Windows will rely on drivers installed in firmware (BIOS/UEFI) or certain basic drivers to show the setup screens. Thus the first steps to making this petition a reality is inclusion of a generic sound card driver that allows blind people to install Windows completely on their own via speech.
However, with the current infrastructure, this is far from reality. Different sound card vendors add custom features onto their sound cards that may not be compatible with the generic sound card framework. There is also a possibility that certain sound cards will not listen to sound card drivers. Here, "listen" means that a sound card hardware should output sound as directed by a hypothetical generic sound card driver. With a variety of sound cards out there (including built-in ones), the idea of a generic sound card will require discussion between sound card manufacturers (Creative, Realtech and others), motherboard makers (Asus, Gigabyte, etc.) and operating system vendors.
Speaking of discussion between makers of sound cards, operating systems and motherboards, the idea of a hypothetical generic sound output architecture is something that requires careful colaboration between sound cards, operating systems and firmware. This means that before the proposed idea of complete Windows installation via speech can come to life, sound cards must be willing to play whatever sound required during installation phases (speech, for instance) when device-specific driver isn't available. Next, the operating system must be willing to discover as much as it can about any sound cards present on a system and would be willing to load a generic sound driver. Lastly, firmware (BIOS (Basic Input/Output System)/UEFI (Unified Extensible Firmware Interface)) must expose protocols (contracts and rules) for accessing sound hardware so that the operating system installers (especially those that run from an installation media) can talk to sound hardware 9if any). Currently, UEFI specification permits loading external EFI applications, which may mean it might be possible to create a program to discover and provide a mechanism to talk to sound card so the operating systems can take advantage of it later.
But is loading a generic sound driver at installation time a true universal solution? Think about a situation when a network administrator may wish to install Windows on remote computers (or servers) with no guarantee of presence of a sound hardware or sound output isn't desirable. Another example is if the installation is automated and steps for loading the generic sound driver is skipped. These examples highlight the limited practicality of the idea that the petition is proposing: speech output during installation, and without a firm infrastructure for it, the proposed idea will just be a food in a picture.
Lastly, clean installation isn't the only way to install any operating system. For Windows installation, there are two methods of installing it: clean installation (the steps are outlined above) or in-place upgrade. In case of the latter, the initial phase of installation is usable by blind users using screen readers, as the setup screens are similar to the ones encountered when installing any program (in fact, operating systems are programs, although they have specific purposes and promise to run even though other apps stop functioning unless drivers that crashes the entire system are involved). Given that this initial setup screen phase are (no different than that of certain phases during clean installation (except for some parts) and this can be done by screen reader users familiar with installing programs, I would say this defeats a major assumption put forth by the petition: Windows installation should be completely accessible when in fact it is when done corectly.
Given the evidence above and when considering current technology, I would like to cast doubt as to practicality of the idea presented in the petition. Having speech output during clean installation is a dream that blind users of Windows have been dreaming for a long time. But in order for this to work, a minimal or a generic infrastructure must be present, which requires careful colaboration between the parties involved, namely the sound card, operating system and firmware. Also, given that many would use in-place upgrade to upgrade from say, Windows 7 to Windows 10 and since this process is usable for people using screen readers, the petition would be redundant. But there are use cases when clean installation is desirable, and barring circumstances, having at least a minimal, generic solution would allow power users who are blind to install Windows with minimal effort. Therefore, I would like to urge the lbind community and other parties involved to carefully research what the petition is asking, what's possible with technology and what can be done before signing this petition. Thank you.
Tuesday, February 24, 2015
Wednesday, January 14, 2015
Microsoft screen reader petition: operating system access minus app support, customization and colaboration equals half-baked pie
In January 2015, a blind Microsoft Windows user posted a petition asking Microsoft to come up with a fully functional screen reader in Windows 10. This petition received a great deal of attention, with a number of Twitter users tweeting support or else providing link for the petition.
Although the idea of a fully integrated screen reader for Windows isn’t new, the timing of this particular petition is of interest. With Apple and Google leading the way in mobile dominance and with their respective screen readers, blind smartphone users are accustomed to having their smartphones talk out of the box after adjusting some settings. Also, with growing number of blind users using Mac OS X and with increased interest in talking Linux distributions, it isn’t surprising to find more and more blind computer users demanding Microsoft to do something with their own operating systems or else make Narrator more functional. Lastly, now that Microsoft is about to unveil consumer preview of Windows 10 and with changing landscape in Windows screen reader market, it is natural to see blind consumers asking Microsoft to take this opportunity to enhance Narrator or develop a more feature complete screen reader and ship it as part of Windows 10.
However, a screen reader that works out of the box isn’t the complete picture of a screen reader. A feature complete screen reader is expected to not only work with built-in applications, but also be ready to tackle today’s applications and their building blocks. Also, if the above petition is accepted and becomes a reality, it needs to allow power users to customize its behavior, something that cannot be done unless this extensibility is considered. Lastly, leaving out a crucial audience – app developers – will not get the above petition going forward, as third-party developers are also involved to make Windows what it is today and to enhance its user experience. Based on evidence from desktop and mobile operating systems and with my experience working with screen reader developers, the author would like to ask the petition writers and commenters to think about the following points.
First, a complete computer system is composed not only of hardware and operating systems, but also includes third-party apps. A functional screen reader should not only work with built-in applications such as OneDrive, File Explorer and others, but also with third-party applications such as media players, chat clients, office suites and others. This gets interesting when it comes to supporting Microsoft’s own products such as Office, Windows Live packages and any future apps (Cortana, for instance; Cortana is special in that it needs to coordinate with screen readers to receive voice queries and output just the needed messages). Thus an OS-specific screen reader that only supports built-in programs is, in my opinion, a half-baked pie – a crust without a filling.
Second, application development and usage is akin to completing a jigsaw puzzle. Not just the screen reader developer should support third-party apps, power users should be given opportunities to customize the screen reader’s behavior. Part of the reason for success of third-party screen readers for Windows is their extensive extensibility frameworks, such as scripting, reacting to various events and wide range of customization options. Without user customization facility such as scripting framework and integration with facilities such as power Shell, a screen reader – especially a built-in screen reader for an operating system – is a half-baked pie – a cold pie.
Lastly, screen reading is a collaborative process. Not only screen readers need to access information from built-in applications, they need to access information from third-party programs, and the key to this access is held by third-party app developers. If third-party app developers doesn’t take screen reading to account when designing their apps (especially with Windows Store apps and those using GUI frameworks such as WX and QT), it would make life of screen readers harder, especially for those who expect to use these apps with a built-in screen reader. In other words, without collaboration from third-party application developers (after all, developers of third-party screen readers are third-party developers as well), the above petition and its efforts could best be described as a half-baked pie – a crust, filling with no icing.
So what is the complete picture of a screen reader, especially that of a built-in screen reader for an operating system? It needs to support third-party apps just as good as built-in programs, it needs to allow customization from power users via various methods and third-party developers should be willing to take advantage of it. In my opinion, if the supposed built-in screen reader is considered an essential part of an operating system, then it should be open for usage not only by users, but also by developers so that app developers can utilized its functionality (API’s and frameworks provided by that screen reader, etc.), as without collaboration from outsiders, the effort would be best described as a half-baked pie, a half-baked solution and food in a picture. Not that I oppose this petition, but I think petition writers and commenters should also consider the petition’s impact on application programmers, as the idea being proposed – screen reading facility – is something that not only be used by users, but also can be used by developers to make their apps more accessible and appealing for blind and visually impaired Microsoft Windows users (application programmers hold the key to accessibility of their apps for screen reader users).
Thanks.
Although the idea of a fully integrated screen reader for Windows isn’t new, the timing of this particular petition is of interest. With Apple and Google leading the way in mobile dominance and with their respective screen readers, blind smartphone users are accustomed to having their smartphones talk out of the box after adjusting some settings. Also, with growing number of blind users using Mac OS X and with increased interest in talking Linux distributions, it isn’t surprising to find more and more blind computer users demanding Microsoft to do something with their own operating systems or else make Narrator more functional. Lastly, now that Microsoft is about to unveil consumer preview of Windows 10 and with changing landscape in Windows screen reader market, it is natural to see blind consumers asking Microsoft to take this opportunity to enhance Narrator or develop a more feature complete screen reader and ship it as part of Windows 10.
However, a screen reader that works out of the box isn’t the complete picture of a screen reader. A feature complete screen reader is expected to not only work with built-in applications, but also be ready to tackle today’s applications and their building blocks. Also, if the above petition is accepted and becomes a reality, it needs to allow power users to customize its behavior, something that cannot be done unless this extensibility is considered. Lastly, leaving out a crucial audience – app developers – will not get the above petition going forward, as third-party developers are also involved to make Windows what it is today and to enhance its user experience. Based on evidence from desktop and mobile operating systems and with my experience working with screen reader developers, the author would like to ask the petition writers and commenters to think about the following points.
First, a complete computer system is composed not only of hardware and operating systems, but also includes third-party apps. A functional screen reader should not only work with built-in applications such as OneDrive, File Explorer and others, but also with third-party applications such as media players, chat clients, office suites and others. This gets interesting when it comes to supporting Microsoft’s own products such as Office, Windows Live packages and any future apps (Cortana, for instance; Cortana is special in that it needs to coordinate with screen readers to receive voice queries and output just the needed messages). Thus an OS-specific screen reader that only supports built-in programs is, in my opinion, a half-baked pie – a crust without a filling.
Second, application development and usage is akin to completing a jigsaw puzzle. Not just the screen reader developer should support third-party apps, power users should be given opportunities to customize the screen reader’s behavior. Part of the reason for success of third-party screen readers for Windows is their extensive extensibility frameworks, such as scripting, reacting to various events and wide range of customization options. Without user customization facility such as scripting framework and integration with facilities such as power Shell, a screen reader – especially a built-in screen reader for an operating system – is a half-baked pie – a cold pie.
Lastly, screen reading is a collaborative process. Not only screen readers need to access information from built-in applications, they need to access information from third-party programs, and the key to this access is held by third-party app developers. If third-party app developers doesn’t take screen reading to account when designing their apps (especially with Windows Store apps and those using GUI frameworks such as WX and QT), it would make life of screen readers harder, especially for those who expect to use these apps with a built-in screen reader. In other words, without collaboration from third-party application developers (after all, developers of third-party screen readers are third-party developers as well), the above petition and its efforts could best be described as a half-baked pie – a crust, filling with no icing.
So what is the complete picture of a screen reader, especially that of a built-in screen reader for an operating system? It needs to support third-party apps just as good as built-in programs, it needs to allow customization from power users via various methods and third-party developers should be willing to take advantage of it. In my opinion, if the supposed built-in screen reader is considered an essential part of an operating system, then it should be open for usage not only by users, but also by developers so that app developers can utilized its functionality (API’s and frameworks provided by that screen reader, etc.), as without collaboration from outsiders, the effort would be best described as a half-baked pie, a half-baked solution and food in a picture. Not that I oppose this petition, but I think petition writers and commenters should also consider the petition’s impact on application programmers, as the idea being proposed – screen reading facility – is something that not only be used by users, but also can be used by developers to make their apps more accessible and appealing for blind and visually impaired Microsoft Windows users (application programmers hold the key to accessibility of their apps for screen reader users).
Thanks.
Wednesday, November 26, 2014
Tentative Access: Current situation with Windows 10 and screen reader support announcements
Hi,
Then this week, AI Squared which acquired GW Micro not long
ago, announced Window-Eyes 9.0 beta 1. Besides support for table reading and
math player support, one of the highlights was support for Windows 10. Although
the word “preliminary” was not used directly, as of November 2014, it is
considered a preliminary support given latest developments in Windows 10,
particularly some internal changes that may affect some code.
As someone who have used Windows 10 and a user of two screen
readers, I believe it isn’t right for assistive technology companies to
announce support for Windows 10 when NT kernel code base is still in late alpha
stage. In software development lifecycle, “alpha” usually refers to
bleeding-edge code meant for internal testing. Except for open-source projects,
alphas are not released to the public (exceptions exist). In case of Windows
10, current releases can be considered late alpha code, with hints at very
early beta code given user experiences, talks of OneDrive functionality changes
and what not. Thus, given that NT kernel code can change rapidly (which is a
trademark of fast-pace developments in large companies), November 2014 might be
too early (I’d say, a bit early) of a date to announce support for Windows 10
by a screen reader. Although it has a tactical advantage of throwing
competition off guard, when we consider Windows 10 from development
perspective, I would say AI Squared may have sent out a possibly misleading
message (again, the announcement is open to interpretation).
For the past few weeks, one of the topics brought up on some
blindness mailing lists and on social networking platforms was support for
Windows 10 by screen readers. Since the release of technical preview of Windows
10, some blind users installed this OS and sent tweets regarding supposedly
enhanced Narrator, some user interface issues and feelings about Windows 10
using their preferred screen readers. The consensus was that, although it felt
like using Windows 8.1, it had its potential with return of start menu from
Windows 7 yet cautioned that the OS is far from complete.
So when would have been a more appropriate time to announce
support for Windows 10? Based on current developments in Windows 10 and with
the current tech preview series being quite unstable, I’d put forth spring 2015
to be the right time (more towards CSUN 2015 conference season). This would
allow a more mature Windows 10 code to be available for early adopters and for
screen reader vendors to prepare their source code to tackle changes in
accessibility implementation, as by then developer preview with API release
notes would have been released. However, even if support for Windows 10 (NT
10.0) is announced by Freedom scientific, AI Squared, NV access and others,
vendors should keep an eye on any critical changes to accessibility
implementations that warrant further refinements to their source code (JAWS is
written in C++, evidenced by the fact that it installed C++ runtime
redistributables, NVDA’s front end is written in Python while critical backend
is written in C++). As it is now, I’d consider Windows 10 support (or
announcement of it) providing “ten”tative access to Windows 10. Thanks.
Thursday, October 2, 2014
Windows 10 Technical Preview: first impressions, feature intros and compatibility with screen readers
Hi,
Now that Microsoft lifted the veil on Windows 10 (formerly
codenamed Threshold), it’s time to examine its features and compatibility with
screen readers, specifically with NVDA. In this article, I’ll introduce you to
some of the new features in Windows 10 as of October Tech Preview build when
used with NVDA.
Introduction
When we think of GUI’s (graphical user interface), we often
think of icons, pictures and sliders to tell computers what to do. Along with
graphics, we also think about interaction with GUI elements, such as with mouse
clicks, touchscreen taps and keyboard commands. With the advances in screen
reading technology for GUI, blind computer users can utilize sophisticated
features of GUI’s to perform tasks, such as dragging, mouse clicks and so on.
One of the aspects of GUI environments is the overall user
interface and the introductory screen to launch various programs, open files
and search for information. For many, it would be a desktop where a grid of
icons representing folders and programs are displayed. For others, it might be
a home screen or apps launcher screen to search for apps and open apps by
tapping on the app icon.
Windows 8.x: is desktop an “app?”
In 2012, Microsoft introduced Windows 8, featuring a major
update to Windows GUI in years. This included a new style of apps, new ways of
starting programs and relegation of desktop into an “app”. While the
touch-centric interface of Windows 8 and its successor, Windows 8.1 was praised
for usability and interactivity, others criticized the decreased prominence of
desktop interface and asked Microsoft to undo some of the changes. Responding
to criticism, Microsoft reintroduced Start button and ability to go to desktop
upon login in Windows 8.1.
Windows 10: attempt at marriage of touch and desktop
Windows 10 can be best summarized as a hybrid between modern
UI and traditional desktop interface. For starters, we have the traditional
structure of the Start Menu combined with live tiles. Desktop became more
prominent with virtual desktops to run programs in virtual workspaces. Of
course Windows 8.1 is not forgotten; for instance, toggling a setting in
Taskbar and Navigation control panel lets you work with tiles alone.
Windows 10 and screen reader users: current status
As of October 2014 Tech Preview of Windows 10, NVDA works
well with Windows 10. It is expected that latest versions of JAWS for Windows,
Window-Eyes and other screen readers supporting Windows 8.1 will work with
Windows 10 to some extent. If you are used to Windows 8.1 with screen readers,
you can pick up Windows 10 quickly, though with some adjustments required such
as navigating the hybrid Start menu/screen interface. Let’s examine Windows
10’s features from viewpoint of screen reader users.
Start menu/screen: hybrid of Windows 7 and 8.1
When you press Windows key to bring Start UI, the notable
difference from Windows 7 and 8.1 would be addition of live tiles and return of
apps tree view, respectively. The screen is divided into two areas: on the left
is a familiar structure of Start Menu from Windows 7 days with search box at
the bottom. When you open Start UI, you’ll land on the search box, just like it
was with Windows 7. Pressing right arrow will you let explore the tiles, which
are on the right side of the screen. On the top of the screen are user accounts
and power options buttons, just like Windows 8.1 – you can press TAB to move to
these buttons.
Task view: viewing running apps at a glance
If you press Windows+TAB in Windows 10, you’ll land at what
is termed “Task View”. This window lets you glance running programs for the
“current virtual desktop” (more on that in a second). Here you can press left
and right arrow keys to move between apps you are running.
Related to Task View is virtual desktops, a virtual
workspace that allows you to run programs in separate desktops. For example,
you might be running Skype and various instant messaging applications in one
desktop while running web browsers on the other. This is similar to features
found in some of the Linux distributions. To switch between desktops, press TAB
from Task View to go to desktops list, use the left and right arrows to select
the desired desktop and press ENTER.
Modern apps: title bars, toolbars and other additions
One of the highlights in Windows 10 is change of appearance
of Modern apps. If you use smartphones such as Android and iPhone, you might be
familiar with app interfaces where the app takes the whole screen, and in
Windows world, it was termed “immersive app”. This isn’t the case with modern
apps in Windows 10: just like traditional programs, Windows Store apps have
title bars and toolbars. This may pose a problem for screen reader users who
uses announce title command to find out which app they are in (for example, in
NVDA, the word “itle bar for” is announced instead of the name of the app).
So who should and should not use Windows 10 Technical
Preview?
With just the features listed above, some may wish to
migrate to Windows 10. If I’m to give an answer to this question, I’d say,
“definitely, possibly and no” depending on the audience.
I highly recommend that you try Windows 10 Technical Preview
(at least as a virtual machine; more on that in a second) if you are:
·
A screen reader developer who wishes to optimize
his or her screen reader for Windows 10.
·
A power user of Windows who can’t wait till next
year to try some of the features in Windows 10.
·
A computer user who knows how to format and
install new operating systems and knows way of restoring old versions.
It might be possible that you may wish to try Windows 10 but
may not commit to it right away. This would be a good option for trainers who
wish to get ahead with Windows 10 features and to develop training materials
for blind computer users.
You should not use Windows 10 if you are:
·
Content with Windows 7 or 8.x.
·
Unsure about how to format and install operating
systems.
The reason is that, as of now, Windows 10 Technical Preview
is a late alpha and early beta code, so features may change rapidly. Given some
of the feedback comments, it wouldn’t be a surprise if even some of the
features described above are changed significantly.
As for using Windows 10 Technical Preview physically or
virtually, I highly recommend installing it as a virtual machine to minimize
disruption to your existing Windows installation.
I hope this gave you an accessible picture of what Windows
10 Tech Preview is like. I hope to update this series with more news on WinTen
with screen readers and to highlight major changes to UI as the Tech Preview
(Windows Insider program) progresses.
Joseph S Lee
UC Riverside (formerly), translator and code contributor to
NVDA project and author of NVDA add-ons
October 2014
Saturday, July 19, 2014
My ideal mailing list administrator...
Hi all,
First off, like my friend Alex Hall, I've officially retired from the
BrailleNote list. After going through several spam sagas (crashing
Eloquence, curse words, attacks on members, etc.), I and Alex decided to
retire and hand our batons to the next generation of BrailleNote
enthusiasts. As of July 2014, I'm still on the list, answering questions,
offering opinion pieces and guiding our new admins on doing their job.
Now that I have one less list to manage, I have more time to concentrate on
my interests, including course preparations, NVDA development and what not.
At the same time, I've been thinking about the subject of this post: what is
my ideal list administrator like? In my view, an ideal list administrator
should be an approachable expert, a good communicator between groups, a good
representative of a list, be gentle when dealing with troublesome members
and willing to sacrifice, even it means stepping down from the leadership
position when needed.
First, a list administrator should be an expert, or knows about a product or
a service in a way that allows him or her to teach it to a new user. I
should add, an approachable expert that is willing to go to lengths to
explain a concept to a new user until the user has solid grasp of a concept,
even this means communicating offlist and in the middle of the night. It is
better to have at least one approachable expert on a list (a person that a
new user or the list can trust to provide answers in a friendly way) than a
group of experts who are doing their thing (it is not okay to ignore
requests from a new member, in my opinion).
In addition to being an expert, a list administrator should be a good
communicator. Many people have adjusted to Twitter talk - that is, shortened
writings which are often quite descriptive but does not convey their
thoughts completely. I don't mean that all Twitter users (including myself)
are bad at communicating their thoughts - we have a number of great
communicators using Twitter to convey their thoughts. In terms of mailing
lists, what I mean by great communicator is this: being polite and
professional, even to a troublemaker (after all, as long as a person is a
member of a mailing list, the person is part of a group, whether or not he
or she is a moderator or a member).
Being polite means being gentle to all, including troublesome members. In my
experience on various mailing lists, members put more confidence in a
moderator who is gentle and willing to settle the matter politely with a
troublemaker. First, the members in question would feel honored in that even
the list leader understands them, and is more likely to not trouble the list
(there are exceptions). Second, other members would see that even moderators
are vulnerable, thus putting their support behind the moderators as they
carry out their duties. Third, the administrators are discharging the most
important duty: peacemakers, for which the trouble is just one lesson for
them to learn as they gain experience.
In addition to being polite, ideal list administrators should remember that
they are some of the prominent representatives of the mailing lists (the
others are members), which demands professional conduct. A list without a
professional administrator (one who is a polite expert, friendly, offers
solutions to disputes and knows how to stop off-topic threads kindly) is a
doomed list (sorry for the word usage here). In contrast, more new users are
bound to join a list run by one or more professional administrators and
learn from the experts (the administrators and current members) and are more
likely to recommend the list to others. Thus my emphasis about admins being
list representatives: a person who looks at joining the list would not only
look at the content of the list, but also would take into account the
conduct of its leaders, hence my opinion that admins are good
representatives of a mailing list.
Lastly, an ideal administrator should be willing to sacrifice. This may
involve time (saying up some nights to resolve conflicts between members),
ambition (listening to the list members and follow their suggestions) and,
in some cases, leadership (stepping down from leadership position). In my
view, sacrifice defines true leaders, as they show what's best for the
group, allowing members to relate to them easily (after all, a mailing list
is created for a specific purpose).
In closing, I'd like to offer some advice to admins and members of mailing
lists:
* List members, please remember that you're one of the reasons why people
join mailing lists. As much as the reputation of the list depends on content
and leaders, your conduct also adds to the reputation of a mailing list.
More often than not, a prospective member would think about how members talk
to each other before joining the list.
* List admins, please remember to love and serve the members of your list -
show respect to troublesome members, be a good friend to those who are
struggling with understanding a product's concept, be gentle when moderating
someone and be an approachable and trustworthy expert.
* To members and admins of mailing lists (even to blindness mailing lists):
content is just one aspect of a mailing list. The crown jewel of any mailing
list is the people who are part of the mailing list. Please remember that
the reputation of the list depends not only on content, but also on people.
Thanks.
First off, like my friend Alex Hall, I've officially retired from the
BrailleNote list. After going through several spam sagas (crashing
Eloquence, curse words, attacks on members, etc.), I and Alex decided to
retire and hand our batons to the next generation of BrailleNote
enthusiasts. As of July 2014, I'm still on the list, answering questions,
offering opinion pieces and guiding our new admins on doing their job.
Now that I have one less list to manage, I have more time to concentrate on
my interests, including course preparations, NVDA development and what not.
At the same time, I've been thinking about the subject of this post: what is
my ideal list administrator like? In my view, an ideal list administrator
should be an approachable expert, a good communicator between groups, a good
representative of a list, be gentle when dealing with troublesome members
and willing to sacrifice, even it means stepping down from the leadership
position when needed.
First, a list administrator should be an expert, or knows about a product or
a service in a way that allows him or her to teach it to a new user. I
should add, an approachable expert that is willing to go to lengths to
explain a concept to a new user until the user has solid grasp of a concept,
even this means communicating offlist and in the middle of the night. It is
better to have at least one approachable expert on a list (a person that a
new user or the list can trust to provide answers in a friendly way) than a
group of experts who are doing their thing (it is not okay to ignore
requests from a new member, in my opinion).
In addition to being an expert, a list administrator should be a good
communicator. Many people have adjusted to Twitter talk - that is, shortened
writings which are often quite descriptive but does not convey their
thoughts completely. I don't mean that all Twitter users (including myself)
are bad at communicating their thoughts - we have a number of great
communicators using Twitter to convey their thoughts. In terms of mailing
lists, what I mean by great communicator is this: being polite and
professional, even to a troublemaker (after all, as long as a person is a
member of a mailing list, the person is part of a group, whether or not he
or she is a moderator or a member).
Being polite means being gentle to all, including troublesome members. In my
experience on various mailing lists, members put more confidence in a
moderator who is gentle and willing to settle the matter politely with a
troublemaker. First, the members in question would feel honored in that even
the list leader understands them, and is more likely to not trouble the list
(there are exceptions). Second, other members would see that even moderators
are vulnerable, thus putting their support behind the moderators as they
carry out their duties. Third, the administrators are discharging the most
important duty: peacemakers, for which the trouble is just one lesson for
them to learn as they gain experience.
In addition to being polite, ideal list administrators should remember that
they are some of the prominent representatives of the mailing lists (the
others are members), which demands professional conduct. A list without a
professional administrator (one who is a polite expert, friendly, offers
solutions to disputes and knows how to stop off-topic threads kindly) is a
doomed list (sorry for the word usage here). In contrast, more new users are
bound to join a list run by one or more professional administrators and
learn from the experts (the administrators and current members) and are more
likely to recommend the list to others. Thus my emphasis about admins being
list representatives: a person who looks at joining the list would not only
look at the content of the list, but also would take into account the
conduct of its leaders, hence my opinion that admins are good
representatives of a mailing list.
Lastly, an ideal administrator should be willing to sacrifice. This may
involve time (saying up some nights to resolve conflicts between members),
ambition (listening to the list members and follow their suggestions) and,
in some cases, leadership (stepping down from leadership position). In my
view, sacrifice defines true leaders, as they show what's best for the
group, allowing members to relate to them easily (after all, a mailing list
is created for a specific purpose).
In closing, I'd like to offer some advice to admins and members of mailing
lists:
* List members, please remember that you're one of the reasons why people
join mailing lists. As much as the reputation of the list depends on content
and leaders, your conduct also adds to the reputation of a mailing list.
More often than not, a prospective member would think about how members talk
to each other before joining the list.
* List admins, please remember to love and serve the members of your list -
show respect to troublesome members, be a good friend to those who are
struggling with understanding a product's concept, be gentle when moderating
someone and be an approachable and trustworthy expert.
* To members and admins of mailing lists (even to blindness mailing lists):
content is just one aspect of a mailing list. The crown jewel of any mailing
list is the people who are part of the mailing list. Please remember that
the reputation of the list depends not only on content, but also on people.
Thanks.
Thursday, July 10, 2014
NFB Resolution 2014-12: thoughts on possible implications, long term reputation and impact on mainstream and blindness society
A few days ago, as I was browsing Twitter feeds of my friends, I came across an item that caught my eye: a resolution on making iOS apps accessible. Specifically, the resolution, known as “NFB resolution 2014-12” (which was passed on July 5th) calls on Apple to make all apps accessible for the blind by implementing accessibility standards and policies in collaboration with National Federation of the Blind (NFB). In describing the current situation, the resolution outlined how VoiceOver, Apple’s screen reader for OS X and iOS, was an integral tool for accessibility, and described how some apps were not accessible (or have become inaccessible in recent releases) with problems such as unlabeled buttons and so on.
At first, I felt uneasy about the resolution for several reasons. First, as a developer, I knew how some programmers would be burdened by implementing accessibility layer on top of their apps (techniques would have been labeling buttons, adding custom hints in addition to proper labels, etc.) and resources to be spent on such projects in an industry where cost is a key consideration in projects. Second, as some users pointed out, not all apps are guaranteed to be accessible (or accessibility would be incomplete), such as popular games like Angry Birds series despite advocacy efforts. Third, I believe in direct negotiations with app developers, as it allows a developer to become aware of the needs of their users, and if a famous developer would announce implementation of accessibility standards in his or her app, chances are that it’ll translate to a domino effect (other developers following the leader). Lastly, I feared that some app authors would leave iOS ecosystem due to accessibility requirement that Apple might impose as a result of passage of the said resolution, saying that some apps will never become accessible.
At the same time, I also thought about possible implications of this resolution in case it passes. First, although there were comments asking why Apple was singled out, some, including myself, also thought about the impact that this resolution might have on other industry giants such as Google, Microsoft, Amazon and so forth (particularly Google due to their mixed reputation of Android among blind users). Second, I worried that the reputation of the blindness community (represented by consumer advocacy groups such as NFB and ACB (American Council of the Blind)) might suffer as a result of demanding accessibility policies to a company such as Apple, seeing that people would misinterpret this as wanting more comfort. Third, NFB’s reputation among blindness community is mixed, with more people having negative views on this organization due to its history and patterns on their advocacy strategies, thus some were concerned by this resolution and its impact in the future.
Personally, I identify myself with those who oppose NFB resolution 2014-12. I’ve opposed the resolution due to the reasons outlined above: implementation resources, incomplete accessibility ecosystem, need for direct negotiations and departure of apps. I also agreed with sentiments raised on various social media (especially Twitter), such as flaws with the resolution, logic used, reputation and so on.
First, not all apps would be accessible in the long term for technical reasons. Some of the popular apps on app distribution channels are video games, and due to their nature, it becomes hard to implement accessibility with current development methods. One practical solution is to provide audio feedback and documentation on how a potential blind gamer would play the game. This becomes difficult when we have games which require fast response time and is CPU/GPU intensive. In this scenario, a phone’s processor would be busy not only servicing routines from the game, but also need to service output and input from blind gamer (this requires good design, even with dual core or quad core processors as they need to work together). Without good communications and accessibility design in place, we’ll never see a day when 100% of the apps (including games and professional apps which are very visual) are guaranteed to be accessible (and I use the word “guaranteed” to mean it’ll work out of the box). And that, folks, is current reality of programming mobile apps (solid design naturally leads to accessible app).
Second, I believe it is better to start from small things and allow others to learn from case studies. I once compared this statement to a waterfall and a boulder. A waterfall, with incredible sight to behold, starts from a small stream deep in the mountains. As other streams join the main stream, it creates massive body of force that cannot be stopped (unless something is blocking its path), culminating in a spectacular show of nature we call waterfall. Now suppose we have a boulder somewhere, blocking path to a stream’s progress. The stream, although struggling at first, eventually forces the boulder out of its way and continues downstream unless the boulder has more than enough force to repel forces from water (as a consequence of one of the famous physics laws). Or consider dominos where pushing a domino forward would cause others to fall.
In connection with app accessibility, I believe in direct negotiations for accessibility as opposed to forced policies. Although it may become necessary for a company to come up with design policies for accessibility, what really makes a difference (in my opinion) is if small steps are taken at first. By ensuring that an app is accessible, an app developer would have gained more customers, which would trigger a domino effect where other app writers in the similar genre would try to make theirs accessible. This would then be noticed by apps in other categories, thereby making them join the stream and creating a “virtual waterfall of accessibility”. In other words, it is far better (in the long term) to let app authors be creative and learn about accessibility when working with their customer base than for a company to institute accessibility policies after recommendations from a consumer organization (I must stress that I do believe in collective action, but for this case, I believe it is far better to go through direct negotiations, sitting with app authors and allowing them to have an intimate learning experience about accessibility needs).
With that said, I’d like to present some suggestions for all parties involved in this event, and offer some thoughts on what we can do next, now that the resolution is in the record books.
First, I’d like to kindly suggest that users approach app developers as friends and partners. App users and software developers (like myself, as I belong in both camps) are all consumers: users consume products made by programmers, and in turn, programmers consume suggestions, bug reports and improvements from users. I believe that better (I should add, ultimate) accessibility of an app comes through solid partnership between users and developers in understanding each other’s needs – accessibility for blind consumers and product feedback for developers. And I do kindly suggest that it be done in a friendly manner in order that reputation of both parties (consumers and developers) would improve.
Second, I’d like to kindly suggest that we look at consequences and long term goals and reputation about our community when we write resolutions and campaigns. I’m sure we don’t want reputation of the blindness community to suffer now and in years to come, particularly for our people to be misinterpreted by mainstream society, right? And since our posterity depends on our actions today, I believe it is important to not only consider our current reputation, but also the reputation of our community a few decades down the road as well, as well as consequences of our campaigns and resolutions so that our posterity can look up to us and learn from us, even if we make mistakes (if we do make mistakes, it’s better to acknowledge it for the benefit of future generations).
Third, I’d like to gently suggest to app authors to become our partners in accessibility to provide rich case studies for others to follow. A well-known Korean proverb says, “better is seeing once than to hear it a hundred times.” That is, a person would retain understanding of a concept once he or she sees it rather than hearing about it many times. By providing ready to use examples of accessibility (even small demos and case studies), an app author can open possibilities for other apps to become accessible for people with disabilities.
Lastly, I’d like to gently suggest that we have reality checks from time to time. We cannot pass through a mountain without knowing which way is the route to a safe camping location for the night, nor we cannot easily say that we can cross a desert without checking our water supplies and thinking about passing through this valley safely. Likewise, it is good to have dreams of an unseen accessible ecosystem down the road (and we do need visionaries in our generation), but we cannot make it there unless we have a sense of what we can and cannot do (a good example is braille system; although we cannot easily communicate with print, we can at least learn about the current affairs and express our opinions through alternates such as braille and related technologies). And we shouldn’t forget that there are talented individuals (I should add, all of us are talented in one way or another) who can bring ideas to reality, and that reality could be another reality check in a few years down the road.
In conclusion, some would say that we’ve spilled our beans of reputation, while others would say that we’ve laid the stepping stone for others to follow. Whatever it might be, I do acknowledge that NFB resolution 2014-12 is now in the record books, to be scrutinized in front of cameras and talked about on blogs and in social networks. Despite my uneasy feeling about its passage, I do realize that it has and will produce impact to be felt in software development and advocacy channels for years to come. At this stage, what we, the blind consumers of iOS (and other mobile operating systems) and their apps can do is to extend our offer of friendship and partnership to app developers, for both users and developers to work together in understanding their needs, be friendly for the sake of our reputation and keep an eye on what can be done. And please don’t forget that app developers are people and users, just like us, as I and other software developers who are blind can testify.
P.S. As I’m one of the young people who’ve debated about the resolution fiercely on social networks, I’m afraid that our “virtual war” could have brought not only our reputation down (I’d say, a lot), but also that of the blindness community. If this is the case, I’d like to formally apologize for our behavior.
Tuesday, June 17, 2014
NVDA: Source code documentation (June 2014)
Hi,
For some time, I’ve been thinking about writing a book called “NonVisual Developer’s Aid to NVDA,” a comprehensive reference on NVDA’s source code. I sort of wrote an outline for it while I was writing the add-on development guide, but decided to post the actual documentation that comes with the source code in hopes that someone might learn something about NVDA, screen reading technology, accessible software design and perhaps contribute to NVDA (and perhaps write a book about nVDA with the source code docs). If you are a developer wishing to know the internals of NVDA, this is for you (and hats off to Mick Curran and Jamie Teh, who deserves the credits for writing the source code docs and NVDA in the first place).
A zip file is now available containing source code documentation for the latest master branch (June 2014). Note that this should be studied by programmers who are serious about extending NVDA’s core and/or interested in internals of how add-ons work their magic (in reality, anyone is welcome to study it, publish a book based on the source code, etc. (if you do plan to publish a book, I’d advise asking NVDA devs).
But first, for people who are just getting started with NVDA development should read the latest developer guide, which can be found at:
http://community.nvda-project.org/documentation/developerGuide.html
Now for the source code documentation (based on master branch as of June 2014):
http://www.nvda-kr.org/nvda-source_doc-master-2014Jun.zip
For Mick and Jamie, I hope I’m not going against your rules…
Enjoy.
An NVDA translator and add-on writer
Subscribe to:
Comments (Atom)