938830 - toggle show/hide sidebar with keyboard is very difficult

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Design, defect)

Description

[Isac Lagerblad (:icaaq)]

1. When beta mode is activated, Press Cmd+N to open a new browser window, then type https://developer.mozilla.org/en-US/docs/Web/API/Node in the address bar and press Enter.
2. Make sure that the sidebar is hidden
3. tab your way to the "Show sidebar" link and press enter.
4. tab once more, see that the focus is located nearby in this article.

To hide the sidebar you have to tab all the way thru the #wiki-content area.

5. tab your way to the "Hide sidebar" link and press enter.
6. tab once more see that the focus is located at "these licenses"
7. tab once back and see that the focus is located at the first link in the #wiki-content area.

The toggle should be located in one place and only toggle show/hide.

This is very difficult for sighted keyboard users, and IMHO impossible to use for screenreader users.

Comment 1

[RottinRob]

I was looking at this bug, I had the thought that this could be easily rectified with a hotkey implementation like '^S' or something very simple. Any opinions?

Comment 2

[Stephanie Hobson [:shobson]]

Hotkeys are not very discoverable, before we add an enhancement like that I would like to just create behaviour that works the way the user expects.

Comment 3

[RottinRob]

(In reply to Stephanie Hobson [:shobson] from comment #2)
> Hotkeys are not very discoverable, before we add an enhancement like that I
> would like to just create behaviour that works the way the user expects.

Did you have a specific idea, or are you basically saying to utilize what is already built in, just implemented differently or in another manner?

Comment 4

[Stephanie Hobson [:shobson]]

I think the expected interaction here would be for the link which toggles the side bar open/closed to retain the focus throughout the interaction and for it to not move around in the document as it is toggled.

This is based on what I expect the user's mental model of the document would be, which is different from the actual document structure.

Looking at the source itself I see that there isn't one link, but two. The hide link is at the bottom and only visible when the sidebar is showing and the show link is at the top and only visible when the sidebar is hidden. 

A potential solution here, and I'd want to run it past :icaaq and do some user testing on it before deciding it's the right solution, would be:

- both links become capable of hiding and showing the side bar
- we don't show both links but at all times both are capable of receiving keyboard focus, and will come into view when they do
- when a link is activated, the focus stays on the link that was activated
- we probably also need to re-label the buttons or include some off screen helper text

As a side note, the link at the top of the page should be an anchor link to the quicklinks menu that functions with javascript disabled, and the one at the bottom should be a button, not a link. And we need some aria-controls and aria-expanded attributes on there.

I think this would fix the current interaction problems and make it easier for keyboard and screen reader users to navigate, but it's not the only way to fix it though, I'm open to others that would work with the user's mental model of the document.

Rob, are you interested in submitting a pull request for this bug?

Comment 5

[RottinRob]

(In reply to Stephanie Hobson [:shobson] from comment #4)
> I think the expected interaction here would be for the link which toggles
> the side bar open/closed to retain the focus throughout the interaction and
> for it to not move around in the document as it is toggled.
> 
> This is based on what I expect the user's mental model of the document would
> be, which is different from the actual document structure.
> 
> Looking at the source itself I see that there isn't one link, but two. The
> hide link is at the bottom and only visible when the sidebar is showing and
> the show link is at the top and only visible when the sidebar is hidden. 
> 
> A potential solution here, and I'd want to run it past :icaaq and do some
> user testing on it before deciding it's the right solution, would be:
> 
> - both links become capable of hiding and showing the side bar
> - we don't show both links but at all times both are capable of receiving
> keyboard focus, and will come into view when they do
> - when a link is activated, the focus stays on the link that was activated
> - we probably also need to re-label the buttons or include some off screen
> helper text
> 
> As a side note, the link at the top of the page should be an anchor link to
> the quicklinks menu that functions with javascript disabled, and the one at
> the bottom should be a button, not a link. And we need some aria-controls
> and aria-expanded attributes on there.
> 
> I think this would fix the current interaction problems and make it easier
> for keyboard and screen reader users to navigate, but it's not the only way
> to fix it though, I'm open to others that would work with the user's mental
> model of the document.
> 
> Rob, are you interested in submitting a pull request for this bug?

Ok...I better understand the situation now and do see your line of thought. I like the idea of the button being both open and close...makes it kinda brainless! That and quick relabel on needed items. That sounds like a good route. Sure, I can submit a pull. Did you say you had another person to consult?

Comment 6

[Stephanie Hobson [:shobson]]

Isac: does what I outlined in comment 4 seem like a good solution to you?

Comment 7

[Isac Lagerblad (:icaaq)]

@shobson: it sounds like a good idea!

Comment 8

[Stephanie Hobson [:shobson]]

I'm considering just removing this feature all together. Isac, does it provide any value I should try to preserve in another way (for example: skipping content) or is it just causing confusion?

Comment 9

[Isac Lagerblad (:icaaq)]

@shobson: I think that's a great idea!

Comment 10

[Stephanie Hobson [:shobson]]

Solved by removing the feature in bug 1235075.