Hi. Please find a suggestion below.
1. Do not introduce new roles until it's necessary. It sounds role approach wasn't found appeal and it really looks like it complicates the things regardless of we have precedence for date control like Andres pointed. New states doesn't look like appropriate approach for new input controls. So in short while we live successfully with existing set of roles then let's do not invent new ones and let's find other way to expose new semantic. However if we decide new role is needed then it shouldn't break AT since we change IA2 role and do not change MSAA role so that AT could use MSAA as fallback for role getting. 2) Roles for new input controls. If new input control has associated predefined options lists or autocomplete list (for example, email or url input types) then let's expose it as ROLE_SYSTEM_COMBOBOX, otherwise ROLE_SYSTEM_TEXT. Since IA2 has IA2_ROLE_DATE_EDITOR then let's expose it as IA2 role for date input controls, MSAA role is either system_combobox or system_text. 3) Map in...@type="search" to AT HTML5 in...@type="search" looks similar to ARIA landmark "search" role. Every ARIA role (including landmark roles) is exposed in "xml-roles" object attribute in Firefox. Suggestion is let's expose it on in...@type="search", i.e. "xml-roles:search". So that AT will be able to find a search field similarly how AT deals with ARIA landmarks. 4) Map in...@type="email", "url" and etc to AT Semantic of new input controls used to type a value of certain data type can be exposed in "datatype" object attribute. Originally "datatype" object attribute was introduced for ARIA and XForms and it was oriented to XML Schema (see https://wiki.mozilla.org/Accessibility/Datatypes). Eventually data type support was removed from ARIA and XForms didn't get big popularity in the web. Other thing is datatype oriented to XML Schema is a complex thing and probably AT doesn't need all power of XML schema. For example, XForms 1.1 defines email data type in xforms namespace which has not easy definition (see http://www.w3.org/TR/xforms11/#dt-email). I think AT can do nothing with this email definition until they know what email is. So the suggestion would be is let's use datatype to expose predefined sets of constants like "url", "email", "number" (or "integer" and etc) and some constants for dates. This information should be enough for AT and AT can give a hint to the user what's expected to be typed in this text field. If you find this idea reasonable then we can work on more detailed suggestion. Looking forward for you feedback. Thank you. Alex. On Fri, Apr 16, 2010 at 3:32 AM, Andres Gonzalez <[email protected]> wrote: > There is some precedence for the role approach with: > > /// A date editor. > IA2_ROLE_DATE_EDITOR, > > MSAA chose to express the password attrib as a state and not as a role with: > > #define STATE_SYSTEM_PROTECTED ( 0x20000000 ) > (OleAcc.h, line 413) > > The datatype approach sounds interesting, worth exploring further. Best > regards, > > --Andres. > > > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] >> On Behalf Of Alexander Surkov >> Sent: Wednesday, April 14, 2010 12: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
