Hi, Pete. Object attribute "input-type" if it's going to expose the type value of HTML input is not expandable, in the means it's applicable to HTML5 inputs only. If "input-type" points to the type of values expected to be typed into input (for example, to point you can type numbers) then its meaning wider and probably good to be used instead an "data-type".
Technically we could expose any complex input as combination of controls. But then we should care about relations to allow quick search of these controls. For example, we could need relations between search button and search entry. I think "xml-types" is in use by AT to deal with ARIA landmarks. I suggested to use combobox role similar to address and search bars in firefox. When new controls have associated options list than it's worth to expose them as comboboxes I think. I don't know if other browsers has new input controls implemented, but Firefox hasn't. However I think they are going to appear soon. Alex. On Wed, Apr 21, 2010 at 11:59 AM, Pete Brunet <[email protected]> wrote: > 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 > _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
