RE: date pickers

David,

At 15:00 5-7-2011, David MacDonald wrote:
>I've been looking at the definition for a conforming alternative. 
>Applying the date picker situation to it is another one of those 
>murky things, but I think it's worth exploring:
>1.     conforms at the designated level, and
>2.     provides all of the same information and 
><http://www.w3.org/TR/2008/REC-WCAG20-20081211/#functiondef>functionality 
>in the same 
><http://www.w3.org/TR/2008/REC-WCAG20-20081211/#human-langdef>human 
>language, and
>3.     is as up to date as the non-conforming content, and
>4.     for which at least one of the following is true:
>1.     the conforming version can be reached from the non-conforming 
>page via an 
><http://www.w3.org/TR/2008/REC-WCAG20-20081211/#accessibility-supporteddef>accessibility-supported 
><http://www.w3.org/TR/2008/REC-WCAG20-20081211/#mechanismdef>mechanism, or
>2.     the non-conforming version can only be reached from the 
>conforming version, or
>3.     the non-conforming version can only be reached from a 
>conforming page that also provides a mechanism to reach the conforming version
>The text field "alternative" to a date picker meets all of those 
>criteria, except perhaps an argument can be made against #2 (all 
>same information and functionality).  However, looking up our 
>definition for functionality gives us:
>"<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#processdef>processes 
>and outcomes achievable through user action"


Unless I misread something "conforming alternate version" is about 
alternate versions to a *Web page*, not about alternate versions to 
widgets or pieces of content inside a page. There is no such thing as 
a "conforming alternate version" for a date picker.


>I think the operative word is "outcome". The outcome is to book a 
>ticket (or whatever else), and the text box allows that.


In the case of a date picker I would say the outcome is the chosen 
date (which in itself is usually a step in a larger process).


>Perhaps it would be great to get an accessible date picker widget, 
>but as Jim points out... so far they are all disappointments... 
>Sailesh points out it can be done using regular html markup... but 
>so far they are all clunky, and I've yet to meet a Screen Reader 
>user who as ever found a date picker they like or would use. Most 
>don't think it's an enough of an issue to lobby for... they'd rather 
>type in the date, than to go into tables mode, and surf through a 
>bunch of greyed out previous dates in the current month...


So the question is, if the date picker does not meet certain WCAG 2.0 
criteria but inputting a date is still possible because there is a 
text entry field, does the page as a whole fail WCAG 2.0?
The date picker increases usability for those who can use it, but it 
does not exclude other users from using the page or form as a whole 
(because the widget serves as a kind of alternative to the text 
entry). The same issue also applies to other types of widgets: colour 
pickers, drag-and-drop functionality, ... So I think the discussion 
should be widened: if there is a widget or mouse-oriented (not 
keyboard-accessible or AT-accessible) functionality for which the 
keyboard interaction is less efficient and/or less user friendly, how 
does that affect conformance for the page as a whole? For example, 
certain items on a page can be dragged and dropped, and the keyboard 
alternative for this interaction is less efficient. For example, a 
search field provides a list of suggestions (for autocompletion), but 
these suggestions are not exposed to AT, etcetera.


>On the other hand if web sites stop using popup date pickers then 
>people with cognitive disabilities might be disadvantaged... since 
>the visual date picker is easier to use for a sighted person who has 
>a cognitive disability...

So the quest for an accessible date picker continues...

Best regards,

Christophe



>
>David MacDonald
><http://www.eramp.com>www.eramp.com
>
>
>From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] 
>On Behalf Of adam solomon
>Sent: July-05-11 8:26 AM
>To: Bailey, Bruce
>Cc: Sailesh Panchang; WCAG; David MacDonald; 508
>Subject: Re: date pickers
>
>I was going to weigh in against Sailesh on this one (in fact I was 
>the one who posted the original question in the WebAim list), yet he 
>then brought up an important point - even if we assume the textbox 
>option is easier, it is still missing information about what day of 
>the week a particular date falls on. So, even though we have an 
>alternative to inputting the date, we don't have an alternative to 
>the content which is provided by the datepicker as to days of the 
>week. The question I have is - where do we draw the line. Can we 
>consider such content to be secondary, or do we require all content 
>to have an alternative to be wcag conformant. This question really 
>applies to many situations. Is there any leeway as to not providing 
>alternatives to secondary, perhaps less important content.
>What say you all?
>On Tue, Jul 5, 2011 at 2:40 PM, Bailey, Bruce 
><<mailto:Bailey@access-board.gov>Bailey@access-board.gov> wrote:
>Very interesting discussion Sailesh and David.  Thanks too for the 
>links to the web aim discussion and Aria example.  I have to confess 
>that my favorite comment was "Often the accessible date-pickers are 
>more work than just typing it in and is something you should consider."
>
>This comes up in the Federal sphere with 508 and the on-going 
>consensus at this point is that a properly labeled text box option 
>is a sufficient alternative to a pop-up date picker.  That is not 
>the same judgment call that would be made for a calendar program 
>(where, as Sailesh describes, knowing the day of the week, adjacent 
>appointments, and full keyboard navigation would all be essential).
>
>--
>Bruce Bailey
>Accessibility IT Specialist
>U.S. Access Board
>1331 F Street NW, Suite 1000
>Washington, DC  20004-1111
>202-272-0024 (voice)
>202-272-0082 (TTY, shared)
>202-272-0081 (Fax, shared)
><mailto:bailey@access-board.gov>bailey@access-board.gov
>

-- 
Christophe Strobbe
K.U.Leuven - Dept. of Electrical Engineering - SCD
Research Group on Document Architectures
Kasteelpark Arenberg 10 bus 2442
B-3001 Leuven-Heverlee
BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/
Twitter: @RabelaisA11y
---
Open source for accessibility: results from the AEGIS project 
www.aegis-project.eu
---
Please don't invite me to Facebook, Quechup or other "social 
networks". You may have agreed to their "privacy policy", but I haven't.

Received on Tuesday, 5 July 2011 14:05:12 UTC