Hi, James. AFAIK UI of new controls is under discussion. I expect they might have different styling, additional images, or more complex UI like in the case of searchbox, it might have search and clear buttons. Also I assume UI might be browser-dependent. But originally I was interested if screen readers wants to announce more specific information when control is focused than just "text entry". Also it could be useful if AT provides an ability for quick search of elements of certain type for example they could provide shortcut to find search field on the page.
Disadvantage of new roles approach is screen readers should support new roles and users must update their screen readers to get new controls working. On the another hand we could say if IA2 role is not supported by screen reader then it should look at MSAA role which is close to IA2 role as much as possible. I wouldn't like custom/extended roles since these roles are standard at least in the browser's word. Thank you. Alex. On Wed, Apr 14, 2010 at 7:58 PM, James Teh <[email protected]> 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 > > -- > 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 > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
