1588156 - Accesskey is not ignored for hidden non-input elements

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Description

[Mark Striemer [:mstriemer]]

The behaviour of accesskey usage when an element is hidden is different between XUL and HTML.

The model in Firefox seems to be that if there is one element with a specific accesskey then it will be activated. If there are multiple, then they will be cycled between and focused, but not activated.

In XUL the hidden element appears to be ignored, so if there are 2 elements with the same accesskey but one is hidden then the single accesskey behaviour is seen. If there are still multiple visible then you get the cycling behaviour.

In HTML however, the hidden element is still considered. If it is the only element with that accesskey then it will be activated even though its hidden. If there are other elements with that accesskey then the cycling gets stuck trying to focus the hidden element.

I made a codepen [1] with an example of what happens. When a button is activated it will print its id below.

I also tested the example in Chrome and Edge. Edge ignore the hidden elements, but activates the item when it is focused in the cycling mode. Chrome also doesn't ignore hidden elements, but doesn't have a cycling mode.

[1] https://codepen.io/mkstrmr/pen/gOOaoMx

Comment 1

[Anne (:annevk)]

Per https://html.spec.whatwg.org/#keyboard-shortcuts-processing-model it seems you have to explicitly use the hidden attribute for an element with an accesskey to not be able to be activated. There's also no cycling defined though user agents would be allowed to do so as it's UI.

Anyway, I'm guessing the high-order bit is that this is preventing us from moving away from XUL. Does the hidden attribute help? (If it's not implemented properly, would it help if we did implement it properly?)

What's the priority for getting this addressed?

Comment 2

[Mark Striemer [:mstriemer]]

Alright, so I dug into that a little and hidden worked when I updated my codepen to use it but it wasn't working in my about:addons changes. It looks like it's related to the element type.

Using all <button> elements with the hidden attribute works the same way as XUL. However, if you make the hidden element with an accesskey a <span> then you get the behaviour as if it's visible, but cycling is broken as I specified above. The codepen has been updated to reflect this.

What I have in about:addons is <panel-item>#shadow-dom(<button>)</panel-item>. Since we can't use an accesskey on a shadow DOM button (bug 1037709) right now, which is what is in the tab order, I put the accesskey on the panel-item. This means I'm hitting the bug mentioned in comment 0 where the accesskey is still usable when its parent is hidden.

I think I'd rather see bug 1037709 fixed for my problem, so I don't think this needs to be a high priority for me since there is a workaround.

Comment 3

[Anne (:annevk)]

Since there's a workaround marking P5 until there's more evidence of this being problematic.