W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > May 2013

RE: Command line / text application language

From: David MacDonald <david100@sympatico.ca>
Date: Wed, 8 May 2013 11:06:35 -0400
Message-ID: <BLU0-SMTP767D0DEAC2C388ADCAB09AFEBB0@phx.gbl>
To: 'Loďc Martínez Normand' <loic@fi.upm.es>, "'Peter Korn'" <peter.korn@oracle.com>
CC: <public-wcag2ict-tf@w3.org>, "'Jason White'" <jason@jasonjgw.net>, "'Loretta Guarino Reid'" <lorettaguarino@google.com>, "Janina Sajka" <janina@rednote.net>
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

 <http://www.can-adapt.com/> 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.
Received on Wednesday, 8 May 2013 15:07:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:56:23 UTC