Re: [orca-list] braille presentation of links

[Michael Whapples <mwhapples aim com>]

Your suggestions I think are good, but I have a couple of questions,
which you may be able to answer.

You say about the way to indicate a control, now I am not sure about GTK
(or windows as you were describing it based on outspoken for windows),
but as I understand it in java accessibility, a custom control could be
given its own role so making it a non-standard accessible control. How
might the system you describe support such a possibility? Or does this
not really exist in GTK and so might not be necessary in the main.

How would blinking cursors be, may be different rates for the different
types (IE. mouse could be much slower than actual cursor), although I am
not so sure about mouse cursor in the context of GTK accessibility as
part of the idea is that you shouldn't need the mouse if accessibility
is correct. The other reason I wonder about the mouse cursor and if it
is needed, is that when using a braille display is it needed to know the
mouse cursor, as cursor routing keys could relate to left/right click at
that point.

I agree that the braille system needs a more general look at for
improving output.

Michael Whapples
On Mon, 2008-04-28 at 10:50 +1000, Jan and Bertil Smark Nilsson wrote:
> Greetings,
>
> Mike Pedersen wrote:
> > Currently in firefox we put the word link after a hyper link In my 
> > opinion this will be a real problem when trying to show links in 
> > editable documents where layout and formatting are much more important.
>
> > We are currently adding the ability to use combinations of dots 7 and 8
> > to underline hyperlink text.  This feature will be user-configurable.
> > You will be able to choose none, dot 7, dot8, or both.
>
> That sounds like a good idea to me. However, I think that the whole 
> attribute area should be addressed.
>
> Some time ago, on one of the lists, I wrote about my experience with 
> Outspoken for Windows and what a good job Peter Korn and his then 
> colleagues had done with regard to braille presentation. Thus, I'd like 
> to put forward the following suggestions for discussion:
>
> Names of graphics are shown between special brackets which open with 
> dots 12378, and close with dots 45678. Between these special brackets 
> the name assigned to that graphic symbol is given.
>
> An end of Line indicator is shown on the braille display at the end of 
> each actual line of text or graphics, corresponding to the layout on the 
> screen. A new line could be indicated by dots 13478.
>
> Symbols such as buttons, check boxes, and combo boxes are enclosed in 
> special brackets. Each type of control has its own letter code that 
> indicates whether it is a button, radio button, check box, etc. This 
> one- or two-character code is shown just inside the opening bracket that 
> indicates a control. The beginning of a control is indicated with dots 
> 2378. Just after this is the letter code that indicates which type of 
> control the brackets enclose. The letter codes are underscored with dots 
> 7 and 8 to indicate that they are part of the bracket, rather than part 
> of the control's contents. A suggested list of these codes follows. The 
> end of a control is indicated with dots 5678.
>
> Letter codes:
>
> b - button
> x - check Box
> db - default button 
> r - radio bbutton
> s - scroll bar.
>  
> Indicators for text Fonts and Attributes could be assigned to 
> highlighted text, underlined text, bold text and 
> italics. Such text could be enclosed in brackets. 
>
> Highlighted text - dots 23678...35678
> Underlined text - dots 238...567
> bold text - dots 68...37,
> italics - dots 568...237, etc.
>
> It would also be useful to have different representations for cursor and 
> mouse pointer. For instance, the mouse pointer could be represented by 
> dot 8.
>
> If these brackets could be user defined, clashes with the different 
> braille tables could be avoided.
>
> Other interesting features would be to be able to monitor areas on the 
> screen which are not in focus and to provide various types of 
> information through the status cells. However, this is enough for now. 
>
> Sorry I was so long in responding.
>
> Regards,
>
> Bertil