- From: Cynthia Shelly <cyns@exchange.microsoft.com>
- Date: Fri, 25 Sep 2009 20:27:44 +0000
- To: Jim Jewett <jimjjewett@gmail.com>, Maciej Stachowiak <mjs@apple.com>
- CC: HTML WG Public List <public-html@w3.org>, "wai-xtech@w3.org" <wai-xtech@w3.org>
(And are these questions that need to be formally asked of the pfwg?) Yes, please do. I think this is a good discussion for PF to have. It's possible these roles should be added. -----Original Message----- From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Jim Jewett Sent: Tuesday, September 22, 2009 7:45 PM To: Maciej Stachowiak Cc: HTML WG Public List Subject: Re: aria mappings On Tue, Sep 22, 2009 at 8:42 PM, Maciej Stachowiak <mjs@apple.com> wrote: > On Sep 22, 2009, at 5:02 PM, Jim Jewett wrote: >> input type=color and input type= (datetime, date, month, week, time, >> datetime-local) are defined with no role. >> I think that these should have role=spinbutton > In practice, I don't think the UIs for these will be useful to reflect > to assistive technology as if it were a spin button. I think datepicker would be much better, but that role doesn't seem to exist in aria. And I have certainly used interfaces that required me to pick a date by hitting the little "arrow" glyph way too often. How would you recommend AT represent these input types? As text fields with validity patterns? > For many of these controls, there are multiple viable implementation > strategies for the exact UI. I don't think the spec should assume a > particular implementation in designating the accessibility behavior. Is the (aria-)role supposed to represent the physical implementation that happens to have been chosen, or the underlying semantics? Should the AT see the same underlying date field differently depending on which browser is being used (and how that browser vendor decided to style the chooser for sighted users)? (And are these questions that need to be formally asked of the pfwg?) -jJ
Received on Friday, 25 September 2009 20:28:29 UTC