Open Bug 1591848 Opened 1 year ago Updated 5 months ago

Permanent search icon in front of megabar has no tooltip/accessibility label and no keyboard functionality

Categories

(Firefox :: Address Bar, defect, P3)

defect
Points:
3

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: access, blocked-ux, Whiteboard: [access-s2])

Just for something new and different 😒, we have a new toolbar button - the permanent search icon introduced in bug 1589836 - which has no tooltip/accessibility label and cannot be reached nor activated via the keyboard (space/enter when focused). I realise this is unfinished, but I'm filing this now because otherwise it's likely to be missed.

  1. Put role="button" on #urlbar-search-icon. As well as exposing the correct accessibility role, that will make it reachable with toolbar keyboard navigation.
  2. Support activation with space/enter. I don't know how this thing handles mouse clicks, but it doesn't seem to respond to click (which the toolbar key nav code fires by default), so it'll need to support keypress itself.
  3. Give it a tooltip with tooltiptext or an accessibility label with aria-label. A tooltip is more ideal because it makes the purpose clear to users who might not use screen readers but might (for whatever reason) have trouble determining the purpose of the icon. Unless the icon already contains text?

Bug 1590374 is tracking the tooltip. The rest depends on the finalized design we are waiting for.

Depends on: 1590374
Priority: -- → P3

(In reply to James Teh [:Jamie] from comment #0)

Just for something new and different 😒, we have a new toolbar button - the permanent search icon introduced in bug 1589836 - which has no tooltip/accessibility label and cannot be reached nor activated via the keyboard (space/enter when focused).

Clicking the icon currently does the same as Accel+K. Verdi is also considering letting the icon do nothing except for focusing the address bar. Either way it seems redundant to expose it as a button to accessibility software. But as mak said, nothing is set in stone yet as we're waiting for the final UX specification.

Blocks: 1589836
Keywords: regressionblocked-ux
No longer regressed by: 1589836

(In reply to Dão Gottwald [::dao] from comment #2)

(In reply to James Teh [:Jamie] from comment #0)
Clicking the icon currently does the same as Accel+K. Verdi is also considering letting the icon do nothing except for focusing the address bar. Either way it seems redundant to expose it as a button to accessibility software.

I understand the thinking here. It can be argued, though, that the button is no more redundant for keyboard users than it is visually. That is, as I understand it, this is about discoverability. Sure, you can press control+k, but maybe you don't know about that shortcut? In contrast, once you learn toolbar keyboard navigation (and yes, I know that isn't discoverable in itself, but it's one paradigm to learn instead of many), now this function is just as discoverable to a keyboard/screen reader user as it is to anyone else.

As you say, though, let's wait to see what the final UX spec is.

Points: --- → 3

Updating the Accessibility Team's impact assessment to conform with the new triage guidelines. See https://wiki.mozilla.org/Accessibility/Triage for descriptions of these whiteboard flags.

Whiteboard: [access-p1] → [access-s2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.