Allow combobox and spinbutton on input type text

[mcking65]

For input type text with no list attribute, I see allowed roles are "no role".

It should allow combobox and spinbutton. Input type text is the basis for practically every custom combo and spinbutton .

[stevefaulkner]

@mcking65 please provide some examples of deployed custom controls so the pattern can be reviewed.

[mcking65]

google.com

[stevefaulkner]

@mcking65 that's a good example for combobox how about spinbutton?

[mcking65]

https://github.com/OfficeDev/office-ui-fabric-react/blob/master/packages/office-ui-fabric-react/src/components/SpinButton/SpinButton.tsx

[mcking65]

It doesn't seem reasonable that we would justify the allowed roles based on what's being done by other people; it should be based on what is needed to achieve our objectives of utilizing ARIA.

For example, we should also allow role=searchbox on type text ... but you won't find any implementations of that out there ... role searchbox is still as shiney as a new penny.

[stevefaulkner]

@mcking65 describing use cases without necessary prior art is fine. But simply asserting that "ARIA x should be allowed because we think so" is not. What reason is there to use role=searchbox over type=search?

[mcking65]

@stevefaulkner, thank you for 20484cd.

What reason is there to use role=searchbox over type=search?

The reason for using a textbox is to get browser support for accessible text. Is there a better way to get that if you are creating a custom searchbox?

I suppose you could use a div with contenteditable and role textbox, but doesn't that force the developer into a more complex box?

Should I open another issue for the searchbox role?

[stevefaulkner]

@mcking65 I suggest you could use
<input type="search" role="searchbox">

In all evergreen browsers input type=search is conveyed via accessibility APIs but not all AT have support, it falls back to input type=text in browsers without support. There is no visual/behavioral difference between type=text and type=search. addition of role=searchbox fills gaps.

failing that I can look at adding role=searchbox to text input

[jnurthen]

There is no visual/behavioral difference between type=text and type=search

Except in webkit where if I do this I now have to remove the styling.
https://stackoverflow.com/questions/9421551/how-do-i-remove-all-default-webkit-search-field-styling

[jessebeach]

@jnurthen exactly, one of the difficult issues with using semantic HTML is the styling and behavior assumptions baked into the elements: For the <input type="search" /> case, the input exposes a "clear" button on hover and focus.

In practice, we see developers drifting to non-semantic HTML in order to avoid default agent styling. Sure, this presents additional problems for back-filling behavior, but that can be dealt with as long as I can express the intended semantics of the component via ARIA. If I'm arbitrarily limited because "there's already and HTML5 element that expresses that role", then I'm left with a system of semantic gaps. For instance, we certainly have elements for headings.

<h1>Cats and dogs, what's their deal?</h1>

But if developers at my company chose to use a div instead of h1 some time in the distant past because they didn't want the default heading styling and now I'm tasked with expressing the semantics of the element correctly, I can easily do that:

<div>Cats and dogs, what's their deal?</div>

becomes

<div role="heading" aria-level="1">Cats and dogs, what's their deal?</div>

and I don't need to worry about resetting styles or busting some obscure UI because the CSS specificity played out in a way I hadn't anticipated. We've got tools like eslint-plugin-jsx-a11y to guide developers in best practice. What I'd like to avoid is limitations in how I can use ARIA to override legacy bad practice so that I'm not compelled to take on risk of introducing visual regressions because I'm forced to use semantic HTML elements because an ARIA role is disallowed on an element in arbitrary cases.

[stevefaulkner]

Fixed by 157130a