Why react wai-aria is not in camelCase?

Question

From react docs

Note that all aria-* HTML attributes are fully supported in JSX. Whereas most DOM properties and attributes in React are camelCased, these attributes should be hyphen-cased (also known as kebab-case, lisp-case, etc) as they are in plain HTML:

AFAIK, every HTML attribute is renamed to camelCase in react. Is there any reason to explain why aria-* is kept their original name?

Bonus, is there anyone know, should it be <input autoFocus='autofocus'/> or <input autofocus='autofocus'/>. The former looks correct because my editor does not throw any warning. But is it inconsistent between the attribute name and its value?

Should it also be autocomplete or autoComplete, while there is no hyphen between auto and complete in the original attribute name?

Answer 1

The React API Reference provides some information about this. At DOM Elements, it says:

In React, all DOM properties and attributes (including event handlers) should be camelCased. For example, the HTML attribute tabindex corresponds to the attribute tabIndex in React. The exception is aria-* and data-* attributes, which should be lowercased. For example, you can keep aria-label as aria-label.

The section All Supported HTML Attributes gives autoComplete and autoFocus as the expected names.

Now, this doesn't actually answer why the aria-* attributes remain lowercased, but at least it's a clear statement of how they are supposed to be used.

Speculation: Perhaps this has something to do with a change which took place between React versions 15 and 16. The blog post "DOM Attributes in React 16" explains that custom attributes are now allowed in React 16, which were previously stripped out. It describes some concerns that an internal whitelist of attributes had become a maintenance burden, which needed to be simplified. Now arbitrary attributes can be included in JSX. I don't know how this works internally, but I suppose the aria-* attributes play some part in the story of the internal whitelist. For instance, WAI-ARIA 1.1 recently introduced several new aria-* attributes, and the WAI Personalization Semantics Content Module working draft introduces a lot of aui-* attributes. Both of these would have needed to be whitelisted.