- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Apr 2010 08:11:40 -0700
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: Shelley Powers <shelley.just@gmail.com>, HTMLWG WG <public-html@w3.org>
On Thu, Apr 1, 2010 at 8:00 AM, Steven Faulkner <faulkner.steve@gmail.com> wrote: > Hi all, > i agree that it is better for accessibility to have native controls > as the properties of these controls can be hooked up to accessibility > APIs by the browser. > In the case of the new HTML5 controls implemenetd in Opera there are a > number of issues: > 1. they do not expose any of their properties via an accessibility API. > 2. their styles and formatting cannot be modified to suit user requirements. > 3. programmatic focus and keyborad operability is limited or non-existent. > > Until such times that these conditions are met in browsers that > implement native HTML5 form controls, then the use of javascript UI > libraries that do, provide the above the more accessible choice. Ah, indeed. It's obvious to me that any and all semantic elements need to be appropriately exposed to accessibility APIs. Ranging from <a> and <h1> to <input type=date> and <progress>. It surprises me if Opera does not do this, though it seems to me that the proper solution to that problem is to fix the bug in Opera, not remove the feature from HTML5. Likewise with keyboard navigation. See my reply to Shelly in regards to styleablility. I'm curious to hear that you're bringing up programmatic focus. This is something I haven't thought or heard about before. Do you mean that it's important that the *web page* can programmatically focus a particular button in, for example, a date picker? Rather than that the user can use accessibility APIs to do this. If so, why is that important? Could you describe a scenario/use case. / Jonas
Received on Thursday, 1 April 2010 15:12:29 UTC