Users need to be sure they can explore and find all focusable and actionable elements, even if they cannot use a mouse.

The HTML5 specification should explicitly state that user agents are allowed and encouraged to provide modes or commands that let the user move focus to all elements that take focus or input, even if the author has indicated that the element should not normally be included in sequential navigation (e.g. tabindex is a negative integer), of if the element takes input but lacks other attributes that would normally render it focusable (e.g. img with an onClick handler).

However, as per current wording, this should not allow navigation to elements that are not being presented to the user at all (e.g. aria-hidden, @hidden, or display:none). That is described in 7.3.2 (Focus management) which reads in part "...only if the element is either being rendered...". 

The list of elements in 7.3.2 (Focus management) that can take focus should be modified to include elements with input handlers (e.g. img with an onClick handler).

Use case: Laurie is tabbing through a dynamic web page, but finds that there are certain buttons she cannot reach because the author, thinking only of mouse users, has specified that the buttons should not be included in the tab order by setting tabindex to a negative number. Therefore Laurie, who relies entirely on keyboard input, cannot access some functionality on the page.

Use case: Laurie is using a web page that contains a custom control, an image that does not take keyboard input or focus but does have an onClick handler. Therefore Laurie, who relies entirely on keyboard input, cannot click on the element to activate it, and even though her browser provides a context menu that would let her activate the image's onClick event, it does not let her move focus to it because that would violate the (current draft) HTML5 specification.