399059 - Caret can browse only the first line of XUL <description> element contents

Status: RESOLVED WONTFIX

(Firefox :: Disability Access, defect)

Description

[Milan Zamazal]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a9pre) Gecko/2007100814 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a9pre) Gecko/2007100814 Minefield/3.0a9pre

When text in a <description> XUL element exceeds a single line and wraps in several lines, there is no (documented) way to move the caret to another line than the first one.  See the URL given above for particular example.  Note this behavior is not observable when Orca is running, because Orca uses its own arrow key bindings to move over text elements.

Reproducible: Always

Steps to Reproduce:
1. Enter the URL given above.
2. Press TAB to move to the initial text.
3. Using arrow keys, try to move over the text.
Actual Results:  
The second line is unreachable as well as the following lines.

Expected Results:  
Using the right or down arrow key the caret should be able to move to the second line and the following lines.

Comment 1

[Marco Zehe (:MarcoZ)]

Question: Is it at all desired to have caret browsing inside XUL:description elements? If yes, then this is a bug. If not, then this is not a bug, and the fact that the first line can be navigated is by accident.

Comment 2

[Milan Zamazal]

Of course it is desired, the same way as inside other text content elements (e.g. html:p).

Comment 3

[Aaron Leventhal]

Sorry, it's not desired. Let me explain why we don't need the caret to browse static text.

Dialog boxes do not work the same way that documents work. The screen reader just follows focus.

So how/when does a description get read? Each <description> must be associated with a widget, a group of widgets or the XUL window itself.

For example:
<button id="checknow">Check now</button>
<description control="checknow">Check to see if Firefox is currently the default browser</description>

When the button gets focused, the description is read.

If a description is associated with a grouping like a fieldset or radiogroup, then the description is read as the user enters that grouping.

Finally, having the caret browse static text of a dialog would make Firefox unlike every other application. That would be confusing.

Comment 4

[Joanmarie Diggs]

Hope no one minds my playing devil's advocate. :-)

1. Take a look at gtk-demo.  In particular the dialog and message boxes demo.  Press the Message Dialog button and you will get a dialog in which you can tab to each of the labels/static text and arrow amongst their characters.

2. Launch Gedit, type some text, then press Alt F4.  In the resulting dialog you can Tab to the label/static text and arrow amongst their characters.

3. Launch Thunderbird and get into the create new account wizard.  Look at all of the static text that shows up!  Imagine that you missed it the first time around.  Yes, you can switch to your screen reader's review mode, figure out where that text is in relationship to where you are, and look at it that way.  But given such a large chunk of text, it might be cool to be able to move focus there and examine it.

I'm not suggesting that this issue should be given priority over the much-needed work that is already taking place for the Firefox 3 release; merely offering reasons for not closing it out as WONTFIX. :-)

Comment 5

[Milan Zamazal]

There is some confusion here.  First, I can't see in the XUL element reference    (http://www.xulplanet.com/references/elemref/ref_description.html) nor in the    XUL tutorial (http://www.xulplanet.com/tutorials/xultu/textimage.html)    information about the necessity to associate <description> with other XUL    elements and forbidding to use it as a normal text.  Second, caret browsing    doesn't concern common dialogs at all, because <description> elements are not    focusable by default (caret browsing is enabled only for <description>s with    -moz-user-focus set to normal).  Third, my concern is not primarily about    dialogs but about XUL applications that contain texts which are either long or    difficult to read/listen to (such as acronyms or chemical equations).

In case <description> should really never be used for normal texts in XUL applications, please leave this bug open (or open new accessibility bug for the    purpose) until this is clearly documented in both the XUL reference and the XUL    tutorial so that XUL application writers would never use it that way. Otherwise very important parts of XUL applications may get inaccessible.