Reproduces with ChromeVox per steps above, grayed out option is skipped. 


Google Chrome	69.0.3497.35 (Official Build) dev (64-bit)
Firmware Version	Google_Lulu.6301.136.57

I see it labelled as 'sort by name' rather than 'sort alphabetically', just for the benefit of other sighted users who may be confused

https://www.w3.org/TR/wai-aria-practices-1.1/#h-note-17 notes "Disabled menu items are focusable but cannot be activated."

That menu is implemented in a somewhat strange way as buttons.
When there are no elements in the page to sort, the buttons get a 'disabled' attribute set, which means they are no longer focusable.

Alice pointed out that the html spec doesn't specify that a disabled button should be non-focusable. So that sounds like a spec bug (ideally disabled should only prevent activation but not focus) - I'm going to attempt to file a bug.

I suggest we (me?) rewrite the menu, as our current implementation is a bit strange.


Note: it seems all menus on the bookmarks page are using the same code, I am able to re-create this problem in other menus.

Reproduction steps:
1. visit chrome://bookmarks
2. right click on the first folder called 'bookmarks bar'
3. try select the first menu item 'rename' or the second menu item 'delete'

Expected:
First two menu items should be focusable but not selectable.

Actual:
First two menu items are neither focusable nor selectable.

After digging around some more I found that elsewhere in the spec. it states that disabled elements are not focusable

https://html.spec.whatwg.org/multipage/interaction.html#focusable-area
states
> Focusable area
> Example
> Elements that have their tabindex focus flag set, that are not actually disabled, [...]

and 'actually disabled' then links to
https://html.spec.whatwg.org/multipage/semantics-other.html#concept-element-disabled
which states
> An element is said to be actually disabled if it is one of the following:
>  - a button element that is disabled
>  [...]
> This definition is used to determine what elements can be focused and which elements match the :enabled and :disabled pseudo-classes.


What I have been able to reproduce:
 - disabled menu items are not focusable using the tab or arrow keys.
 - ChromeVox seemed to start at the first non-disabled menu item when reading and would start counting as '2 of N', I could loop all the way through to 'N of N', when I looped around I started again at '2 of N'.

I wasn't able to find any other webui menus within chromium which have disabled elements to compare to.
I think the current disable behavior (neither focusable nor selectable) of this menu matches native menus (at least within Linux and Mac).
I am not able to focus on disabled elements using tab, although Alice was able to get ChromeVox to highlight it using some magic incantation.
I am not yet sure if the counting of '2 of x' happens in native UIs, I found this quite non-ideal.
I think our keyboard access behavior is consistent with other menu systems (e.g. https://github.com/Heydon/inclusive-menu-button).

Do we have any examples of where a disabled menu item works as expected?

The plot thickens - I just turned on VoiceOver, and it started visiting all menu items, including disabled ones. Then I turned it off and it ... kept doing the same thing? 

In terms of announcing indexes - no, VoiceOver does not do this in native UI. Seems to come "for free" with using the menu/menuitem roles - the native UI uses the same underlying roles, so I'm not sure why the indexes don't get announced there.

It's really annoying that disabled buttons are not even *programmatically* focusable, apparently by design. One slightly gross way to work around that would be to wrap the disabled (and only when disabled) button in a focusable div which takes the menu role and aria-disabled attribute. 

Or just make the menuitem button into a focusable div when disabled, that probably makes more sense.

And I meant "menuitem role", not "menu role" in my last paragraph above.

It looks like Google Sheets also uses buttons for menus and has the same accessibility behaviour.

You can see this in the youtube video tutorial for using a screen reader with Google Sheets
https://youtu.be/oCYT63b_m88?t=13m22s

When they open the sheets menu and press down it selects the second menu item, as the first is disabled, and reads it as "2 of 8".

Assigning back to Chris since he is working on it.