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.
>>
>>
>>
>> -----Original Message-----
>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>> Behalf
>> Of Birkir R. Gunnarsson
>> Sent: Monday, November 02, 2015 9:17 AM
>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>> Subject: Re: [WebAIM] Datepicker questions - are they useful?
>>
>> Re the Deque University datepicker:
>> The original idea was to use grid and we expect that would ensure screen
>> readers going into forms mode.
>> But at the time we tested it, we did not get the behavior we expected.
>> To force forms mode we added the application role.
>> We may need to look at this again, since I think the grid role alone is
>> sufficient now.
>>
>>
>>
>> On 11/2/15, Bryan Garaventa < <EMAIL REMOVED> > wrote:
>>> A date picker is very useful, especially when it's important to know
>>> the day of the week or month involved, or when planning months or
>>> years in the future. This is especially the case with travel sites.
>>>
>>> There is another implementation you are welcome to test at
>>> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Date%20Pickers/ARIA%20Da
>>> te%20Picker%20(Basic)/demo.htm Which supports disabled date ranges,
>>> comment notation, date format changing, localization support within
>>> any language, calendar changing for European calendar layout
>>> differences, full control over styling across various devices, and so
>>> on.
>>>
>>> The module works as powered by jQuery within the archive at
>>> https://github.com/accdc/tsg
>>>
>>> Or powered by Dojo at
>>> https://github.com/accdc/tsg-dojo
>>>
>>> Or powered by MooTools at
>>> https://github.com/accdc/tsg-mootools
>>>
>>> Sincerely,
>>> Bryan Garaventa
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
>>> Behalf Of Mary Elizabeth Sullivan
>>> Sent: Monday, November 02, 2015 4:57 AM
>>> To: WebAIM Discussion List < <EMAIL REMOVED> >
>>> Subject: [WebAIM] Datepicker questions - are they useful?
>>>
>>> Hello,
>>>
>>> I have a question about datepickers for the group.
>>>
>>> We are looking to create a recommended pattern for a style guide. This
>>> style guide will influence desktop, responsive and mobile native
>>> applications.
>>>
>>> Generally we know we want
>>>
>>> <label ...>
>>> <format instructions>
>>> <input text box>
>>> <date picker validation>
>>>
>>> We obviously will also have to keep error handling in mind. My
>>> questions to everyone are:
>>> - do screen reader users enjoy accessible datepickers or do they
>>> prefer a text box?
>>> - do keyboard only or zoomtext users enjoy accessible datepickers or
>>> do they prefer a text box?
>>> - same question for dragon users
>>>
>>> - also for responsive and mobile web, do people like the input
>>> typeÚte with mobile assistive technologies like VoiceOver and
>>> talkback? Switch control? Or is the textbox preferred?
>>>
>>> - is a sequence of drop downs better?
>>>
>>> Lately I've been trying to find a one size fits all option and I
>>> really haven't found one. It begs the question, what is the most fluid
>>> way for people to use a date picker. What is the user impact? Are
>>> calendar date pickers helpful or do they make a simple process more
>>> difficult?
>>>
>>> Thank you,
>>>
>>> Beth
>>>
>>>
>>> Sent from my iPhone
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Work hard. Have fun. Make history.
>> >> >> archives at
>> http://webaim.org/discussion/archives
>> >>
>> >> >> >> >>
>
>


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
<EMAIL REMOVED> - - - Find more at http://yandex.com