Hi,
i tryed to add some improvements to the core and to the dialog.
Demo: http://protofunc.com/scripts/jquery/ui-dialog/demos/functional/index.html#ui.dialog
Source: http://protofunc.com/scripts/jquery/ui-dialog.zip
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.
sorry about my english.
regards
alex
> 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).
>
>
On 26-Oct-08, at 8:50 AM, alexander farkas wrote:
>
> II. UI-Dialog
>
> 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?
Thanks,
Michelle
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.
Here is a simple test-case (the div-element turns blue, if it is focused
by javascript, it is not tabbable by the user):
http://protofunc.com/scripts/jquery/ui-dialog/ui/test.html
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.
regards
alex
Nice work! We've run into a number of cross-browser quirks with the
tabindex attributes. For all the gory details, check out this blog post:
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;
}
var attributeNode =
this[0].getAttributeNode(normalizeTabindexName());
return attributeNode ? attributeNode.specified : false;
};
I hope this helps,
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
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?
Colin
---
Colin Clark
Technical Lead, Fluid Project
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?
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...).
Yeah, that check is overkill. I'll put it back to what you had (just check that it has a tabindex set).
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.
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.
http://ui.jquery.com/bugs/ticket/3559
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