<div>I think using the role attribute is the best solution here:<br></div><br>&lt;input type=&quot;text&quot; role=&quot;username&quot;&gt;<br>&lt;input type=&quot;email&quot; role=&quot;username&quot;&gt;<br><br>This way we&#39;re using the type attribute to indicate what sort of data<br>

is being entered, and the role attribute to indicate how it will be<br>used. I think the separation of these is sensible, although it&#39;s not<br>entirely consistent across the spec (in my model, &quot;search&quot; would be a<br>

role on a type=&quot;text&quot;). It&#39;s also backwards compatible with HTML4 and<br>with current implementations of HTML5, and could tie in with the rest<br>of ARIA&#39;s roles model.<br><br>The same concept could, for instance, also be applied to a signup form<br>

where there is a check box for opting in to marketing:<br><br>&lt;input type=&quot;checkbox&quot; role=&quot;optin&quot;&gt;<br><br>You&#39;d need to use a role attribute of &quot;login&quot; or &quot;signup&quot; on the form<br>

as well to give context to things like role=&quot;username&quot; so the browser<br>would know what behaviour is appropriate. As someone pointed out, the<br>form element isn&#39;t always available if you&#39;re working with <a href="http://ASP.NET">ASP.NET</a>, so<br>

it would seem right to make the roles legal for fieldset, section and<br><div>div as well. In fact, it would seem right anyway because you could have <br></div><div>something like an ecommerce site where there&#39;s a single form to place</div>

<div>an order which deals with payment for the current order as well as </div><div>signup for the account.</div><div><br></div><div>David Goss</div>