GNOME Bugzilla – Bug 542771
[blocked] Orca loops on pages which use onfocus="this.blur();"
Last modified: 2015-05-28 03:22:10 UTC
Please describe the problem: Request tracker is a popular web based ticketing system. When viewing the main page of rt orca loops on ticket summary tables. It appears to randomly return to the top of a table and start reading it again. It is not always happening at the same spot. Another side effect appears to be that speech is getting queued up and taking many presses of the shift key to silence. For example Steps to reproduce: 1. visit http://rt.easter-eggs.org/demos/stable/index.html 2. log in as one of the demo users. 3. Once logged in the homepage is displayed. Use the down arrow to arrow over the summary tables. You will notice that orca gets stuck on the table for example "the 10 highest priority tickets I own" table. 4. This is a demo site and the database is wiped every day. If there are no tickets in these tables on the homepage it may be necesary to create some using the new ticket in queue button. 5. Orca appears to read correctly if you use say all. Actual results: Orca loops and you are unable to read the page correctly. Expected results: Orca should allow reading of the table line by line as it does in any other html table. Does this happen every time? yes Other information:
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.
Hi Joanie. Much appreaciate the effort you put into this. This story has a happy ending. I wrote the RT development list last night and woke up to two new emails in my inbox. The first from Jessie Vinsent the original author of RT: "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?" And the answer to that is yes. And even more encouraging the second email from another of the RT developers: "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" So it's ausom to see such a quick response from and the willingness to actualy test the issue with orca itself! Well done Bestpractical team! Unfortunantly I haven't got access to a instance of rt3.8 as it's just released and we're still using 3.6 at work. I can however confirm that the fix for 3.6 works fine. Bart
Bart, that's awesome news!! Thanks for the update! It also confirms my suspicion as to why on earth people blur upon focus: As Thomas put it, "ugly focus box". Anyhoo, because the request tracker is -- make that was -- only one example (alas, of many) where this problem can be seen, I'm going to leave this bug open. That way, Orca users with a looping problem will hopefully see it and be able to determine if the same thing is causing it -- and that, if it is, a little bit of advocacy might be all that's needed.