I. UI-Core
1. tabbable & focusable
i refactored the tabbable-selector and added a new selector called
focusable:
a) i think the tabbable selector was broken: everything, that is in
tab order (tabIndex higher -1) and is visible should be tabbable.We don
´t have to check wether the element is natively tabblable. The only
browser, wich doesn´t support the "advanced" tabindex-attribute yet is
Safari. I think, we don´t have to address this special case. (Safari 4
will have Aria and tabindex-Support).
2. setFocus & stopFocus
In Aria we should use a setTimeout to focus elements. I added a little
jQuery-Plugin, wich wraps the focus in a timeout.
II. UI-Dialog
1. Configuration:
a) dialogRole
The ui-dialog adds the dialog-Role. I made this configurable, because
aa) the dialog role hasn´t good support yet (the author should be able
to use the alertdialog-role, wich has very good support)
bb) the dialog role is an application role. But sometimes a author
wants to use a document-role
b) closeHTML
I made the innerHTML of the close-link configurable. The default is
now:<span>X</span><span class="ui-accessible-hidden"> close</span> and
i added a button-role attribute to the close-link.
c) setFocus
I added the posibility to decide, wich element of the dialog gets
focus, if it is opened. The default is now the title of the dialog,
before it was the close-link (This sounds much better in
screenreaders. Testet with Jaws 9 and NVDA)
2. Opener & reFocusElem
I have added a parameter to the open-Method, wich can take a dom-
element, that recieves focus. if the dialog is closed (by itself).
I don´t know, how we should properly and elegantly handle the setFocus-
option and reFocusElem-Parameter, if the option autoopen is turned on.
-------
One big remaining issue:
I think, that we should look harder to the visual styling of focused
items. This is a huge problem in all of the ui-themes and the jquery-
site, too.
> I. UI-Core > 1. tabbable & focusable > i refactored the tabbable-selector and added a new selector called > focusable: > a) i think the tabbable selector was broken: everything, that is in > tab order (tabIndex higher -1) and is visible should be tabbable.We don > ´t have to check wether the element is natively tabblable. The only > browser, wich doesn´t support the "advanced" tabindex-attribute yet is > Safari. I think, we don´t have to address this special case. (Safari 4 > will have Aria and tabindex-Support).
I think I'm okay with the tabbable selector ignoring node types, but I don't think your implementation is correct. I haven't tested this yet, but it looks like it will return input elements that have a tabindex of -1 because everything is combined in an or.
Is there really a difference between tabbable and focusable? I think of them as being exactly the same.
> 2. setFocus & stopFocus > In Aria we should use a setTimeout to focus elements. I added a little > jQuery-Plugin, wich wraps the focus in a timeout.
Can you provide some background on why this is needed? Is this simply to ensure that the current process (adding/changing/removing elements/attributes) is done before we set focus so that screen readers know all the context at the time of focus?
II. UI-Dialog
> 1. Configuration: > a) dialogRole > The ui-dialog adds the dialog-Role. I made this configurable, because > aa) the dialog role hasn´t good support yet (the author should be able > to use the alertdialog-role, wich has very good support) > bb) the dialog role is an application role. But sometimes a author > wants to use a document-role
This sounds like a good addition.
> b) closeHTML > I made the innerHTML of the close-link configurable. The default is > now:<span>X</span><span class="ui-accessible-hidden"> close</span> and > i added a button-role attribute to the close-link.
We've been having some discussion about this. Can you provide any insight about the benefits or drawbacks of your suggested markup vs. the following markup?
> c) setFocus > I added the posibility to decide, wich element of the dialog gets > focus, if it is opened. The default is now the title of the dialog, > before it was the close-link (This sounds much better in > screenreaders. Testet with Jaws 9 and NVDA)
This sounds like a good addition. I'd like to expand the option to accept a selector, DOMElement, jQuery object, or function.
2. Opener & reFocusElem
> I have added a parameter to the open-Method, wich can take a dom- > element, that recieves focus. if the dialog is closed (by itself).
> I don´t know, how we should properly and elegantly handle the setFocus- > option and reFocusElem-Parameter, if the option autoopen is turned on.
Perhaps we should add an option for which element should receive focus when the dialog is closed and allow it to be overriden on a per-use basis by passing an element in to the open method. I'm not sure if it's common for focus to go to the same element every time a dialog is closed, so it may not make sense to create an option for that. Either way, I think it's probably fine to not handle this with the autoOpen option. Users can easily do $(el).dialog({autoOpen: false}).dialog('open', focusElement);
One big remaining issue:
> I think, that we should look harder to the visual styling of focused > items. This is a huge problem in all of the ui-themes and the jquery- > site, too.
Feel free to start another thread focused on this to get some discussion started.
> sorry about my english.
> regards > alex
Your English seems perfectly fine :-) Thanks for all of your suggestions and work. I'll make sure to update this thread as progress is made. These changes may need to wait until after the 1.6 release.
> I think I'm okay with the tabbable selector ignoring node types, but I > don't think your implementation is correct. I haven't tested this > yet, but it looks like it will return input elements that have a > tabindex of -1 because everything is combined in an or.
Yes, you are right. I didn´t think of it.
> Is there really a difference between tabbable and focusable? I think > of them as being exactly the same.
Yes: if you want to know, wether the element is focusable by the user, you should use tabbable, if it is focusable by the author via javascript you would use focusable.
> 2. setFocus & stopFocus
> Can you provide some background on why this is needed? Is this simply > to ensure that the current process (adding/changing/removing > elements/attributes) is done before we set focus so that screen > readers know all the context at the time of focus?
I read the following text in the W3C ARIA Best Practises document: "/Use setTimeout with element.focus() to set focus/ - Do not use createEvent(), initEvent() and dispatchEvent() to send focus to an element, because DOM focus events are considered informational only -- generated by the system after something is focused, but not actually used to set focus. The timeout is necessary in both IE and Firefox 1.5, to prevent scripts from doing strange unexpected things as the user clicks on buttons and other controls."
> b) closeHTML > I made the innerHTML of the close-link configurable. The default is > now:<span>X</span><span class="ui-accessible-hidden"> close</span> and > i added a button-role attribute to the close-link.
> We've been having some discussion about this. Can you provide any > insight about the benefits or drawbacks of your suggested markup vs. > the following markup?
> I have added a parameter to the open-Method, wich can take a dom- > element, that recieves focus. if the dialog is closed (by itself).
> I don´t know, how we should properly and elegantly handle the > setFocus- > option and reFocusElem-Parameter, if the option autoopen is turned on.
> 2. Opener & reFocusElem
> Perhaps we should add an option for which element should receive focus > when the dialog is closed and allow it to be overriden on a per-use > basis by passing an element in to the open method. I'm not sure if > it's common for focus to go to the same element every time a dialog is > closed, so it may not make sense to create an option for that. Either > way, I think it's probably fine to not handle this with the autoOpen > option. Users can easily do $(el).dialog({autoOpen: > false}).dialog('open', focusElement);
This sounds fine.
I will make some changes in a few days, according to what you say(ed).
> c) setFocus > I added the posibility to decide, wich element of the dialog gets > focus, if it is opened. The default is now the title of the dialog, > before it was the close-link (This sounds much better in > screenreaders. Testet with Jaws 9 and NVDA)
I like the ability to choose what gets focus when a dialog is opened. I'm curious about the choice of defaulting to focussing the title of the dialog. It seems to me that it would be a more natural user experience for focus to be on the first thing they can interact with - the first thing in tab order perhaps. The title should be read since there is a labeled by attribute. Was this not the case for you?
i have updatet the source and the demo files. the selector bug is
fixed now, some tests were added (http://protofunc.com/scripts/jquery/ ui-dialog/tests/core.html), and i modified the demos, to show some of
the new functionality. (simple dialog, modal dialog and dialog with
buttons). (+ I fixed one ariaState-bug in IE).
Open/closed issues:
1. I think the autoopen-Issue isn´t this big problem, i thought.
Scotts Suggestion is fine. ($(el).dialog({autoOpen:
false}).dialog('open', focusElement); )
2. The default HTML for the close-Button needs to be defined. But this
isn´t an important thing (It´s cusomizable, so everybody gets what he/
she wants).
3. The default setFocus-option is in discussion. I really think it
should be the title/label-element:
a) Like I already sayed the dialog-role has quite bad support. The
label-element isn´t read automatic. (In Jaws 9 and NVDA) To focus the
label/titel element is a nice workaround. (works in Jaws and NVDA)
b) the first element in taborder is the close-button (not really nice)
c) there is no focusable element in the content area, we can lean on.
d) it´s cusomizable (look to the demo 'dialog with buttons')
4. focusable in Safari 3.
Safari 4 will have aria-extended tabindex support. But Safari 3 doesn
´t have support for this. I implemented the selector according to the
Aria-Specification. This meens, that in Safari some elements are
treated as focusable, but you can´t focus them.
Should i change this? The downside would be, that the returned
elements can vary between safari and the other browsers (IE5+, FF 1.5+
and Opera 9.5+).
On Oct 27, 4:18 pm, alexander farkas <i...@corrupt-system.de> wrote:
> 2. The default HTML for the close-Button needs to be defined. But this
> isn´t an important thing (It´s cusomizable, so everybody gets what he/
> she wants).
There is still some work that needs to go into this, if only for
i18n. The HTML shouldn't contain language-specific text because it
makes changing the language dependent on the markup.
> 4. focusable in Safari 3.
> Safari 4 will have aria-extended tabindex support. But Safari 3 doesn
> ´t have support for this. I implemented the selector according to the
> Aria-Specification. This meens, that in Safari some elements are
> treated as focusable, but you can´t focus them.
> Should i change this? The downside would be, that the returned
> elements can vary between safari and the other browsers (IE5+, FF 1.5+
> and Opera 9.5+).
The selector definitely has to work the same cross-browser. This
would normally mean that the selector can return different results
than you would normally get from Safari 3. However, because doing so
would break accessibility (we wouldn't be able to focus on the
elements that we're trying to focus on), this isn't acceptable. I
think until we can drop support for Safari 3, we'll need to have it
return the limited set (continue using current implementation).
When Safari 4 is released, will there be a difference between tabbable
and focusable?
> The selector definitely has to work the same cross-browser. This > would normally mean that the selector can return different results > than you would normally get from Safari 3. However, because doing so > would break accessibility (we wouldn't be able to focus on the > elements that we're trying to focus on), this isn't acceptable. I > think until we can drop support for Safari 3, we'll need to have it > return the limited set (continue using current implementation).
> When Safari 4 is released, will there be a difference between tabbable > and focusable?
Hi,
Ok, my english is too bad. I´m a little bit confused. I try to explain the hole thing:
The Aria - extension of the tabindex-attribute adds 2 new possibilties (This concept was added form Microsoft, so it works in IE5+). This concept was adapted with FF 1.5 and Opera 9.5.
I. the tabindex-attribute 1. crossbrowser focus & tabindex Normally there is only a subset of elements (a, input and so on), that can recieve focus. You can change the taborder by adding a specified tabindex attribute. You can add a negative tabindex value to move the element out of the taborder, but you can still focus it with javascript.
2. the aria-extension of tabindex (doesn´t work in safari) Every element can recieve focus. If an element can not recieve focus by default. The only thing you have to do is to add a tabindex-attribute. http://www.w3.org/TR/wai-aria-practices/#kbd_focus This doesn´t work in Safari 3. For example a div element can never recieve focus in Safari.
II. difference between focusable & tabbable The tabbable selector should return all elements, that can recieve focus by the user. the focusable selector should return all elements that can be focused by the javascript-author.
the tabbable selector returns a subset of the focusable elements.
this is the difference of both selectors and they will remain.
III. the current selector implementation in all browsers the focusable and the tabbable selector can return elements, that are not focusable or tabbable in safari 3. for example:
<div tabindex="0"></div>
should be tabbable (and focusable), but this doesn´t work in safari. although my current selector implemention says, that this is tabbable and focusable even in safari.
III. we shouldn´t support accessibility in Safari 3
It is right, that jquery and jquery ui are supporting Safari. But i think we don´t have to bother about accessibility in Safari 3. The tabindex extension is essential to the aria specification. We cannot implement a proper keyboard usage and aria-semantics in safari3. I think this decision was already made by some of the ui-developers: for example the accordion - widget is using tabindex=0 on the header-elements to provide keyboard accessibility. This doesn´t work in safari, but who cares :-). On the other side: The slider widget is using an empty link-element, to provide a cross-browser way of keyboard support. but empty links are really bad for accessibility: http://yuiblog.com/blog/2008/01/23/empty-links/
The only question is, should the selector return the elements, that are focusable in the current browser (different elements in different browsers) or should it return the elements, that should be able to recieve focus, according to the aria specifications (current implementation). But i would accept the fact, that we try to focus an element that isn´t focusable in safari, because disabled users won´t use a browser that is not accessible at all.
Did i unterstand you right, that i should change the selector, so it is returning the elements, that are really focusable or tabbable in the specific browser (this isn´t the current implementation)?
i hope i could explain it right. if not, look to the tests, i added to the test-suite and see what i´m expecting in the results.
Thanks for the really detailed explanation, that helped me out a lot. I
think the point you made about disabled users not using a browser that
doesn't support accessibility well is enough to justify "broken" widgets in
Safari 3. Let's keep the selectors working as they are defined in the specs
(what you've already done). I'll verify whether this is acceptable by the
team tomorrow.
On Tue, Oct 28, 2008 at 4:24 AM, Alexander Farkas <i...@corrupt-system.de>wrote:
> Scott González schrieb:
> > The selector definitely has to work the same cross-browser. This
> > would normally mean that the selector can return different results
> > than you would normally get from Safari 3. However, because doing so
> > would break accessibility (we wouldn't be able to focus on the
> > elements that we're trying to focus on), this isn't acceptable. I
> > think until we can drop support for Safari 3, we'll need to have it
> > return the limited set (continue using current implementation).
> > When Safari 4 is released, will there be a difference between tabbable
> > and focusable?
> Hi,
> Ok, my english is too bad. I´m a little bit confused. I try to explain
> the hole thing:
> The Aria - extension of the tabindex-attribute adds 2 new possibilties
> (This concept was added form Microsoft, so it works in IE5+). This
> concept was adapted with FF 1.5 and Opera 9.5.
> I. the tabindex-attribute
> 1. crossbrowser focus & tabindex
> Normally there is only a subset of elements (a, input and so on), that
> can recieve focus. You can change the taborder by adding a specified
> tabindex attribute. You can add a negative tabindex value to move the
> element out of the taborder, but you can still focus it with javascript.
> 2. the aria-extension of tabindex (doesn´t work in safari)
> Every element can recieve focus. If an element can not recieve focus by
> default. The only thing you have to do is to add a tabindex-attribute.
> http://www.w3.org/TR/wai-aria-practices/#kbd_focus > This doesn´t work in Safari 3. For example a div element can never
> recieve focus in Safari.
> II. difference between focusable & tabbable
> The tabbable selector should return all elements, that can recieve focus
> by the user. the focusable selector should return all elements that can
> be focused by the javascript-author.
> the tabbable selector returns a subset of the focusable elements.
> this is the difference of both selectors and they will remain.
> III. the current selector implementation in all browsers
> the focusable and the tabbable selector can return elements, that are
> not focusable or tabbable in safari 3. for example:
> <div tabindex="0"></div>
> should be tabbable (and focusable), but this doesn´t work in safari.
> although my current selector implemention says, that this is tabbable
> and focusable even in safari.
> III. we shouldn´t support accessibility in Safari 3
> It is right, that jquery and jquery ui are supporting Safari. But i
> think we don´t have to bother about accessibility in Safari 3. The
> tabindex extension is essential to the aria specification. We cannot
> implement a proper keyboard usage and aria-semantics in safari3. I think
> this decision was already made by some of the ui-developers: for example
> the accordion - widget is using tabindex=0 on the header-elements to
> provide keyboard accessibility. This doesn´t work in safari, but who
> cares :-). On the other side: The slider widget is using an empty
> link-element, to provide a cross-browser way of keyboard support. but
> empty links are really bad for accessibility:
> http://yuiblog.com/blog/2008/01/23/empty-links/
> The only question is, should the selector return the elements, that are
> focusable in the current browser (different elements in different
> browsers) or should it return the elements, that should be able to
> recieve focus, according to the aria specifications (current
> implementation). But i would accept the fact, that we try to focus an
> element that isn´t focusable in safari, because disabled users won´t use
> a browser that is not accessible at all.
> Did i unterstand you right, that i should change the selector, so it is
> returning the elements, that are really focusable or tabbable in the
> specific browser (this isn´t the current implementation)?
> i hope i could explain it right. if not, look to the tests, i added to
> the test-suite and see what i´m expecting in the results.
I. UI-Core
1. tabbable & focusable
i refactored the tabbable-selector and added a new selector called
focusable:
a) i think the tabbable selector was broken: everything, that is in
tab order (tabIndex higher -1) and is visible should be tabbable.We don
´t have to check wether the element is natively tabblable. The only
browser, wich doesn´t support the "advanced" tabindex-attribute yet is
Safari. I think, we don´t have to address this special case. (Safari 4
will have Aria and tabindex-Support).
2. setFocus & stopFocus
In Aria we should use a setTimeout to focus elements. I added a little
jQuery-Plugin, wich wraps the focus in a timeout.
II. UI-Dialog
1. Configuration:
a) dialogRole
The ui-dialog adds the dialog-Role. I made this configurable, because
aa) the dialog role hasn´t good support yet (the author should be able
to use the alertdialog-role, wich has very good support)
bb) the dialog role is an application role. But sometimes a author
wants to use a document-role
b) closeHTML
I made the innerHTML of the close-link configurable. The default is
now:<span>X</span><span class="ui-accessible-hidden"> close</span> and
i added a button-role attribute to the close-link.
c) setFocus
I added the posibility to decide, wich element of the dialog gets
focus, if it is opened. The default is now the title of the dialog,
before it was the close-link (This sounds much better in
screenreaders. Testet with Jaws 9 and NVDA)
2. Opener & reFocusElem
I have added a parameter to the open-Method, wich can take a dom-
element, that recieves focus. if the dialog is closed (by itself).
I don´t know, how we should properly and elegantly handle the setFocus-
option and reFocusElem-Parameter, if the option autoopen is turned on.
-------
One big remaining issue:
I think, that we should look harder to the visual styling of focused
items. This is a huge problem in all of the ui-themes and the jquery-
site, too.
> Thanks for the really detailed explanation, that helped me out a lot. I
> think the point you made about disabled users not using a browser that
> doesn't support accessibility well is enough to justify "broken" widgets in
> Safari 3. Let's keep the selectors working as they are defined in the specs
> (what you've already done). I'll verify whether this is acceptable by the
> team tomorrow.
> So it took much longer than a day, but this proposal was approved.
> On Oct 28, 8:04 am, "Scott González" <scott.gonza...@gmail.com> wrote:
> > Thanks for the really detailed explanation, that helped me out a lot. I
> > think the point you made about disabled users not using a browser that
> > doesn't support accessibility well is enough to justify "broken" widgets in
> > Safari 3. Let's keep the selectors working as they are defined in the specs
> > (what you've already done). I'll verify whether this is acceptable by the
> > team tomorrow.
> It's a combination of your implementation, the previous UI
> implementation and some ideas I've been playing around with.
Hi Scott,
Your code looks much more clean, great.
The only thing, i saw is the old discussion how to handle Safari.
Safari doesn´t have the tabindex-property on all elements. If you want
the selector to return the same elements in all browsers, you have to
use the getAttribute-method first and if there is no result you have
to check the tabindex-property:
var tabIndex = parseInt(element.getAttribute('tabIndex'), 10);
(isNaN(tabIndex) && (tabIndex = element.tabIndex));
Thanks. I spent a lot of time trying to figure out why you were doing
that and couldn't figure it out. I'll fix that and write some tests.
Can you check the existing tests for the tabbable selector and see if
any cases are missing? Thanks.
On 11/9/08, alexander farkas <i...@corrupt-system.de> wrote:
>> It's a combination of your implementation, the previous UI
>> implementation and some ideas I've been playing around with.
> Hi Scott,
> Your code looks much more clean, great.
> The only thing, i saw is the old discussion how to handle Safari.
> Safari doesn´t have the tabindex-property on all elements. If you want
> the selector to return the same elements in all browsers, you have to
> use the getAttribute-method first and if there is no result you have
> to check the tabindex-property:
Once I'm done with those three, I'll work on the close button and the
dialog role. Then I'll review your proposal for defining which
elements should get focus on open/close.
In short, directly referring to the attribute as "tabIndex" will break in XHTML documents due to case-sensitivity. The value of tabindex is also incorrectly reported in Internet Explorer for elements that don't actually have one set. So, for example, if you've got a plain old <div> with no tabindex attribute, IE 6 & 7 will compute a tabIndex value of "0," which is incorrect.
I implemented code to work around these issues in my jQuery keyboard accessibility plugin. Here's the implementation:
// Normalizes the tabindex attribute name across browsers. var normalizeTabindexName = function() { return $.browser.msie ? "tabIndex" : "tabindex"; };
// Checks if a tabindex attribute is actually present on the first element of this jQuery instance. $.fn.hasTabindexAttr = function() { if (this.length <= 0) { return false; }
>> Can you provide some background on why this is needed? Is this >> simply >> to ensure that the current process (adding/changing/removing >> elements/attributes) is done before we set focus so that screen >> readers know all the context at the time of focus? > I read the following text in the W3C ARIA Best Practises document: > "/Use setTimeout with element.focus() to set focus/ - Do not use > createEvent(), initEvent() and dispatchEvent() to send focus to an > element, because DOM focus events are considered informational only -- > generated by the system after something is focused, but not actually > used to set focus. The timeout is necessary in both IE and Firefox > 1.5, > to prevent scripts from doing strange unexpected things as the user > clicks on buttons and other controls."
I'm late to this thread, but I'm curious to know more details about this issue. If I remember correctly, Aaron Leventhal ran across this issue way back in the early days of ARIA, but I've never read any details about what the "strange unexpected things" actually are in practice.
I found other sorts of hard to pin down quirkiness in my keyboard-a11y plugin when I did wrap focus() calls in setTimeout. I think focus and blur events are probably some of the more arcane areas of the browser, and it can be really hard to debug. I managed to get full FF 1.5 and IE compliance without using setTimeout() at all, so I wonder if we really need it here?
Maybe David Bolter has some insights either from his Dojo experience or the ARIA group about this particular issue?
Thanks for jogging my memory about tabindex vs tabIndex. Dojo
normalized this in core (specifically in _base/html.js). Note IE8
doesn't require the camel case as far as I know.
I can't recall the timer issue. I do remember having one heck of a
time trying to trust form element value/state at the time of focus
(or blur) events cross-browser. The order of focus, blur, onchange
and and other DOM events is unspecified as far as I know... or at
least not implemented the same.
I haven't read this thread yet, but thought I'd throw this out there.
I'm humbled by my inbox.
cheers,
D
On Nov 10, 11:53 am, Colin Clark <colinbdcl...@gmail.com> wrote:
> On 26-Oct-08, at 11:50 AM, Alexander Farkas wrote:
> >> 2. setFocus & stopFocus
> >> Can you provide some background on why this is needed? Is this
> >> simply
> >> to ensure that the current process (adding/changing/removing
> >> elements/attributes) is done before we set focus so that screen
> >> readers know all the context at the time of focus?
> > I read the following text in the W3C ARIA Best Practises document:
> > "/Use setTimeout with element.focus() to set focus/ - Do not use
> > createEvent(), initEvent() and dispatchEvent() to send focus to an
> > element, because DOM focus events are considered informational only --
> > generated by the system after something is focused, but not actually
> > used to set focus. The timeout is necessary in both IE and Firefox
> > 1.5,
> > to prevent scripts from doing strange unexpected things as the user
> > clicks on buttons and other controls."
> I'm late to this thread, but I'm curious to know more details about
> this issue. If I remember correctly, Aaron Leventhal ran across this
> issue way back in the early days of ARIA, but I've never read any
> details about what the "strange unexpected things" actually are in
> practice.
> I found other sorts of hard to pin down quirkiness in my keyboard-a11y
> plugin when I did wrap focus() calls in setTimeout. I think focus and
> blur events are probably some of the more arcane areas of the browser,
> and it can be really hard to debug. I managed to get full FF 1.5 and
> IE compliance without using setTimeout() at all, so I wonder if we
> really need it here?
> Maybe David Bolter has some insights either from his Dojo experience
> or the ARIA group about this particular issue?
1. tabindex and focusable/tabbable-selector.
Colin is right, great catch. I added some tests to my local testsuite
and the test fails in all Browsers. For example in FF there is always
a tabindex-property on all elements (-1). So there is a lot to do and
forgive my mistakes :-(
I will look in Colin´s code and try to fix all known issues
Should I update the testsuite on my server or do you have a better way
to share tests and code?
2. setFocus
a) timeout
I think this is especially a problem with form elements. I suppose the
button itself gets focus after the click event is triggered in some
browsers. I didn´t expierenced this problem yet (because/but i almost
used a timeout).
In one case, i had a focus-problem with an accordion menu and jaws,
that i could solve with a timeout. if the user opened a subnavigation
and i focused the container of this subnav jaws jumped over it to the
next heading. i had to add a timeout of 180ms (or more) to get it work
right.
so i don´t know wether we normally should use a timeout to focus, but
it can be useful in some cases.
focus can be very strange.For example jQuery triggers focus twice in
IE.
b) focusable-Check
I think we should delete the focusable check in the setFocus-Method.
Traversing the hole tree above, can be very problematic in some widget
(for example in a menu-widget where you also should set the focus, if
the mouse enters a menuitem...).
On Mon, Nov 10, 2008 at 5:08 PM, alexander farkas <i...@corrupt-system.de>wrote:
> Hi,
> 1. tabindex and focusable/tabbable-selector. > Colin is right, great catch. I added some tests to my local testsuite > and the test fails in all Browsers. For example in FF there is always > a tabindex-property on all elements (-1). So there is a lot to do and > forgive my mistakes :-(
> I will look in Colin´s code and try to fix all known issues
> Should I update the testsuite on my server or do you have a better way > to share tests and code?
I'll try to create a branch in the UI SVN just for these selectors so we can work on it collectively. Do you have commit access? If not, I'll set it up for you.
> a) timeout > I think this is especially a problem with form elements. I suppose the > button itself gets focus after the click event is triggered in some > browsers. I didn´t expierenced this problem yet (because/but i almost > used a timeout).
> In one case, i had a focus-problem with an accordion menu and jaws, > that i could solve with a timeout. if the user opened a subnavigation > and i focused the container of this subnav jaws jumped over it to the > next heading. i had to add a timeout of 180ms (or more) to get it work > right.
> so i don´t know wether we normally should use a timeout to focus, but > it can be useful in some cases.
> focus can be very strange.For example jQuery triggers focus twice in > IE.
Yeah, the problems occur when you're trying to set focus in the middle of certain events. The problem arises because you set focus before the default action occurs for the event that you're reacting to. For example, if you're handling a keypress event, the actual keypress won't occur until after the handler finishes running. This can obviously be problematic, especially if you're handling a key press of tab. This is why dialog already uses a setTimeout for setting focus in modal dialogs.
b) focusable-Check
> I think we should delete the focusable check in the setFocus-Method. > Traversing the hole tree above, can be very problematic in some widget > (for example in a menu-widget where you also should set the focus, if > the mouse enters a menuitem...).
Yeah, that check is overkill. I'll put it back to what you had (just check that it has a tabindex set).
On Mon, Nov 10, 2008 at 8:51 PM, Scott González <scott.gonza...@gmail.com>wrote:
> Yeah, that check is overkill. I'll put it back to what you had (just check > that it has a tabindex set).
Heh, so that's probably confusing you. Apparently, I had already done this in my local code and I was thinking that it was the other way around (I thought you just checked tabindex and I changed it to :focusable).
On Mon, Nov 10, 2008 at 8:51 PM, Scott González <scott.gonza...@gmail.com>wrote:
> I'll try to create a branch in the UI SVN just for these selectors so we > can work on it collectively. Do you have commit access? If not, I'll set > it up for you.
This is available in /branches/experimental/tabbable. It's mostly just a copy of the code I pasted in codedumper, so it still needs to be updated for everything Colin pointed out and needs a lot more tests.
> On Mon, Nov 10, 2008 at 8:51 PM, Scott González <scott.gonza...@gmail.com > > wrote: > I'll try to create a branch in the UI SVN just for these selectors > so we can work on it collectively. Do you have commit access? If > not, I'll set it up for you.
> This is available in /branches/experimental/tabbable. It's mostly > just a copy of the code I pasted in codedumper, so it still needs to > be updated for everything Colin pointed out and needs a lot more > tests.
I've created a patch for the tabbable functionality in your branch, providing cross-browser normalization for the tabindex attribute. Let me know what you think; I hope the style is appropriate for jQuery UI.
There's a fair bit more code from my plugin that I'd be happy to migrate over if it's useful, including the ability to get and set tabindex values properly across browsers.
Colin
--- Colin Clark Technical Lead, Fluid Project Adaptive Technology Resource Centre, University of Toronto http://fluidproject.org
nice work, you are to fast for me :-). I was currently working on this
and looking to your implementation and then I saw, that you have done
the work for me :-). I merged your code with mine and finally all
written tests are greeen (Testet in FF3, Opera 9.5, Safari 3 and IE6-
IE8) :-).
Some changes to your code:
1. MSIE-Detection: ($.browser.msie && parseInt($.browser.version, 10)
< 8) > ($.browser.msie < 8)
2. area is treated like an anchor tag
3. moved the performance-expensive hidden-Tests to the bottom
