[Bug 13579] New: Clarify behavior of accesskey on static content elements

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

           Summary: Clarify behavior of accesskey on static content
                    elements
           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
        Depends on: 13555


It is extremely useful to be able to define keyboard shortcuts for the sole
purpose of navigation, rather than activation, and without visible links. HTML5
allows accesskey elements, even if they are not focusable and have no
associated action, which would trigger a click event to the element (per
4.11.5.8 Using the accesskey attribute to define a command on other elements).
However, the spec should more clearly state that when the users presses the
accesskey they should effectively navigate to the element. If the element is
not focusable, it should still be scrolled into view, any future sequential
navigation or search would start at this location, etc.

Use case: Jeanine is creating a web page, and wants to define a shortcut that
would assist users with disabilities by moving the keyboard focus and point of
regard to a specific heading in the page. However, she doesn't want to have a
link to that location be visible on the page, so she merely assigns an
accesskey attribute to the heading. The documentation tells users that they can
press that accesskey to navigate to the appropriate section of the document.

-- 
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 Wednesday, 3 August 2011 05:46:05 UTC