W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2015

RE: ARIA Problem

From: Bryan Garaventa <bryan.garaventa@whatsock.com>
Date: Wed, 25 Nov 2015 16:46:58 -0800
To: "'Beranek, Nicholas'" <Nicholas.Beranek@capitalone.com>, "'Batusic, Mario'" <mario.batusic@fabasoft.com>, <w3c-wai-ig@w3.org>
Message-ID: <007901d127e3$fae0f000$f0a2d000$@whatsock.com>
That sounds reasonable to me, it just depends on what your UI requires.


Adding aria-disabled='true' and removing it from the tab order seems clearer to me if the Listbox includes no Option nodes, but if
there is some need for allowing this to receive focus, then you would need to set focus to the container element that includes


Then when populated by Option nodes, if focus remains on the role=listbox container, aria-activedescendant must be set appropriately
when selection changes.


However, if there is no tabindex on the role=listbox container, and tabindex is managed upon the role=option elements using roving
tabindex, then the Listbox will only become focusable after Option nodes are programmatically added to the container.


These are all valid ways to do the same thing, it just depends on what your functionality is.


All the best,




From: Beranek, Nicholas [mailto:Nicholas.Beranek@capitalone.com] 
Sent: Wednesday, November 25, 2015 6:36 AM
To: Batusic, Mario <mario.batusic@fabasoft.com>; Bryan Garaventa <bryan.garaventa@whatsock.com>; w3c-wai-ig@w3.org
Subject: RE: ARIA Problem


A teammate of mine and I just discussed. Honestly, I recommend hiding the Listbox from users altogether via display: none,
aria-hidden, and tabindex=-1. What's the point of having a Listbox focusable if you cannot perform any action? Or, if you'd rather,
apply aria-disabled=true, tabindex=-1, and certain styles to the component to make it appear disabled.






From: Batusic, Mario [mailto:mario.batusic@fabasoft.com] 
Sent: Wednesday, November 25, 2015 2:34 AM
To: Bryan Garaventa; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: AW: ARIA Problem


Hi Bryan,


Thanks a lot for your complete explenation of the listbox role. We use it now for years in our products exactly as you describe it.


My only question was the problem of empty listboxes:

*         According to the ARIA Spec 5.2.5: Required owned elements <http://www.w3.org/TR/wai-aria/complete#mustContain> , an
element with a role defining one or more requred owned elements must own at least one element with such a role.

*         Listbox role defines "option" as a required owned role.

*         What is then the validation result of an element with a listbox role which does not own any option role element?

*         And, if fortunately such a valitation is OK, where should we set the focus in case of an empty list - also to the element
with the role listbox directly?


Thanks in advance!




Von: Bryan Garaventa [mailto:bryan.garaventa@whatsock.com] 
Gesendet: Mittwoch, 25. November 2015 02:07
An: Batusic, Mario <mario.batusic@fabasoft.com <mailto:mario.batusic@fabasoft.com> >; w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Betreff: RE: ARIA Problem



The Listbox role is analogous to a standard HTML select element, and as such does support being empty if nothing is currently
contained within it.


The role mappings when an Option is present however, require that selectable Option nodes be children of the Listbox container,
whether as embedded children or mapped explicitly using aria-owns if not.


In practice, the most reliable usage presently is to make sure that Option nodes are embedded within the same container though.


Then you can set focus to the role=listbox container and use the arrow keys to change selection and update aria-activedescendant
accordingly to point to the ID of each selected role=option element, or use roving tabindex to set focus to each role=option element
individually using the arrow keys to change focus between them.


The aria-selected attribute is used to specify which role=option element is selected within the Listbox.


It's also important to assign an explicit label for the role=listbox container, in the same way that you would label a form field.
This can be done using aria-label or aria-labelledby. Supplementary descriptions can be assigned using aria-describedby too if
applicable. This is true regardless if the Listbox is empty of Options or not.


If it's helpful, I've mapped out the role and attribute hierarchies for Listbox at



As opposed to a structural construct such as List, at


Which is directly analogous to an HTML ul element.


It's important for people not to get the two of these confused.


Does this help?


All the best,




From: Batusic, Mario [mailto:mario.batusic@fabasoft.com] 
Sent: Tuesday, November 24, 2015 3:02 AM
To: w3c-wai-ig@w3.org <mailto:w3c-wai-ig@w3.org> 
Subject: ARIA Problem


Dear ARIA Specialists,


I have a fundamental problem with ARIA (also not yet better in ARIA 1.1):

An element with role=listbox requres at least one descendant with role=option. But I have to implement a selectable list (listbox)
that very often can be empty. The HTML solves this for static lists allowing for <ul>-elements to be without contents.


Is there some other possibility to solve the empty list problem without optimizing the definition for the listbox role?

Thanks in advance!


Ciao     Mario




The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be
used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the
individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified
that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this
information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the
material from your computer.
Received on Thursday, 26 November 2015 00:47:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 26 November 2015 00:47:45 UTC