GNOME Bugzilla – Bug 512222
title properties in link tags in ff3 not being announced
Last modified: 2008-02-14 13:22:50 UTC
Please describe the problem: title properties in link tags in ff3 not being announced. For accessibility reasons, we should present the title property text. <a href='http://diveintoaccessibility.org/day_14_adding_titles_to_links.html' title='a page to describe title properties.'>nondescript</a> Apparently the title property is presented as a tool tip text? I can see issues there. Can we differentiate between reading a link as part of larger object and reading a link because it has the current focus? If we avoid presenting the tool tip when we are reading paragraph/list/whatever, then wen we actually give focus to the link (user tabbed across) then present the title. This behavior would emulate the standard user interaction. alternatively we should always present the info if present. regarding presentation format: <screentext>: <titletext> Steps to reproduce: 1. visit http://www.mozilla.org/projects/minefield/ the links are not presenting their title texts. Actual results: Expected results: Does this happen every time? yes Other information:
Jon, I agree that it would be nice to present the title information and also that there are issues. Because it's a "nice to have" I'm changing this from a bug to an enhancement. Because there are issues, we need our UI guy to spec out the desired user interaction. Mike, please spec. <smile> Thanks!
Just as a note. I'll be out for meetings for the next several days so probably won't get to this one until early next week. Joanie if you want to work on implementing this earlier please give me a call and perhaps we can talk about what the desired behavior should be.
Jon, Mike, now that I'm getting my head above water w.r.t. line navigation again, I took a look at this bug and a couple of things dawned on me: 1. We already make this information available via basic whereAmI: If you Tab to a link that has title properties and press KP_Enter, if there's a title it will be spoken after the basic link information. 2. As a sighted user, when I tab among such links the tooltips don't appear. I can force them to appear by hovering the mouse over them. So I'm not sure if always presenting the info if present is standard user interaction or not. In addition, every once in a while I'll hover the mouse over a link and get the Great American Novel in return. Thus I'm not sure if always presenting the info if present is a desirable user interaction or not. But that's why I'm not the UI guy. <smile> Regardless: If Firefox were to follow the example set by Gtk apps, pressing Control+F1 would cause the tooltip to appear. When tooltips appear as a result of the user causing them to appear via keyboard, we automatically speak them. There is an existing FF bug requesting they implement this functionality: https://bugzilla.mozilla.org/show_bug.cgi?id=367364 which we are tracking with bug 481815. So: Given that we already present them when the user asks for that information via whereAmI and given that we'll automatically present them when they are made to appear via keyboard (once FF fixes that bug), what shall I do w.r.t. this bug? Thanks!
I'm OK with closing this one as "won't fix" if you want.
ok, I'm fine with that too, I'll check that the firefox page does inform the users if they need the tool-tip text, then just ask where am I. Thanks
(In reply to comment #5) > I'll check that the firefox page does inform the > users if they need the tool-tip text, then just ask where am I. Thanks Jon!! Okay, closing this out as WONTFIX.