Media search presents results as an enumeration of links grouped in a tab panel.
I think it should be a list. There is even a code smell that says this, as the class for this group of link is "results__list".
Note that links cannot be list items at the same time though (an element can only have one role)
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| MediaSearch results are not a list | mediawiki/extensions/MediaSearch | master | +16 -3 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T286937 [Epic] Accessibility improvements for Commons MediaSearch page | |||
| Open | None | T283819 [S] MediaSearch results are not a list |
Note that links cannot be list items at the same time though (an element can only have one role)
I believe this is what prevented us from using a list element originally. We needed very specific behavior from the image grid and could only achieve it with Flexbox. We wanted the parent results grid <div> to apply grid rules to immediate <a> child elements.
In terms of accessibility we do already ensure that users can navigate through the results (including the image grid) using the keyboard, and :focus styles are used on the result links to provide visual feedback to the user.
However, we could probably make things more semantic and assistive-technology-friendly without having to re-work the existing layout by using the ARIA list role.
Change 703703 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):
[mediawiki/extensions/MediaSearch@master] MediaSearch results are not a list
@egardner I have created a patch, and then re-read the main message and notice that an "a" element cannot also have a role of "listItem".
Do you want me to Make the correct modification to all the different search results (images, video) to contain a "div" wrapper (with a role of listitem) around the link? or what do you guys envisage to fix this issue?
Part of my original hope here was that we could avoid making significant changes to markup and styling. But you're right, adding the role listitem to the <a> tags means they are no longer seen as links from the perspective of assistive technology.
Before going further I think we should determine if this is really necessary. For the sake of comparison, google image search (similar UI) does not present its results as a list at all – no <li> tags, no list or listitem ARIA roles.
Are there specific accessibility behaviors we are not getting because of the way we currently present search results? So far we've been more focused on ensuring keyboard navigation works in the results.
Ensuring that the entire UI works smoothly with tools like VoiceOver is probably a bigger task than just this one change, and may deserve it's own epic-level ticket. After taking a quick spin with VO & Firefox, it looks like we could probably improve the labels we provide on a number of different elements. We should also think about real-world use-cases here; an image search tool won't be much use to non-sighted users that rely 100% on spoken descriptions, but there likely are users who rely on a combination of visual and auditory cues that would benefit from more work in this area.
TLDR; if this is about making the page more screen-reader friendly we may want to close this ticket and open a bigger/more general one.
@TheDJ Hello! As we have been digging into this ticket, I wanted to inquire about the original intent. Initially we thought this was related to accessibility, but as we researched it, it doesn't appear to be so. Would you be willing to share your original goal in logging this ticket? Thanks!
I've opened a related task about doing an accessibility audit for MediaSearch here: https://phabricator.wikimedia.org/T286937.
Change 703703 abandoned by Simone Cuomo:
[mediawiki/extensions/MediaSearch@master] MediaSearch results are not a list
Reason:
Further research and decision need to be considered before addressing this issue.
@SimoneThisDot: Per emails from Sep18 and Oct20 and https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup , I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!). Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task. Please claim this task again when you plan to work on it (via Add Action... → Assign / Claim in the dropdown menu) - it would be welcome. Thanks for your understanding!