IE compatible markup for ARIA combobox

Question

I'm taking another stab at finding a way to make Ext JS Combobox components to be compatible with IE/JAWS. Presently we're using the following markup:

<div role="presentation" id="combobox-1011">
    <label id="combobox-1011-labelEl" for="combobox-1011-inputEl">
        <span>Choose:</span>
    </label>
    <div id="combobox-1011-bodyEl" role="presentation">
        <!-- This wraps both input and triggers -->
        <div id="combobox-1011-triggerWrap" role="presentation">
            <div id="combobox-1011-inputWrap" role="presentation">
                <input id="combobox-1011-inputEl" type="text" name="choose"
                    role="combobox" aria-readonly="false"
                    aria-haspopup="true" aria-expanded="true"
                    aria-autocomplete="none" aria-owns="boundlist-1014-listEl"/>
            </div>
            <!-- Trigger element styled to look like a button -->
            <div id="combobox-1011-trigger-picker"></div>
        </div>
        <!-- This is used to announce input validation errors -->
        <div id="combobox-1011-ariaErrorEl" role="alert" aria-live="polite"></div>
    </div>
</div>
<div id="boundlist-1014">
    <div id="boundlist-1014-listWrap">
        <ul id="boundlist-1014-listEl" role="listbox" aria-hidden="false">
            <li role="option" tabindex="-1" aria-selected="true" id="ext-element-7">Option 1</li>
            <li role="option" tabindex="-1">Option 2</li>
        </ul>
    </div>
</div>

This works reasonably well in Firefox with JAWS and NVDA; however JAWS in IE will announce the input field as "edit" when focused.

After reading WAI-ARIA Combobox pattern until cross-eyed and experimenting for several days I'm ready to admit that IE is just too buggy to make combos work reliably. Or maybe it's not IE itself but rather MSAA/UIA bridge as suggested in this comment. This could as well be true because I found at least one combination of ARIA attributes that appeared to be working well in IE8/XP with JAWS (uses MSAA) but did not work in IE11/Win7 with JAWS (MSAA/UIA).

The markup can be changed to some degree; what I cannot change is the existence of the wrapping elements like bodyEl, triggerWrap, and inputWrap. These elements are necessary to apply relevant CSS classes, render error indicator elements when input validation fails, etc.

Another constraint is that the listbox element is rendered outside of the component element. This can be changed but not easily; also rendering it adjacent to the input does not seem to help at all. It should be worth mentioning that the list itself is rendered dynamically on first expand, with aria-owns attribute added after the fact.

What I tried so far:

• Placing role="combobox" on the outer element. Does not do anything useful, combo is not recognized as such.

• Placing role="combobox" and relevant attributes on the inputWrap. This way IE will announce "Choose edit combo" when input is focused directly; when tabbing from another element it will announce that element's role instead, along with the combo label. Quite funny but not really helpful.

• Placing role="combobox" on the triggerWrap and assigning role="button" to the trigger pseudo-button. In theory this should be close to the first design pattern but combo is not recognized as such.

• Many other ad-hoc combinations, most of which I don't recall anymore.

The only quasi working way is placing combobox role on the inputWrap and making inputWrap tabbable instead of the actual input. This corresponds with markup in this example that appears to be more or less working with IE/JAWS; however this solution is very undesirable since it opens Pandora's box full of very hairy focus management bugs.

Unfortunately the Accessibility inspection tools are not entirely useful in this case because what I need is a workaround for bugs in the existing implementation, not stricter standard compliance.

Another obstacle to better understanding is ambiguity in the WAI-ARIA spec. For example, for the first pattern it is required that "the first element within the combobox is an input text field". Does that mean first structural element (i.e. non-presentational), or absolutely first child element? Modifying markup either way does not seem to make any difference for IE, unless the wrapper <div role="combobox"> is tabbable.

Sorry if this post looks more like a rant ;) but it's actually a question: is there a way to work around IE deficiencies by applying ARIA attributes to our existing markup elements? If not, what can be changed to making it work (barring tabbable wrapper)? And ultimate bonus points for insights into why this is not working as expected.

I would appreciate any hints and suggestions. I'm very much concerned with our combos not being fully accessible in IE and would like to resolve this issue if possible. I still have a faint hope that someone out there might possess a secret ingredient recipe to make both IE and JAWS happy with each other. ;)

UPDATE: Here's an example fiddle. Note how combo is announced properly in Firefox but it's just "edit" in IE11 (tested with JAWS 16). For better results with the screen reader I recommend to use Open outside of Fiddle option that is available in Share menu.

Answer 1

I also faced the same problem for our custom combobox widget. I found that if you mark input field readonly and use role="combobox" on input field then JAWS on IE reads it as combobox. This solution has some issues like normal user can't type the text to filter the combobox.