WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Datepicker questions - are they useful?

for

From: Chaals McCathie Nevile
Date: Nov 2, 2015 5:21PM

On Tue, 03 Nov 2015 07:08:34 +0900, Birkir R. Gunnarsson
< <EMAIL REMOVED> > wrote:

> Thanks for all that info, very true.
> The difficulty is the concept of interactive vs. browse mode in screen
> readers and custom keyboard shortcuts implemented by applications.
> There is no graceful way to communicate to screen readers that the
> webpage developers implemented a set of keyboard navigation features
> that could speed up and simplify the interaction.

In principle you should be able to use accesskey to do this - with the
added bonus that it would work for keyboard users who haven't got a
screenreader running.

As we know, implementation in browsers is still generally bad - although
it has improved from the "truly dreadful" it used to be, so there is hope.

More importantly, it is often screen reader users who miss out since their
shortcuts are generally not overridden any more, but no effort is made to
reassign the access key.

This is one of the gazillions of use cases that motivate
https://chaals.github.io/accesskey/index.src.html which I hope is ready to
propose for wider review now, as a step to getting a decent solution to
these problems in browsers.

One of the things I tried to do there is make as easy a transition path as
possible. The result is basically that people who are using piles of
javascript in an attempt to solve the issue will be able to throw most of
it away, people who use accesskey already will find it magically being
more useful, and browsers have a smooth upgrade path without breaking any
kind of compatibility I can find.

Of course we'll see what happens if we get this on the road…

cheers

> A lot of beginner to intermediate screen reader users are still not
> fully aware of the idea of browse mode or key pass through options.
> Sure, off-screen instructions could be added for the element that
> receives focus when the datepicker opens, or link them with the
> calendar pop-up trigger element, but those would probably start to
> annoy screen reader users who are used to interacting with the
> webpage.
> So in creating this example I was caught between forcing the users to
> discover the behavior by using the application role, and let the
> screen reader application itself decide on the interaction mode and
> leave the mode of navigation up to the user by using the grid role.
> I think the grid roll spec strongly suggests use of application mode
> (else it would be no different from a table that includes interactive
> elements), but ultimately I cannot read a definite interpretation from
> the spec.
> I only consider grids for content that does not include static
> elements (unless associated with itneractive elemetns in some way).
> So I may revisit the example and choose one mode over the other,
> probably role = grid over application.
> In general I don´t like the application role, and I avoid it whenever
> possible, because we should not dictate how specific assistive
> technologies work, it is up to them to know how to do things in a way
> that is best for the end user.
> But sometimes it seems like it would be the best option to ensure that
> when a lot of work has been put into the user experience, for all
> users including keyboard only and screen reader users, that work
> should not go unnoticed.
> Cheers
>
>
>
> On 11/2/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>> Actually it's not last time I checked, and may be doing the opposite in
>> JAWS
>> when in Virtual Cursor mode.
>>
>> E.G, using IE11 with JAWS16 on Win7 at
>> https://dequeuniversity.com/library/aria/date-pickers/sf-date-picker
>> simply arrowing to the calendar picker button in VC mode and pressing
>> Enter
>> causes the date picker to open, but Applications Mode is not invoked as
>> expected.
>>
>> Regarding role=grid, there are still significant screen reader
>> differences
>> between how JAWS and NVDA treat this, which you will notice between IE
>> and
>> FF using both, as well as within Chrome. E.G
>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Data%20Grids/ARIA%20Data%20Grid%20(Dynamic)/demo.htm
>>
>> One thing to keep in mind with role=grid as well, the use of role=grid
>> is
>> not supposed to cause a specific behavior to occur according to the ARIA
>> spec, but role=application is, which is why there is so much confusion
>> there
>> even today.
>>
>> A Grid is simply meant to convey an interactive Grid construct where
>> Gridcell nodes can be interacted with, but role=application specifies
>> that
>> an AT should pass all keystrokes to the element that has focus, but they
>> both don't mean the same thing. E.G a Grid is a Composite widget type
>> (Reference
>> http://www.w3.org/TR/wai-aria-1.1/#composite )
>> and may include embedded active elements that may not require
>> Applications
>> Mode when focus is set to one of them.
>>
>>
>>
>>