According to the spec:

If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false.

This can lead to an inconsistency between native and ARIA listboxes. Consider the following:

<select size="3">
<option>blue</option>
<option>red</option>
<option>green</option>
</select>
<button>ok</button>

If the user arrows down to the "red" option and then presses Tab, "red" is still selected even though the "ok" button is focused. Furthermore, and more importantly, a screen reader's review mode could be used to examine the select list and obtain the currently-selected value without ever changing focus. In the case of Linux, the AtkSelection interface implemented on that select element will return the accessible associated with the "red" option.

In contrast, we have this example:

<div role="listbox" aria-activedescendant="red" tabindex="0">
<div role="option">blue</div>
<div role="option" id="red">red</div>
<div role="option">green</div>
</div>
<button>ok</button>

Assume the author provided keyboard navigation, the user arrowed to "red", the author updated the value of aria-activedescendant accordingly. Then the user pressed Tab to give focus to the "ok" button.

If the user agent provides an implicit aria-selected (which Chrome/Chromium does), the spec states that it should only report the selected item to ATs when the listbox or option is focused. Chrome/Chromium follows this. As a result, a screen reader's review mode cannot be used to examine the listbox and obtain the currently-selected value without ever changing focus.

What is the rationale behind the language in the spec? Is there a benefit to not exposing the selected item when the listbox is no longer focused and introducing this inconsistency between native elements and ARIA?