Capturing text

In my previous posts, I have focused primarily on issues which affect me as a visually impaired user who does not actually use a screen reader, because it is simply not possible to do so.  Without considerable amounts of scripting, even some of the most basic functions of Studio are not readily available to  a screen reader.  As I have said before, a company in the UK has been attempting to script JAWS for Studio 2011 for 18 months on and off without success.  Some of the problems are related to issues I have discussed in other posts, but as far as I understand it, there are far more fundamental issues  that prevent screen readers from capturing text cleanly.  I have only limited knowledge of what these problems are, but I understand them as follows:

  • Many elements of the Studio interface appear to be custom controls. Screen readers are generally very good at reading  elements in standard controls,, but have to resort to  methods such as scraping text  between boundaries  given by screen coordinates  or background colors. Apparently, this has proved to be necessary in the editor  in particular. Left to their own devices, all the screen readers I have tried attempt to read the editor from left to right across the screen, i.e. the first line of the source text  followed by the percentage match  (first line only) followed by the first line of the target text and then by any segment type information (p, H, TAG, etc.).
    An attempt to read the next line may or may not read the second line of the source segment followed by the second line of the target segment. Some screen readers will read only the source, others only the target and others nothing whatsoever.
    The Freedom Scientific script language provides several methods of  scraping text from the screen, and recent  additions to the script language  have provided better results in some of the tests that I did a few months ago.  Nevertheless, these tests were not reliable, particularly because methods which scrape the text from the screen are unable to pick up lines which overflow the bottom of the screen.
  • Because the focus and the insertion point are not necessarily at the expected position when a function is performed (this is discussed in another post), screen readers have difficulty tracking where they should begin to read text.
  • Control elements in dialog boxes have not been provided with accessible text to allow a screen reader to announce  the meaning of, for instance, a text box (a basic minimum for accessibility).

I shall attempt to obtain more detailed technical information  in the coming weeks.