Thread by @codingchaos

A brief thread about ARIA side effects, since one outcome of the accessibility push at Microsoft is by the time it filters down to product teams, it still results in regular old div soup, but with a side of ARIA salad.

https://twitter.com/stowball/status/1156451879087247361

This is not a comment on Twitter's choices; there are legitimate use cases for a custom contenteditable region over textarea.

And obviously no shade towards Microsoft devs doing their best with a new and complex task. Accessibility ain't easy.

So, the contenteditable approach looks OK at first glance: it has the proper roles and attributes attached, it's labelled, it's focusable, works ok with screen readers. All in all, not a bad pattern.

The thing is, non-native controls never fully match native element behavior.

So, without further ado, a list of easily-overlooked ways the custom contenteditable div behaves differently from a textarea, using this simplified reproduction: jsfiddle.net/a6jsgm5d/1/show

(ignoring the autocomplete listbox functionality)

1. When tabbing to the custom textbox, it puts the insertion point at the beginning of the text instead of at the end.

I watched someone using a screen reader be briefly confused about this

2. Clicking the label of a form field generally sends focus to the form field, which does not work (without additional javascript) with the custom textbox

3. The color of the placeholder text in the custom textbox does not match expected placeholder text color in high contrast mode.

Both the label text and placeholder text for the custom textbox are separately reached in scan mode/virtual PC cursor mode/swiping on iOS with Voiceover before encountering the custom textbox. This is not the case with the native textarea.

Entering the custom textbox does not trigger an automatic screen zoom on iOS, as it does when entering other form inputs.

(Is this a bad thing? I'm really not sure! Let me know if you find this useful)

Observed on NVDA and Firefox: when tabbing to the custom textbox or jumping by form control, NVDA will only announce the first letter of an entered value instead of the full first line.

None of these seem like complete blockers, but they all have the potential to cause moments of confusion. This also isn't comprehensive -- I only tested what I had easily available. I'm not sure how it works with Dragon, for instance (though voice dictation was OK).

In summary: non-native solutions always come with tradeoffs, and ARIA is not enough to patch up everything (at least in today's web)