[Bug 13532] New: Sequential navigation to all elements that take focus or input

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13532

           Summary: Sequential navigation to all elements that take focus
                    or input
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: a11y, a11ytf
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: gcl-0039@access-research.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org, public-html-a11y@w3.org


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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 2 August 2011 21:52:03 UTC