Dijit.Form: DropDown functionality not accessible for JAWS users

[mikeb]

Dijits that use drop down functionality (ComboBox?,DateTextBox?, FilteringSelect?) can seemingly "trap" JAWS users.

To reproduce:

1. Open the URL:

​http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/_autoComplete.html?testWidget=dijit.form.FilteringSelect

2. Open JAWS' field list (Insert + F5) and choose the first edit combo.
3. JAWS places the focus on the down arrow and not the combo text.

This happens because JAWS field list will focus on the first focusable element in source code for the role="combobox" object, which turns out to be the drop down arrow. The drop down arrow is using an <input> tag with role="presentation" and tabindex="-1" which ensures users cannot tab into the arrow element, but it does not make the element "non-focusable"

The attached patch just connects to the <input>'s onfocus and sends focus to the textarea instead. CLA on file with IBM.

(Another option would be to change the <input> to a non-focusable element like a <div> but this was leading to some styling issues.)

[Douglas Hays]

Would setting disabled=disabled instead of readOnly=readOnly in the template work just as well w/o the extra onfocus connect? There are also sizing INPUTs in the ValidationContainers? as well and on other widgets.

[Douglas Hays]

Setting disabled doesn't work on FF since it prevents mousedown events.
Another idea: in TextBox.js, change
_buttonInputDisabled: has("ie") ? "disabled" : "",
to
_buttonInputDisabled: has("gecko") ? "style='-moz-user-focus:ignore'" : "disabled",

[bill]

Sounds like -moz-user-focus:ignore should be set on that node in dijit.css.

[Douglas Hays]

In [28678]:

Fixes #15398. Add -moz-user-focus:ignore to down arrow button to prevent screen reader focusing on Firefox even with tabIndex=-1.

[mikeb]

Adding disabled=disabled to the input definitely keeps JAWS from focusing on it, but does break the drop down.

I was not aware of -moz-user-focus:ignore but it doesn't seem to work; the bug is still reproducible. We found these posts that suggest -moz-user-focus is no longer used or implemented(​https://bugzilla.mozilla.org/show_bug.cgi?id=256003,https://bugzilla.mozilla.org/show_bug.cgi?id=379939)

We could try to put the textbox <input> before the arrow <input>. Since JAWS focuses on the first focusable element in the combobox, this would work. However, when I tried it the height gets pretty messed up. I tried for a little bit but couldn't find any way to keep the height the same. Maybe we need to use a hidden <input> with disabled=disabled to set the height and then a second input after the textbox to show the drop down arrow? Do you something like that would work?

[Douglas Hays]

I don't think adding another element to the template is good, nor is changing focus (especially from within a focus event handler). Since this is a Firefox+JAWS specific issue, a CSS-only or a node/attribute solution would be greatly preferred.

[Douglas Hays]

mikeb, can you try adding these well:
-moz-user-select: none;
-moz-user-input: disabled;

[Douglas Hays]

If this fails, maybe aria-disabled=true will work - but not sure of the side-effects.

[mikeb]

Adding the following, they do not work:

-moz-user-select:none; - JAWS users can still access with INS+F5. Makes Jaws say "Button unavailable readonly" but using the keys still causes them to get 'trapped' in the input box

-moz-user-input:disabled; - Breaks drop down functionality for all users

aria-disabled="true" - doesn't do anything

aria-hidden="true" - doesn't affect useability for sighted users. Makes Jaws say "edit combo readonly. Black down pointing triangle....". JAWS users are still trapped by the keyboard

It seems like aria-disabled is the correct ARIA tag to use. aria-disabled says: Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable.

I understand how making it appear in the Form Field list is a way to ensure the element is perceivable. However, by listing it in the Form Fields, it allows JAWS users to focus on and try to interact with the element, even though it is supposed to be not operable.

Seems like this is a JAWS bug with JAWS not respecting aria-disabled on elements when generating the Form Fields list. (The fact that users can still type and use the arrow keys inside the black down pointing triangle shows that JAWS doesn't respect the "not operable" portion.)

Further support for aria-disabled: the spec says: "Disabled elements might not receive focus from the tab order." This indicates that the reasoning behind aria-disabled is to keep users from tabbing into and interacting with a disabled element.

Following up with Freedom Scientific

[mikeb]

fixes focus problem from JAWS field list by adding role="button presentation" CCLA on file with IBM

[mikeb]

Still debating with Freedom Scientific about what the correct JAWS behavior should be in this case. However I was able to find an aria-only workaround. By setting the role to something other than presentation (in this case, button) we can make JAWS respect the aria-hidden attribute. We still need "presentation" in the aria attribute to avoid needed to set a label for the button.

Tested with JAWS13, everything works as before except when you use the Field list and select a combobox, it focuses on the input element and lets the user use drop down keys (or keyboard) to select a new one.

Also updated the test page to be more compliant.

[Douglas Hays]

In [29815]:

Fixes #15398. Add proper roles to ComboBox?. Proxy commit for Mike Billau (IBM, CCLA).