Web Posted on: February 9, 1998

THE CASE FOR INDEPENDENT SCREEN ACCESS

PETER DIAMOND
CEO DOLPHIN COMPUTER ACCESS
PDIAMOND@CLEAR.NET.NZ

This paper details the strategy and key principles that have led to the development by Dolphin of screen access software for Windows NT and Windows 95.

Introduction

My company, Dolphin Computer Access, has been designing, manufacturing and distributing screen access software and related products since 1986.

Four years ago Dolphin took on the task of planning our research and development program for a post-DOS market. At the time we were faced with Windows 3 and an early beta of Windows NT. After much discussion and experimentation we decided to go for Windows NT as this, or something very similar, seemed to be the operating system that we were most likely to have to deal with in the future.

Other than the belief that we were looking at the future of PC operating systems, the main technical factor was the 32-bit pre-emptive multitasking environment which seemed extremely well suited to serious access software development. Our software could be written to run alongside applications and the operating system without recourse to quick fixes and somewhat dirty non-standard code.

I must admit that at this point I was not popular with our engineers amongst others and it did seem an impossible task. However, after the first year the development team had planned a solution that would work with the rapidly expanding number of non-standard interfaces appearing in Windows applications. The last three years have been spent successfully implementing that solution, with some time out in the middle to provide solutions for Windows 95.

Hal, our screen access software, was designed to be easily and quickly adapted for what is an ever changing software application market. This was tested recently with the new releases of Office 97, WordPerfect and Internet Explorer 4. It took our engineers little effort to get these applications talking and accessible, demonstrating to us that our independence from the operating system, or any other third party, allowed us the necessary rapid response time our clients should expect. Hindsight is a wonderful thing and on looking back at the decision to make NT accessible I think we got lucky. At the time NT had no access facilities whatsoever so everything we did had to be totally independent of and compliant with the operating system.

As a company we are more than happy to discuss the technical strategies we have employed in the development of our access software, anyone who is interested need only ask. In addition I hope that over time the market (and for 'market' read 'PC users') will soon let us know as to the usefulness or not of what we have done. I firmly believe, just like any other free market, that this is the way it should be.

However, the purpose of this paper is to put forward our views regarding visually impaired users as a significant niche market in the wider PC world. We believe there are extremely important issues that are not technical in nature, rather they are fundamentally influenced by how and why access is achieved.

The DOS Market - Healthy and Competitive

By the time Windows had become the operating system found on new PC's, confidence in our DOS based market was high and growing. There were many companies both large and small offering screen access solutions of many different varieties. Feature and price wars were rife among the growing number of manufacturers, competition was alive and kicking and, most importantly, the user had choice. I feel that the support infrastructure in terms of dealers and trainers was also growing to meet the increasing demand.

To digress slightly I am always reminded of one user in particular, although I am sure her story was not an uncommon one. She had been both young enough and lucky enough to have been exposed to PC's throughout her secondary and vocational education which coupled with her enthusiasm took her a long way. She applied for a job in telesales with a division of an household name in microprocessors, the one 'inside' everything. The job entailed selling highly technical training and familiarization courses over the phone and relied heavily on concurrent use of a DOS based PC terminal connected to the company's network. Her prospective employer was doubtful about the whole thing to say the least, so she suggested that she turn up the next day with her screen access software and synthesiser and have a crack at running the system. She did just that. He was blown away along with his doubt and any thoughts of token employment. She got the job, by herself on her terms.

I guess this taught me that equality of access in employment had a lot more to do with equality of opportunity to compete with the other sighted applicants rather than the technical issues I so often find myself embroiled in. Our job was to provide the tools to facilitate that equality of opportunity.

What has this to do with DOS? Well, in this instance our products did the job well but in other circumstances one of the many other products then available in the DOS market may have been just as appropriate. The key issue here is that there were lots of other diverse products available and they were all getting easier to use, more transparent, more efficient and cheaper every year. If technical access problems arose it was highly likely someone would come up with a solution. I do not think this is currently the case.

Since Windows has replaced DOS we have seen job opportunities for our clients diminish rapidly along with confidence and funding. Our industry has shrunk which deeply affects us all. I do not think that we as an industry should lose sight of how much had been achieved under DOS or forget those hard won goals no matter how tough the engineering problems we face are.

The Pros and Cons of Microsoft Active Accessibility

When Microsoft first made us aware of MSAA we took it very seriously, spending considerable time going through what was given to us. This resulted in a comprehensive report that was fed back to Microsoft. I have to say it seemed only to contain a long list of MSAA functions that we could not see working reliably or consistently. Nevertheless, we still had thoughts of including MSAA support and felt that it would prove to be a worthwhile addition to our access software. Like many others we were disappointed at the lack of response we got from Microsoft at the time and it seemed we were really going down very different tracks with radically different agendas. Over the past two years we have had the time to give MSAA and its ramifications far more considered thought which has shaped the views that follow.

In theory the thought of in-built access in the industry's most prolific operating systems is a most tempting one. The sheer size and power of Microsoft seems all consuming so perhaps with such a successful company working for screen access our problems should be over. They do all the basic work and ensure that third party application developers conform to MSAA standards. Screen reader developers would all get the same platform to work from thus ensuring continuity of diverse development of product just like the good old DOS days. It sounds like a great way forward, maybe inevitable, but is it really the answer to GUI access?

As I have already stated, our engineers have had grave misgivings regarding the ability of MSAA to overcome what we saw as inherent ambiguity and complexity in the system. I do not want to drown in technicalities but would suggest that anyone who wants details contact us directly, but have regard to our position regarding the non-disclosure agreement we signed as a pre-requisite to MSAA involvement.

Next on my list of concerns is where did the idea for MSAA spring from? Maybe I missed something, certainly it wouldn't be the first time. Surely if it came from anywhere it should have been driven by the existing access industry as a whole which I do not believe it was. In comparable niche market computer industries I believe the manufactures themselves have got together to agree common standards and systems for the benefit of the companies concerned and their clients who, after all, ultimately pay the bills. These standards have then been put to the operating system suppliers for registration as standards and inclusion in the system.

As I mentioned previously, during the DOS period we saw a healthy growth of support infrastructure for access software through local dealers and trainers across the world. Other than the obvious benefits this provided users it also provided useful self start employment for many visually impaired people and, far less obvious, it provided a strong developing structure for user feedback. I would suggest that if Microsoft ended up as the only supplier of access technology then all these healthy and useful benefits would be lost and I do not see proposals for their replacement. We are already getting to the point where many users are put off complaining (just like the bad old days, be grateful for what you're given!) just in case it's all there is.

My next problem lies with the probability that the effectiveness of an MSAA powered screen reader will be determined by four factors:

1. How well MSAA is implemented in the application software.
2. How well MSAA is implemented in the screen reader.
3. How effective Active Accessibility actually proves to be.
4. The absolute necessity to ensure that the operating system, application and screen reader all contain the same appropriate version of MSAA.

I don't think you need to be a computer programmer to see that this is probably asking a lot of reality; the phrase 'all your eggs in one basket' spring to mind. The poor screen reader developer has no control whatsoever over points 1, 3 and 4 and who does the user choose to call if it doesn't work. This seems to me like the last thing a blind user needs, a large amount of complicated logistics and uncertainty to tackle before they even get started using the computer.

My final concern relates to existing application software. I am led to believe the General Manager of the Office Product Unit at Microsoft has pointed out that there are many applications that have been developed over many years that are now huge and not all that pretty when viewed from the inside. Successfully implementing MSAA into mature and complex products may not be practical from an engineering point of view. Many products that can be changed may not see an MSAA compliant implementation until well into the next millennium. Software applications are like pop songs, you are only as good as your latest release and lets face it release follows release ad infinitum. With so much to co-ordinate to achieve access through MSAA I fear that blind users would yet again find themselves behind and out of sync with their sighted counterparts which would inevitably lead to marginalization from the mainstream.

Conclusion

Do I have all the answers?, certainly not. To paraphrase someone much wiser than myself 'answers are relatively easy, the key is to establish and ask the right questions'. Whatever the way forward I feel it must be inclusive of as many access software manufacturers as possible which will hopefully ensure that as much as possible of the blind market throughout the world is given the opportunity to feed their views, complaints and success's into the system.

I'll end this paper with a list of suggestions for Microsoft which people may or may not find useful, at the end of the day Dolphin is just one of many companies in the industry. At least it's a start in a direction that is both alternative and additional to MSAA. I appreciate others have also been through this process and would respectfully ask this list to be considered as an addition to the work that has gone before.

Microsoft could use their position to:

• Ensure that all Windows compliant application software has comprehensive keyboard access in addition to any other input methods.
• Ensure that all Windows compliant application software conforms to the Windows Interface Guidelines, at least in those areas such as the current application focus that screen access depends upon.
• Go through their own application software with the above two points in mind. In particular I would draw attention to multimedia reference applications which have so much unique potential for blind people from education and home use to those in professions.
• Actively encourage accessible programming standards amongst third party and in-house application program developers. I think the latter is very important for blind employees and job applicants as so often these are large state organisations or corporate companies.
• Actively aid access software developers through funding or discounting of development tools and training.
• Place access software developers high on the priority list for beta releases of operating systems with particular attention paid to those areas of change that may affect screen access. Be inclusive of all access software manufacturers before making development decisions that may affect screen access.
• Be active in helping the software access industry to produce its own engineering standards and guidelines.

Thanks for taking the time to listen to or read this offering.