W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: Mouse-less browsing/Datepicker (was RE: ISSUE-96 Change Proposal)

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 1 Apr 2010 11:23:32 -0700
Message-ID: <g2i63df84f1004011123pf74923fcj6c145e91db1d3720@mail.gmail.com>
To: John Foliot <jfoliot@stanford.edu>
Cc: Steven Faulkner <faulkner.steve@gmail.com>, Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>
On Thu, Apr 1, 2010 at 11:12 AM, John Foliot <jfoliot@stanford.edu> wrote:
> Jonas Sicking wrote:
>> Are you saying that "programmatic focus and keyborad operability" from
>> your initial email is about that these things must be provided by the
>> browser to the user via accessibility APIs? I.e. the browser must
>> allow the user to use keyboard navigation as well as use other
>> accessibility APIs to focus various parts of the date picker?
> Not for a minute suggesting that I am replying for Steven, but, yes, of
> course the browser must allow the user to access all aspects of a
> date-picker via keyboard control. There are many use-cases where keyboard
> only access would be a requirement even if no specific AT or accessibility
> API call is/would be required: for example on a 'mouse-less device'
> (mobiles *without* touch screen functionality), for a user with limited
> mobility (tabbing via voice-activation) or simply when the mouse is not
> available (the battery in my wireless mouse just died, and I need to
> replace it *after* I get all the other work done).  Chaals
> (McCathieNevile) just wrote up some thoughts about mouse-less browsing
> this week: http://my.opera.com/chaals/blog/2010/03/31/living-without-mice
> that expands on these thoughts - well worth the read.

Indeed, the things you mention are important. I was trying to
understand if Steven was asking for additional capabilities in
addition to this.

/ Jonas
Received on Thursday, 1 April 2010 18:24:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:00 UTC