Announcement

**Isomorphic** · 3 Dec 2012, 16:47

When we last looked at the ARIA spec this issue was left unaddressed; the spec was clear that keyboard focus should *not* go to the list, but there was no way to signal to the reader what option should be read.

However there's been an update, see this section in the editor's draft:

If an author sets a combobox's value of aria-autocomplete to 'list', user agents MUST expose changes to the aria-activedescendant attribute on the combobox while the combobox remains focused. If a change to the aria-activedescendant attribute occurs while the combobox is focused, assistive technologies SHOULD alert the user of that change, for example, by speaking the text alternative of the new active descendant element. Authors SHOULD associate the combobox textfield with its listbox using aria-owns.

The new part is the activedescendent piece. Would you mind verifying that this ARIA markup actually works in NVDA/JAWS or whatever you have handy? If so, we'd happily update the framework to use it. But this is new enough that readers may not have caught up..

**hohwille** · 7 Dec 2012, 05:22

Thanks for your response. I will have a look.

However, I tested your showcase once more and figured out something very interesting:

http://www.smartclient.com/smartgwt/showcase/#form_controls_various

The problem applies for the first of the comboboxes but nut for the second one with the icons (countries with flags). There the selection option is read by screenreaders.

With your hints and this finding I am quite sure, that I will be able to fix my problem. I will provide additional feedback if I get new insights.

**hohwille** · 19 Dec 2012, 02:36

I checked setting aria-activedescendent in ISC_Forms.js, lines 1357 and 1358.
However this did not do the trick.
Please note that your SelectItem does not even have aria-owns set but selecting with arrow keys from the pick list triggers the screen-reader there.

Another problem is that both ComboBoxItem and SelectItem can not be properly controlled with the keyboard. It is very hard (for SelectItem it seems impossible) to expand the list only with the keyboard.

BTW: Here is an excellent example of a ComboBox:

http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Select.html

It is entirely accessible according to my tests. It can also be expanded by pressing arrow down. Further, it highlights the currently selected item whenever it gets exposed. Maybe you can get some good inspirations for your ComboBox from there.

**hohwille** · 19 Dec 2012, 06:07

I found it in your JavaScript:

if(_4=="Enter"&&this.isSelectOther){if(this.$19u!=null)this.updateValue()}else if(_4=="Arrow_Down"){if(isc.EH.altKeyDown())this.showPickList();

You have to hold the [alt] key while pressing arrow down. Is that just something I do not know but is a common standard? From my experience with other web applications (or frameworks) arrow down is just sufficient. Typical users try [space], [return] and arrow-keys.

Is there some reason why [alt] is required? What would happen if this additional condition was removed? If I hit arrow down without [alt] then nothing happens. Wouldnt it make sense, if the picker list would then expand?

**Isomorphic** · 19 Dec 2012, 11:47

Alt+DownArrow is the standard Windows key for opening a drop-down.

Just DownArrow doesn't make sense for opening the drop-down list on a SelectItem - that should change the value in place.

Again, if you can verify that adding the appropriate aria-owns and aria-activedescendant attributes would actually work with a screen reader, we'd be happy to add them.

It's generally a waste of time for us to look at demos like you pointed. We've found they usually do not fulfill the actual requirements (eg, no load on demand, or values exist in the DOM at page load, etc).

**hohwille** · 21 Dec 2012, 00:39

> Alt+DownArrow is the standard Windows
> key for opening a drop-down.

Ok. Microsoft is sometimes good about usability,
but should not always be used as reference,
especially for the web.
It is simply unintuitive and not known by many users.
It is also a common standard to do multi-selection
in lists on the web holding [ctrl] but still tons of
users do not know as is nothing you simly guess.
I am very happy that SmartGWT offers checkbox selection
in ListGrid what is way more intuitive. Thanks for that!

I showed the Dojo combobox to other guys and all said it
is easier to use and more intuitive, while they considered
the SmartGWT ComboBox as partially buggy (esp. the fact
that if you have a selection and exand the dropdown list
the first item is highlighted instead of the one that is
currently selected).

> Just DownArrow doesn't make sense
> for opening the drop-down list on a
> SelectItem - that should change the
> value in place.

OK. But then there is a bug as in some situations
when using just the keyboard I can put the focus
in the SelectItem and arrow-down is just doing nothing.

Why can't arrow down just always expand the dropdown?
However, I am aware that you have to consider compatibility
and there might be other users that think the current
behavior is the way it should work. But aks real users
(esp. non IT guys) and think about it...

> Again, if you can verify that adding
> the appropriate aria-owns and
> aria-activedescendant attributes would
> actually work with a screen reader,
> we'd be happy to add them.

I tried, but unfortunately it does not work
as expected. I cannot even notice a difference
when adding aria-activedescendant pointing to
the id of the dropdown list.

> It's generally a waste of time for us to look
> at demos like you pointed. We've found
> they usually do not fulfill the actual
> requirements (eg, no load on demand, or
> values exist in the DOM at page load, etc).

I see your general point but I do not want you
to copy the solution. All I wanted is that you
have a look at the way they do it, especially
the ARIA attributes.
You are saying:

"Smart GWT is a fully accessible technology
which fulfills the Section 508 requirements of
U.S. government law and similar international
standards."

www.smartclient.com/smartgwtee-latest/javadoc/com/smartgwt/client/docs/Accessibility.html

And really SmartGWT is doing a great job about
accessibility in various arias. However in others
like ComboBoxItem and RadioGroupItem it is actually
not accessible for users of screenreaders.
As a user of SmartGWT it is extremely hard for me to
find a solution. With plain GWT or other frameworks I
can interfere and hook into within Java. But for
SmartGWT I have to dig into your JavaScript code
that I do not understand and find the spot where to
make a change in order to set some aria attribute and
do a test. So unfortunately I am not able to provide
you with the patch that solves the problem. You can
also install NVDA. It is free and easy to use.
Switch off volume and select Tools > SpeechViewer.
Then you can see what the screenreader is reading.

However, here are the difference I analysed about
the Dojo ComboBox:
* they set aria-selected="true"/"false" to mark the
selected item in the dropdown list. Maybe thats
the important one.
* they use role="listbox" for the outer container and
role="option" for the inner one holding the value.
I would have expected role="combobox" instead.
* they use aria-owns and aria-expanded like you do
for ComboBoxItem, also they do not use
aria-activedescendant.
* they do use aria-haspopup="true".

**Isomorphic** · 21 Dec 2012, 07:41

We're getting into subjective minutia here, things we have discussed many times with many, many groups and companies, so please understand if we stop responding (we have actual bugs to fix).

In general, when looking at usability and accessibility here, realize that SelectItem and ComboBoxItem are totally different things, and also that load-on-demand introduces special requirements, but examples of such widgets are somewhat rare in native software, so there tends not to be clear standard to follow.

... SmartGWT ComboBox as partially buggy (esp. the fact
that if you have a selection and exand the dropdown list
the first item is highlighted instead of the one that is
currently selected).

Keyboard navigation for a ComboBox starts at the top because that's where the most likely options are.

For SelectItem, remember load on demand - the selected option is not necessarily even loaded. Consider how weird it would be to do two different things in the load-on-demand vs fully loaded case, when the same SelectItem in the same form may be using load on demand or not based on values in earlier fields.

The best compromise is to always place the highlight at the top.

> Alt+DownArrow is the standard Windows
> key for opening a drop-down.

Ok. Microsoft is sometimes good about usability,
but should not always be used as reference,
especially for the web.

We look at many different systems that users might be familiar with. Implementing the Windows shortcut here is a clearly good thing and doesn't preclude other shortcuts.

> Just DownArrow doesn't make sense
> for opening the drop-down list on a
> SelectItem - that should change the
> value in place.

OK. But then there is a bug as in some situations
when using just the keyboard I can put the focus
in the SelectItem and arrow-down is just doing nothing.

Let us know if you can show how this could be reproduced.

Why can't arrow down just always expand the dropdown?
However, I am aware that you have to consider compatibility
and there might be other users that think the current
behavior is the way it should work. But aks real users
(esp. non IT guys) and think about it...

Based on your suggestions you are used to SelectItems on Macs. But these are in a minority, and in Windows the DownArrow changes the value.

As far Spacebar, we think it's a bit too fundamental of a key to use for opening the list by default, as it could have other functions in a given app. But a specific app can always implement spacebar as a key that opens the dropdown, and perhaps this is worth adding as a simple flag in SmartGWT.

As far as the Dojo example, looks like again you have some confusion re SelectItem vs ComboBox. The Dojo samples do not show ComboBoxes at all - ComboBoxes are controls where you can type in values.

They also do not show load on demand. So much, much, much simpler problem, and not enterprise-capable.

Our SelectItem already uses "listbox" and "option" and appears to use them correctly. If the reason NVDA doesn't read the value properly is because it relies on aria-selected here, we'd regard that as a bug in NVDA relative to the ARIA spec. As we've discussed, load on demand means the selected element is not always present in the browser or visible to the user.

Announcement

ComboBox not accessible

Comment

Comment

Comment

Comment

Comment

Comment

Comment