1286211 - Correct the markup for the Search button in the top right-hand box

Status: RESOLVED DUPLICATE of bug 1871596

(Firefox :: Search, defect, P3)

Description

[Marco Zehe (:MarcoZ)]

Spun off bug 1279665 comment #24, which is quoted in part below:

> (In reply to :Gijs Kruitbosch from comment #22)
> > (In reply to alexander :surkov from comment #21)
> > > apparently I was looking at another search button, which is a child of
> > > search autocomplete. Just to be clear the accessible tree, I was looking at,
> > > is:
> > > autocomplete
> > >   graphic ('magnifying glass' button, 'search' name)
> > >   entry (for textbox)
> > >   combobox_list (for popup)
> > >   pushbutton search ('arrow' button, 'serach' name)
> > > 
> > > that probably yet one more bug.
> > 
> > "that" is what, in this context?
> 
> 'magnifying loop with green plus sign' image inside the searchbox is a
> button semantically, but it is exposed as a graphic role (image).
So the markup should be corrected to make this an actual button instead of just an image.

Comment 1

[Stephanie Cunnane [:scunnane]]

This bug deals with the legacy search bar. We need to distinguish whether this bug deals with the add search engine button or the arrow (go) button. This bug likely refers to the green plus sign that appears over a search engine icon allowing it to be added by the user.

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: Hidden-from-VoiceOver-button.png

It appears to be that the part of the bug that still applies to the current search bar experience is the -> arrow that is only shown when the search input is focused - this control shows a tooltip when hovered with a mouse Go to the address in the location bar, but it has no role and it cannot be accessed even with a screen reader in browse mode (which should be able to access and announce everything on the screen).

While the experience is not blocked for a keyboard-only user, because they still can press Enter to submit their search input, but since the sighted keyboard users and sighted screen reader users (i.e. those with low vision, dyslexia, or cognitive difficulties) would still see this control without being able to access it, it is still an access-s3 bug.

Comment 3

[Mark Banner (:standard8)]

(In reply to Anna Yeddi [:ayeddi] from comment #2)

Created attachment 9360474 [details]
Hidden-from-VoiceOver-button.png

Hi Anna, thank you for the information, however this bug is for the separate search bar which can be displayed via the customize options, or in the Search preferences.

Should we have a different bug for the address bar? (or maybe there is already one?)

Comment 4

[Anna Yeddi [:ayeddi]]

Attachment: Fixed-Search-bar-Go-image-button.png

(In reply to Mark Banner (:standard8) from comment #3)

(In reply to Anna Yeddi [:ayeddi] from comment #2)

Created attachment 9360474 [details]
Hidden-from-VoiceOver-button.png

Hi Anna, thank you for the information, however this bug is for the separate search bar which can be displayed via the customize options, or in the Search preferences.

Should we have a different bug for the address bar? (or maybe there is already one?)

Apologies for the delay in actually replying here, Mark!

It looks like both the URL bar (bug 1864962) and the Search Bar (bug 1871596) -> Go buttons were inaccessible - they were marked up as static images. But the URL Bar button was fixed in it's own bug and the issue reported here was fixed in the bug 1871596, I think, we could close this bug (as a dupe of 1871596, maybe?) - please refer to the screenshot of the Search bar's Go button with it's (expected) accessibility information from today's Nightly 123.0a1 attached.

Note: we still do not want this button to be focusable with keyboard (neither with Tab nor with arrow key nav within the search bar) since keyboard-only users could simply press Enter to perform the same action and we do not want to increase the number of keyboard tab stops for a redundant functionality. At the same time, in the current implementation assistive technology would still be able to access the control and send a click event to it, i.e. with voice control

Comment 5

[Mark Banner (:standard8)]

Thank you for the response, I agree, lets close this out as a duplicate.