Last Comment Bug 158757 - Make type ahead find work with button and image labels
: Make type ahead find work with button and image labels
Status: NEW
: helpwanted
Product: Toolkit
Classification: Components
Component: Find Toolbar (show other bugs)
: Trunk
: All All
: P5 normal with 31 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 174040 175765 182407 183718 206468 234566 250037 253586 265716 282949 345436 373743 385203 399678 420791 447622 466285 580821 778644 (view as bug list)
Depends on:
Blocks: 271540 orca isearch
  Show dependency treegraph
 
Reported: 2002-07-22 21:43 PDT by Aaron Leventhal
Modified: 2016-04-14 07:21 PDT (History)
41 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
First cut on zaplet to turn buttons into typeaheadfinable anchors (684 bytes, text/plain)
2002-10-29 09:52 PST, Amit Kumar
no flags Details

Description Aaron Leventhal 2002-07-22 21:43:28 PDT
Right now type ahead find does not find text in button labels or in alt/title
for images. It would be really useful if it did.

When a match was found in an image that is a link, the tooltip would pop up, and
the part of the tooltip that matches would be highlighted, just like the
selection is.

It would make this easier if these 2 bugs were fixed:
bug 97223 - show tooltips as user tabs around
bug 25537 - alt tags not shown as tooltips
Comment 1 Tim Powell 2002-08-23 14:36:19 PDT
I think it'd be cool if link typeaheadfind would just highlight the image link
based on the alt text. This would work particularly well for those sites that
use links that are images with text in them, assuming they have similar alt text.

I hope that bug 25537 is always wontfix. Alt text is almost never appropriate as
a title tooltip (and vice versus). I can see the point that it might be somewhat
mysterious to have an image match for no apparent reason. Perhaps in this one
particular case it would make sense to show the alt text as something like a
tooltip. I'd suggest something more distinctive than a tooltip, such as
temporarily replacing the image with the alt text with the match highlighted, or
constructing a tooltip-like box aligned with the image's top and left position
that shows the alt text. Having a distinctive box would make it clearer that it
isn't the title being displayed.

Note that images and buttons aren't the only items that need this time of match:
a similar thing applies to matching alt text in image maps (area tag), objects,
and applets.
Comment 2 Aaron Leventhal 2002-08-23 14:44:02 PDT
Do you have any examples where the alt text makes a poor tooltip, because they
did not intend it to be a tooltip?
Comment 3 Marius Kotsbak 2002-09-14 00:29:34 PDT
This also could be useful for form fields, using the name/id of it. The focus
should be placed on the field when it is used.
Comment 4 Aaron Leventhal 2002-09-14 00:33:31 PDT
That won't work, because the name/id of formfields are often nonsensical to the
end user. A lot of people would be confused if the seach went to a form field
and some garbage popped up.

The <label> element is what's used to tie text to form fields.
Comment 5 Marius Kotsbak 2002-09-14 00:43:58 PDT
What about having a little tooltip-like label with the alt-name, or a number
above every image with a link, form field and buttons, that is always shown? I
have seen that be done for all links too in a voice navigation system for IE
(from philips I think), and it wasn't that annoying.

At least there should be a nubmered label on the imagelinks that doesn't have a
alt or label-tag (and I think there are many of them on popular sites).
Comment 6 Aaron Leventhal 2002-10-12 11:19:21 PDT
*** Bug 174040 has been marked as a duplicate of this bug. ***
Comment 7 Aaron Leventhal 2002-10-21 10:51:04 PDT
*** Bug 175765 has been marked as a duplicate of this bug. ***
Comment 8 Amit Kumar 2002-10-29 09:52:43 PST
Created attachment 104512 [details]
First cut on zaplet to turn buttons into typeaheadfinable anchors

(posting as per suggestion by aaron. quoting from mail sent to him:)

{using typeaheadfind to search button text}

anyways, i found one sneaky way around this problem: create a zaplet 
that (a) hides the buttons, and (b) creates anchors hrefs that simply 
click the hidden buttons as their 'onclick' action. now, all you need 
to do is map a keystroke to this zaplet, and presto! you can use 
typeaheadfind to click these buttons through the newly created 
anchors! (know of a good way to do this? i just gave up and made that 
zaplet my homepage, and mapped f8 to 'browser:home')

the attached zaplet works for *named* forms etc. still need to work 
on unnamed forms. just remove the whitespace (including newlines) and make the
javascript your homepage. inspired by the excellent zaplets at:
http://www.squarefree.com/bookmarklets/

this works like a charm on yahoo!mail. reading mail, f8, type 'delete', press
enter... shwwweeeet :-)
Comment 9 R.K.Aa. 2002-11-27 22:48:15 PST
*** Bug 182407 has been marked as a duplicate of this bug. ***
Comment 10 Owen Marshall (Not reading bugmail) 2002-12-05 08:57:01 PST
*** Bug 183718 has been marked as a duplicate of this bug. ***
Comment 11 Joshua Goldberg 2003-02-28 16:04:24 PST
I'm agnostic about the issues discussed with alt tags, but I think there would
be no drawbacks to having type-ahead find work with simple, text-labelled
buttons (highlighting the text appropriately in that case would be nice.)
Comment 12 simulationszeitalter 2003-03-17 09:37:12 PST
I would really like to be able to rotate through input elements such as buttons
as well using typeahead find. 
Maybe an optional modifier could be used in order to achieve this, like the
slash modifier for plaintext within the document.
Comment 13 Aaron Leventhal 2003-05-20 14:31:40 PDT
*** Bug 206468 has been marked as a duplicate of this bug. ***
Comment 14 jsp 2003-07-17 08:16:52 PDT
I almost submitted a dup on this.  I have an app that writes javascripted
anchors (like those generated by Amit's zaplet), but I want to move to using
buttons instead, in part for reasons of accessibility.  I've barely begun and I
already miss the easy keyboard navigation.  I can search for any text, but there
are more spurious matches, and matches on buttons don't cause the button to get
focus.

I think it's most important to deal with text buttons, in part because it seems
straightforward compared to image inputs.  If a design for image inputs can be
agreed upon and implemented without dragging the process out, that would be
fine, but it would be a pity to slow the introduction of a usability enhancement
that benefits sites with accessible designs in order to accommodate sites with
less accessible designs.  (Yes, I'm asserting that image buttons decrease
accessibility.)

This may be a slippery slope.  One could make the case that what's really needed
is navigation to any element that has a text label and a notion of
activation/focus.  I think this would include all labeled inputs, selects, etc,
as well as anchors and buttons.  I don't have an opinion as to whether this is a
good idea; I mention it for completeness.
Comment 15 Aaron Leventhal 2003-07-17 09:55:36 PDT
This is not a trivial bug to fix. I won't have time for this in the forseeable
future.
Comment 16 Jesse Ruderman 2004-02-15 13:51:33 PST
See also bug 234363, "Find skips alt text (of broken images)".
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2004-02-16 16:21:16 PST
*** Bug 234566 has been marked as a duplicate of this bug. ***
Comment 18 Philip Hoyt 2004-05-27 06:17:27 PDT
Internet Explorer 5 for Mac already does this for alt text in image, but
apparently not for form elements.
Comment 19 Aaron Leventhal 2004-07-06 10:37:17 PDT
*** Bug 250037 has been marked as a duplicate of this bug. ***
Comment 20 Bogdan Stroe 2004-07-30 14:39:21 PDT
*** Bug 253586 has been marked as a duplicate of this bug. ***
Comment 21 Aaron Leventhal 2004-10-23 04:38:41 PDT
*** Bug 265716 has been marked as a duplicate of this bug. ***
Comment 22 Aaron Leventhal 2005-02-20 14:18:19 PST
*** Bug 282949 has been marked as a duplicate of this bug. ***
Comment 23 prestowk 2005-08-14 18:27:15 PDT
Users waiting for this to be fixed might want to have a look at the Hit-a-hint
(http://hah.mozdev.org/) extension.  It allows selecting in addition to links,
also buttons, images and other elements by keyboard.
Comment 24 Jesse Ruderman 2006-07-21 16:15:59 PDT
*** Bug 345436 has been marked as a duplicate of this bug. ***
Comment 25 Jesse Ruderman 2007-06-20 12:28:45 PDT
*** Bug 385203 has been marked as a duplicate of this bug. ***
Comment 26 [:Aleksej] 2007-07-24 11:34:17 PDT
*** Bug 373743 has been marked as a duplicate of this bug. ***
Comment 27 hhaamu 2007-09-16 09:47:28 PDT
In case this ever gets implemented: it should ignore the image alt for links with images *and* textual content.

i.e.:
<a href="#"><img src="icon.png" alt="icon"/>some text</a> /* ignore img */
<a href="#"><img src="navbar_links.png" alt="links"/></a> /* good */

This might not be so critical to users with the startlinksonly option set to false.
Comment 28 Phil Ringnalda (:philor) 2007-10-12 22:40:19 PDT
*** Bug 399678 has been marked as a duplicate of this bug. ***
Comment 29 Jesse Ruderman 2008-03-03 16:21:24 PST
*** Bug 420791 has been marked as a duplicate of this bug. ***
Comment 30 Joanmarie Diggs 2008-03-03 17:58:43 PST
Given the number of dups, this is arguably a desired feature.  And it would greatly benefit users with visual impairments.

I realize that the focus right now is on the upcoming release, but after the FF3 dust settles, any chance that this could be bumped up in priority for the minor release that follows?  Thanks in advance for the consideration!!
Comment 31 Jesse Ruderman 2008-07-23 13:37:58 PDT
*** Bug 447622 has been marked as a duplicate of this bug. ***
Comment 32 Jesse Ruderman 2008-11-22 19:57:07 PST
*** Bug 466285 has been marked as a duplicate of this bug. ***
Comment 33 Kevin Brosnan 2010-07-21 16:38:43 PDT
*** Bug 580821 has been marked as a duplicate of this bug. ***
Comment 34 Adam 2010-07-21 22:07:50 PDT
Seems like they'll have to wait till the dust settles on FF4 soon... heh.
Comment 35 Bruno 'Aqualon' Escherl 2010-12-07 05:41:30 PST
Can still see this in Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101207 Firefox/4.0b8pre and Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101205 Firefox/4.0b8pre SeaMonkey/2.1b2pre

=> Moving to Toolkit
Comment 36 Jo Hermans 2012-07-30 04:01:32 PDT
*** Bug 778644 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.