Page MenuHomePhabricator

Further improve screenreader compatibility in AdvancedSearch by adding aria-controls tags
Closed, ResolvedPublic3 Story Points

Description

As pointed out by @Volker_E, the ARIA tags we have previously added are not complete enough, for reference:

https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AdvancedSearch/+/444630/

Specifically the remark about aria-expanded:

This will only work in connection with aria-controls as the button.$elment isn't a parent.

As part of this ticket, aria-controls should be added so that screen readers know what to do with the newly added aria-expanded tag.

Details

Related Gerrit Patches:
mediawiki/extensions/AdvancedSearch : masterAdd aria-controls attribute

Event Timeline

Tim_WMDE triaged this task as Medium priority.Jul 17 2018, 2:07 PM
Tim_WMDE created this task.
kai.nissen set the point value for this task to 3.

Change 447619 had a related patch set uploaded (by Tonina Zhelyazkova; owner: Tonina Zhelyazkova):
[mediawiki/extensions/AdvancedSearch@master] Add aria-controls attribute

https://gerrit.wikimedia.org/r/447619

@Volker_E aria-controls attribute is now added, but according to this and this article aria-controls does not work on all platforms and browsers.
I'm not quite sure what else to do. Do you have any other improvements in mind? Any help is highly appreciated.

Change 447619 merged by jenkins-bot:
[mediawiki/extensions/AdvancedSearch@master] Add aria-controls attribute

https://gerrit.wikimedia.org/r/447619

Thanks @Tonina_Zhelyazkova_WMDE – yes, this is a weakly supported attribute. But it follows the standard docs and in such case we should make use of the standard in cases where other (currently probably wider supported) solutions are too time-costly. Or as Léonie Watson puts it at the end of the article mentioned by you:

Despite the fact support amongst browsers and screen readers could be better, the aria-controls attribute is still worth using. Creating relationships within the DOM is certainly more robust, but it isn’t always practical or achievable. The presence of aria-controls won’t damage the User Experience (UX) for people using UA that don’t support it, but it will enormously improve the UX for those people whose browser/screen reader combinations do.

And I don't see a time-sensitive solution right now, as it would probably result in a major refactoring and some parent child construct, that leads to other issues. See also Heydon's –as second critical author on aria-controls support above– example on progressive collapsibles using exactly the structure we now have.

Aklapper changed the edit policy from "Custom Policy" to "All Users".Sep 17 2018, 5:57 PM
Aklapper changed Risk Rating from N/A to default.
Volker_E updated the task description. (Show Details)Sep 17 2018, 6:24 PM
Lea_WMDE closed this task as Resolved.Sep 18 2018, 9:05 AM
Lea_WMDE claimed this task.