W3C home > Mailing lists > Public > public-html@w3.org > September 2009

Re: Questions arising from ARIA/HTML5 integration

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Tue, 1 Sep 2009 12:57:20 +0100
Message-ID: <55687cf80909010457p41490320yfe29df222e7566cd@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: Ian Hickson <ian@hixie.ch>, public-pfwg-comments@w3.org, wai-xtech@w3.org, public-html@w3.org
hi henri,
>This makes sense for <nav> vs. role=navigation, but what ARIA attributes
would you put on <input type=date> to expose it to AT in a UA that doesn't
support ><input type=date> (i.e. where it degrades to <input type=text>)?

would it not be the case that if the UA does not support <input type=date>
then the datepicker widget would not be displayed?

In this case there is no need to have any extra roles to define how to
interact with the date picker. it would present itself as an input
type="text" which already has a mapping to Accessibility APIs. i

for a UA that supports <input type=date> such as Opera the role, properties
and states for the various pieces of the associated UI will have to be wired
to the various  Accessibility APis by the browser developers.

as an example though, as presented in the Opera  implementation, the role
for <input type=date> would have be an aria role="textbox" with
aria-haspopup="true"


regards
stevef

2009/9/1 Henri Sivonen <hsivonen@iki.fi>

> On Aug 24, 2009, at 15:35, Steven Faulkner wrote:
>
>  The conclusion I drew when developing the schema prototype was that these
>>> have native semantics that needs to be exposed to AT by the browser without
>>> AT in between and that it doesn't make sense to set the role attribute in
>>> these cases.
>>>
>> Can you explain a bit more what you mean here?
>>
>
> I mean e.g. <input type=file> and <input type=date> have semantics and
> those semantics could even be exposed to AT. However, the exposure may have
> to happen by exposing more than one accessible tree node per DOM node and
> there's no single ARIA role that is sufficient for exposing either.
>
> What i would suggest is that there is a place for the use of ARIA on native
>> elements where appropriate until such time that these elements are correctly
>> exposed by browsers through accessibility APIs.
>>
>
> This makes sense for <nav> vs. role=navigation, but what ARIA attributes
> would you put on <input type=date> to expose it to AT in a UA that doesn't
> support <input type=date> (i.e. where it degrades to <input type=text>)?
>
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Tuesday, 1 September 2009 11:58:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:47 GMT