AN 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 financial, 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 ment in SUE along with its success factors and chal- lenges, we will introduce the SUE project in section Open source software development provides an inter- 2 and provide an overview of our open source devel- esting way for sustainable software evolution and for opment experiences in section 3. In section 4 we will distributing software products. It offers advantages in discuss a special factor in the success of open source various aspects such as in economy (efficient produc- development: communities. Section 5 summarizes tion of software based on available resources, better and discusses our experiences. market position among competitors with similar, but non-free products, shorter time to market thanks to code reuse), in security (quick identification of po- 2 THE OPEN SOURCE SCREEN tential security problems and their correction), and in READER SUE personal psychology (peer recognition, engagement into a rewarding task) – just to name a few. For a more The project SUE: Screenreader & Usability Exten- detailed discussion cf. (Working group on Libre Soft- sions2 has been funded by the German Federal Min- ware, 2000). However, to enforce these aspects lots istry for Labor and Social Affairs for a period of 3 of effort and also fortunate circumstances are needed. years (2007 – 2009). Its goal was to support blind and This paper will take a look at open source software visually impaired computer users on Linux using the development and its success factors using the example most important applications: desktop environment in- of the SUE screen reader project. This project deals teraction, e-mail and text processing, spreadsheet cal- with supporting blind and visually impaired users on culation and a basic web browser support. Linux by providing alternative access to the graphical Development for SUE is based on the former user interface. The development of SUE is an interest- 3 1 Linux Screen Reader (LSR) project . LSR was meant ing example of FLOSS development in general and to be a “reusable development platform for building in the health care area in particular. alternative and supplemental user interfaces in sup- In order to describe open source software develop- port of people with diverse disabilities” (Parente and 1Free/Libre Open Source Software; free/libre/open 2http://sue.sourceforge.net/ in terms of source code access and reuse 3http://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 Copyright c SciTePress HEALTHINF 2010 - International Conference on Health Informatics Clippingdale, 2006). Its development was funded by 3 REQUIREMENTS FOR A IBM until a change in their accessibility support strat- SUCCESSFUL OPEN SOURCE egy (Parente, 2007b) led to the LSR project going dor- mant after one last release of version 0.5.3. PROJECT Looking carefully into the LSR project and all the There are quite a few information sources available on work that had been done up to then, the decision was criterias for a successful open source project. Some of made to base screen reader development within SUE them provide rather practical guidelines such as “Use upon the LSR project – made possible by generous a version control system” or “Get free hosing for your licensing of LSR. project”6. Others describe more abstract success fac- For the SUE project, building upon LSR meant tors like pursuing a clear goal, maintaining focus on that we did not have to start from scratch. The LSR the project’s mission, or choosing a business model7. code base was carefully laid out as a sustainable, ex- With our background in software development, we tensible architecture for assistive applications and al- have chosen four main success criteria and will apply lowed us to continue its development both along our them to the screen reader project. ideas and a retrospect document provided by the LSR project lead (Parente, 2007a). Most of its architecture 3.1 Resources in Terms of Time, is still recognizable in SUE, especially the strategy of Knowledge, and Money abstracting dependencies which was even improved in SUE. The code has been adapted to a more recent When the SUE project started, resources seemed version of the used accessibility interface and restruc- plenty. The project was laid out for four full-time de- tured for better handling. Some of the actual screen velopers over a period of three years. None of them reading functionality was only implemented in very had any experience in either open source software de- basic ways in LSR, such as Braille support, which we velopment (though all have been using open source integrated into a holistic output concept for all out- software before) or screen reader software, but had put capabilities in SUE: Braille, speech, and magni- different levels of experience in software development fication. These are represented by both virtual and in general (on Windows and Linux) and in project physical devices: a Braille display and a Braille moni- management. In order to gain insight into both of the tor, magnification, and speech output (text-to-speech). new fields, a community of open source / accessibil- Application support – both for the requested applica- ity / screen reader experts was brought together in a tions and a few small other ones – had to be updated workshop. and extended in some parts and newly created in oth- ers. 3.2 A Clear Goal and a Goal-pursuing Today, SUE’s base called AccessEngine is this en- visioned platform for assistive applications and the Strategy screen reader SUE is the first of them; others are cer- tainly possible. In general, the AccessEngine pro- After the workshop, the project team retreated to eval- vides an event-based information processing to any uating and interpreting this gathering, unifying its re- input and output devices connected to it. It takes care sults with their project description while going into of all data and device management tasks including re- further research where necessary, into requirements ceiving information from the accessibility interface analysis and project specification. This behavior has (AT-SPI, part of Gnome Accessibility project4) and been criticized by the above-mentioned community as delivering it to the proper recipients. they did not feel involved into the decision-making process. They expected a more bazaar-like project or- Both the AccessEngine and SUE are published 5 ganization (many contributors loosely organized via under BSD license , so anyone may either support our the Internet) whereas the project team – coming from work, develop their own open source screen reader closed source software development – adopted the based on SUE or develop another open source assis- cathedral style (code developed by small group and tive application based on the AccessEngine. One idea released to the public) (Raymond, 1999). This ap- may be to integrate it into an AAL scenario by turning proach seemed natural to the project team as they the TV into an easy-to-use in-home information basis were funded by the Ministry as opposed to the group with speech output and sound icons. 6http://www.wikihow.com/Have-a-Successful-Open- Source-Project 4http://projects.gnome.org/accessibility/ 7http://beradrian.wordpress.com/2009/05/12/success- 5http://www.opensource.org/licenses/bsd-license.php in-open-source/ 526 AN OPEN SOURCE SCREEN READER FOR BLIND AND VISUALLY IMPAIRED PEOPLE - Experiences and Thoughts of volunteers spending their free time on open source titude of tools for open source software development: projects. Unfortunately, this misconception signif- web hosting, forums, blogs, mailing lists, trackers for icantly harmed the parties’ trust into one another, bugs, feature requests, and patches, code control sys- which for the remainder of the project did not recover. tems like SVN, Bazaar, Git, a file release system, Meanwhile with respect to their project descrip- project, content and task management tools, a wiki tion the development team made decisions for their and more. SourceForge.net is well-established among development, defined a road map and milestones for OSS developers and only requires one registration for their work and dove into screen reader development all activities within one or more projects. All infor- preparing first releases. When in doubt, the project mation at SourceForge.net is provided in English in description was used as a reference. At different order not to limit ourselves to German contributions, stages during the project it differed from the com- but to find as many users as possible. munity’s opinion. However, it was decided to rely upon the official project description while at the same 3.4 Sustainability time respecting the community’s interests and wishes as much as possible.