Jamie, I want to throw in that these form elements will have associated labels (part of the markup) and an autocomplete feature which is quite different than we would normally expect.
Rich Schwerdtfeger
CTO Accessibility Software Group
James Teh
<[email protected]
rg> To
Sent by: [email protected]
accessibility-ia2 tion.org
[email protected] cc
nuxfoundation.org
Subject
Re: [Accessibility-ia2]
04/14/2010 05:58 accessibility of HTML5 input
AM controls
Hi Alex,
Do these controls actually look any different from a normal <input
type="text">? In my opinion, if the control doesn't look different
visually, there's probably no need for an AT to report it differently
either. I guess there's no harm in exposing it as an object attribute in
case an AT did want to access this for some reason.
Note that some would argue that this is a case for custom/extended
roles. I don't really agree, but that's another possible approach.
Jamie
On 14/04/2010 5:51 PM, Alexander Surkov wrote:
> Hi.
>
> HTML5 introduces several new types of input controls like phone
> number, url, search, email, dates and times fields. AFAIK most of new
> controls doesn't have new UI however they are intended to represent
> data of certain types. The question is what can we do to make the life
> of screen reader users easier when new input control is encountered on
> web page?
>
> I think it would be cute if screen reader would announce the type of
> new input controls so that for instance when user navigates to email
> input then the users hears like "email text field". I keep in mind two
> approaches to make this happen.
>
> 1) datatype apporach
>
> Firefox exposed datatype object attribute if the control had
> associated datatype for its value. It makes sense for markups like
> XForms where any control can have associated data type. For example,
> xforms:output and xforms:input can be bound to the same instance node
> that used to store date. It's kind of universal approach in the means
> it's applicable to all controls, not only to input controls. However
> it doesn't encompass the case of search input what isn't data type.
>
> 2) role approach
>
> Historically, HTML input accessible has entry role, HTML
> in...@type="password" accessible has password role. We could spread
> this approach to new input types and introduce new role for every new
> input type. It's more cumbersome approach but it fits any new type of
> input control.
>
> What do you think?
>
> Thank you.
> Alex.
> _______________________________________________
> Accessibility-ia2 mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
--
James Teh
Vice President
NV Access Inc, ABN 61773362390
Email: [email protected]
Web site: http://www.nvaccess.org/
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
<<inline: graycol.gif>>
<<inline: pic11745.gif>>
<<inline: ecblank.gif>>
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
