(In reply to James Craig from comment #0)
> Created attachment 1410 [details]
> test case demonstrating bug (tested in WebKit)
> 
> Full Keyboard Access (FKA): when document.activeElement is hidden, it
> retains its status as document.activeElement, and therefore intercepts
> keyboard events as the event target.
> 
> Load attached test case and follow the instructions. It doesn't make sense
> that a hidden, unfocusable, unrendered element would be retained as
> document.activeElement, and therefore be an acceptable event target. This is
> either a spec bug or a browser bug.

I am not so sure that it's a bug. At least, it's a trick I've used before. The use case is this: you wish to expose a way of editing something that is like text, but not rendered at all like an input (notably, the text itself isn't rendered that way at all). So you give focus to a hidden input and render its content whenever it gets a keyboard event.

I'm not sure that's great for A11Y or that it's the best implementation strategy overall. I'm just pointing out that if it's something that I felt the need to do for a project at some point, I might not be the only one.

That sounds like a hack to me, but either way, your use case can still be achieved by setting the input's opacity to 0 or positioning it offscreen. However, hidden (and display:none) elements are not rendered in any modality and should therefore not be the document.activeElement or receive keyboard events.

Hixie says this is resolved in the WHATWG spec:

"An element is focusable if [...] The element is [...] being rendered [...]. When an element that is focused stops being a focusable element [...] the user agent should synchronously run the unfocusing steps for the affected element only."

reflect WHATWG resolution