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

Re: Command line / text application language

From: Peter Korn <peter.korn@oracle.com>
Date: Wed, 08 May 2013 09:34:42 -0700
Message-ID: <518A7EA2.7040606@oracle.com>
To: David MacDonald <david100@sympatico.ca>
CC: 'Loďc Martínez Normand' <loic@fi.upm.es>, public-wcag2ict-tf@w3.org, "'Jason White'" <jason@jasonjgw.net>, "'Loretta Guarino Reid'" <lorettaguarino@google.com>, Janina Sajka <janina@rednote.net>
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.


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
> **
> *Can**Adapt**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.

Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment
Received on Wednesday, 8 May 2013 16:39:20 UTC

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