Re: [orca-list] Position of state vs. label for checkboxes (wasRe:progress of progress bars is not reported., is it a known thing?)

[Michael Whapples <mwhapples aim com>]

Halim you really don't seem to have understood me. I will put the comments in the message below which hopefully will explain it further, and if this fails to get through then I will just take the view it probably will never.
On Mon, 2007-05-07 at 21:44 +0200, Halim Sahin wrote:
> Hello,
>
> On Mo, Mai 07, 2007 at 08:06:52 +0100, Michael Whapples wrote:
> > What you describe would not fall into the category of what a screen reader 
> > should be trying to do. 
>
> Who is deciding that?
Nobody decided, it just came to be, its a limitation of the output systems we have to use currently that means if a screen reader doesn't do what I said it will certainly be working against things. See comments below which hopefully explain the limitation of our output systems.

> I would have said that a screen reader is to 
> > optimise the output for its user, whereas what you describe sounds more 
> > like an alternative display output, in this case onto a braille display 
> > (like brltty does in a text console, presenting exactly what is on the 
> > screen and providing minimal tracking to put the braille display on what is 
> > of interest eg. a highlight). 
To expand on this, in a text console, output for everyone is made up of characters of fixed size and width, and a braille display likewise has fixed sized characters (cells) in fixed positions. In the standard text console configured with 25 lines containing 80 columns, on an 80 cell braille display we can show any given line (provided the characters on the screen could be given by eight bits if necessary), and we can just move our viewable braille line up and down those 25 lines to gather exactly what is on the screen. This is what I think you are asking for in a GUI, but the GUI is much more complicated than that. Hopefully if I have done this right, there will be two lines which follow, same number of characters on the line, but different font sizes, so that one finishes before the other, by using any screen reader of your choice, only using speech or braille output, tell me what percentage of the first line is compared to the second.
Sample text
Sample text

If this proves impossible, then this proves the point I will make below, and this is a basic example, GUIs can get even more complicated on their layout. As an example we could mention maths, visually it is spaced out 2 dimensionally, and the only braille like access to that spatial information is with dots plus, but can you present dots plus on a braille display? NO.

> As I described brltty does this in a text 
> > console with no problems, but text consoles are much easier to do than a 
> > GUI (as the text console is character based like a braille display), where 
> > as a GUI allows so much more, including text which could be anywhere (not 
> > just in the fixed columns and rows grid) and then non-text items. Basically 
> > you are calling for a non-character based output to be mapped to a 
> > character based device, you will never get an exact match of layout.
>
> Orca is not the first graphical screenreader!!!
What a stupid suggestion, of course I am aware of all the other screen readers, if you had paid attention, I have made comments of others, and even sometimes replied to messages when I have been using windows (so the outlook express original message way of marking the original text has been showing).
> Some things were implemented before you know?
They've tried, but perfect presentation of the layout has never been achieved, name me one screen reader which does (refering to GUIs). 
> You are voting for a screenreader that is perhaps useful 
> to do something with but Nobody of its users are able to talk with 
> other about their system because the blind user is not able to get 
> enough info to describe his own environment.
What I am asking for is that the user should have representations of what is on the screen not an exact presentation of the screen (see comments above for why I think an exact presentation isn't possible, it would require new output systems to be developed eg. a refreshable tactile graphic tablet (which I think may have been looked at experimentally but I am unaware of one hitting the main market)). This representation may not be how it is on the screen, but it should contain enough information that you could communicate your experience (you as the user would be expected to know what the representation means, which you already need to, check boxes in windows don't always contain an X when checked, they visually contain a tick, but you know what that <x> means on your braille display, don't you?).

There again may be its you who isn't understood, thinking back through, first you seemed to be asking for output in the form
<x> checkbox's text
rather than 
checkbox's text <x>
which I understand, making things more usable, but then you seemed to go on to say, if a developer gives the text for the checkbox to the left, then we should have it in the form 
checkbox's text <x> 
Why? I thought you said you didn't want that. Make up your mind.
> Ok.
>
> Halim
> PS.
> Why are you writing to the list using the cc adress??
> I was replying and that is how evolution did it when I chose reply to list, I was just too lazy to change it.