(*** This bug was imported into bugs.kde.org ***) Package: Version: 4.0 (using KDE 3.0.0 ) Severity: wishlist Installed from: Red Hat Linux 7.2.93 Compiler: gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-110) OS: Linux (i686) release 2.4.18-3 OS/Compiler notes: As far as I can see there are no support for "accesskey" in Konqueror which is a part of HTML 4.01: http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey I will hope that this will be in future releases because it will help navigating sites which uses this HTML 4.01 feature. Thanks in advance The most enjoyable greetings Claus Sørensen (Submitted via bugs.kde.org) (Called from KBugReport dialog)
Yes, please add accesskeys support, it'd let me fix 48259 really easily
While using http://www.dclp-faq.de/, I tried to focus the "Suchen" field using the defined accesskey, but neither "Alt-S" nor "Control-S" did work. Support for "accesskey" in Konqueror is needed.
Please ppl, add accesskey support, it is needed for visually impaired and is quite handy for normal users.
So how is the progress? I hear this bug will be finally resolved in KDE 3.2, will it be backported as well then?
Yeah, just *do* it... It shouldn't be that hard (I already see the startover in kthml commented out with "#if 0" in the sources...) And I would consider this to be a real bug, not only a "wishlist" item.
*** Bug 19401 has been marked as a duplicate of this bug. ***
*** Bug 65033 has been marked as a duplicate of this bug. ***
People say this is a bug and from the description I agree. Is this resolved now? What's the status?
Does not work in "Tereza".
Yeah, it works in Mozilla, Netscape 6, IE4(!), Opera 7, Amaya and iCab. It's a great feature for the disabled (some 15% of the world's population, or 25% if you include those with visual difficulties). But as well as that, it's pretty useful for laptop users, or anybody else who has a crappy mouse (or no mouse at all)! As well as the legal implications, it looks as though a standard key scheme has finally emerged, and it now in widespread use in the UK, mainland Europe, USA and Australia... http://www.clagnut.com/blog/193 So hopefully KDE can be the last major browser to introcude support for this.
I would like to see that too therefore I voted for this "bug" :-) I've to agree with #10... even the w3c put it on there wai-checklist (Prio3, http://www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html).
Changing severity from "wishlist" to "normal" since a bug and not a wish is what this report really is about. I'm personally tempted to give it an even higher severity.
It has been saying on http://www.kde.org/media/accesskeys.php since about November that "access key support is currently being implemented", and I was just wondering the status on this? If we're going with the standard Mozilla/Opera/Amaya approach (ie follow a link when the key is pressed), then I would have thought it would only take a few days? Maybe I'm missing something. And presumably once implemented it will trickle down into Safari and Omni?
Basic elements should work, even backported for KDE3.2.2 (http://lists.kde.org/?l=kfm-devel&m=107902290707432&w=2).
The accesskey system was recently updated for KDE 3.3 & should work fine. You now have to press & release the ctrl key, then press the accesskey. That way, there is no shortcut conflict. Still, there is a minor problem: Accesskeys don't work if you are inside a file input widget or a textarea. I am leaving the bug open until this can be fixed...
Thanks Tobias! The last problem is now fixed and accesskeys are now fully supported in konqueror!
In KDE 3.4, if the focus is in a file upload field (input type=file) and an accesskey activated for another field (press and release ctrl, type a character corresponding to an accesskey), then instead of changing the focus to the field corresponding to the typed accesskey, the character is added to the file field.
Works with CVS HEAD.