Bug 121572 - Support tabindex on all elements
Summary: Support tabindex on all elements
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Compiled Sources Other
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-08 04:04 UTC by Aaron Leventhal
Modified: 2024-05-06 18:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Leventhal 2006-02-08 04:04:11 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Other

Support tabindex for all elements, thus enabling accessible DHTML/AJAX web
applications. Both IE and Gecko-based browsers such as Firefox now support
tabIndex on all elements. The Web Applications spec from WHATWG also enables
tabIndex for all elements
(http://whatwg.org/specs/web-apps/current-work/#the-tabindex)

Basically, any element such as a div or span can be added to the default tab
order by setting tabindex="0". In addition, any item with tabindex="-1" can be
focused via script or mouse. 

The tabindex system is needed for developing custom widgets which are
accessible, from simple widgets like a slider to container widgets like a
menubar, tree view or spreadsheet. IBM needs this for web apps it is
developing, in order for them to run properly. Other large
organizations are also picking up DHTML accessibility as well.

* The Gecko documentation on what the behavior should be is here:
http://www.mozilla.org/access/keyboard/tabindex
* The MSDN docs for IE's tabindex behavior is here:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/tabindex.asp
* Test cases and more docs about DHTML accessibility here:
http://www.mozilla.org/access/dhtml
* W3C standards work in this area:
http://www.w3.org/WAI/PF/roadmap/DHTMLRoadmap110505.html

Work we had to do in Gecko (see
https://bugzilla.mozilla.org/show_bug.cgi?id=171366):
- Have each element class support an IsFocusable method which also returns a
boolean out to indicate whether it is tabbable.
  Specific implementations of the method need to upcall to the generic
element's method, which jas the generic tabindex implementation..
  Then the scripting, mouse click handling and tab key handling  code needs to
use the new IsFocusable() method.
- Support the focus() method in nsIDOMNSHTMLElement, which is outside of the
official DOM interface but is supported fro all elements.
- Add rules to the default style sheet so that any element with :focus receives
a focus outline
- Make cancelling an keydown event cancel the keypress event, for purposes of
compatibility with IE. Authors writing cross-browser content should use keydown
events to process keystrokes, because IE won't fire keypress events for
non-alphanumeric keys.
- Ensure that all elements which are focusable are exposed in the accessibility
API hierarchy, so that when they get focused there is an object to fire an
accessibility event for.
- Any element that can receive focus must fire onfocus/onblur

Note: I just filed the same bug for WebKit: I just filed a bug in opendarwin: http://bugzilla.opendarwin.org/show_bug.cgi?id=7138
This is not bug 48341, it goes much further than that.
Comment 1 Maksim Orlovich 2006-02-09 03:19:17 UTC
Thanks for the info (plus it explains what people may expect from tabIndex = -1 -- no, I didn't report that bug, silly script put me as reporter because I handled it). I think we actually have most of the bits for supporting this --- I might just need to, well, add a single if to our isFocusable() method to get things to be tabable. Though tabIndex = -1 may take more work. 

I think the only difficult part here is about cancelling the key event --- the code for mapping from Qt events to/from DOM events is quite subtle. And, uhm, I think we implemented the keypress cancellation to match mozilla!


Comment 2 Aaron Leventhal 2006-02-09 19:50:15 UTC
Does isFocusable let you know if something is tabbable?

isTabbable should be a subset of the items which are focusable.

For example, an item in a list is focusable but not tabbable. That often goes for children in complex container widgets.
Comment 3 Maksim Orlovich 2006-02-23 17:30:51 UTC
Sort of, there is isTabFocusable, and isMouseFocusable, but some code just uses the generic isFocusable (which ought to be protected, as it's only meant to be a default for both). And the tabIndex handling code looks a bit iffy/I've seen it do some funny things. So will need some cleanup/audit first.


Comment 4 Maksim Orlovich 2011-05-17 14:46:33 UTC
Git commit 8fdb65112cb87f07d25433bcfe5a6c9913984277 by Maks Orlovich.
Committed on 08/05/2011 at 22:12.
Pushed by orlovich into branch 'master'.

Handle tabIndex every where, as per ARIA

CCBUG: 121572
CCBUG: 158857

M  +6    -19   khtml/ecma/kjs_html.cpp     
M  +9    -10   khtml/ecma/kjs_html.h     
M  +4    -2    khtml/html/html_baseimpl.cpp     
M  +1    -1    khtml/html/html_baseimpl.h     
M  +4    -2    khtml/html/html_elementimpl.cpp     
M  +14   -1    khtml/html/html_formimpl.cpp     
M  +2    -4    khtml/html/html_formimpl.h     
M  +6    -0    khtml/html/html_inlineimpl.cpp     
M  +1    -1    khtml/html/html_inlineimpl.h     
M  +5    -25   khtml/svg/SVGAElement.cpp     
M  +1    -3    khtml/svg/SVGAElement.h     
M  +28   -3    khtml/xml/dom_elementimpl.cpp     
M  +4    -2    khtml/xml/dom_elementimpl.h     
M  +13   -3    khtml/xml/dom_nodeimpl.h     

http://commits.kde.org/kdelibs/8fdb65112cb87f07d25433bcfe5a6c9913984277
Comment 5 Christoph Cullmann 2024-05-06 18:39:09 UTC
Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann