Hope all readers in the US had a nice thanksgiving.  I wanted to share a recent encounter I had with software that was inaccessible.  I was recently interested in turning my Macbook Pro into a multi-platform machine so I could easily move back and fourth between operating systems.  The benefits are pretty obvious I think.  For this purpose I took a look at Virtual Box which is an open source virtual machine program.  The install process went flawlessly on the mac, but when it came to running the program, Voiceover was unable to read any of the text or controls.  Apparently the culprit is the fact that they are using a GUI library known as QT.  The benefits of QT is that it is cross-platform, but on the other hand it does not use native controls of the operating system.  Thus, most screen readers have trouble working with programs that use this GUI, at least out of the box.  Someone on the Windows side was able to get some QT applications working through use of a Window-Eyes script.  I’ll be talking more about scripting as it relates to screen readers in a future post, since I think the subject could actually be quite relevant to this project.  This script essentially makes use of Microsoft Active Accessibility to make all of the controls readable when reviewing them with the keyboard.  I’m not sure if there is anything equivalent to MSAA on the mac.  If there is, getting these types of programs to work on the mac would be a great project.  In the mean time, looks like I will be looking into Fusion for my multi-platform needs.

I’m sure I don’t have to remind any readers of this blog that there are many considerations to make when first developing software.  It can be difficult to design so called idiot-proof software, and software that can adapt to the user from the most novice computer user to the greatest software engineers.  If there is a wide variety of users that you are targeting with your software package, trying to balance a friendly user interface can be a challenge.  There are also considerations to make when it comes to accessibility.  Not only should the final product be accessible and screen reader friendly, but the software development process is another consideration.  It is important that this development process be accessible to any programmer that might be blind or visually impaired.

Typically the software design phase is a very visual phase.  Actually, visual tools often come into the picture much earlier than that (yes there was a pun intended).  So how does a person who does not benefit from wonderful tools such as UML diagrams deal with this challenge?  This is actually quite pertinent to the computer science course I am taking right now.  In this course we are essentially developing a software product in one full semester, starting with the requirements phase and continuing all the way through the implementation phase which is what we’re doing now.  Our solution to date has not been all that creative.  That is, I deal with the visual aspects of development by, well, not dealing with them.  While there are a number of visual aspects, there are also parts of the development that are not so visual, and my responsibilities were primarily to focus on the non-visual aspects.  For example, I might work on writing a use case description document for our software, while someone else in the group draws the corresponding diagrams that accompany the descriptions I wrote.  The professor I have for this course has also not focused as much on UML as I originally thought she would.  There was only one question on our midterm that required us to draw a UML diagram, and she allowed me to describe the diagram rather than draw it.  So even though I may not be drawing diagrams, that doesn’t mean that I’m not responsible for knowing how each diagram is used and how to describe one.  I may not be describing it in terms of triangles, boxes, arrows etc. but I am still describing it.  I thought this was a reasonable modification for a few reasons.  First I am exposed to the uses that UML has and I still have the knowledge of how to communicate what I want.  Second, if I had to draw a diagram I’m pretty sure I would fail quite miserably at it.  You might be thinking that the whole purpose of a graphical language such as UML is so we don’t have to describe things in words.  After all, who wants to read about the design of a class for a program in a 10-page document that covers every class component in agonizing detail?  The reader will surely be comatose before the third paragraph.  This is probably why I will not be given the task of drawing up UML diagrams any time soon.  Communication through diagrams is quicker in general, but I contend that there is more than one way to skin the cat.  I think the reason visual tools such as those that we have in the software development cycle are so popular because so many people are visual learners.  I could be way off target in saying that so I hope I don’t get too many readers offended.  I don’t believe that a fundamental property of the software development cycle is that it is visual.  I think we make it that way because most people think it is more convenient and yes, it is probably more efficient in some ways.  This may be a case where accessible UML creation software comes into play (I don’t know of any UML software that is usable with a screen reader to date).  When it comes to me interpreting diagrams this is a bit of a different issue.  Since I am not a visual learner I think I’d rather read a description of a software design rather than try to get someone to describe a diagram to me.  For me, words have more meaning in a context such as this than diagrams do.  I will concede however, that I have never been involved in a major software development process before, and the software projects I have worked on thus far have been relatively small.  Therefor, it’s quite possible that I simply haven’t yet realized the full benefit of these visual tools.

I should apologize for the lack of a good blogging schedule.  Truthfully, I’ve been a bit busier than I would like to be and it makes it hard to find the time not just for blogging, but to get the amount of research done that I intended.  I’ve had grandiose plans for writing python scripts for the mac as I mentioned in a previous post and some other cool things.  This hasn’t happened yet, mostly because I haven’t found a whole lot of documentation on the subject.  I found plenty of tutorials on learning apple script which at least for the time being doesn’t interest me that much.  My original request for a how-to on writing scripts for the mac still remains.  A document that has an emphasis on VoiceOver would be even better.  Could I be so lucky?

Anyway, since I’ve essentially been learning two languages this semester I thought I’d describe some of the work that is involved in learning a programming language from a blindness prospective.  We are obviously using python for this particular project, but I am also learning C++ in the CS course I am taking this semester.  For me, learning language syntax is one of the easier tasks.  I think I share the sentiments of many others that once you know 1 language it makes it easier to continue to another because thankfully, the structures are very similar in all languages.  I suppose the tricky part is making sure I have the necessary resources to start exploring the given language.  This usually consists of documentation of some kind.  Unfortunately the selection of pre-recorded texts is limited, and brailled texts are even more rare to come by.  If there is a required textbook say, for a class, the publisher in question will usually release an electronic version of the book as long as one has purchased a hard copy of the book.  This process of releasing an electronic version can take a few weeks while your request is processed, so it’s a good rout to take if you know in advance what is needed.  This is why it is helpful to obtain the names of textbooks as early as possible.  Anyway I digress.  In a lot of ways I think having electronic versions of the text is more convenient than say, an audio recording of the same text.  This is because I’m usually at my computer when I’m looking at programming documentation and I use it as a reference.  A pdf version makes it easy to look up syntax quickly and then I can simply switch back and forth between the textbook and my work environment.  It is relatively easy to switch between windows on a computer logistically speaking, so it is not uncommon that I have 10 or 15 windows opened at a time, particularly when I’m writing a program.  I suppose this can be compared to someone sighted who might keep a python reference guide on their desk opened to the relevant page while they type.  By the way, I’m assuming sighted people actually do this; I wouldn’t know for sure, and I don’t want to sound too presumptuous.

The other part of this discussion that deserves attention is text editors.  When I first started writing simple programs I really preferred editing with regular old notepad that comes with windows.  While it is really a no thrills solution it was good enough.  However now it is not uncommon for me to be dealing with lots of files at once. Thus, I’m learning to appreciate IDEs a bit more.  I’ve been using visual studio in windows and have started exploring x-code on the mac.  For python however, I still just use a text editor most of the time since my programs are still somewhat simple.  While notepad works fine, I’ve used notepad++ a bit too and it also seems to work reasonably well from an accessibility prospective.  One thing I noticed is that, because of the automatic syntax highlighting that notepad++ does by default, it can sometimes confuse screen reading software when trying to determine what text is selected.  Many screen readers rely on the highlight color of the text to determine what text is selected for manipulating.  This would include deleting, cutting, copying etc.  I found that it’s best to turn off syntax highlighting if you are a screen reader user.

On a closing note let me just say to Please feel free to leave comments if there are any questions; it may give me an idea of topics I should cover in future entries.