- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 14 Jul 2009 12:50:48 +0200
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "public-html@w3.org" <public-html@w3.org>
On Tue, 14 Jul 2009 08:07:25 +0200, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 22 Jun 2009, Simon Pieters wrote: >> >> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#using-the-accesskey-attribute-to-define-a-command >> >> says >> >> "The Action of the command is to run the focusing steps for the >> element." >> >> while all other commands the Action is basically the same as clicking. >> >> Shouldn't it be fire a click event instead? > > What would clicking do? It would run the onclick handler. > On Mon, 22 Jun 2009, Simon Pieters wrote: >> >> "An element that is focusable, has an assigned access key, and is [not >> an element that already defines a command], defines a command." >> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#using-the-accesskey-attribute-to-define-a-command >> >> Please remove "that is focusable, ", since it seems pointless to require >> that e.g. >> >> <div accesskey=a onclick=foo()>test</div> >> >> should have an assigned access key that does nothing. > > Don't use <div> for this purpose. Use <input type=button>, or <button>, > or > <a>. Well, I don't disagree, but ARIA and global tabindex="" exists to support using other elements for this purpose... > On Mon, 22 Jun 2009, Simon Pieters wrote: >> >> Although you can add an authoring conformance requirement saying that an >> element with an accesskey attribute that wouldn't otherwise define a >> command must also have a tabindex attribute (since the browser should be >> able to just focus the element). > > I don't follow. Considering your previous reply about focussing and accesskeys, I guess this comment can be ignored. -- Simon Pieters Opera Software
Received on Tuesday, 14 July 2009 10:51:35 UTC