Datepicker: Announce dates using aria-live so screen reader users can us...

[dylanb]

...e the keyboard shortcuts. Fixes #9623. Does not announce to AT with keyboard shortcuts

[mikesherov]

Is there any way to accomplish the goals of this ticket without a browser sniff?

[dylanb]

We could always apply the role="application" to the input element but it is currently only required for JAWS and hence the browser sniff. I don't see a downside to always applying the role except for the fact that it would override any user-supplied role but that would cause problems anyway.

[mikesherov]

Great, thanks for fixing. Looks like your travis build failed though.

[dylanb]

fixed

[jzaefferer]

Setting role="application" seems like a bad idea in general to do inside a framework. Though instead of patching the terrible old datepicker implementation, I'd prefer to focus our efforts on the rewrite.

@dylanb could you please take a look at the current state of our rewrite? http://view.jqueryui.com/datepicker/demos/datepicker/default.html
Hans Hillen worked on this a while back. We refactored the underlying code a lot since then, but the ARIA implementation should still work, and work much better then our current datepicker.

[dylanb]

This new datepicker is relying on two features that do not work in the Apple world today. As far as I can tell from Apple's attitude towards one of them, this will probably not be fixed for a long time.

It relies on aria-activedescendant within an ARIA grid and it relies on 2 dimensional table aria grid markup.

The first one does not work on OS X and the second does not work on iOS (I am not sure about activedescendant support on other platforms as I have not tested it and my experience with ARIA has taught me to test before I use/recommend).

There are some other keyboard interaction bugs - like PAGE_UP moving back a month instead of forward, but the datepicker could probably be made to work on all platforms by replacing the reliance on activedescendant with some aria-live logic.

As far as application use in a framework. The only problem this could possibly cause is JAWS 12 or older - it will force the whole page into application mode which is not a good idea. However, for the most part, it behaves pretty well in all other major ATs.

[dylanb]

one more thing - not sure what your support for iOS is but the arrow key events do not get delivered on iOS at all. In order to address this you might want to add support for gestures instead, all other solutions are sub-optimal.

For example, marking up the table to work on iOS would have to be done along these lines: http://unobfuscated.blogspot.com/2013/04/3d-tables-in-voiceover-on-ios-61x.html

And then the datepicker HTML would have to be inserted inline into the document immediately after the input so the screen reader could get to it.

Another solution would be to defer to HTML 5 date input types on iOS because the pickers that appear as part of that are fully accessible.

[dylanb]

This blog post proposes how gestures would be mapped to keystrokes (for the ARIA authoring practices guide) - similar mappings could be made for the jQuery UI keystrokes.

http://unobfuscated.blogspot.com/2013/11/accessible-javascript-gestures.html

[dylanb]

@jzaefferer @mikesherov do you guys want me to do anything about the new datepicker implementation? It is definitely problematic from a cross-platform perspective

[jzaefferer]

Hey Dylan,

I'm going to close this PR, since this potentially introduces new issues that we don't want to deal with. It would be great if you could focus on the rewrite instead (potentially reusing some of the implementation here). While Hans worked on the datepicker rewrite a while, you've already improved various other ARIA implementations Hans was originally involved with, so I'm fine with following the suggestions you're making.

Specifically regarding iOS we should always include people from the jQuery Mobile team, in this case @arschmitz.

[dylanb]

@jzaefferer I am starting to look at the new datepicker now. I have a question about how I should approach the fixes. Should I create specific bugs for each fix (I think this is the right answer), or bunch them all together in a "fix accessibility" PR?

[jzaefferer]

Do you mean specific PRs? I guess so and I think a single PR with individual commits would be best. Makes it easy to test the whole thing, while still being able to look at atomic changes.

Would also be good to coordinate with @tjvantoll on this, since he's the one who's mostly been working on datepicker lately.

That said, I'm very much looking forward to your contributions here.

[tjvantoll]

@dylanb I agree with @jzaefferer that a single PR with the individual commits would be best.

Also if you want to just list out the issues, this wiki page would be the place to do it. It's what we're using to track all things about the rewrite.

And thanks!