"e-mail" is incorrect localized control type

[RobGallo]

In https://w3c.github.io/html-aam/#el-input-email

This issue refers specifically to the use of "e-mail" as the recommended UIA LocalizedControlType property when the HTML input element with the type="e-mail" attribute is used (section 4.4).

Here's why this is a worse choice than the standard and appropriate "edit":

First, "edit" conveys a rich set of information which "e-mail" does not. "edit" conveys the following:

• Enter text
• Navigate by character, word, and line
• navigating with the up and down arrows will not change the value of the control (unless the edit is marked as auto-complete or is part of a combo box)

"e-mail" conveys the following:

• ?

"e-mail" is not a type of control, and therefore conveys no semantic information to the user about how to interact with the control. An "e-mail" control could easily indicate any one of the following:

• A text field where one enters an e-mail address
• A text field where one enters the body of an e-mail
• A read-only, but arrow navigable field where an e-mail one has received is to be read.
• A list of e-mail messages
• A specific e-mail message in a list

In some of these cases, the arrow keys are expected to navigate by character, word and line. In some, they are not. In some, text may be entered. In some, it may not. How can the user disambiguate without context?

That brings me to my second point: the user already has context: the UIA Name property. The Name property (i.e., the label for the edit field) always indicates what is to be entered into the edit field. So the LCT of "e-mail" not only adds no new information but is redundant. Instead, if the LCT were "edit" the user would quickly understand that they are to enter an e-mail address using the standard methods for text editing they are used to.

One argument I have heard in favor of using "e-mail" as the UIA LCT is that it alerts the user as to which touch keyboard will pop up when editing. Having this information included in UIA is certainly not a bad idea. However, the LCT is the wrong place for it. The reason is what is being modified by the LCT. Logically, the two types belong to two different controls:

"edit" -> edit control
"e-mail" -> type of touch keyboard

The two LCTs modify (belong to) the two separate types of controls.

Another argument made is that the AT now has access to the specific type of edit field through the LCT. That argument, while technically true, is pretty bad. The AT does not expect that piece of information to be in the LCT. And it rightly expects an entirely different type of information to be in that property.

A parallel can be drawn to password fields. Password fields still have an LCT of "edit". There is a separate boolean value: IsPassword, which indicates if the edit is a password.

And if the argument is that there is no other place to put this information in UIA, that is an insufficient argument for three reasons:

• the aria-properties property in UIA would be much more appropriate for this type of information.
• UIA can and should be changed to be better.
• Adding information in places it does not belong has historically been a big mistake, making it much harder for screen readers and other ATs to provide correct, dependable information to users.

There seems to be a false equivalency in mind between HTML and UIA (or any accessibility API). The goal is not to translate HTML directly into UIA. HTML is designed to tell a browser how to render content. UIA is designed to represent the properties required to provide a good experience for an AT user. So a mapping is good, but a direct translation, like most direct translations of natural language, may not make sense.

I should also like to point out that, wisely, neither Chrome nor iOS obey the recommendation as it is currently written.