Check accessibility on Top Sites
Categories
(Firefox :: Address Bar, task, P2)
Tracking
()
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: access)
We should involve the a11y team to ensure that the new Urlbar Top Sites feature is fully accessible.
Reporter | ||
Comment 1•5 years ago
|
||
Jamie, we're now showing Top Sites in the Urlbar when the user focuses it. openViewOnFocus goes hand-in-hand with this feature. Other than bug 1608766 (which is in the process of landing) would you say the a11y on this feature is acceptable?
Comment 2•5 years ago
|
||
I think it's acceptable, though playing with it, I have a couple of questions:
- If the address bar is empty but collapsed, pressing down arrow expands the autocomplete, but does not select the first item. This means the user has to press down arrow twice to get to the first item in this case. If I press down arrow, I expect to select a suggestion, not just open the suggestions. This issue probably existed before address bar top sites, but it'll potentially get more use now. It's particularly jarring when combined with (2).
- openViewOnFocus triggers when you focus the address bar via alt+d/control+l, but it doesn't trigger when you open a new tab with control+t. Opening a new tab isn't quite the same as explicitly focusing the address bar, but it effectively does this and I wonder if this might seem inconsistent. Is this deliberate? I don't really have a strong opinion either way; it's just something I noticed.
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to James Teh [:Jamie] from comment #2)
- If the address bar is empty but collapsed, pressing down arrow expands the autocomplete, but does not select the first item. This means the user has to press down arrow twice to get to the first item in this case.
Verdi, what do you think of this? Are you open to having down arrow select the first result when the view is closed?
- openViewOnFocus triggers when you focus the address bar via alt+d/control+l, but it doesn't trigger when you open a new tab with control+t. [...] Is this deliberate?
Yes. Top Sites are already shown on about:newtab and so automatically opening the UrlbarView containing Top Sites would add visual noise to the page. The inconsistency is unfortunate, but I don't think it's the right choice for the UX on about:newtab. Plus it would obscure work done by Activity Stream/User Journey. Verdi, feel free to weigh in on this one too if you have thoughts.
Comment 4•5 years ago
|
||
(In reply to Harry Twyford [:harry] from comment #3)
Verdi, what do you think of this? Are you open to having down arrow select the first result when the view is closed?
Yes! This makes a lot of sense.
- openViewOnFocus triggers when you focus the address bar via alt+d/control+l, but it doesn't trigger when you open a new tab with control+t. [...] Is this deliberate?
Yes. Top Sites are already shown on about:newtab and so automatically opening the UrlbarView containing Top Sites would add visual noise to the page. The inconsistency is unfortunate, but I don't think it's the right choice for the UX on about:newtab. Plus it would obscure work done by Activity Stream/User Journey. Verdi, feel free to weigh in on this one too if you have thoughts.
Originally you couldn't open the top sites view at all over the new tab page. We added that because it seems valuable and doesn't interfere with the page but I don't think we should do that automatically for all of the reasons Harry stated.
Comment 5•5 years ago
|
||
(In reply to Verdi [:verdi] Best to slack me from comment #4)
(In reply to Harry Twyford [:harry] from comment #3)
Verdi, what do you think of this? Are you open to having down arrow select the first result when the view is closed?
Yes! This makes a lot of sense.
Note that the first entry for TopSites (empty search) has no relation with the default action, if we preselect the first entry, the input field will be filled with the first entry url. Currently you can open the panel with down, look at top sites, if there's not what you were looking for you can run a search. This won't be possible anymore.
Comment 6•5 years ago
|
||
And by that I mean that if you don't have a search shortcut in your top sites, searching from the urlbar will be much harder if we preselect the first entry, because you'll have to clear the full url to be able to search.
Comment 7•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #5)
Currently you can open the panel with down, look at top sites, if there's not what you were looking for you can run a search.
(In reply to Marco Bonardo [:mak] from comment #6)
And by that I mean that if you don't have a search shortcut in your top sites, searching from the urlbar will be much harder if we preselect the first entry, because you'll have to clear the full url to be able to search.
- How likely is it that someone would open the panel, then realise that's not what they wanted and do a search? Opening the panel seems like a pretty deliberate action to choose from the panel.
- Note that from this state, pressing escape twice or pressing control+k will allow the user to perform a search. Arguably, that isn't intuitive, but I'm not convinced pressing down arrow and expecting it not to select something is particularly intuitive either.
Comment 8•5 years ago
|
||
(In reply to James Teh [:Jamie] from comment #7)
- Note that from this state, pressing escape twice or pressing control+k will allow the user to perform a search. Arguably, that isn't intuitive, but I'm not convinced pressing down arrow and expecting it not to select something is particularly intuitive either.
None of those is discoverable though, the most obvious thing left to the user is to delete the url that we forcibly put into the input field. And this is made worse by the lack of one-off buttons.
I filed bug 1615222 to better evaluate the change, considered it may have impact on search, we'll also have to go through PM.
That is not a blocker issue though, right? Can we get your official sign-off that accessibility on TopSites is good enough to ship the feature, and thus resolve this bug?
Comment 9•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #8)
(In reply to James Teh [:Jamie] from comment #7)
- Note that from this state, pressing escape twice or pressing control+k will allow the user to perform a search. Arguably, that isn't intuitive, but I'm not convinced pressing down arrow and expecting it not to select something is particularly intuitive either.
None of those is discoverable though, the most obvious thing left to the user is to delete the url that we forcibly put into the input field. And this is made worse by the lack of one-off buttons.
I filed bug 1615222 to better evaluate the change, considered it may have impact on search, we'll also have to go through PM.That is not a blocker issue though, right?
It shouldn't be. It's not even an accessibility issue in the narrow sense, it's more of a general UX question. Let's continue in bug 1615222 and close this.
Comment 10•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #8)
That is not a blocker issue though, right?
No.
Can we get your official sign-off that accessibility on TopSites is good enough to ship the feature, and thus resolve this bug?
Yes. :)
(In reply to Dão Gottwald [::dao] from comment #9)
It shouldn't be. It's not even an accessibility issue in the narrow sense,
I disagree. A screen reader user will find this more confusing than most because when they press down arrow, they'll hear "expanded", but no item will get reported. It's not clear that the list appeared but just has nothing selected. That said, it's not a blocker because it's probably unlikely many users will actually try this after opening a new tab, given that top sites are shown on the new tab page anyway.
Description
•