Bug 1813517 Comment 5 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

First, let me explain why the buttons: we are trying to make many of the features discoverable and usable, plus we have a lot of ideas to add value and options. We think giving more control to the user over their data and the results composition is a good thing.

Second, why change tab? We already have results with sub-buttons, like Firefox Suggest, Quick Actions, etc., that require a way to select sub widgets, or buttons inside a single result. We are also evaluating to concretize undiscoverable features like the possibility to override a switch-to-tab entry to reopen the page. All of these features require a way for the keyboard to reach the buttons, and the universal way to move through widgets and buttons is tab, everyone is already used to tab moving through buttons.
With the direction we are taking, and the will to preserve accessibility through the keyboard, it's just no more possible to support tab to move through results. DOWN/UP will continue working as usual. We know it will be annoying for some users that are used to move with TAB, we pondered a lot over that and tried to find solutions, but didn't find something good enough for discoverability and accessibility.

My suggestion, for how much it may sound disappointing, is to get used to up/down, because:
* even if you can disable the buttons now, after we release the feature, the pref will go away
* you may hide things with CSS, but the number of things to hide will just grow with time, making it even more annoying

Of course, we're open listening to ideas, but "other means to reach the button" must be an industry standard, not a custom made up solution.
First, let me explain why the buttons: we are trying to make many of the features discoverable and usable, plus we have a lot of ideas to add value and options. We think giving more control to the user over their data and the results composition is a good thing.

Second, why change tab? We already have results with sub-buttons, like Firefox Suggest, Quick Actions, etc., that require a way to select sub widgets, or buttons inside a single result. We are also evaluating to concretize undiscoverable features like the possibility to override a switch-to-tab entry to reopen the page. All of these features require a way for the keyboard to reach the buttons, and the universal way to move through widgets and buttons is tab, everyone is already used to tab moving through buttons.
With the direction we are taking, and the will to preserve accessibility through the keyboard, it's just no more possible to support tab to move through results. Down and up will continue working as usual. We know it will be annoying for some users that are used to move with TAB, we pondered a lot over that and tried to find solutions, but didn't find something good enough for discoverability and accessibility.

My suggestion, for how much it may sound disappointing, is to get used to down and up, because:
* even if you can disable the buttons now, after we release the feature, the pref will go away
* you may hide things with CSS, but the number of things to hide will just grow with time, making it even more annoying

Of course, we're open listening to ideas, but "other means to reach the button" must be an industry standard, not a custom made up solution.

Back to Bug 1813517 Comment 5