- From: Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>
- Date: Tue, 05 Jul 2011 16:04:39 +0200
- To: WAI GL <w3c-wai-gl@w3.org>
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