how to handle WAI ARIA role="listbox" - accessibility

Question

I have a list of options from which one can be selected. For all intents and purposes HTML's <select> element covers this. Since we need a different visual presentation, I'm looking at using WAI ARIA role="listbox". I'm unclear on how to use aria-activedescendant, aria-selected and aria-checked.
Questions regarding focus/active state:
If I use aria-activedescendant on the listbox to point to the [role="option"] that is currently active (has "virtual focus"), I would use [aria-selected]. How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually? (:focus is on the listbox, after all)
an [role="option"] can have [aria-checked] and [aria-selected]. I guess I need [aria-selected] but don't see what I'd use [aria-checked] for.
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant?
Questions regarding keyboard interaction:
"Checkbox - Space toggles checkboxes, if the list items are checkable" - how do I figure out if they are checkable or selectable?
Questions regarding validation:
If the listbox has [aria-required="true"] some sort of validation has to be performed. specifically if an option has been selected (or checked).
when do I trigger the validation? is on blur sufficient?
when invalid, what do I have to do besides setting [aria-invalid="true"] on the listbox?

Answer 1

aria-checked is indeed more something for a list of very closely related options with actual visible checkboxes that can be toggled on or off. This is most common in the Windows world. Explorer can be set to such a pseudo multi-select mode, or some apps use that to activate or deactivate a set of accounts. On the Mac, you can think of the list of accounts in Adium, which can be either checked (active) or not. A selection will always be there, and one or more of their checkboxes can be checked or not.
aria-selected is always the right one to indicate the selected state of an option. E. g. when traversing the list with the arrow keys, aria-selected="true" moves from item to item, while the others must then get aria-selected="false". As Patrick said, you can use this to also generate some nice looking CSS.
As for keyboard interaction: arrows up and down will select an item, and if the items are checkable, too, space will toggle the checked or unchecked state of the currently selected item.
In a true multi-select, like html:select #size>1, and multiselectable being true, the interaction would be:
Arrow keys select a single item.
Ctrl+Arrow keys would move focus from item to item, but not select the item yet.
Ctrl+Space would select the item.
Shift+up and down arrows would select contiguous items.
This is, again, standard Windows paradigm, can be observed in Explorer in Details view, for example.
As for validation: onBlur is sufficient, or you could dynamically do it via changes in selection/focused item, make sure at least one item is selected, or whatever validation you need.
aria-invalid="true" is sufficient for screen readers to know, but an error message and possibly a visual indication would be nice for everyone to know what's wrong.

Answer 2

How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually?
Generally, you'd add aria-selected="true" and then craft some CSS that takes care of it using attribute selectors, e.g. div[role=option][aria-selected=true] { ... }, or add a css class dynamically?
[aria-checked] and [aria-selected]
This is more of a philosophical question I guess. aria-selected more closely matches what you'd have with a select...but then again (particularly for multi-select widgets) you can imagine the listbox actually being a series of checkboxes, and in that case you'd use aria-checked. there's no definitive right or wrong about either one (something you'll find a lot once you dive into more complex ARIA widgets).
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant
Hmm...perhaps you could dynamically generate IDs for all options on page load via script? Or - but not tested - you could have something like a "roving" ID that moves around the options depending on which one is active (adding/removing the ID to the relevant option).