E-mail List Archives
Re: Date fields in forms: one input vs three
From: Bryan Garaventa
Date: Mar 21, 2013 8:32PM
- Next message: Susan Grossman: "Re: Date fields in forms: one input vs three"
- Previous message: Birkir R. Gunnarsson: "Re: Date fields in forms: one input vs three"
- Next message in Thread: Susan Grossman: "Re: Date fields in forms: one input vs three"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Date fields in forms: one input vs three"
- View all messages in this Thread
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>
>> >> >> >>
> > >
- Next message: Susan Grossman: "Re: Date fields in forms: one input vs three"
- Previous message: Birkir R. Gunnarsson: "Re: Date fields in forms: one input vs three"
- Next message in Thread: Susan Grossman: "Re: Date fields in forms: one input vs three"
- Previous message in Thread: Birkir R. Gunnarsson: "Re: Date fields in forms: one input vs three"
- View all messages in this Thread