Hi, Rob. They provide different styling for example email, telephone, search are going to have autocomplete or I assume date input should have popup calendar. Also these controls provides automatic value validation so that we can expose STATE_INVALID for AT if value is invalid.
Alex. On Wed, Apr 14, 2010 at 10:34 PM, Rob Gallo <[email protected]> wrote: > I like the idea of exposing the information as an object attribute. I think > a case could be made that users might find the information useful or > interesting. > > Also, what is the purpose of such fields from the sighted/page author's > point of view? Is it merely to provide better data formatting? > > > > Thanks, > RG > > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Alexander Surkov > Sent: Wednesday, April 14, 2010 3:51 AM > To: [email protected] > Cc: [email protected] > Subject: [Accessibility-ia2] accessibility of HTML5 input controls > > 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 > > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
