Hi Jamie, all, Could you imagine this input type information helping prediction based alternative input technology such as speech input?
cheers, David On 14/04/10 6:58 AM, James Teh wrote: > 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 >> > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
