HTML 5 ARIA mappings Action Item - Implied native ARIA semantics for new HTML 5 input types and elements

Below is my assessment.

Before I do any further accessibility API mapping (this will need to be a
separate document from the HTML 5 spec.) we should go through and discuss
my assessment on Tuesday. There are MANY Dom methods provided for each of
these widgets that provide information beyond what is provided in the DOM
attributes. Do we need to do anything with that information when dealing
with the HTML 5 accessibility API mappings? That would require HTML 5 to
allow ant AT or the user agent to call these methods. That is a new wrinkle
and has the group considered that possibility.

Also, I have identified some issues with the HTML 5 specification we should
discuss.

For all of these roles the author should NOT be able to override element
with an ARIA role.

1. details element

Implied Native semantics:
role="button"
aria-labelledby="id" of the summary element
open content attribute = aria-expanded
DOM children of details:
<summary> provides the level of semantics as a div.

example:
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html


This may be overriden by a combobox as there is no reason the author could
not convert this to a button with a drop down menu. Here anything in the
details area could be selected as a menu item. This would change the
functionality of the control.

2. meter is an range object in the ARIA taxonomy

Implied Native semantics:

role="progressbar"      It is defined as a scalar guage and not a control
meaning it should not become a slider or a scrollbar
aria-valuemin = min content attribute
aria-valuemax = max content attribute
aria-valuetext= the content within meter is the equivalent

low, high, and optimum are not ARIA values  and we need to make sure they
are exposed through the accessibility API on each platform. Also, some
notification that properties exceed or fall below a particular level should
be created.

This should not be overriden with ARIA properties as it will create
conflicts

3. The user agent can bind whatever they want to this input type. So all
though there is a constraint on the data type implied semantics in terms of
UI components are indeterminant.


  input type=date – date input control

  input type=month – year-and-month input control

  input type=week – year-and-week input control

  input type=number – number input control

  input type=color – color-well control



  Implied ARIA semantics:

  These accessibility mapping is dependent on the browser implementation.

  So, these input types have NO determinable ARIA mapping. The ARIA mapping

  and accessibility API mapping are dependent on the control bound to the

  input element used by the browser.



  These do all support a min and max value. However, the min and max value

  could be strings vs. numerical values.



  One can also imagine that the user agent will draw a different control

  based on the real estate available to the device.



  4.  input type=url



Implied Native semantics:
  Although the rendering is not stated, this is a textbox. The ARIA role

  for this is textbox.



  5. input type=email – e-mail address input control

Implied Native semantics:
  Although the rendering is not stated, this is a textbox. The ARIA role

  for this is textbox.



   6. input type=range – imprecise number-input control

Implied Native semantics:
   The ARIA role for this is a slider. The aria-min, aria-max, and
aria-valuenow values should be equivalent to the min, max, and value
content attributes provided in HTML. Aria-valuetext should be allowed on
this element. There is a DOM method corresponding to returning a string
equivalent for all these content attributes.


   7. input type=search field

Implied Native semantics:

   The definition of what is to be rendered is unclear. No ARIA role can be
determined.

  8. input type=time – time input control

Implied Native semantics:

The ARIA role for this is a spinbutton. The aria-min, aria-max, and
aria-valuenow values should be equivalent to the min, max, and value
content attributes provided in HTML. Aria-valuetext should be allowed on
this element. There is a DOM method corresponding to returning a string
equivalent for all these content attributes.

9. input type=datetime – global date-and-time input control and input
type=datetime-local – local date-and-time input control

Implied native semantics:

ARIA has no direct role for the combined control.

This is a combination of a date and time control. Now the Opera rendering
of this separates date and time into two controls, yet the values are
integrated (max, min, value) into single values. Should we ask that they be
separated?

Within the user agent this could be mapped to a group role with child date
and time (spinbutton) objects. The values for max, min, and current value
should be split between the two controls.

The actually ARIA role for date is non-deterministic based on the spec. The
time control is. Internally, the browser should create a role=group. where
the label could be datetime but actually should be supplied by the author.

There should be a defect logged requiring a label for the date and time
control and date and time local control.

10. progress – progress indicator.

Implied native semantics:

The role is "proggressbar"
aria-currentvalue is position
aria-valuemax is max
aria-valuemin is 0?

Authors should be able to supply aria-valuetext

There should be a defect log to have a minium value or to at least state in
the specification that it should be zero or undeterminable. There should be
an issue raised regarding what resides between the start and and end
<progress> elements. Is it fallback content? This is unclear.

11. input type=tel – telephone-number-input field

Implied native semantics:

The role is "textbox"

References Used:

http://www.quirksmode.org/html5/compatibility.html

http://dev.w3.org/html5/spec/rendering.html#rendering

http://dev .w3.org/ht ml5/spec/rendering.html#bindings
http://dev.w3.org/html5/markup/


This web site shows that even the Opera people do not know what to do with
many of these and that man of the browser manufactures do not have
inplementations: http://www.quirksmode.org/html5/compatibility.html





Rich Schwerdtfeger
CTO Accessibility Software Group