Re: [whatwg] accesskey attribute with display:none elements
On Fri, 28 Nov 2008 05:01:42 +1100, Olli Pettay olli.pet...@helsinki.fi wrote: On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote: Perhaps a *good* rationale could be, if you can't see the control, There are other modalities than just visual. Sure. But users generally expect the page to work the same dependent on usage, not dependent on their modality (which the page can't be sure of anyway). So, I stand up for standardizing the disallow accesskey activation for 'display:none' elements behaviour. So you're willing to break accesskeys on some websites. Note, I'm not very strongly supporting accesskeys on display:none elements, but breaking existing web sites doesn't sound good. In principle I think it makes good sense for accesskeys not to work on things that are disply:none. But in practice, I think Olli's argument (it ain't broke so lets not 'fix' it - especially in a way that breaks stuff) is the one that carries the most weight. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto:
On 11/27/2008 06:52 PM, Calogero Alex Baldacchino wrote:
Perhaps a *good* rationale could be, if you can't see the control,
There are other modalities than just visual.
Indeed, and the display property applies to every and each the very same
way. From http://www.w3.org/TR/CSS21/visuren.html#propdef-display
'display'
Value: inline | block | list-item | run-in | inline-block | table
| inline-table | table-row-group | table-header-group |
table-footer-group | table-row | table-column-group | table-column |
table-cell | table-caption | none | inherit
Initial:inline
Applies to: all elements
Inherited: no
Percentages:N/A
*Media: all*
If you care of any media aving trouble with 'display:none' (and might be
for a visual browser + a screen reader), you have to change the value
for that media. But if one can afford to write different style sheets
for different media, one can also afford to avoid 'display:none' at all
when it comes to interaction, and instead emulate it by setting a bounch
of other properties so that the element occuped 1px or so, without
affecting heavily the overall visual layout, and without problems with
non-visual media (but there is another possibility, yet working only
with css 2 compliant browsers: a menu can have an absolute positioning,
or being floating, and a zindex telling if it's in front of or behind
another element, which in turn can be opaque, so switching the zindex
could work as fine as switching the display property).
So, I stand up for
standardizing the disallow accesskey activation for 'display:none'
elements behaviour.
So you're willing to break accesskeys on some websites.
HTML *5* is the next evolution of HTML, that means it's almost a new
language looking backward with one eye and forward with the other,
carrying on something from the past and throwing away somthing else,
finding some compromises for the transition phase. I think that hiding
something to the user (whatever is the presentation modality), as if
that wasn't in the document at all ('display:none' as a stronger
semantics than just being hidden, invisible, behind something, and so
on), but expecting the user would interact with that, is not the best
possible practise, and since, as far as I remember, there have never
been assurances on good working of accesskeys, a break with old,
non-standard behaviours could not be a murderer. But, however...
Note, I'm not very strongly supporting accesskeys on display:none elements,
but breaking existing web sites doesn't sound good.
-Olli
but the question could be another. The new behaviour of FF3 breaks
compatibility with existing HTML *4* (or xhtml) sites, without being an
HTML *5* *only* browser (perhaps, at some point in the future, html 5
could become the 'older' backward compatibility basis, like today
browsers provide older features, i.e. document.all or document.layer,
along with newer DOM features), so that break, though not being in
contrast with any standard, could be deemed a kind of bug. My point now
is: let's state *HTML 5* elements cannot be activated through accesskeys
when they have a display propery of 'none', but user agents are left
free (after all that's never been a standard) to activate non-HTML 5
elements with the property 'display:none' for backward compatibility.
That should mean the old, non-standard behaviour could be turned on for
existing websites just by adding a dtd reference in the doctype
declaration. Does it sound acceptable at you?
Regards, Alex.
--
P.S. I take it separate because off topic, but I'd really consider
something like,
HTMLKeybordEvent{
readonly boolean attribute activationModifiers;
}
independent from generic DOM keyboard events, yet easily bindable to
them and quite safe from changes in DOM 3 Events Working Draft.
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Scegli la tua suoneria! Il meglio della musica sul tuo cellulare!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8269d=28-11
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto:
On 11/26/2008 02:34 AM, Calogero Alex Baldacchino wrote:
A
better way to do what you aim would consist of setting a listener for
key events on a displayable element and choosing a different operation
basing on the pressed key(s);
This is not content author friendly way to do it, because different
browsers/OSes
use different keys to activate accesskey targets.
-Olli
On one hand, whoever wished to write a 'complex' web application, with
keybord shortcuts, should be aware of this concern and try and deal with
it, since it's even more complex than you wrote, and might affect
accesskey attributes too. The problem is, keybord shortcuts have always
been strongly platform-dependent, while the web is aimed as a somewhat
cross-platform architecture, so both accesskeys and key events handling
cannot be 'fully author friendly'. I mean, a somewhat browser, on a
somewhat OS, might use the same combination of modifiers (i.e. crtl+alt
- just an example, not thinking on a real situation) to activate both
its own controls (which take precedence) and a web page controls, so
there is always a chance to choose an accesskey which won't work on a
particular platform. Perhaps it was an heavier concern a few (or even
several) years ago, since nowaday I think most browsers take great care
on this matter, however such problem might arise from time to time, i.e.
with a new browser version, or a version supporting a new OS (or a new
OS version), or using an old browser version apparently compatible with
a new OS version (but such should be a concern more for browser/os
developers than for web developers, since the latter can only assume the
underlying platform - browser + os - works correctly, and cannot care
about any 'bug' outside their work, yet access keys, whatever way
handled, cannot be though as a 'fully and always' reliable mechanism,
while mouse clicks and tab-key navigation plus return-key activation
usually are). Perhaps, keybord shortcuts may work better in a 'make
application state'.
I agree that setting an accesskey attribute is easyer to deal with than
handling key events, and the 'no-dimension, display:inline elements
trick' stands always out there; anyway I think key events handling may
be improved and become easier to adopt by adding to a somewhat interface
a few constants representing the modifiers combination used by the
browser to activate access keys, so those modifiers could be compared to
the modifiers 'carried on' by the key event (this would require support
for the DOM 3 Events, which I think could be improved/modified too -- if
something like the above is yet present in html5 spec and I've missed
it, I apologize).
On the other hand, the key events listener could just operate on single
alphanumerical characters, something like (javascript-style)
switch(pressedKey){
case 'a' : doSomething(); return;
case 'b' : doSomethingElse(); return;
}
so to bypass any modifiers concern, with some extra care to avoid
interferences with textual fields (and to avoid casual key pressing by
the user - i.e. the very first time a key listened for is pressed, the
webapp could just show an advise and list all valid shortcuts). Anyway,
even in this case there would be chances to clash with a browser default
behaviour for some keys (i.e. when the key is a digit).
--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f
Sponsor:
Scopri i games più scaricati su cellulare! Gioca la tua partita!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8272d=26-11
Re: [whatwg] accesskey attribute with display:none elements
On 11/26/2008 05:35 PM, Calogero Alex Baldacchino wrote: anyway I think key events handling may be improved and become easier to adopt by adding to a somewhat interface a few constants representing the modifiers combination used by the browser to activate access keys, so those modifiers could be compared to the modifiers 'carried on' by the key event (this would require support for the DOM 3 Events, which I think could be improved/modified too -- if something like the above is yet present in html5 spec and I've missed it, I apologize). Note, accesskey events (http://www.w3.org/2008/webapps/track/issues/40) won't be probably defined in DOM 3 Events (which is still just a draft). And those events are anyway different thing to this problem. I'd want it to be specified somewhere how accesskeys should behave in display:none content. Because of the valid use case (dhtml menus) and the current behavior of FF2/Safari/Opera and it-is-used-in-the-web, I think allowing those accesskeys to work should be ok. Of course if there is some *good* argument why they shouldn't work, that behavior should be standardized. br, -Olli
[whatwg] accesskey attribute with display:none elements
Hi all, currently it isn't specified anywhere (AFAIK) what should happen if the element which has an accesskey attribute is hidden using display:none. HTML4 says the following: Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link... The problem is that focusing and activating isn't the same thing. FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets. FF3 changed the behavior to require visible and focusable element. IE7 doesn't seem to activate, only focus (at least a elements), and because hidden element isn't really focusable, it doesn't seem to do anything with elements with display:none. A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588 I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. (Key event listeners could do something similar, but they'd need to handle all the different browsers and OSes.) So I prefer what FF2, Safari and Opera do, and would like to change FF3.1 to work the same way. Anyway, I hope some behavior could be standardized. Comments? br, -Olli
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto: Hi all, currently it isn't specified anywhere (AFAIK) what should happen if the element which has an accesskey attribute is hidden using display:none. HTML4 says the following: Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link... The problem is that focusing and activating isn't the same thing. FF2, Safari 3.x and Opera 9.6 can activate display:none accesskey targets. FF3 changed the behavior to require visible and focusable element. IE7 doesn't seem to activate, only focus (at least a elements), and because hidden element isn't really focusable, it doesn't seem to do anything with elements with display:none. A simple testcase https://bugzilla.mozilla.org/attachment.cgi?id=339588 I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. (Key event listeners could do something similar, but they'd need to handle all the different browsers and OSes.) So I prefer what FF2, Safari and Opera do, and would like to change FF3.1 to work the same way. Anyway, I hope some behavior could be standardized. Comments? br, -Olli Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Incontri con Meetic : Primo sito d'incontri in Europa - Milioni di single ! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8293d=25-11
Re: [whatwg] accesskey attribute with display:none elements
On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote: Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. That isn't what any of the browsers do currently, so I'm not in favor of this pretty strange behavior. And how could the browser know how to change the display value? From display:none to display:inline or display:block or display:inline-block or what?
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay wrote: I think allowing hidden elements to be activated is useful for web apps, especially because there isn't any API to add listeners for accesskey activation. Hmm … Couldn't you style such elements visible with :focus and :active? Does popular assistive technology report accesskey on elements that aren't rendered (display: none;) rather than merely hidden off-left (position:absolute; left:-9em;)? (It tends not to report elements that are display: none; at all, note.) And, either way, is there any reason why it should report the accesskey but not the element? -- Benjamin Hawkes-Lewis
Re: [whatwg] accesskey attribute with display:none elements
On 11/26/2008 12:39 AM, Benjamin Hawkes-Lewis wrote: Olli Pettay wrote: Couldn't you style such elements visible with :focus and :active? What you mean? How do you focus a display:none element? Good point. You can't. Isn't that a problem in practice? i.e. When do you want a control to have an accesskey but _not_ be focusable? For example when you want to execute some JS when accesskey is pressed: a accesskey=x href=javascript:doSomething(); That behavior is used in the web https://bugzilla.mozilla.org/show_bug.cgi?id=419059mark=1#c1 The comment mentions dhtml menus and that is a valid use case for accesskeys in display:none elements. -Olli
Re: [whatwg] accesskey attribute with display:none elements
Olli Pettay ha scritto: On 11/25/2008 11:17 PM, Calogero Alex Baldacchino wrote: Maybe, the standard behaviour (for both 'display:none' and 'visibility:hidden') could be just focusing (and changing visibility) after pressing the access key (so the user notices what's happening before activating any 'control'), then activating the element after a second press. That isn't what any of the browsers do currently, so I'm not in favor of this pretty strange behavior. And how could the browser know how to change the display value? From display:none to display:inline or display:block or display:inline-block or what? Maybe I've replied to quickly, sorry for this. The user agent should have a default style sheet with a default display value for each element, so that value could apply (this may lead to unwanted results if the element had a different display value before the value none was set, and this case should be handled by script). I guess what you wish is something like a shortcut in a desktop application, letting you access any control in a menu without showing and esploring the menu. Despite this could be a desireable behaviour for a web application, I think it could also be used to trick the user, or cause an unwanted operation to be performed as a consequence of a casual key pressing, thus the idea of showing the control before activating it, giving the user a chance to stop the operation. For the possible tricks, I guess that might be a minor concern (since there are far 'better' ways to compromise your navigation); anyway, consider that an element constraint with 'display:none' is not a part of the formatting structure for any media and you cannot access it anyway (i.e. you cannot click on it, you cannot reach it by pressing the tab key). That's not just invisible, that's not presented to you at all, almost if that wasn't in the document tree, so that's not focusable at all, and accessing it through an access key would be quite a tricky way to bypass the above 'restrictions' (as if that was forced into the document layout). A better way to do what you aim would consist of setting a listener for key events on a displayable element and choosing a different operation basing on the pressed key(s); a perhaps tricky alternative would be using controls with an accesskey attribute properly set and 'emulating' the 'display:none' layout property by setting their width, height, margin, etc., to a value of zero, and their display property to the 'inline' value. I guess any browser allowing the behaviour you ask for any element with a 'display:none' value perhaps just works around a somewhat misuse of the display property as a quirk. -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Incontri con Meetic : Primo sito d'incontri in Europa - Milioni di single ! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8293d=26-11
Re: [whatwg] accesskey
On Mon, 28 Jan 2008 16:31:04 +0100, Mikko Rantalainen [EMAIL PROTECTED] wrote: Matthew Paul Thomas wrote: Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. It does. Just allow the UA to accept the key a a hint, but provide the real binding itself. (And therefore require the UA and not the author to provide dscoverability for things with accesskey. As envisioned by the UAAG most of a decade ago). The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. Perhaps the accesskey should be kept but its meaning should be transformed a bit. Instead of being a key (letter) it should be a keyword for a behavior. A good accesskey values could be home, index, search, contact. The user then could bind the home accesskey to any home button of his selection. It could be CTRL+H or perhaps F11 instead. Some keyboards have additional multimedia keys that could easily be used for such behavior. This functionality is already available via the rel attribute, and where there are good common values it makes more sense to use those than accesskey in the first place. ... So my suggestion is to turn the accesskey to a tag of the behavior or feature linked to the element. One could argue that instead the rel attribute should be used for such behavior and I really cannot claim otherwise... No :) Accesskey is where there isn't something obvious - a function that hasn't been common (send was once such a function on the web, before the growth of web-based mail systems. Add to shopping basket is another. I am sure there are new services we haven't developed yet...). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] accesskey
Matthew Paul Thomas [EMAIL PROTECTED], 2008-01-27 23:02 +: [...] The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. That statement would conflict with existing, long-standing requirements that a number of large mobile operators have published and that have been followed by the vendors providing compatible browsers for their services, as well as content providers wanting to deliver compatible content for customers of those operators using those services. And market realities will require that statement to be ignored by any browser vendor wanting to get their product preinstalled on handsets destined for use with carrier networks in Japan (and I think in other markets as well) and have it be compatible with user expectations of existing content. A browser that doesn't support accesskey is going to break/degrade the expected user experience of that content. So any browser that is looking to compete in the market with the existing browsers in Japan intended for use with that content would never be accepted or shipped by device makers targeting that market, nor by the mobile operators their devices are targeted/branded for -- if that browser is intended for the same use case as the core browsers already shipped on handsets here. And even if it were possible to convince the device makers and carriers, making accesskey non-conforming would push all the compatibility/content-migration costs onto the thousands of content providers who'd be forced to remove from all their existing content the numbered image markers they currently have in it to visually indicate accesskey associations. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] accesskey
Charles McCathieNevile [EMAIL PROTECTED], 2008-01-28 18:39 +1100: On Mon, 28 Jan 2008 10:02:26 +1100, Matthew Paul Thomas [EMAIL PROTECTED] wrote: [...] Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. They do. As for example, Opera Mobile provides for each page, from a submenu, a numbered list of all the links on the page. However, accesskey, which is to primarily designed to give an increased navigation priority to certain links, I guess that's the key point. Other than accesskey, we have provided no other standard way for authors/content-providers to indicate through markup that kind of navigation priority for selected links. So lacking that, all that a UA could really do is to find all the links on the page and present them to the user in a list of some kind accessible from a submenu or whatever in the browser UI. (I guess it could attempt to implement some mechanism that used heuristics to try to intelligently determine which links are meant to have that navigation priority, but from what I've seen of the existing content that uses accesskey, that mechanism is not likely to be successful very often). is very useful for handsets, and not actually very complicated to implement, in a way that is consistent with the existing markup. It might not be the same across all implementations, but there is very little restriction needed to make an implementation compatible with almost any imaginable UI. And in that light -- knowing that some browser vendors will go ahead and implement accesskey regardless (because it's useful and not costly to do so and because the realities of a market they want to sell in demand it), the solution of putting into spec an explicit UAs must ignore the accesskey= attribute that they are going to necessarily have to ignore really doesn't seem like a practical or productive solution. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] accesskey
Matthew Paul Thomas wrote: Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. Perhaps the accesskey should be kept but its meaning should be transformed a bit. Instead of being a key (letter) it should be a keyword for a behavior. A good accesskey values could be home, index, search, contact. The user then could bind the home accesskey to any home button of his selection. It could be CTRL+H or perhaps F11 instead. Some keyboards have additional multimedia keys that could easily be used for such behavior. The spec could describe that for backwards compatibility UAs should expect to find keywords such as 1, 2, 3, ... and a, b etc. and that those keywords should be considered to be static for the site but have no specific meaning otherwise. A mobile device could map keyword 1 to button 1 by default if it seems to make sense. So my suggestion is to turn the accesskey to a tag of the behavior or feature linked to the element. One could argue that instead the rel attribute should be used for such behavior and I really cannot claim otherwise... -- Mikko signature.asc Description: OpenPGP digital signature
Re: [whatwg] accesskey
Dnia 25-01-2008, Pt o godzinie 23:06 -0500, Jean-Nicolas Boulay Desjardins pisze: In the present standard you are alowd to use the same accesskey in to different links... For example: a href=bob.html accesskey=bBob web page/a a href=bob.html accesskey=bBob web page/a But what would happend if this was to happend: a href=bob.html accesskey=bBob web page/a a href=alex.html accesskey=bAlex web page/a Again this is allowed in the present web standard, but if you think about it its illogical, on what bases thus the browser decide wich one to access first or should it open the tow? The visible and enabled elements marked with the same access key should take focus in turn and in page order. If the element is an active element, its action should not be performed. Chris
Re: [whatwg] accesskey
On Tue, 29 Jan 2008 03:31:46 +1100, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: Dnia 25-01-2008, Pt o godzinie 23:06 -0500, Jean-Nicolas Boulay Desjardins pisze: ... But what would happend if this was to happend: a href=bob.html accesskey=bBob web page/a a href=alex.html accesskey=bAlex web page/a Again this is allowed in the present web standard, but if you think about it its illogical, on what bases thus the browser decide wich one to access first or should it open the tow? The visible and enabled elements marked with the same access key should take focus in turn and in page order. Indeed... User agents must, in any case, be free to reassign access methods (for example using a key other than the one the author suggested). This is one reason they might do that (a more common reason would be that there isn't a readily available 語 key...). Since it is critical user agents can do this, user agents, not authors, should be responsible for telling the user how to activate the things that have access keys. (This was envisioned in the User Agent Accessibility Guidelines, where it has its own checkpoint [1]). So the user agent can actually decide to leave the keys as they are and allow cycling through them (IE does this in some versions at least), or change the key (or other behaviour) that triggers the effect and of course make it clear to the user what the actual activation method is. If the element is an active element, its action should not be performed. Hmmm. I am not sure about this. In general, I prefer an acceskey mechanism that activates controls (although it should be configurable), and a user agent that just re-maps doubled accesskeys. I certainly don't think that we should be overly prescriptive about how to handle the situation. This is, after all, primarily a question of user interface design, not markup design. cheers chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] accesskey
Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. ... Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and 5-way directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. ... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Re: [whatwg] accesskey
On Mon, 28 Jan 2008 10:02:26 +1100, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Michael(tm) Smith wrote: Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: ... Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. But that's precisely the problem: accesskey= *can't* be consistent and interoperable across UAs, or even across browsers, because browsers compete (amongst other things) on their user interfaces, and therefore they have different user interfaces, and therefore they conflict with different values of accesskey=. If that problem had a good solution, removing the attribute would not have been necessary. The problem does indeed have a god solution, which is to remove the stupid suggestion about the activation behaviour (alt/cmd/etc) in the spec. iCab, Opera, Amaya and Firefox have already implemented something intelligent that lets you avoid conflicts. The specification could include an explicit statement of the form UAs must ignore the accesskey= attribute, but any such statement would be in the yet-to-be-written Rendering section. And an unimaginatve and unintelligent approach anyway. ... Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and 5-way directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. ... Since most pages that contain links don't also use accesskey=, handset vendors should find a way to allow easy navigation of links regardless of whether the attribute is present. They do. However, accesskey, which is to primarily designed to give an increased navigation priority to certain links, is very useful for handsets, and not actually very complicated to implement, in a way that is consistent with the existing markup. It might not be the same across all implementations, but there is very little restriction needed to make an implementation compatible with almost any imaginable UI. And all of this has been proposed before, implemented by people in various ways in javascript or via proxy-based scripting as well as in user agents, and is hardly rocket science. http://lists.w3.org/Archives/Public/public-html/2007Jul/0213.html gives you a set of implementation techniques, links to a set of minimal changes required to the spec, etc. (There is more that could be done in an advanced implementation, but it isn't really complicated). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] accesskey
Jerason Banes [EMAIL PROTECTED], 2008-01-25 23:41 -0600: Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. Another long story short: accesskey mark is already in use in a significant amount of existing content, so leaving it unspec'ed for implementors does not seem like a practical option -- not if we care about trying to ensure that behavior of that content is consistent/ interoperable across UAs. To elaborate a bit: A class of content in which accesskey markup is in particularly wide and effective use (effective as far as its content providers and users of it are concerned) is content intended for viewing, as one of its possible delivery contexts, on mobile handsets. Most handsets don't have keyboards or real pointing devices that let you quickly point and click on links; instead they just have numeric keypads and 5-way directional pads that are basically the equivalent of arrow keys plus an enter key/mouse button. In the context of delivering content to those devices, it's useful to provide numbered access keys for quick access to certain links on a page -- to save users the time and trouble of needing to use the 5-way on the handset to scroll to the links and activate them. And that's why there's a large body of existing content that has accesskey markup: sites that takes browsing from mobile handsets into consideration as one of their possible delivery contexts. The intended replacement is the XHTML Role Access Modulehttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule. I think it might be more accurate to say that's one proposal for providing a better means to meet the same requirement that accesskey was originally intended to meet. A few links on the subject: http://www.cs.tut.fi/~jkorpela/forms/accesskey.html The original version of this document had a much more positive attitude to the accesskey attribute. Experience and analysis has shown, however, that the idea of author-defined shortcuts is generally not useful on the Web. I guess this is a case where anybody making that assessment might need a little more experience -- and need to do a little more analysis that involves looking at the existing content I mentioned above. The use case of accesskey for Accessibility considerations (targeted to improve accessibility of content intended in the context of using it from a computer that has a full keyboard or equivalent) is not the only use case it should be judged on. Whether it's turned out that accesskey markup has failed to be effective for that use case is something that doesn't really matter. Because it's clearly not the only case for which it has come into use in existing content. And even if we make the determination that HTML5 will ultimately not make the accesskey conformant for authoring, we would still need to have it spec'ed for implementors in HTML5 if we want the existing content that already uses to remain usable/interoperable. [quoting Jukka] Unfortunately, browser support to the attribute is limited, and rather primitive. Not true now since many/most browsers on mobile handsets support it (and note that Jukka says on that page that he wrote that part a long time ago). [quoting Jukka] The accesskey attribute tends to mask out the functionality of a browser's predefined keyboard control, which is often much more important than page-specific access keys. Whether for a particular site the access keys provided by site or the browser's predefined keys are more important is something for users of that site to decide. What's needed is for browsers to be made smarter so that they can provide a way for users to be able to access both. [quoting Jukka] Moreover, browsers do not indicate that access keys are available. That doesn't matter for the case of numbered access keys in the class of content I've mentioned. Because those sites don't expect the browser to indicate that access keys are available. Instead, they put a numbered image inline next to each link that has a numbered access key. There are of course other ways that a browser can make access keys discoverable. As far as desktop browsers, Konqueror does it by displaying tooltip-like popups next to the links when you press and release the Control key (without pressing any other key in combination with it). Anyway, all that said, I'm not a fanboy for accesskey. I think in hindsight it's clear to all of us now that it should probably have been better thought out before it got spec'ed originally and put into a standard. But then so should have a lot of other things. The general problem we face with that what-we-now-see-as-bad-legacy markup now is that because it did make it into a standard and authors and content providers ended up using it in their content, we
[whatwg] accesskey
In the present standard you are alowd to use the same accesskey in to different links... For example: a href=bob.html accesskey=bBob web page/a a href=bob.html accesskey=bBob web page/a But what would happend if this was to happend: a href=bob.html accesskey=bBob web page/a a href=alex.html accesskey=bAlex web page/a Again this is allowed in the present web standard, but if you think about it its illogical, on what bases thus the browser decide wich one to access first or should it open the tow?
Re: [whatwg] accesskey
Why are there removing accesskey? http://www.w3.org/TR/html5-diff/#absent-attributes I though it was recommended to be used by WAI... What are we should we use? Because its not said what accesskey is replace with...
Re: [whatwg] accesskey
Long story short, accesskeys were an idea that worked better on paper than they did in practice. They inevitably interfered with normal browser operation as well as other accessibility features in such a way as to * reduce* the accessibility of many web pages. The intended replacement is the XHTML Role Access Modulehttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule. It works in a manner similar to accesskeys, but attempts to resolve some of the original shortcomings. I'm afraid I'm not intimately familiar with it, but I believe it also resolves the original multi-mapping problem you brought up. A few links on the subject: http://www.cs.tut.fi/~jkorpela/forms/accesskey.html The original version of this document had a much more positive attitude to the accesskey attribute. Experience and analysis has shown, however, that the idea of author-defined shortcuts is generally not useful on the Web. Moreover, serious damage is often caused by the way in which the attribute has been implemented in browsers: it uses key combinations that override built-in functionality in browsers and other software. Unfortunately, browser support to the attribute is limited, and rather primitive. The accesskey attribute tends to mask out the functionality of a browser's predefined keyboard control, which is often much more important than page-specific access keys. Moreover, browsers do not indicate that access keys are available. http://en.wikipedia.org/wiki/Access_keys In the summer of 2002, a Canadian Web Accessibility consultancy did an informal survey to see if implementing accesskeys caused issues for users of adaptive technology http://en.wikipedia.org/wiki/Adaptive_technology, especially screen reading technology used by blind and low vision users. These users require numerous keyboard shortcuts to access web pages, as pointing and clicking a mouse is not an option for them. Their research showed that most key stroke combinations did in fact present a conflict for one or more of these technologies, and their final recommendation was to avoid using accesskeys altogether. The World Wide Web Consortium http://www.w3.org/, the organization responsible for establishing internet standards, has acknowledged this short-coming, and in their latest draft documents for a revised web authoring language (XHTML 2http://www.w3.org/TR/2005/WD-xhtml2-20050527/), they have deprecated (retired) the ACCESSKEY attribute in favor of the XHTML Role Access Modulehttp://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-role.html#s_rolemodule . http://www.wats.ca/show.php?contentid=32 *So while it seems that Accesskeys is a great idea in principle, implementation brings with it the possibility that it either will not be available to all users, or that the keystroke combination encoded within the web page may conflict with a reserved keystroke combination in an adaptive technology or future user agent.* This potential problem was subsequently brought to the attention of the Canadian Common Look and Feel Access Working Group (who had previously suggested the use of Accesskeys M, 1 and 2), and after consideration the Access Working Group reversed it's recommendation and now suggest *not* to use Accesskeys on Government of Canada Web sites. Thanks, Jerason On Jan 25, 2008 10:43 PM, Jean-Nicolas Boulay Desjardins [EMAIL PROTECTED] wrote: Why are there removing accesskey? http://www.w3.org/TR/html5-diff/#absent-attributes I though it was recommended to be used by WAI... What are we should we use? Because its not said what accesskey is replace with...
