secondary quickfilter modification bar: Implement tab stop and/or keyboard accelerators for filter buttons (sender, recipients, subject, body currently inaccessible)



8 years ago
2 years ago


(Reporter: Thomas D., Unassigned)


({access, regression})

access, regression
Bug Flags:
wanted-thunderbird +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [workaround: Addon, comment 5])



8 years ago
+++ This bug was initially created as a clone of Bug #538738 +++


1 quickfilter bar: enter search terms
-> secondar filter modification bar appears
2 try changing filter criteria like sender, recipients etc. using keyboard only


- no in-place keyboard accessibility
- no other way of accessing the underlying commands via keyboard (we haven't included these in any menu, which might be a bug, from a canonical pov)
-> secondary filter functions are not keyboard accessible, at all


- any function of the UI must have a way of keyboard access; normally, it should be in-place keyboard access right there in the relevant UI (otherwise in menus, or customizable buttons, dropdowns etc).

Possible solutions: a), b), or both

a) add a single tab stop to sender botton on secondary filter bar; other buttons via cursor right/left as its like a set of options to choose from (for an easy start, let's ignore tag buttons on secondary filter bar when tag filter is on); having low number of tab stops is desirable so that user can move focus fast-track (for very fast, we have F6).
<tab> is the master key for moving focuss between sections of the UI, it's simple and intuitive as you do not have to remember or focus on anything: just tab'n cursor until focus arrives where you want it

b) add access keys to secondary filter buttons:
for en-US, I propose (please double-check if these are used by any other element, like customizable toolbar elements etc.):

sender: alt+s
recipient: alt+r
subject: alt+u
body: alt+b

The obvious benefit of access keys is that they provide a fast and direct way of pressing an individual button.
The disadvantage compared to just jusing tab and cursor is that you have to look very closely and concentrate to get the right access key, whereas with tab you just go on without thinking until focus arrives where you want it

[ftr: we do NOT want shortcut keys (like Ctrl+...) for these buttons (not relevant enough)]

IMO, both a) and b) should be implemented.

Which one would be easier and faster to do?
a) tab sequence might need further thought
b) access keys require L10n attention as strings on the buttons differ (but no L10n changes involved, i think)

We should implement at least *one* way of keyboard access before shipping 3.1.
It's bad practice to introduce new UI elements that are totally inaccessible via keyboard (where totally really means nowhere in the whole UI). It's also a regression from Tb2, where you could at least use alt+cursor down, then cursors to select a set of filter criteria from the dropdown.

We can deal with tab stops in a separate bug if necessary. I propose that this bug primarily focusses on keyboard accelerators, but whatever helps to get this started asap is fine with me.


8 years ago
Severity: enhancement → normal
status-thunderbird3.1: --- → ?
status-thunderbird3.1: ? → ---
Flags: wanted-thunderbird+

Comment 1

7 years ago
Quick Filter criteria are completely inaccessible for keyboard users -> major
Severity: normal → major


7 years ago
Flags: in-testsuite?


7 years ago
Duplicate of this bug: 652776

Comment 3

6 years ago
ping? (feedback on comment 0 welcome)

A big part of one of our most important UI functions (Quick Filter) is still completely inaccessible for keyboard users...
Version: 3.1 → Trunk

Comment 4

6 years ago
This is still completely inaccessible via keyboard. Several groups of handicapped people have for the past two years been completely unable to use mail filtering via quick filters due to this and there is no comparable workaround available. Can we please raise a priority on this?

Comment 5

5 years ago
the current quick filter bar is strange UI, implemented in seemingly the most complex way possible.

i've made it into a toolbar (with consequent expected behavior and added full keyboard access).

Comment 6

5 years ago
(In reply to alta88 from comment #5)
> the current quick filter bar is strange UI, implemented in seemingly the
> most complex way possible.

That sounds typical, like some other familiar corners of Thunderbird ;)

> i've made it into a toolbar (with consequent expected behavior and added
> full keyboard access).

Wow, that's impressive, well done. Definitely going the right direction.

OT: I like accessability & customizability of the addon, that's great.
Some problems / potential enhancements:
1) Like 1st reviewer, I don't like the UX of tags & criteria choices expanding on the toolbar itself, forcing user into delicate scrolling to reach those hidden things -> dropdowns, floating bars, or even temporary horizontal toolbars would be better (pls have a look at Bug 570815, attachment 460747 [details] for some ideas and related discussion).
2) After 1), your toolbar could be less wide, so it should fit above message list (instead of across both msg list & folder list)
3) Combined customization with main toolbar has advantages, but disadvantage is that if I want icons only for the filter bar, I'll be forced to have icons only for main toolbar too. Don't know if we could have the best of both worlds.
4) Bug: focus "Sticky filter" button with keyboard tab, then press space to push it (ok); tab to "Unread", push Space again -> "Sticky Filter" is gone (wrong). 

I suppose I'm entitled to hijack my own bug for this ;)


5 years ago
Whiteboard: [workaround: Addon, comment 5]
I am using the Unified Search add-on which also adds keyboard shortcuts to most (all?) quick filter bar functions:

Comment 8

5 years ago
(In reply to Thomas D. from comment #6)
> I suppose I'm entitled to hijack my own bug for this ;)

you certainly are, thanks for the feedback.  but if you post the issues to the forum, i'll address them there so others who care can see them.
You need to log in before you can comment on or make changes to this bug.