RT Firefox and Orca screen reader

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: Bug 542771 – [blocked] Orca loops on pages which use onfocus="this.blur();" 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:

X

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.
:frowning:

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: 422981 - [a11y] better/different handling needed for onfocus blur

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.

Hi all,

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: Bug 542771 – [blocked] Orca loops on pages which use onfocus="this.blur();"
for this issue. Unfortunantly the response I have got is that it
is a web design issue.

Usually, that sort of response form the developer of a custom browser
add-on causes me to immediately discount the author’s opinion. But I
think she’s right.

If you remove the offending line from share/html/Widgets/
TitleBoxStart, does everything work right?

I am blind and use screenreaders to access RT.

Are you aware of the CLI RT client? I am not saying you should use that,
but you could give it a try. Maybe it does what you want and it is definately
less ‘cluttered’ (from a screen-reader’s POV) than the web front-end.

Richard

Hey Bart,

I committed a fix for the focus issue this morning to 3.8 trunk, which
means it should make it into the 3.8.1 release. I tested it with Orca
in Firefox and it seems to work.

In the meantime, if you remove the onfocus attribute as Jesse suggested,
that should fix the problem in your current RT. It will, however, have
the side effect of a visually ugly focus box for any of your sighted users.

Hope that helps!

Cheers,
Thomas

Jesse, Thomas,

Thanks so much for your extremely quick response.

Patching 3.6 works very well. I haven’t had a chance to try a 3.8 installation as yet.

I very much appreciate you guys taking accessibility issues seriously.

Regards

Bart

Thomas Sibley writes:

Jesse, Thomas,

Thanks so much for your extremely quick response.

Patching 3.6 works very well. I haven’t had a chance to try a 3.8
installation as yet.

I very much appreciate you guys taking accessibility issues seriously.

Accessibility matters. Thanks for bringing it up with us. The fix
should be in RT 3.8.1. We have some other small issues to work out for
the 3.8.1 release, but I’d hope to see it within a month.

-j