Update aria-details

[aleventhal]

1. Support multiple elements.
2. Support types of information/annotations that are not descriptions.

Refers to issue #749.

---

Preview (#aria-details) (#AriaAttributes) | Diff

[joanmarie]

(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."

[aleventhal]

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

[carmacleod]

@aleventhal What is the use case for multiple elements? Does it merit an example?

[aleventhal]

@aleventhal What is the use case for multiple elements? Does it merit an example?

Example is multiple comments on the same content. These may not be part of the same thread. For example, Google Docs allows this.

[carmacleod]

Example is multiple comments on the same content.

Ah, ok - I see. Thanks.

[aleventhal]

This branch has conflicts, but if I rebase to master and push, will that make the review harder? I think it will be harder to see changes between versions.

[carmacleod]

if I rebase to master and push, will that make the review harder?

We're so close - maybe wait? @jnurthen ?

[mcking65]

Looking great now! Thank you for the updates!!

[aleventhal]

Anyone else want to approve so we can get this in?
@carmacleod @jnurthen @joanmarie

[joanmarie]

LGTM. Thanks!

[carmacleod]

+1
Looks good!

[carmacleod]

@aleventhal
Would you be able to add one teeny tiny completely inconsequential change "while you're there"?
In example 18, the word "ramp" is missing from:

In this example you will notice a skateboard ramp with a base and vertical board ...

I know... it's the equivalent of Lorem ipsum and nobody's going to read it, and you didn't even write that example... but I noticed it and I Can't. Let. Go... 😄

[aleventhal]

@aleventhal
Would you be able to add one teeny tiny completely inconsequential change "while you're there"?

Done.