UI-Dialog & UI-Core Accessibility Improvements
alexander farkas
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
Scott González
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).
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?
<span class="ui-dialog-titlebar-close"><button type="button">close</button></span>
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.
Alexander Farkas
>
>
> I. UI-Core
> 1. tabbable & focusable
>
>
> 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.
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?
"/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?
>
> <span class="ui-dialog-titlebar-close"><button
> type="button">close</button></span>
markup (already´uggested), too:
<abbr title="close">X</abbr>
> 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).
>
>
Michelle D'Souza
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
alexander farkas
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+).
regards
alex
Scott González
> 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).
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+).
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?
Alexander Farkas
> 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?
>
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
Scott González
Rich Caloggero
I like the additions.
-- Rich
Scott González
David Bolter
D
Scott González
Can you take a look at this implementation of :focusable
and :tabbable?
http://codedumper.com/icuda
It's a combination of your implementation, the previous UI
implementation and some ideas I've been playing around with.
alexander farkas
On Nov 8, 11:25 pm, Scott González <scott.gonza...@gmail.com> wrote:
> Hey Alex,
>
> Can you take a look at this implementation of :focusable
> It's a combination of your implementation, the previous UI
> implementation and some ideas I've been playing around with.
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));
Scott González
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.
Scott González
http://ui.jquery.com/bugs/ticket/3559
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.
Colin Clark
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
Colin Clark
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
David Bolter
normalized this in core (specifically in _base/html.js). Note IE8
doesn't require the camel case as far as I know.
David Bolter
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
alexander farkas
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...).
Scott González
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.
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.
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).
Scott González
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).
Scott González
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.
Colin Clark
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
alexander farkas
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
All other changes to your code are accidentally.
alexander farkas
alexander farkas
i saw that you haven´t moved the patches form the ticket to the svn. i
don´t have svn-access to the tabbable-branch. could you set it up for
me. i would add colins implementation and add somemore tests. i think
the functionality is quite good now. we only have to write some tests,
so that we can refactor the code without bad surprises.
regards
alex
Scott González
I've started taking the code from the patches and moving them into a new implementation that proxies $.attr. This is just taking a while because it's tricky and I've been busy with other UI work. I'll try to get the existing code, plus my work in progress in the same file so i can commit it.
Google requires SVN project members to have Google accounts. If you send me an email (scott.g...@gmail.com) with your Google account, I'll add you to the project.