Datepicker

[Rich Caloggero]

There is an option in the date picker to allow an icon trigger to open the
calendar:
http://jqueryui.com/demos/datepicker/#icon-trigger

1. The icon's text label should be set to something other than "...".
Perhaps there is a way of setting this?
2. The icon should be in the tab order, and it should just follow the date
picker's input field - i.e. if your focused on the input field and press
tab, you should be focused on the icon.
3. The calendar is appended to the document body when it is opened. This is
not good for screen reader users because it isn't generally "near" the date
picker's input field. I see this pattern in other jquery-ui widgits as well
such as dialog. If at all possible, put the code for the calendar just after
the input field and icon trigger (if it is turned on) in the DOM. Ditto for
dialogs - place the dialog code just following the trigger which invoked it
if at all possible. Its probably a huge pain to do this, but it makes
things far easier on screen reader users who often don't even know that
something has been added to the dom.

-- Rich

[E.J. Zufelt]

Agreed, it is a bit annoying to have to go hunt down the dynamic content appended to the DOM.  And many screen-reader users don't even know to look there, they just presume that their action didn't take effect.

Everett Zufelt

http://zufelt.ca

Follow me on Twitter
http://twitter.com/ezufelt

View my LinkedIn Profile
http://www.linkedin.com/in/ezufelt

--
You received this message because you are subscribed to the Google Groups "jQuery Accessibility" group.
To post to this group, send email to jquer...@googlegroups.com.
To unsubscribe from this group, send email to jquery-a11y...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jquery-a11y?hl=en.

[Scott González]

Regarding 1 & 2, the datepicker is being rewritten and we'll make sure that we handle these situations properly in the new version.

As for 3, the reason elements are appended to the end of the document is to ensure that they show up properly visually with regard to z-index. In order to ensure that the datepicker is in front of other elements on the page, we need to make sure it comes later in the DOM, in addition to having a high z-index. This is unfortunate, but necessary. As for accessibility, shouldn't the proper ARIA settings make the new content immediately available and announced regardless of position in the DOM?

[Rich Caloggero]

Scot González  wrote:

*> This is unfortunate, but necessary. As for accessibility, shouldn't the proper ARIA settings make the new content immediately available and announced regardless of position in the DOM?

Which aria attributes are you talking about?

The only thing which might work is to add an aria-live="assertive" to the body. Then, when the calendar shows up, the entire thing will be read. However, this is less than optimal. What you really want is to add a div with heading and calendar, but only announce the contents of the div. I've not gotten this to work. It seems that aria-live only works when stuff is added to a container that already exists in the dom. I tried adding stuff in two pieces:

- first add a div with a bunch of content in it and a slot for the heading (the slot for the heading is a div with aria-live="assertive" set);

- then fill the div with aria-live set on it with a heading tag or whatever.

 

You would think that this would then announce only the heading tag - but Jaws remains silent.

 

What am I missing?

 

I'll play with this some more when I get to work tomorrow, but perhaps there are real aria gurus out there that can comment?

 

-- Rich

 

----- Original Message -----

[Rich Caloggero]

http://www.mit.edu/~rjc/aria/liveRegionTest.html

I suggest this pattern when adding stuff to the end of the body. If you
click the "ad / remove div" button, the container is added and the screen
reader will not speak its contents. In the date picker for instance, you'd
add the calendar here.
When you click the "add / remove heading text" button, the h2 just
preceeding the just-added paragraph of text will be filled in and since it
has aria-live="assertive" set on it, it should be spoken.

Of course, there is a catch. If we perform these operations sequentially,
the screen reader does not have enough time to register the change in the
dom and thus the existence of the live region to then speak the heading text
when it is added. So, we must put a delay between the time the outer
container div is added and when the live region is then filled in with text.
My trials seem to suggest 150 milliseconds is adequate, but who really
knows. The "add / remove both" button exercises this test.

The other catch is that NVDA does not respond at all to any of this. Why
not!! It remains silent no matter which test I run.

All tests work with both Jaws10 and Jaws11.

-- Rich

----- Original Message -----
From: "Rich Caloggero" <r...@MIT.EDU>
To: <jquer...@googlegroups.com>

Sent: Tuesday, April 13, 2010 10:39 PM
Subject: Re: Datepicker

What am I missing?

-- Rich

-- Rich

jquer...@googlegroups.com<mailto:jquer...@googlegroups.com>.

To unsubscribe from this group, send email to

jquery-a11y...@googlegroups.com<mailto:jquery-a11y%2Bunsu...@googlegroups.com>.

[Rich Caloggero]

One more addition to this thread -- with date picker (and other widgits
which append to the body), always begin the widgit with a heading, and set
focus to this heading when the widgit appears. Combining this with the live
region approach already presented here should give screen reader users more
of a hope of figuring out what's going on. Of course, focus changes aren't
always picked up and/or acted upon correctly with Jaws or NVDA, but we can
always hope...

Its kind of sad to have to keep trying to work around screen reader bugs and
ruin such clean code with mess. On ethought would be to add some sort of
option which could be enabled for widgits which append code like this to
alert screen readers. Seems to me that it could even be some sort of jQuery
plugin or written in such a way as to not clog up the main code, and could
then be available to use in multiple contexts. Eventually, screen readers
will get this stuff right, and this kind of messing around shouldn't be
needed (he says - trying to be optomistic).