Refactor dropdowns to follow WAI recommendations

[nlhkabu]

Closes #3194, closes #2127.

@di, we now just need to add the JS, as per "approach 1" here: https://www.w3.org/WAI/tutorials/menus/flyout/

Note that our class is not called has-submenu as in the example, it's called dropdown__trigger

[di]

@nlhkabu The indentation is kinda wonky in the HTML here, maybe you're using tabs and not spaces? Could you fix it?

[nlhkabu]

Fixed @di - thanks for catching it. I think it was because I copy pasted from the WAI page :(

[lgh2]

Hi @nlhkabu ! I took a look at this one in Chrome (Version 65.0.3325.124 (Official Build) beta (64-bit)) and it seems like the bottom of one of the menus is getting chopped off when it interacts with the bottom of the page. (The dropdown menu on the top menu item looks fine.)

The same cutoff of the bottom of the menu happens in Firefox also.

[di]

@lgh2 I'm not sure if this PR is supposed to fix that clipping issue, we might need to break that out from #3194 into a separate issue for a separate PR.

[di]

@nlhkabu I'm not sure if I really understand what needs done here. The tutorial is suggesting that we make the target content appear on a click rather than a hover, which means that we'd have to a) remove the current hover CSS and b) add some JS to handle the click event instead.

However this would not degrade well if folks don't have JS enabled, as they would have no way to open the menus.

Instead we can bind to a focusin/focusout event, which would make the menu appear/disappear when the user tabbed to the button. I think this would suffice, and it would reduce our userbase of "users that can't use dropdowns" to just users that don't use mice, and don't use JS.

I'll push a commit which does this, and you can tell me if that is what you're looking for.

[nlhkabu]

Hi @di. Reading over the tutorial - I don't think we need to remove the hover CSS, rather, we can have both the CSS and JS (with click) working in parallel.

A couple of problems I found (I'm not sure if they're on my side or yours)

• I can't seem to open the top (logged in user menu) dropdown with the keyboard.
• The option buttons are working fine, but I can't actually tab through to the sub items

@lgh2 I just pushed a fix for the cut-off problem. It would be great if you could help us to continue to test this PR :) The criteria is:

1. Use only your keyboard to navigate around the page
2. Can you open each dropdown only using your keyboard?
3. Can you access each of the sub menu items in the dropdown using only your keyboard?
4. Now using your only mouse - does each dropdown still work as expected?

[di]

I can't seem to open the top (logged in user menu) dropdown with the keyboard.

Ah yeah, I think my selector might not be catching this.

The option buttons are working fine, but I can't actually tab through to the sub items

OK, finally figured this out. Reading https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role was a tremendous help.

We need to refactor how we structure these dropdown menus a bit. Only button elements (or things with role="button") are focusable, so we need to make anything we want to tab to a button.

I made the necessary refactoring for one such dropdown in 7777eeb, the main things are:

• Put the dropdown__trigger class on the parent nav element, with two children:
  • a button element that the user would click/hover on
  • an element with the dropdown__content class
• Don't need the extra li elements wrapping the trigger button
• Individual links in the dropdowns need to wrap buttons as well

This actually looks pretty good to me (aside from the buttons in the dropdown having default styling):

@nlhkabu Does that all make sense? I think if you take the same approach with the logged-in user dropdown, it should just work. Can you do the same refactoring elsewhere, style the dropdown buttons, and ensure I didn't totally break anything? 🙂

[di]

Heads up @nlhkabu I figured out how to do this myself so I think I can wrap this up on my own!

[di]

@nlhkabu I think this is pretty much done! The only thing I couldn't figure out was how to properly set the :focus style for the user indicator menu (it's just getting what dropdown__link has right now:

(You'll need to tab to it to get it to have :focus.)

[nlhkabu]

ah great @di! You beat me to it!!! Let me pull down and tweak and review 🕺

[nlhkabu]

hmmm - it looks like nesting a <button> inside an <a> and vice-versa is not valid HTML.

Investigating alternatives...

[di]

@nlhkabu I think https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role indicates that we can just give role=button to an a tag? Perhaps that would work?

FWIW, the reason that links are wrapping buttons and vice versa is because Firefox does support tabbing to links. Chrome supports tabbing to links and buttons, hence all the tabindex="=-1" on the links.

[nlhkabu]

I don't think adding role=button is going to work, as per https://formidable.com/blog/2014/05/08/anchors-buttons-and-accessibility/

For people who really want to stick with , the aria-role="button" attribute looks like an attractive option. If you add the attribute, the element is pretty much a button, right?

Unfortunately, using an ARIA role will get you part of the way there, but it isn’t a complete solution. While screen readers will interpret the link as a button, the element still responds to keyboard input as if it were a link

It appears that the 'not tabbing to links' issue is actually a mac system setting: https://stackoverflow.com/questions/11704828/how-to-allow-keyboard-focus-of-links-in-firefox

I think it is safe to say that any user who wants to use their keyboard extensively would have updated this setting.

I therefore think we should revert this PR to use links where appropriate :)

[nlhkabu]

@di - I've pushed a commit (with styling) as per my previous comment.

The top dropdown is almost working perfectly for me. The only thing is that when I tab all the way through the list (and then out of the dropdown) the dropdown remains open.

For the 'options' buttons, I am getting a JS error:

[lgh2]

Hi @nlhkabu !

I tested the following things from your comment up thread:

Use only your keyboard to navigate around the page
I can navigate around the page using the tab and arrow keys, this works ok on both /manage/projects/ and, with exceptions noted below, on /manage/project/nachos-txt/releases/.

Can you open each dropdown only using your keyboard?
Using Shift + Enter allows me to open the dropdown menu on the upper left hand side (under "welcome back" but not the dropdown menu under options beside the releases on the release management page at /manage/project/nachos-txt/releases/#content. I tried using some different key combinations (Control + Enter, Shift + Enter, Control + Tab), but none of them dropped down the menu.

Can you access each of the sub menu items in the dropdown using only your keyboard?
I can access all the dropdown items under the welcome back, <username> menu, and I can tab through them. I can't drop down the options menu on the manage releases page.

Now using your only mouse - does each dropdown still work as expected?
Using my mouse, everything works as expected.

[nlhkabu]

Thanks @lgh2 this is consistent with what I am seeing on my side :)

[brainwane]

@nlhkabu I'm seeing merge conflicts here in case you want to resolve those :)

[di]

@brainwane I think this is on my plate right now, I'll be working on this post-launch.

[di]

@nlhkabu I squashed all the previous commits here to make it easier for me to resolve the merge conflicts, there was a lot. Sorry if that causes any trouble!

For the 'options' buttons, I am getting a JS error:

I think I've resolved this issue (at least I can't reproduce it now).

The top dropdown is almost working perfectly for me. The only thing is that when I tab all the way through the list (and then out of the dropdown) the dropdown remains open.

I think this should be the expected behavior? E.g. on Github, you can tab out of the menu and it stays open, and the only way to close it is to go back to the parent and "click" it again with the keyboard.

The only thing remaining I think is that sometime since we last worked on this the focus styles became transparent (but only when using the keyboard):

[nlhkabu]

I think this should be the expected behavior? E.g. on Github, you can tab out of the menu and it stays open, and the only way to close it is to go back to the parent and "click" it again with the keyboard.

Works for me!

The only thing remaining I think is that sometime since we last worked on this the focus styles became transparent (but only when using the keyboard):

Updated :)

[nlhkabu]

🎉 thanks for your work on this @di - we got there in the end 🕺 💃