W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2011

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 22 Nov 2011 04:14:10 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RShkI-0003ZP-EL@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13579

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #4 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2011-11-22 04:14:08 UTC ---
(In reply to comment #0)

Do you suggest:

   a)  that elements with the accesskey should be focusable in AT by default,
inline with what HTML5's section on 'Focus management' says about how different
UAs can make different elements focusable: """An element is focusable if the
user agent's default behavior allows it to be focusable""" ?
   b) or do you - as I am more inclined to think - simply suggest that if we
have the element
      <div id=foo accesskey=a >Foo text.</div>
then, activation of the accesskey should have the same effect as clicking the
link
      <a href=#foo>Go to foo text.</a>
       ?
  c)  or do you mean a third thing - like what I think Joshue talks about?

The thing I wonder about the most is your following statement:

> any future sequential navigation or search would 
> start at this location, etc.

Fact is that, if we consider the effect of following a *link* to fragment #foo,
then "navigation or search" does *not* start from this location. But perhaps,
in AT - at least some AT - this is different? I wish "normal" browsers *did*
behave like you say. But tend to not do that.

Btw, in bug 12709, I propose that accesskeys on unfocusable elements, should
default to be hidden from the user so as not to confuse him or her with
accesskeys that do work. And this bug, seems to support what I propose in 12709
- as you suggest that the accesskeys on non-focusable elements should only be
revealed to AT.

Btw: How does your proposal fit with an element that has been made focusable
e.g. via an onClick() event , but which doesn't have @accesskey ? E.g. what if
a script "suddenly" makes the element focusable? (The same question could
probably be asked about bug 12709.)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 22 November 2011 04:14:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 November 2011 04:14:20 GMT