(I hate adding an "as long as you're fixing stuff here...." request, because I hate receiving them. 😃 But I've been working on implementing support for aria-details in Orca and I think it's relevant.)

I'd like to see an "Authors MUST give an accessible name to the object containing the details." I can live with it being a SHOULD.

EDIT: It just occurred to me that making it a MUST implies role restrictions, namely aria-details could only point to objects whose roles permit naming. Thus no details in paragraphs or the like.... Guess that means it needs to be a SHOULD rather than a MUST.

I came across Scott's blog entry on aria-details when looking for what the user experience should be, and he mentioned:

For instance, when an element has aria-details, JAWS will announce “Has details” but provides no indication in where those details may be located in the DOM.

I agree with his observation. Therefore, what Orca does now is announce "Has details in $OBJECT_NAME $OBJECT_ROLE." While this is not as good as the to-be-implemented command to navigate directly to the object with details, it does make it possible for users to use screen-reader list of dialogs for navigation. For instance, if Scott had named the list associated with the password requirements, Orca could say "Password: Password text. Has details in Requirements list." The Orca user could then do Alt+Shift+L for the list of Lists and find the Requirements list. Unfortunately, he didn't name it. So Orca just says "Has details in list."

AIUI on our phone call we determined that it is not necessary to push a role or name. There are cases where one or both don't make sense.

To get around this and do something helpful for the user, the screen reader can try to present something based on the following:

• optional role
• optional name or contents

Screen reader can have an option like:
[ ] Annotation verbosity: summarize comments, footnotes and other details

Or maybe there is a 3 way toggle -- no details | role only | summary

LGTM. Thanks!

+1
Looks good!