13532 2011-08-02 21:52:01 +0000 Clarify that UAs should make user-accessible all elements that take focus or react to user input, regardless of the input method 2012-02-16 00:06:37 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED FIXED a11y, a11ytf P2 normal --- 1 gcl-0039 ian ian joshue.oconnor laura.lee.carlson mike public-html-a11y public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 52013 0 gcl-0039 2011-08-02 21:52:01 +0000 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. 52035 1 gcl-0039 2011-08-02 23:47:55 +0000 The user should also be able to move the focus to any element that is a source or target for drag and drop operations (e.g. has the draggable or dropzone attributes or handles dragenter and dragover events, etc.) The HTML5 spec correctly states that these should be keyboard accessible, but that requires the user be able to move focus to both source and target. 52496 2 mike 2011-08-04 05:02:01 +0000 mass-moved component to LC1 54353 3 joshue.oconnor 2011-08-07 08:12:34 +0000 I think this is a really good idea and I hope it gets some traction. 60821 4 ian 2011-12-02 19:04:45 +0000 I'll examine what can be added to make this clearer, but I suspect I have already added sufficient text of this nature. 64156 5 ian 2012-02-16 00:06:21 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: I've added some notes, but the conformance criteria were already fine. The specs that really need some normative text is whatever specs define the input-device-specific events like "onkeypress" or "onmousemove" — those need to very clearly state that using such events is an accessibility problem if more generic mechanisms aren't also provided. 64157 6 contributor 2012-02-16 00:06:37 +0000 Checked in as WHATWG revision r7001. Check-in comment: Add some notes explaining why these are SHOULDs and not MUSTs. http://html5.org/tools/web-apps-tracker?from=7000&to=7001