RE: Command line / text application language

Hi Peter and David

The proposal has just gone out on survey. I had seen David's email just prior to finalising the survey, but I too thought that the prosed changes/additions might be handled as survey omments to be discussed during the meeting.

Best regards

Mike

From: Peter Korn [mailto:peter.korn@oracle.com]
Sent: 08 May 2013 17:35
To: David MacDonald
Cc: 'Loïc Martínez Normand'; public-wcag2ict-tf@w3.org; 'Jason White'; 'Loretta Guarino Reid'; Janina Sajka
Subject: Re: Command line / text application language

Hi David,

Assuming we put this out to survey (perhaps later today?) I hope we can capture this and any other comments from the TF there, and then discuss it at our Friday meeting.


Personally I see a significant difference between screen access products developed explicitly for the text/command-line environment, and those developed for the GUI which provide less focused / enhanced access to the text contents of terminal applications.  I believe that the JAWS scripts that Glen is referring to are developed for JAWS for Windows, not the older (and no longer sold) JAWS for DOS.

The fact that the GUI (whether the "WIMP" GUI or the "touch" GUI of iOS/Android/BlackBerry) now makes up the preponderance of computing user interfaces doesn't change both the important history of text-based access, nor the fact that text-based screen readers remain in active development and use (a point Jason made to me last week).  At such time as we move to voice-only (or voice-preponderance) interfaces, our GUI-based AT may likewise fall into more limited use.  And yet we would like WCAG to continue to apply there (if possible).


I'm not opposed to addressing the point you raise; I would more suggest language along the lines of "AT that provides to text applications through a terminal application may require custom scripting", since that is the situation here.  Running BRLTTY (or emacspeak or Speakup) on the host, independent of the terminal applications, generally remains an option.  I leave it to Jason/Janina to speak to any such use they may have made in that configuration.


Peter

On 5/8/2013 8:06 AM, David MacDonald wrote:
I think we have to take into account the comments submitted by Glen (below), my blind programming colleague  ... for instance, the sentence.

"Assistive technologies developed alongside text applications, and several of these use a variety of analysis and scripting techniques"

I think we need to acknowledge that *custom* scripting was often necessary... adding to the last paragraph something like:

"in some cases custom scripting is necessary, which can be expensive."

I also think we should consider providing Glen's JAWS script for terminal applications as a resource, in the same way we provide links to other resources such as the colour contrast tool.

Cheers
David MacDonald

CanAdapt Solutions Inc.
  Adapting the web to all users
            Including those with disabilities
www.Can-Adapt.com<http://www.can-adapt.com/>

Many of the terminals (VT50, VT52, VT100) displayed the newest data at the bottom of the screen with the older data scrolling off the top.
This was a challenge for screen readers as it was always difficult to know what new data should be spoken. Out of the box screen readers tended to either just speak the newest bottom line, or speak the entire screen.
I played with scripting Jaws to handle this type of terminal by keeping a buffer of the previous screen and saying only the differences.
Control characters embedded in the text plus the challenge of what to do if more than an entire screen's worth of data was scrolled were difficulties.
I worked on this for sometime, but my interest was taken over by 3270 emulation.

3270 terminal emulation presents an entire screen worth of data once an option is picked or fields are filled in.
These screens are usually 24 lines by 80 column displays.
(Some less common displays have 132 characters across, the size of the traditional printed line).
You can use the tab key to move through multiple fields on a single screen filling in data before the enter key is hit.
Usually field labels are associated with the fields you are filling in.
Once enter is hit, an entire new screen's worth of data is displayed.
This is commonly known as a full screen terminal.

Screen readers out of the box tended to read out entire screen's worth of data and would read nothing as a screen was traversed using the tab key.
An additional challenge for screen readers was that they tended to work upon a Window object. Usually the entire 24 by 80 character display was a single Window object.  This made any "automatic" feedback from a screen reader (based on Windo objects) not very useful.

Because I work my entire career using 3270 emulation I wrote Jaws scripts which did analysis of the big character blob to give useful feedback.
- When a tab key is hit once the cursor moves to the next field, an an analysis is caried out to determine the field label. This is done by checking the attributes of the characters around the input field to attempt to determine what is a reasonable label for that field.
- Once enter is hit, similar logic is applied once the updated screen is returned so that only the field where the cursor lands is used to determine the label to say rather than reading the entire screen.
- Other logic is in place to ignore line numbers,, indicate when particular columns are traversed (many programming languages use columns for special purposes).
- Other features were added to make the full screen experience more productive.
- I made all of this customizable by the users so that they could use their own preferences.
- Finally I tried to make the scripts generic enough so that they would work with any 3270 emulator program, not just the one I was using.

The key to these scripts is trapping of keystrokes and massive amounts of character string analysis to determine what would be most useful to hear in a given situation based on that key stroke.
Another difficulty is the varied amount of time that it takes when the enter key is hit for the screen to be refreshed.

The situation I have worked on occasionally over the years, but still haven't fully conquered to my satisfaction is data which is presented in tabular form.
IE. a row of headers with data arranged in columns under those headers.

I distributed (and continue to distribute) these scrips for free to anyone who finds them useful in their work lives.
I don't really know how many people are using my scripts but I estimate in the mid 90's there were probably 30 to 40 people around the world using them.

Even today I get 4 or 5 emails a year letting me know they are using my scripts and asking for help with installation problems etc.
I have had people who use the scripts volunteer to help with documentation and installation instructions.

I hope this has answered your questions, hopefully it wasn't too much info.

--
[cid:image001.gif@01CE4C15.41EBA6F0]<http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522<tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
[cid:image002.gif@01CE4C15.41EBA6F0]<http://www.oracle.com/commitment>Oracle is committed to developing practices and products that help protect the environment