E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 1 (In chronological order)

From: Mohith BP
Date: Tue, Oct 30 2018 5:11AM
Subject: jQuery Datepicker - expected kb behavior?
No previous message | No next message

Hi,

Please do not hide the calendar widget from the screen readers as
there are many factors of using a date picker in different situations.
Ensure that there is an option to enter the date in a specified format
along with the accessible calendar widget.

Thanks & Regards,
Mohith BP


On 10/29/18, Isabel Holdsworth < = EMAIL ADDRESS REMOVED = > wrote:
> There is a rationale for providing date pickers, and that rationale
> almost certainly extends to screenreader and keyboard users. If you're
> following an inclusive design approach, it wouldn't be acceptable to
> hide the date picker to save the bother of making it accessible. In
> order to ensure that you offer an equivalent experience to all users,
> that pesky date picker would need to be made accessible too.
>
> On 29/10/2018, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> As long as the user is able to enter a valid date using a series of
>>> input
>>> fields, the date picker can be removed from the screenreader context by
>>> using the aria-hidden attribute.
>>
>> While this may be true, I would add to the list of reasons why it may
>> need
>> to be provided. For example, knowing the day of week or whether the date
>> is
>> the first or last week in a month are also important details to consider.
>>
>> Jonathan
>>
>> -----Original Message-----
>> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
>> Abby
>> Kingman
>> Sent: Monday, October 29, 2018 11:05 AM
>> To: = EMAIL ADDRESS REMOVED =
>> Subject: Re: [WebAIM] jQuery Datepicker - expected kb behavior?
>>
>> After reading this thread, it sounds like this is a pattern that might
>> best
>> be avoided if possible.
>>
>> I recently read an article (one that is also linked to on the WebAxe site
>> referred to earlier) that suggests removing the date picker from the
>> screenreader context and tab index using the aria-hidden role. Here is
>> the
>> suggested method:
>> ---
>> As long as the user is able to enter a valid date using a series of input
>> fields, the date picker can be removed from the screenreader context by
>> using the aria-hidden attribute.
>>
>> Another reason to remove a date picker widget from the screenreader
>> context
>> is that fact that it does not add any other functionality than to ensure
>> the
>> validity of an entered day. (It would be another story if this was a
>> price
>> or availability calendar for example.)
>>
>> Removing the calendar from the tab index by setting the tabindex
>> attribute
>> to a negative integer (such as -1) as well does the same for those
>> depending
>> on using keyboard navigation.
>>
>> This, in combination with implementing input fields will essentially
>> remove
>> any screenreader-related issues and most other issues related to
>> accessibility.
>> ---
>> Link to the full article: We need to talk about the accessibility of date
>> pickers
>> <https://aldavigdis.wordpress.com/2018/06/24/we-need-to-talk-about-the-accessibility-of-date-pickers/>
>>
>> While there are cases where validation might be necessary I thought this
>> was
>> an interesting idea.
>>
>> As a sighted tester it is difficult for me to say with certainty that a
>> pattern needs to be changed if I am not sure what the user is expecting.
>> In
>> order to set up a ticket, I need to identify what the desired behavior
>> is.
>> When it is acceptable to allow direct input, this seems like a workable
>> approach.
>>
>> --
>> Abby Kingman
>> Last Call Media
>> >> >> at
>> http://webaim.org/discussion/archives
>> >> >> >> >> >>
> > > > >