Alex, Thanks for starting this discussion. I think adding new roles is the right thing to do but only if the means of interaction is different. I don't think different stylized looks need to be exposed. Based on that, what new roles are needed?
Is a search box a combined control, i.e. text field plus button? Can it be exposed as two separate controls? If not then I think it needs a new role. If a simple text field is used as a search box I think it's valuable to add an object attribute to indicate that it's a search box, e.g. an "input-type" object attribute. With this attribute, as you say, not only can the AT provide additional information, especially if the page designer didn't label it well, but also AT can allow a user to quickly find the search box (or input field of any other particular type, e.g. phone number, url, email, or date/time). I suspect the "data type" that the input is bound to is not helpful from a UI perspective (beyond the input-type attribute mentioned above). I think this is the first time I've heard of the xml-roles IA2 object attribute. Is that in use? I don't think we should use role COMBOBOX for controls that aren't combo boxes. Do you have some examples I can look at in order to form some ideas on how to best expose them? Pete === Alexander Surkov wrote: > 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
