Inconsistency in allowed uses of placeholder and aria-placeholder

[dd8]

There's an inconsistency between where aria-placeholder is allowed in ARIA and where placeholder is allowed in HTML.

ARIA 1.2 (and the current working draft) only allows aria-placeholder on

• role=textbox
• role=searchbox

HTML allows the placeholder attribute in places that map to additional roles:

• input type=text which has an implicit textbox role
• input type=text with a list attribute which has an implicit combobox role
• input type=search which has an implicit searchbox role
• input type=search with a list attribute which has an implicit combobox role
• input type=number which has an implicit spinbutton role

https://html.spec.whatwg.org/multipage/input.html#input-type-attr-summary

You can see this happening here - there's a visible placeholder (Yummy), but in Chrome and Firefox DevTools it's not exposed anywhere in the accessibility info:

<label for="ice-cream-choice">Choose a flavor:</label>
<input list="ice-cream-flavors" id="ice-cream-choice" name="ice-cream-choice" placeholder="Yummy"/>

<datalist id="ice-cream-flavors">
  <option value="Chocolate"></option>
  <option value="Coconut"></option>
  <option value="Mint"></option>
  <option value="Strawberry"></option>
  <option value="Vanilla"></option>
</datalist>

[scottaohara]

i just checked chrome/edge dev tools and re: the example code provided, the placeholder is shown but crossed out in the dev tools. But, in testing with jaws, nvda and narrator the placeholder works just fine. Maybe more an issue with chrome dev tools than an actual issue with implementations? I also modified the example code to use aria-placeholder instead of placeholder, and "yummy" was exposed by all screen readers for that variant.

In firefox, the placeholder is exposed in the a11y tree view just fine and worked without issue. So not sure why we are seeing different things there.

The issue i see here is that a spinbutton and a combobox in ARIA don't necessarily need to be rendered as editable text fields. A select, for instance, on Windows is exposed as a combobox as well, but there's no allowance for the placeholder attribute there.

So maybe an acknowledgement that if these roles are rendered as editable text fields, aria-placeholder could be used. Again it doesn't seem like there are actual implementation issues in my quick testing... so maybe this issue is really more for clarification for developers (and i assume a11y checkers so as to not throw false positives).

[dd8]

On Windows at least there's 2 kinds of comboboxes: editable and non-editable.

The editable ones have an edit box (which displays the placeholder) and a dropdown list (like input=text with a list). The non-editable ones work like <select> so there's nowhere to display the placeholder.

https://learn.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.combobox?view=winrt-26100

I think the issue partly stems from the fact there are 2 different types of comboboxes, but aria-placeholder only makes sense for one of these types.

[scottaohara]

yes. that's what i already mentioned.

[dd8]

Yep, for our purposes (updating the RNC schemas for validator.w3.org/nu) all we'd need is aria-placeholder added to the role tables for combobox and spinbutton.

If this goes into ARIA 1.3 we'd need to figure out what to do about it in the current VNU before 1.3 becomes a REC (maybe just issuing a warning rather than an error when aria-placeholder is used on combobox/spinbutton is the way to go).

A combobox input MAY be either a single-line text field that supports editing and typing or an element that only displays the current value of the combobox

Probably not necessary for our purposes, but it's not clear from the description of combobox how AT actually figures out whether a combobox is editable, since there are multiple ways to implement the edit box portion (e.g .input type=text, textarea rows=1, contenteditable or a custom-element).

Chrome treats a combobox using input/textarea/contenteditable as an editable combobox. Firefox only treats input/textarea as an editable combobox (contenteditable with role=combobox is not reported as editable in the FF a11y inspector).

Not tried custom elements but guessing that even if they do work, there will be differences between custom elements inheriting from input/textarea and autonomous custom elements (not even sure how an autonomous custom element could communicate that it's editable).