[gui-talk] Fwd: coding graphical user interface interface applications by programmers with no memory of vision

[Steve Pattison]

 From:    Jude DaShiell jdashiel at shellworld.net

If I understand email possibly posted on this access-l mailing list a 
report done by the Royal National Institute For The Blind correctly, 
changes to graphical user interfaces that will make it possible for those 
of us with no memory of vision to do graphical user interface programming 
will need to include two different levels of change which will complement 
each other.  First, Windows and similar systems will have to upgrade their 
command line environments and facilities for the use of those environments 
when they'll be needed.  Second, conversion software that takes as input 
console application-based source code and translates it to graphical user 
interface-based source code and writes that additional source code in a 
separate location so the original source code is preserved will also be 
needed.  If that software can also do the reverse, take in graphical user 
interface-based source code and write additional console interface-based 
source code, accessibility to windows software that may have been written 
in the graphical user interface so as to be inaccessible possibly because 
of use of proprietary controls may well suddenly become accessible.  When 
the software identifies a proprietary control, the user of the software 
gets asked to choose a standard windows control that replaces the 
proprietary control and in so doing, the console-based equivalent code 
gets appended to the console-based source code.  A user of proprietary 
software controls can then build a windows standard graphical user 
interface source code package and find out how well or poorly windows 
controls work as compared to proprietary controls too but that'll be a 
side benefit that won't effect the screen reader community immediately. 
That may effect the screen reader community eventually if that proprietary 
control performs noticeably better than comparable windows controls and 
Microsoft does a deal and adds a new control to Windows.  Now that I think 
of it, it may be adviseable to ask what set of windows standard controls 
best describes what the proprietary control does in specific order of 
operation and ask for interface narratives for each of the windows 
standard controls so that if a proprietary control does more than one 
operation and passes data to one standard control to another which the 
recieving standard control needs to use correctly, the conversion software 
will better be able to emulate the proprietary control with more than a 
single standard control if that's necessary.  I'm one of those software 
developers with no memory of vision and where I work the users aren't 
willing to touch anything where they can't click their mouse and do work 
that way.  Since mice aren't used in a console interface context because 
console interfaces are character-based not pixel-based even though I 
wasn't part of that study, it effects me.  All of that's for the future. 
How much of it gets done, time will tell.  For more immediate fixes, it's 
probably best those of us with no memory of vision doing software 
development work on console-based and command line projects and increase 
our knowledge for this work.  If we get lucky, we may find ourselves 
working on the Linux side of the industry for the rest of our lives. 
That beats unemployment handily in my book at least.  People with no 
memory of vision in the future if what I write is implemented and the 
conversion packages become available will have to study is what 
console-based code will produce what graphical user interface-based source 
code that will do a particular highly desired windows-based task.  Even 
after the graphical user interface-based source code gets compiled, those 
with memory of vision and actual vision will invariably need to check it 
out and make adjustments.  They'll be wise if they send reports to the 
software producer or producers letting them know deficiencies they have to 
continually correct.  Some deficiencies will be found because the 
translation stanzas are deficient and some because the programmer without 
a memory of vision failed to do something they ought to have done because 
they are new to the conversion software themselves; but in that way the 
software will improve and the burden on sighted people who support those 
with no memory of vision will in that way over time be lessened and our 
contributions will be more recognizeable in the future.

 From:    John Hedges jhedges at iglou.com

In touch screen environments like iPhone/Ipad and Windows 7, you have three input methods to track,
keyboard, mouse, and multi-touch or motion. I am not including voice input as it usually emulates
another method. UI work depends on your framework such as .Net Framework forms or WPF. It is
interesting to work on WPF with its lookless controls. The style or theme appearance is defined best
in a separate file. Command routing for events is not something that really translates back and
forth from custom controls or command line functions to a GNOME or WPF environment. Some Linux
toolkits are a framework layer which can be built on Windows controls, so offer some access, while
others are not and would not translate in a meaningful way by some automated conversion tool. It is
interesting to create the processing for a system without a visual UI and find it works, but sighted
users do not appreciate it so much.

John

Regards Steve
Email:  srp at internode.on.net
MSN Messenger:  internetuser383 at hotmail.com
Skype:  steve1963
Twitter:  steve9782