Bug 180866 – AX: macOS VoiceOver doesn't announce when details element is expanded when using role group

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Anika Henke]

When you expand a details element which has the ARIA role "group" or access one which is already expanded, it wrongly announces that it is collapsed in VoiceOver on OS X 11.

Steps to reproduce:
1. Activate VoiceOver on OS X
2. Open http://jsbin.com/cequcu in Safari
3. Navigate to the first details element ("Open this")
4. Hit the space bar to open the element

Result:
VoiceOver says "Open this, collapsed, summary".

Expected:
VoiceOver should say "Open this, expanded, summary" like it does in the second example (which doesn't include the group role).

Although the group role is the default implicit role of the details element [http://w3c.github.io/html/interactive-elements.html#elementdef-details] and it is recommended not to use it in such a case [http://w3c.github.io/html/dom.html#do-not-set], it should also not make the element behave any differently.

[Radar WebKit Bug Importer]

<rdar://problem/36074338>

[Nan Wang]

Created attachment 341546 [details]
patch

[chris fleizach]

Comment on attachment 341546 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341546&action=review

> Source/WebCore/accessibility/AccessibilityObject.cpp:-2800
> -            return object.roleValue() == AccessibilityRole::Details;

What if someone made a details element into a landmark. Would we still expose expanded status?

Also is the attribute name exposed in this case?

We might want to list out the allowed roles a details can have and still have an expanded status

[Nan Wang]

(In reply to chris fleizach from comment #3)
> Comment on attachment 341546 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=341546&action=review
> 
> > Source/WebCore/accessibility/AccessibilityObject.cpp:-2800
> > -            return object.roleValue() == AccessibilityRole::Details;
> 
> What if someone made a details element into a landmark. Would we still
> expose expanded status?

Yes I think so.

> 
> Also is the attribute name exposed in this case?
> 
> We might want to list out the allowed roles a details can have and still
> have an expanded status

I don't see a list of allowed roles in any spec for details element. Do you have any suggestions? 

Or I can only allow details element with group role for this particular case

[WebKit Commit Bot]

Comment on attachment 341546 [details]
patch

Clearing flags on attachment: 341546

Committed r232285: <https://trac.webkit.org/changeset/232285>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Comment on attachment 341546 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=341546&action=review

> Source/WebCore/accessibility/AccessibilityObject.cpp:2800
> +            return object.node() && is<HTMLDetailsElement>(object.node());

No need to do a null check if using is<>, which returns false for null. So it would be better to just write:

    return is<HTMLDetailsElement>(object.node());

[Nan Wang]

(In reply to Darin Adler from comment #7)
> Comment on attachment 341546 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=341546&action=review
> 
> > Source/WebCore/accessibility/AccessibilityObject.cpp:2800
> > +            return object.node() && is<HTMLDetailsElement>(object.node());
> 
> No need to do a null check if using is<>, which returns false for null. So
> it would be better to just write:
> 
>     return is<HTMLDetailsElement>(object.node());

Ok updated
https://trac.webkit.org/changeset/232287/