adde accessability

2.11: web,sci.adde/blind assist/what jaws can work with:

sci.adde/blind assist,
web.adde/blind assist/mac's accessability framework

founder of Technologies for the Visually Impaired
talks about switching to mac
says (not exactly fun) but mac is unfairly condemned by
September 2005 issue of Access World
. the store he found includes brail displays,
so in this case, a simple gui or tui could be useful .

Introduction to Accessibility Overview

Don’t override built-in keyboard shortcuts. (listed in the Apple Human Interface Guidelines
appendix “Keyboard Shortcuts Quick Reference”)
and to the accessibility-related keyboard shortcuts
(listed in “Accessibility Keyboard Shortcuts”).

This chapter introduces the accessibility protocol. It describes:
The model that represents accessible applications to assistive technologies
The accessibility object that represents user interface objects
Some of the ways an assistive application interacts with an accessible application
If you’re an application developer, you should read this chapter
to learn about the Mac OS X accessibility protocol.
Then, if you’re ready to access-enable your application,
you should read Accessibility Programming Guidelines for Cocoa
or Accessibility Programming Guidelines for Carbon.


. for those using JAWS for Windows,
GTK/Tkinter impl's are incompatable;
need to use windows forms
as provided by WXPython (or any other WX equivalent),
or standard Windows controls,

. after looking at the output from hg's cli,
I got the idea that for the audio version
one annoyance to be avoided
is having the reader read everything on the screen .
. the pattern with tool outputs,
is that it's a record with named fields;
and you should be given a chance to customize the reading .
. it may already have things like tabbing .
. checking the mac options, they are the built-in voiceover,
so the first path is just making sure you stay voiceover-friendly .
. the next path is to have app's that are meant to be displayed in audio .
. addx uses the mvc pattern,
separating the model from the presentation,
but to make it easier on the programmer,
there had been the idea of implicit inout
where the program just had to present the data as an interface,
and then the user would choose between tui or gui .
. both of those are visual,
so I had implicit assumptions about mapping data to visuals;
ie, the standard datastructures and types
would all have visual representations .
. the primary need from an audio representation
is that all components have brief descriptive names
and then the main mode would use fieldname traversal
along with arrows, tabs, and enter to get in or out of content .
. the user's agent then has to either create or have available
the trees of fieldnames separate from the content
and must be able to serve thses names to voiceover,
or whatever reader is on the system .
. there are more options if the user can touchtype:
getting through a list, and hearing an r-word,
pressing r would stop it at the last r-word .
. otherwise, the arrow keys can still do what's needed .