- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Aug 2011 05:46:03 +0000
- To: public-html@w3.org
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:04 UTC