OPEN SOURCE SCREEN READER

FOR BLIND AND VISUALLY IMPAIRED PEOPLE

Experiences and Thoughts

Martina Weicht, Frank Zenker, Ilvio Bruder and Andreas Heuer

IT Science Center Ruegen gGmbH, Circus 14, 18581 Putbus/Ruegen, Germany

Keywords:

Open source software development, Community, eHealth, Screen reader.

Abstract:

Developing open source software offers great potential for sustainable software evolution and for software

product distribution, holding particular advantages in ﬁnancial, psychological, security, and other aspects.

However, lots of effort and fortunate circumstances are needed to enforce them.

This paper will take a look at open source software development and its success factors using the example of

the SUE screen reader project. This project deals with supporting blind and visually impaired users on Linux

by providing alternative access to the graphical user interface. The development of SUE is an interesting

example of FLOSS development in the eHealth area.

We will introduce SUE and provide an overview of our open source development experiences discussing a

special factor in the success of open source development: communities.

1 INTRODUCTION

Open source software development provides an inter-

esting way for sustainable software evolution and for

distributing software products. It offers advantages in

various aspects such as in economy (efﬁcient produc-

tion of software based on available resources, better

market position among competitors with similar, but

non-free products, shorter time to market thanks to

code reuse), in security (quick identiﬁcation of po-

tential security problems and their correction), and in

personal psychology (peer recognition, engagement

into a rewarding task) – just to name a few. For a more

detailed discussion cf. (Working group on Libre Soft-

ware, 2000). However, to enforce these aspects lots

of effort and also fortunate circumstances are needed.

This paper will take a look at open source software

development and its success factors using the example

of the SUE screen reader project. This project deals

with supporting blind and visually impaired users on

Linux by providing alternative access to the graphical

user interface. The development of SUE is an interest-

ing example of FLOSS

development in general and

in the health care area in particular.

In order to describe open source software develop-

Free/Libre

Open Source Software; free/libre/open

in terms of source code access and reuse

ment in SUE along with its success factors and chal-

lenges, we will introduce the SUE project in section

2 and provide an overview of our open source devel-

opment experiences in section 3. In section 4 we will

discuss a special factor in the success of open source

development: communities. Section 5 summarizes

and discusses our experiences.

2 THE OPEN SOURCE SCREEN

READER SUE

The project SUE: Screenreader & Usability Exten-

sions

has been funded by the German Federal Min-

istry for Labor and Social Affairs for a period of 3

years (2007 – 2009). Its goal was to support blind and

visually impaired computer users on Linux using the

most important applications: desktop environment in-

teraction, e-mail and text processing, spreadsheet cal-

culation and a basic web browser support.

Development for SUE is based on the former

Linux Screen Reader (LSR) project

. LSR was meant

to be a “reusable development platform for building

alternative and supplemental user interfaces in sup-

port of people with diverse disabilities” (Parente and

http://sue.sourcefor

ge.net/

http://live.gnome.org/LSR

525

Weicht M., Zenker F., Bruder I. and Heuer A. (2010).

AN OPEN SOURCE SCREEN READER FOR BLIND AND VISUALLY IMPAIRED PEOPLE - Experiences and Thoughts.

In Proceedings of the Third International Conference on Health Informatics, pages 525-531

DOI: 10.5220/0002787905250531

 SciTePress

Clippingdale, 2006). Its development was funded by

IBM until a change in their accessibility support strat-

egy (Parente, 2007b) led to the LSR project going dor-

mant after one last release of version 0.5.3.

Looking carefully into the LSR project and all the

work that had been done up to then, the decision was

made to base screen reader development within SUE

upon the LSR project – made possible by generous

licensing of LSR.

For the SUE project, building upon LSR meant

that we did not have to start from scratch. The LSR

code base was carefully laid out as a sustainable, ex-

tensible architecture for assistive applications and al-

lowed us to continue its development both along our

ideas and a retrospect document provided by the LSR

project lead (Parente, 2007a). Most of its architecture

is still recognizable in SUE, especially the strategy of

abstracting dependencies which was even improved

in SUE. The code has been adapted to a more recent

version of the used accessibility interface and restruc-

tured for better handling. Some of the actual screen

reading functionality was only implemented in very

basic ways in LSR, such as Braille support, which we

integrated into a holistic output concept for all out-

put capabilities in SUE: Braille, speech, and magni-

ﬁcation. These are represented by both virtual and

physical devices: a Braille display and a Braille moni-

tor, magniﬁcation, and speech output (text-to-speech).

Application support – both for the requested applica-

tions and a few small other ones – had to be updated

and extended in some parts and newly created in oth-

ers.

Today, SUE’s base called AccessEngine is this en-

visioned platform for assistive applications and the

screen reader SUE is the ﬁrst of them; others are cer-

tainly possible. In general, the AccessEngine pro-

vides an event-based information processing to any

input and output devices connected to it. It takes care

of all data and device management tasks including re-

ceiving information from the accessibility interface

(AT-SPI, part of Gnome Accessibility project

) and

delivering it to the proper recipients.

Both the AccessEngine and SUE are published

under BSD license

, so anyone may either support our

work, develop their own open source screen reader

based on SUE or develop another open source assis-

tive application based on the AccessEngine. One idea

may be to integrate it into an AAL scenario by turning

the TV into an easy-to-use in-home information basis

with speech output and sound icons.

http://projects.gnome.org/accessibility/

http://www.opensource.org/licenses/bsd-license.php

3 REQUIREMENTS FOR A

SUCCESSFUL OPEN SOURCE

PROJECT

There are quite a few information sources available on

criterias for a successful open source project. Some of

them provide rather practical guidelines such as “Use

a version control system” or “Get free hosing for your

project”

. Others describe more abstract success fac-

tors like pursuing a clear goal, maintaining focus on

the project’s mission, or choosing a business model

With our background in software development, we

have chosen four main success criteria and will apply

them to the screen reader project.

3.1 Resources in Terms of Time,

Knowledge, and Money

When the SUE project started, resources seemed

plenty. The project was laid out for four full-time de-

velopers over a period of three years. None of them

had any experience in either open source software de-

velopment (though all have been using open source

software before) or screen reader software, but had

different levels of experience in software development

in general (on Windows and Linux) and in project

management. In order to gain insight into both of the

new ﬁelds, a community of open source / accessibil-

ity / screen reader experts was brought together in a

workshop.

3.2 A Clear Goal and a Goal-pursuing

Strategy

After the workshop, the project team retreated to eval-

uating and interpreting this gathering, unifying its re-

sults with their project description while going into

further research where necessary, into requirements

analysis and project speciﬁcation. This behavior has

been criticized by the above-mentioned community as

they did not feel involved into the decision-making

process. They expected a more bazaar-like project or-

ganization (many contributors loosely organized via

the Internet) whereas the project team – coming from

closed source software development – adopted the

cathedral style (code developed by small group and

released to the public) (Raymond, 1999). This ap-

proach seemed natural to the project team as they

were funded by the Ministry as opposed to the group

http://www.wikihow.com/Have-a-Successful-Open-

Source-Project

http://beradrian.wordpress.com/2009/05/12/success-

in-open-source/

HEALTHINF 2010 - International Conference on Health Informatics

526

of volunteers spending their free time on open source

projects. Unfortunately, this misconception signif-

icantly harmed the parties’ trust into one another,

which for the remainder of the project did not recover.

Meanwhile with respect to their project descrip-

tion the development team made decisions for their

development, deﬁned a road map and milestones for

their work and dove into screen reader development

preparing ﬁrst releases. When in doubt, the project

description was used as a reference. At different

stages during the project it differed from the com-

munity’s opinion. However, it was decided to rely

upon the ofﬁcial project description while at the same

time respecting the community’s interests and wishes

as much as possible.

3.3 Marketing

For a long time SUE was too immature to be actively

tested by volunteers. Disseminators were hesitant to

approach possible users as testers as long as the screen

reader only provided limited functionality – obviously

it is difﬁcult for a blind user to test a piece of soft-

ware that he/she absolutely needs to rely upon. At the

same time, others (namely the community mentioned

in sections 3.1 and 3.2) kept asking for the source

code to be published for them to take a look at and to

be integrated into discussion and decision making – a

contradiction between members of the community or

even between two communities (a stable screen reader

vs. early source code releases, screen reader users vs.

open source community members / developers).

Our decision on publishing the source code pre-

sented a compromise to those two sides. Halfway

through the project we chose to move our activities to

SourceForge.net

, an online platform for open source

developments. Up to then we have maintained a

project wiki (in German), but did not offer our source

code on the web. Two platforms have previously been

considered on which to publish our development ef-

forts. Gnome.org

seemed to be a good choice, since

for now SUE has been developed for the Gnome desk-

top environment as it provides the accessibility infras-

tructure that SUE relies upon. On the other hand,

once SUE is no longer limited to Gnome desktops,

this platform’s label will be too restricting. We would

mislead potential users or have to move again. There-

fore, SourceForge.net was chosen as our platform of

choice. Here it is a matter of adding a new keyword

to the project’s trove list when needed.

SourceForge.net proved to be a very useful plat-

form for our project development as it provides a mul-

http://sourceforge.net/

http://www.gnome.org/

titude of tools for open source software development:

web hosting, forums, blogs, mailing lists, trackers for

bugs, feature requests, and patches, code control sys-

tems like SVN, Bazaar, Git, a ﬁle release system,

project, content and task management tools, a wiki

and more. SourceForge.net is well-established among

OSS developers and only requires one registration for

all activities within one or more projects. All infor-

mation at SourceForge.net is provided in English in

order not to limit ourselves to German contributions,

but to ﬁnd as many users as possible.

3.4 Sustainability

One of the biggest problems in open source develop-

ment, especially with those projects that are funded

for a certain period of time, is sustainability. After

funding ends, development needs to continue in or-

der for the software product to be used - even more

with a screen reader that always depends upon an ac-

cessibility infrastructure on the one hand and on the

applications to be supported on the other. As soon

as development stops, the screen reader is out-of-date

and next to useless.

In general, screen reader development cannot be

done in projects. Other concepts and business mod-

els on how to permantently fund this work are neces-

sary in order to ensure continuous development – even

more as the implementation delivered after the funded

project period is only a small part of the application

support that is needed by screen reader users.

4 OPEN SOURCE COMMUNITIES

– EXPERIENCES FROM THE

SUE PROJECT

One of the crucial factors for open source software

projects is their community of users, testers, bug re-

porters and ﬁxers, and developers. This section takes

a look at different types of communities, their estab-

lishment and difﬁculties related to open source com-

munities from the viewpoint of the SUE project.

4.1 Autonomous and Sponsored

Communities - How do They ﬁt

Together?

West and O’Mahony (West and O’Mahony, 2008)

distinguish two different types of communities:

autonomous (community-managed) and sponsored

communities. As far as the SUE project is concerned,

AN OPEN SOURCE SCREEN READER FOR BLIND AND VISUALLY IMPAIRED PEOPLE - Experiences and

Thoughts

527

Figure 1: The SUE screen reader project at SourceForge.net.

the project team can be seen as a sponsored com-

munity with funding provided for a certain period of

time.

On the other side, there is an autonomous com-

munity of people interested in Linux accessibility. In

this particular setting, this community was the one

holding the information needed by the SUE project

team during their early project phase (cf. section

3.1). Serious mistakes in communication have been

made in this phase; to a certain degree due to how

the project team interpreted their own role: the cathe-

dral – “a small group of core developers who control

the architecture and direction of development” (Scac-

chi, 2007). The group decided to work on the screen

reader basis and main concepts ﬁrst before putting it

up on the web for everyone to look at and start con-

tributing. Speaking in terms of West and O’Mahony

and their two types of openness in communities, the

project team decided against accessibility, meaning

the direct inﬂuence of external participants on the

project’s direction, while lacking transparency in the

sense of letting the community know what was hap-

pening in the project. As described in section 3.2, this

policy of non-communication caused irritation within

that community and led to a few counterproductive re-

actions on their side. At this stage, both communities

did not regard each other as partners.

This situation inﬂuenced the project’s standing

when roles where about to change. By moving all

development efforts to SourceForge.net (cf. section

3.3), the team offered more transparency in terms

of project activities. The software gradually became

more and more elaborated and the need for testers

grew. The community that was supposed to be the

screen reader’s target group still suffered from what

they perceived as ill-treatment in the ﬁrst phase of the

project, ignored the development work or eyed – and

mouthed – it very critically.

Questions arose on why they should spend their

time on a project that others were paid to work on.

4.2 From a Sponsored to an

Autonomous Community

Despite this unfortunate start, what is desirable for

this particular project – and any project receiving

only initial funding – is to be transformed into an

autonomous community project. In order for this to

work, volunteers need to be acquired and encouraged

to go through the various stages of community mem-

bership. Nakakoij et al. (Nakakoji et al., 2002) men-

tion eight different roles of community membership

HEALTHINF 2010 - International Conference on Health Informatics

528

(passive user, reader, bug reporter, bug ﬁxer, periph-

eral developer, active developer, core member, and

project leader). These may not all be present in each

and every open source software project, but the gen-

eral classiﬁcation holds true. Those categories, how-

ever, are not static. As opposed to traditional soft-

ware development, community members may change

their roles as they gain more insights into the soft-

ware and acquire more skills. Nakakoij et al. iden-

tify two factors for a successful evolution of an open

source software community: “the existence of moti-

vated members who aspire to play roles with larger

inﬂuence, and the social mechanism of the commu-

nity that encourages and enables those individual role

changes.” What motivates people to get engaged in

an open source project? Numerous reasons exist.

Scacchi names “self-determination, peer recognition,

project afﬁliation or identiﬁcation and self-promotion,

as well as the belief in the inherent value of free soft-

ware.”

This did not hold true for the community of Linux

accessibility enthusiasts mentioned before as they did

not ﬁnd a way to overcome their prejudices nor did

they identify with the project.

At this point it was clear to the development team

that their community of interested users needed to

be found somewhere else. The community of visu-

ally impaired people, however, is not a large one.

Their fraction of people interested in Linux is even

smaller. Apart from this small number of poten-

tial new community members, what are the difﬁcul-

ties people face when considering joining as open

source software project? Shibuya and Tamai (Shibuya

and Tamai, 2009) identiﬁed a number of obstacles

such as selecting “a suitable task according to his/her

skills, lack of up-to-date development documents,

constraints imposed by contributor licensing agree-

ment, no response from core developers for their

doubts and support requests, and need to learn a new

tool”.

This clearly shows responsibilities both on the

newcomer’s and the community’s side that need to

be taken care of in order to successfully integrate the

newcomer into the open source project community.

Something that worked well already in the tiny

SUE community was localization. As the project is

still very young, we have decided not (yet) to rely on

global translation projects such as the Gnome local-

ization team. Again, this would have meant a close

coupling to Gnome, plus we needed in-time localiza-

tion and ﬂexibility for our work.

Also we were hoping to keep translators beyond

that task, engaging them in testing and/or develop-

ment as well. SourceForge.net provides a “Help

Figure 2: The status of internationalization for the SUE

screen reader.

wanted” section as a nice feature to actively ask peo-

ple to participate. A little note in that section asking

for help in localizing SUE lead to four inquiries by in-

terested users, two of whom actively translated it into

their mother tongue. Translating SUE is a clearly de-

ﬁned task with manageable effort (about 1.100 words

and strings). Little expertise is needed, i.e. no spe-

cial programming skills are required. Neither of them

was a screen reader user or had any previous experi-

ence with assistive software. Both of them were in-

volved in the project on a very low level and even

though translations need to be updated as develop-

ment progresses, to them their contribution did not

mean a long-term commitment to the project.

4.3 What are the Difﬁculties in

Establishing an Autonomous

Community?

With a small target group like ours, establishing a

community takes time. Users will not pour in by

themselves as in our case people are used to and de-

pendent upon their (Windows) screen readers. Mov-

ing over to Linux is a big step for a lot of them, one

they do not necessarily perform by themselves. In-

stead, it needs external forces such as their workplace

moving to Linux and therefore creating the need to

learn Linux and a screen reader on Linux. If this does

not happen, lots of marketing effort is needed such

as presenting the screen reader at assistive technology

exhibitions and conferences and directly approaching

disseminators like our project partner, the Study Cen-

tre for Visually Impaired Students (SZS) Karlsruhe

has done with their teaching concept on SUE screen

reader and Linux usage. By providing hands-on in-

troductory sessions, visually impaired people got to

test both the screen reader and the Linux OS, namely

http://www.szs.uni-karlsruhe.de

AN OPEN SOURCE SCREEN READER FOR BLIND AND VISUALLY IMPAIRED PEOPLE - Experiences and

Thoughts

529

Ubuntu, in order to get an idea of what using Linux

with a screen reader feels like.

In return, the development team received valuable

feedback on their work from participants, who over

the better part of the second project phase were the

only testers of the screen reader. Unfortunately, only

very few kept using the screen reader. This is partially

due to the early development stages the screen reader

was in during their teaching sessions.

Still, little by little, people are getting interested

in the project like one person who looked into screen

reading software for his blind friend. He used the

forum provided at SourceForge.net to ask questions

about the screen reader and interaction with him has

been very pleasant and constructive.

On the other hand a few issues arose during

project work that need to be considered as well.

Competing Projects. When starting the project,

another Linux screen reader, Orca

, existed. This

project is funded by SUN Microsystems, Inc. and

relies upon a large community of users, testers,

bug reporters and ﬁxers, and developers. While

competing products are a healthy mechanism in

economy, in open source software development they

are often regarded as waste of time and development

powers. “Instead of creating a second cripple, why

don’t you put your efforts into helping that ﬁrst

cripple improving?” (Comment given by one of the

community members).

Resource Management within the Core Develop-

ment Group. While trying to establish a community,

there is a constant weighing up of the actual develop-

ment tasks against the efforts of communicating with

potential community members. Even though talking

about the software and explaining it to outsiders might

provide new insights to the developers themselves, it

is nonetheless time-consuming and requires patience.

If available, a broker might help in this situation (cf.

section 5).

5 DISCUSSION

A number of obstacles have complicated project

development within SUE. The various communica-

tion problems might have been preventable, had the

project team known more about how open source soft-

ware projects work and had roles been clearly deﬁned.

More transparency along with a strategy on how to in-

tegrate the community of Linux accessibility enthusi-

http://live.gnome.org/Orca

asts into the project and at which stages of the project

might have prevented some of these issues.

It would be interesting to see if a broker mediat-

ing between the two groups as described by Wenger

(Wenger, 1998) could improve communication and

how such a broker gets to be accepted by both groups.

Finding the right broker would be crucial though

as much of the communication success depends on

his/her skills. Should the broker be sent by one com-

munity? Should he/she be completely independent

from both groups? Involving this extra person re-

quires even more sophisticated communication struc-

tures as this person needs to know exactly what both

groups do and what they want to do in order to pro-

vide a satisfying assistance to both.

Without a broker, all project members need to be

willing to interact with their community (of which

they are a part) and the time needed to do so must

be included in their work packages. This procedure is

even more important with the usually different area of

expertise within the development team.

6 CONCLUDING REMARKS

Without FLOSS, the SUE project would not have

been as successful as it now is. Being able to build

upon the LSR project saved a lot of time and allowed

to progress faster than with an implementation from

scratch. SUE also uses existing open source projects

to extend its functionality, i.e. Braille support and

screen magniﬁcation.

Its success, however, does not only depend on its

source code and the functionality it provides, but on

its community of users, testers, and developers. In

order for it to grow, source code accessibility and

project development transparency are of great impor-

tance. They require rethinking from non-open source

projects where development takes place within the de-

velopment team and a ﬁnal product is released.

However, with sufﬁcient knowledge on the mech-

anisms of open source software development in com-

munities, engaging into one can be a very rewarding

task with large potential for the software and a great

personal experience.

ACKNOWLEDGEMENTS

The SUE project team would like to thank the Ger-

man Federal Ministry for Labour and Social Affairs

for funding this project and expresses their gratitude

towards everyone who helped SUE along the way.

HEALTHINF 2010 - International Conference on Health Informatics

530

Thank you very much for your constructive feedback,

help, and support!

REFERENCES

Nakakoji, K., Yamamoto, Y., Nishinaka, Y., Kishida, K.,

and Ye, Y. (2002). Evolution patterns of open-source

software systems and communities. In IWPSE ’02:

Proceedings of the International Workshop on Prin-

ciples of Software Evolution, pages 76–85, Orlando,

Florida. ACM.

Parente, P. (2007a). Linux screen reader in retrospect.

http://www.gnome.org/ parente/lsr/retro/.

Parente, P. (2007b). Status of IBM accessibility.

http://mail.gnome.org/archives/gnome-accessibility-

list/2007-June/msg00000.html.

Parente, P. and Clippingdale, B. (2006). Linux screen

reader: Extensible assistive technology. In Keates,

S. and Harper, S., editors, ASSETS, pages 261–262.

ACM.

Raymond, E. S. (1999). The Cathedral and the Bazaar.

O’Reilly & Associates, Inc., Sebastopol, CA, USA.

Scacchi, W. (2007). Free/open source software develop-

ment. In ESEC-FSE ’07: Proceedings of the the 6th

joint meeting of the European software engineering

conference and the ACM SIGSOFT symposium on The

foundations of software engineering, pages 459–468,

Dubrovnik, Croatia. ACM.

Shibuya, B. and Tamai, T. (2009). Understanding the

process of participating in open source communities.

Emerging Trends in FLOSS Research and Develop-

ment, International Workshop on, 0:1–6.

Wenger, E. (1998). Communities of practice - Learning,

meaning, and identity. Cambridge University Press.

West, J. and O’Mahony, S. (2008). The role of participation

architecture in growing sponsored open source com-

munities. Industry & Innovation, 15(2):145–168.

Working group on Libre Software (2000). Free software

/ open source: Information society opportunities for

europe? version 1.2.

AN OPEN SOURCE SCREEN READER FOR BLIND AND VISUALLY IMPAIRED PEOPLE - Experiences and

Thoughts

531