Consider creation of aria-inputtype property for role parity

[joanmarie]

We have several options regarding achieving role parity with HTML's input element types, including:

1. Create dedicated roles for them (e.g. because input type='color' is a very distinct widget type from input type='date')
2. Punt on them until 1.3 because technically the type attribute of input is an HTML attribute, and attribute parity is the main focus for 1.3.
3. Add an aria-inputtype (or something like that) property now.
4. Some combination of the above.

I've filed this issue so we can discuss solution 3.

If we were to create aria-inputtype, I think it would be of type token and be one of the following (see notes after the list):

• color
• date
• datetime-local
• email
• file
• month
• telephone
• time
• url
• week

Notes:

• I'm not sure if we want to have others like text (role parity achieved: textbox) or search (role parity achieved: searchbox).
• I also think that we'll want to punt on password for now. (We can always add it, or some alternative, later if we ever get consensus on it.)

[carmacleod]

What roles would support aria-inputtype? Maybe textbox and button? Or create a new input role?
I don't think it should be a global attribute, and I can't see it making sense on generic (because generic is supposed to be nameless), and type isn't a global attribute in HTML anyhow.

There's an example of each of the input types listed above (except file) in the "Form:" on this example HTML page. The Date and Time related ones are definitely not "just a textbox" because they have all sorts of child controls and extra keyboard behavior (tested in Chrome/FF on Win). Authors would probably want to add that type of thing to their custom controls.

So I'm kind of leaning towards 1. dedicated roles. (or maybe a new "input" role that would support aria-inputtype).

[joanmarie]

We already have an abstract input role: https://w3c.github.io/aria/#input

That said, I don't think all subclass roles of input should support this hypothetical property. And I most definitely agree with you that if we add the property, it shouldn't be a global property.

[carmacleod]

We already have an abstract input role: https://w3c.github.io/aria/#input

Oh - sorry - I should have looked at the abstract roles.

So, current subclasses of (abstract) input role are:

• checkbox (input type="checkbox")
• option (option element - is this in the right place? I would have expected option's parent to be the input)
• radio (input type="radio")
• slider (input type="range")
• spinbutton (input type="number")
• textbox (input type="text")

You're right - probably none of those should support the hypothetical input type property, unless it's only for their own type (but that would just add confusion).

So it doesn't make sense to make input (or its superclass, widget) a concrete role because the pre-existing subclasses shouldn't support a hypothetical inputtype attribute... which is another argument for dedicated roles for the remaining types.

[schne324]

Color inputs and datepickers should have their own roles. To me, this attribute makes more sense for the text-y input types (email, telephone, url etc...)

[css-meeting-bot]

The ARIA Working Group just discussed input type.

The full IRC log of that discussion

<mck> TOPIC: input type
<HarrisSchneiderman> github: https://github.com//issues/962
<mck> jd: Do AT need to know that it is an email input or url input? partial parity is textbox role.
<joanie> Create dedicated roles for them (e.g. because input type='color' is a very distinct widget type from input type='date')
<joanie> Punt on them until 1.3 because technically the type attribute of input is an HTML attribute, and attribute parity is the main focus for 1.3.
<mck> currenlty exposed as object attribut in webkit and gecko
<joanie> Add an aria-inputtype (or something like that) property now.
<joanie> Some combination of the above.
<mck> Don't know what we are doing with date picker and color picker. diff UAs do in different ways.
<mck> We could do different roles for each one.
<mck> Or, could punt until 1.3 because these come about because of the type attrib on input.
<mck> Or, maybe could have roles for some and attrib for some.
<joanie> color
<joanie> date
<joanie> datetime-local
<joanie> email
<joanie> file
<joanie> month
<joanie> telephone
<joanie> time
<mck> Curt: asking if this is complete list.
<joanie> url
<joanie> week
<mck> jd: all but password
<mck> jd: already have total parity for input type checkbox and radio.
<mck> gives background on password role, so not going to include it.
<mck> This is list is either we do not have full parity or it is not password.
<mck> bg: sees value in exposing email and url because some kebyoards change keys they expose based on that.
<jongund> https://github.com//pull/951
<HarrisSchneiderman> scribe: HarrisSchneiderman

[stes-acc]

https://freedomscientific.github.io/VFO-standards-support/html.html indicates that Jaws support for host language input types is still weak.