In Section 2, "Using WAI-ARIA", the spec states that host language states and properties take 
precedence over ARIA states and properties to avoid a conflict.  This might have exceptions.  For 
example, in the case of creating a DHTML autocomplete developers need to set the "autocomplete" 
attribute on a textbox to "off" in order to suppress the default browser autocompletion, but set the 
"aria-autocomplete" attribute to the appropriate value.  For example:

<input type="text" aria-label="Tag" role="combobox" aria-expanded="true" autocomplete="off" 
  aria-autocomplete="list" aria-owns="owned_listbox" aria-activedescendant="selected_option">

<input type="text" aria-label="Tag" role="combobox" aria-expanded="true"
  aria-autocomplete="list" aria-owns="owned_listbox" aria-activedescendant="selected_option">
<ul role="listbox" id="owned_listbox">
  <li role="option">Zebra</li>
  <li role="option" id="selected_option">Zoom</li>
</ul>

If browsers or AT manufacturers follow the spec as currently written, the host language attribute of 
"autocomplete" would win out over the "aria-autocomplete" and AT wouldn't announce that the 
control has autocomplete.


In Section 5.2.7.4 "Text Alternative Computation Example #1", the example shows use of basic 
menutiems with the aria-haspopup property set to "false".  For example:

<ul role="menubar">
 
 <!-- Rule 2A: "File" label via aria-labelledby -->
  <li role="menuitem" aria-haspopup="true" aria-labelledby="fileLabel"><span id="fileLabel">File</span>
    <ul role="menu">

      <!-- Rule 2C: "New" label via Namefrom:contents -->
      <li role="menuitem" aria-haspopup="false">New</li>
      <li role="menuitem" aria-haspopup="false">Open</li>
    </ul>
  </li>
</ul>

Is this now the recommended approach?  If so, it seems like a waste of bytes.  All previous ARIA 
menuitem markup examples I have seen show that menuitems without a submenu just have a role of 
"menuitem" and that's it.  I think that the "aria-haspopup='false'" should be implied if it is 
simply left off.


Section 5.3.2 lists the roles that act as composite containers.  However, the role of "toolbar" 
isn't on this list, but rather is listed in the "Document Structure" roles list in section 5.3.3.  
This seems like a mistake.  A toolbar is a composite considering that, like all other composite 
controls, it has a set of decendant controls (buttons) whose focusability needs to be managed by 
the container.  This is further reinforced later in the spec in the role definition for toolbar, 
where it states that "To be keyboard accessible, authors SHOULD manage focus of descendants for all 
instances of this role, as described in Managing Focus."