[Rt-devel] RT Firefox and Orca screen reader

[bart at bunting.net.au]

Hi all,

Apologies if I've sent this twic.
I am blind and use screenreaders to access RT.

I have been using jaws under windows and IE which works fairly well with RT.

I have recently switched to using Orca and Firefox under Ubuntu.

I have come across an issue with Orca, Firefox and RT which makes RT pretty much unusable for me.

Basically what happens is when I arrow down over the tables on the main page or anywhere where the "X" is used to hide and show sections Orca loops and won't read past that bit of the page.

I have opened an Orca bug: http://bugzilla.gnome.org/show_bug.cgi?id=542771 for this issue.  Unfortunantly the response I have got is that it is a web design issue.

I have included the comments below.  Would it be possible for someone who understands why/how this particular bit of RT works to comment on this?

Regards

Bart

------- Comment #1 from Joanmarie Diggs  2008-07-14 04:52 UTC -------
This is, I'm afraid, a page coding issue.  The designers of request tracker
have a bunch of instances of things like:

<a href="#" onclick="return rollup('TitleBox--_index.html------Quick ticket
creation---1');" onfocus="this.blur(); return false;" title="Toggle
visibility">X</a>

That says "This is a link, when it is given focus, take focus away from it."
(that's what this.blur() does).

Without using Orca, if I press Tab on that page, I'm constantly finding myself
back at the top. You're seeing it with the arrow keys in Orca because we have
had to implement our own caret navigation. In order to position the caret at
the beginning of the line where the offending "X" link happens to be, we use
the accessible text interface's setCaretOffset().  Setting the caret in a link
causes the link to issue a focus event.  (We actively avoid setting the caret
on a link during a SayAll.) And, like I pointed out above, when the 'X' link
gets focus it says "no" and unfocuses itself. The firefox behavior seems to be
"focus must be somewhere" so it goes back to the document frame and you loop.

I do not see any attribute exposed via the AT-SPI that indicates that there is
a blur() associated with this object, so I don't know how we could prevent it.
:-( 

When a similar issue cropped up on the United Airlines site, I filed a Firefox
bug.  Technically, this issue is not a Firefox bug; it's a web design flaw.
(What is the point of adding a focusable object to your page which unfocuses
itself upon focus???)  But I thought maybe something could be done to make the
user experience on such pages better because no user can Tab past such an
object.

The FF guys haven't closed my bug as WONTFIX, but the comments suggest that
they feel it's a web design bug, so I'm not all that hopeful.  FWIW the bug can
be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=422981

I'll keep this bug open, blocking it against the Firefox bug. But reality seems
to be that if you want this problem to go away, the request tracker guys need
to change things on their end.  I'm really sorry.