Re: Command line / text application language

Hi, David:


I'm in agreement with Peter, and open to an expansion of the statement
about scripting he proposes. To my mind it's a detail among many details
that could turn our few paragraphs into a book, were we to expand fully.
I'm sure we don't want to do that, but I do believe it appropriate to
make the edit Peter suggests.

I also question the use of JAWS to achieve access to 3270 terminals. Do
we know your colleague exhausted available options? Or, was JAWS simply
the environment he was familiar with and then managed to build
reasonably good access for it.

Specifically, I would want to examine the free 3270 emulators IBM
provides:

http://linux.softpedia.com/get/Terminals/IBM-3270-Terminal-Applications-Suite-28373.shtml

It strikes me that a native character environment is a far more likely
candidate for access to another character environment.

In other words, did your friend consider using IBM's C3270 (above URI)
and found it wanting? Or, was he unfamiliar with Speakup, Emacspeak,
and/or Brltty?

The above is just a quick grep through available 3270 emulators on
Linux. There are more.

I would certainly want to know these kinds of answers before
entertaining hosting scripts.

Janina

Peter Korn writes:
> 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
> >
> >**
> >
> >*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

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

Received on Wednesday, 8 May 2013 18:24:57 UTC