WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Date fields in forms: one input vs three

for

From: Bryan Garaventa
Date: Mar 22, 2013 5:10PM

ARIA is still very useful at times, and works very well when properly
implemented.

I've been saying for a long time that Assistive Technology providers need to
implement the ARIA specification equally in order to ensure reliable and
consistent feedback for screen reader users, and this is simply a case in
point why having equal standards adoption, is important.

This is a compound control type that encompasses many different types of
behaviors, which is why it exposes the issue more clearly.

There are many ARIA widget types however that do work correctly and
according to spec, so I don't recommend throwing the baby out with the
bathwater.

I don't have access to the Freedom Scientific bug tracking DB, but if anyone
would like to enter this as a bug, it would at least raise visibility for
the issue.



----- Original Message -----
From: "Wyant, Jay (MNIT)" < <EMAIL REMOVED> >
To: "WebAIM Discussion List" < <EMAIL REMOVED> >
Sent: Friday, March 22, 2013 1:59 PM
Subject: Re: [WebAIM] Date fields in forms: one input vs three


>I have started to raise the visibility of ARIA roles among our designers
>and developers. But after this commentary, I am beginning to wonder about
>the wisdom of doing so. If Freedom Scientific will not provide effective
>support in their latest versions, then it is difficult to justify
>allocating precious resources to adding roles to website code.
>
> Or have I misinterpreted something? Welcome your thoughts.
>
> Jay
> ---------------------
> Jay Wyant
> Chief Information Accessibility Officer
> MN.IT Services, Central
> State of Minnesota
> 651.201.1001
> 612.825.8285 (m)
> <EMAIL REMOVED>
> http://mn.gov/oet/policies-and-standards/accessibility/
>
> On Mar 21, 2013, at 9:32 PM, Bryan Garaventa
> < <EMAIL REMOVED> > wrote:
>
>> When you say 'These are nice and intuitive but would require more work to
>> make sure they are fully accessible', which accessibility issues have you
>> noticed?
>>
>> This is in regards to the date picker at
>> http://whatsock.com/modules/aria_calendar_module/demo.htm
>>
>> It would be great to know, so I can fix them.
>>
>> A few notes, I've tested this successfully using:
>> JAWS 12, 13, and 14 in IE8 and 9, on Win XP, Win7 and 8;
>> JAWS 14 in Firefox (earlier versions of JAWS don't support role=dialog
>> nor role=application in Firefox)
>> and using NVDA in both Firefox and Chrome.
>>
>> The differences have to do with differing levels of ARIA support between
>> the screen reader versions.
>>
>> For example, JAWS 12 and 13 support the use of role="dialog" where the
>> Virtual Cursor is disabled so that arrow key navigation is possible,
>> which matched NVDA.
>>
>> In JAWS 14 however, Freedom Scientific removed this behavior so that
>> nothing happens when role="dialog" is applied, thus breaking this
>> functionality and making it inconsistent across all screen readers that
>> support the role.
>>
>> So the only way to fix this behavior for JAWS 14, was to wrap an internal
>> container element that contains role="application" with another outer
>> container that contains role="dialog", which then makes it work in JAWS
>> 12, 13, and 14 when using IE 8 and 9, and for JAWS 14 when using Firefox.
>>
>> However, this nesting of role="application" within role="dialog" appears
>> to confuse NVDA so that it doesn't work in IE, but it does however work
>> in Firefox, and in Chrome if you press Insert+Space to make sure that it
>> remains in Applications Mode when the Calendar link is activated.
>>
>> JAWS also correctly announces only the aria-label attribute for focusable
>> elements in Applications Mode, but annoyingly appends aria-label text to
>> screen text in Virtual Buffer navigation mode when applied to elements
>> with role="link".
>>
>> The way to fix the issue of screen text being concatenated with
>> aria-label text in JAWS, is to surround the screen text with
>> aria-hidden="true", however doing this breaks Voiceover support in iOS
>> touch screen devices, because iOS doesn't support aria-label.
>>
>> As you can see, I've given this a lot of thought, and it's sort of
>> complicated.
>>
>>
>>
>> ----- Original Message ----- From: "Birkir R. Gunnarsson"
>> < <EMAIL REMOVED> >
>> To: "WebAIM Discussion List" < <EMAIL REMOVED> >
>> Sent: Thursday, March 21, 2013 5:35 PM
>> Subject: Re: [WebAIM] Date fields in forms: one input vs three
>>
>>
>>> Hi
>>>
>>> Can't seem to find the article you mentioned (please post it to the
>>> list if you find it).
>>> Regarding date pickers, whatever version is implemented it has to have
>>> full keyboard support and be labelled accessibly. I have seen many
>>> unsatisfactory versions of date pickers unfortunately.
>>> The most unambiguous one I have used is on www.aa.com when booking
>>> flights (it may have been "updated" .. made worse). It simply consts
>>> of 3 comboboxes, day, month, year, it eliminates any confusion
>>> regarding format of text input (date format, 2 vs 4 digit years etc.).
>>> If an edit field is provided for dates the label should clearly
>>> indicate the expected format (dd/mm/yy or mm/dd/yy or mm/dd/yyyy etc.)
>>> ideally along with an example (mm/dd/yyyy, such as 10/20/2013).
>>> There are some cool date pickers out there, I know www.whatsock.com
>>> had an experimental one that was fully keyboard accessible in a table
>>> format (though it was more of a calendar grid). These are nice and
>>> intuitive but would require more work to make sure they are fully
>>> accessible, and would have to take over keyboard navigation (i.e. be
>>> an application) to make sure arrow keys work as expected. If this
>>> solution is selected it should follow the DHTML keyboard navigation
>>> guide.
>>> This is probably all pretty basic, and stuff you are already aware of,
>>> but I am posting it just in case.
>>> HTH
>>> -B
>>>
>>> On 3/21/13, Susan Grossman < <EMAIL REMOVED> > wrote:
>>>> Last year a vendor supplied me with a white paper on using one field
>>>> and a
>>>> date picker enhancement (one label), instead of using three fields for
>>>> dates (three labels) in forms.
>>>>
>>>> Don't seem to be able to find this paper and was hoping someone could
>>>> point
>>>> me to it, or give me an expert opinion that I can pass on. There is an
>>>> ongoing discussion among our UX teams with members feeling strongly
>>>> about
>>>> both concepts and I'm looking for data or an accessibility experts
>>>> reasoning an recommendation.
>>>>
>>>> I'm aware that many books like Hardboiled Web Design talk about the
>>>> date
>>>> pickers airlines/hotels use as being painful and show single fields,
>>>> but am
>>>> looking for the accessibility angle.
>>>>
>>>> Thank you
>>>>
>>>> --
>>>> *Susan R. Grossman*
>>>> <EMAIL REMOVED>
>>>> >>>> >>>> >>>>
>>> >>> >>> >>
>>
>
> > >