[Rt-devel] RT Firefox and Orca screen reader

[Jesse Vincent]

On Jul 14, 2008, at 3:21 AM, bart at bunting.net.au wrote:

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

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 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.
> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>