Consider adding more normative requirements for authors on the textbox role

[joanmarie]

The ARIA spec says the following for the textbox role:

A type of input that allows free-form text as its value.

If the aria-multiline attribute is true, the widget accepts line breaks within the input, as in an HTML textarea. Otherwise, this is a simple text box. The intended use is for languages that do not have a text input element, or cases in which an element with different semantics is repurposed as a text field.

After that there is a (non-normative) note and the characteristics table. That's it. That suggests the following is, officially, a valid "simple text box":

<div role="textbox" aria-label="good luck!">
  <button>ok</button>
  <a href="#">link</a>
  <label>name: <input></label>
</div>

Some observations:

1. I don't think that's a "simple text box"

2. contenteditable isn't set but the default/implicit value of aria-readonly is false. According to the ARIA spec's State and Property Attribute Processing:

   When WAI-ARIA roles are used, supported states and properties that are not present in the DOM are treated according to their default value.

   So we have to trust that the author is using some non-contenteditable means to make that div editable.

3. aria-readonly is false as described above. aria-disabled is also false for the same reason, but this textbox is also not focusable, which brings me to the next item:

4. Should this really be exposed as a textbox to ATs?

I'm currently working on fixing a Chromium bug related to authoring like the above which breaks the screen-reader user experience because those focusable children get pruned from the accessibility tree unless contenteditable is set on the div with the textbox role. Why are they getting pruned? Simple text boxes don't have children. (Right??)

Fixing the not-in-the-accessibility-tree bug is not hard. But I think authors need to be stopped from doing the above. And depending on the normative statements we add for authors, we might want to consider handling-author-errors content so that user agents can provide a more consistent implementation and user experience given such authoring.

[JAWS-test]

Since an HTML textbox cannot have child elements, I would have expected role=textbox to have "Children Presentational: True".
If a match is to be created between HTML input/textarea and role=textbox, I think it would make sense to add "Children Presentational: True". (But then contenteditable would be something other than a textbox, for which we might need a new ARIA role. )

Your example would then be nothing more than <input type=text tabindex=-1 value="ok link name:"> with an event handler that prevents text input. This would be quite wrong, but I think it should still be submitted to the Accessibility API as an input field. I'm not a fan of too many repair mechanisms in the browser, but rather for clearly explaining in the ARIA spec how an element may be used.