Can you add aria-label to a <h1> heading? Or should we rather add a span with a sr-only class that hides it from anyone not using the screenreader?

Adding the comment from the original meta issue about the search headings here:

After submitting a search, I would expect to have a heading 1 with wording such as "Search results for: XXX, 10 results returned". This should be the first item in the main content, above the search form.

If we need to make heading 1 the first item on the page, above the search form, this will require changes in designs. We've discussed this with @fcoveram.

Is there a way to not change the designs so drastically, but still make the heading with additional information appropriately placed for the screenreaders?

I am going to raise the priority for this issue to high as it is important for a11y, especially now that we are planning to add more search views.

Also, I think these 2 points are related:

1. Heading 1 after submitting a search:

After submitting a search, I would expect to have a heading 1 with wording such as "Search results for: XXX, 10 results returned". This should be the first item in the main content, above the search form.

2. Number of results

The text in quote 2 is not placed in a very discoverable area for users. I would delete it and rely on the heading 1 proposed above.

Quote 2

Over 10,000 results

Not sure if I'm following the design request correctly. It seems that we can add a hidden element within h1 telling the number of results. Something like Showing {count} results for "{search term}", as @zackkrida said. Am I correct?

If we need to make heading 1 the first item on the page, above the search form, this will require changes in designs.

If "search form" refers to the search bar and the whole header, that is a huge change impacting the navigation's core.

The problem with this current layout is the change of context. I didn't realize it until it was called out in designs. On the home page, the search form is part of the page content but on a search results page, the search form moves into the header. In this case, what we can do is make the heading 1 the first HTML element in the page main content. The other issue is, there are sorting filters in an <aside> but no <main> on these pages.

1. Search form stays in header.
2. Add a <main> tag or role="main" to indicate main content.
3. Update the existing heading 1 on the page to report the number of search results. It looks to be already hidden to screen readers only, not shown visually. Code sample.

<h1 data-v-04fb7dee="" class="sr-only break-words md:not-sr-only heading-2 lg:heading-1 !leading-none lg:!leading-none">Showing {count} results for "{search term}".</h1>

Thanks.

Search form stays in header.

@alexstine Can you clarify how this is understood to work for common search engines like Google or DuckDuckGo? The visual layout and presentation of those sites more or less match Openverse. However, neither wrap the search form in <header>, despite the search form appearing in the "header" area of the page. Is that the key difference, that both of those never put the form inside <header>?

If we changed the search results page to have no <header> element, would the form then be more accessible, without needing to change the layout/order of the elements on the page? Would that effectively fix the change of context you mentioned?

I never really paid attention for Google and I would not consider Duck Duck Go an accessible search engine. One thing that might help us is if we added a new landmark. You can add role="search" to the form tag to expose this in the accessibility tree.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/search_role

Is there any reason that navigation is not global? For example, there are navigation links on the home page but not search results pages. These types of UI choices makes things so much harder for users despite what big tech is doing.

Hope this helps. Thanks.

I'm going to lower the priority on this. On further thought, for a page of search engine results using the search query as the h1 seems extremely common. Perhaps we can develop a better approach but our current implementation isn't broken.

@zackkrida I don't really appreciate the sense that this issue is getting ignored. If I thought it was a waste of time, I wouldn't have reported it.

Google certainly doesn't use the search term as a heading 1 so not sure where your information comes from on that.

https://openverse.org/search/?q=olympic

Olympic is the heading 1 here but does not communicate that this is a search results page.

https://www.google.com/search?q=Olympic&sca_esv=673643cfd9d73a9d&sxsrf=ACQVn0-3YzXIE7sNjPbNmv7USSD7S0yo5Q%3A1710171108476&source=hp&ei=5CPvZdfSGv3IkPIP1Pm52AI&iflsig=ANes7DEAAAAAZe8x9M5Ixc-WRQz_PJdpvPf4cSoYrUJE&ved=0ahUKEwjX1LHrw-yEAxV9JEQIHdR8DisQ4dUDCBg&uact=5&oq=Olympic&gs_lp=Egdnd3Mtd2l6IgdPbHltcGljMggQABiABBixAzIIEAAYgAQYsQMyERAuGIAEGLEDGIMBGMcBGK8BMgsQABiABBixAxiDATIFEAAYgAQyCxAAGIAEGLEDGIMBMggQABiABBixAzIEEAAYAzIIEAAYgAQYsQMyCBAAGIAEGLEDSNoMUABYxQtwAHgAkAEAmAFSoAHpA6oBATe4AQPIAQD4AQGYAgegAo8EwgIKECMYgAQYigUYJ8ICBBAjGCfCAg4QABiABBiKBRixAxiDAcICDhAuGIAEGLEDGIMBGNQCwgIREC4YgAQYsQMYgwEYxwEY0QPCAgsQLhiABBixAxiDAcICDhAuGIAEGIoFGLEDGIMBwgIIEC4YgAQYsQPCAg4QLhiABBjHARivARiOBcICCxAuGIAEGLEDGNQCwgILEC4YgAQYxwEYrwHCAggQLhixAxiABMICDhAuGIAEGLEDGMcBGNEDmAMAkgcBN6AHnHE&sclient=gws-wiz

On Google, there are 4 total heading 1s.

1. Filters and Topics
2. Search Results
3. Page Navigation
4. Footer Links

While this does not include the search term or number of results, because Google is not as accessible as people think it is, it does at the very least tell you it's a search results page.

Apologies @alexstine I didn't recall that you originally reported this issue. To clarify, I think that the changes necessary to fix this will involve design work and changing the text for sighted users.

Concerning the prior are from other search engines, I was referring to examples like:

• https://unsplash.com/de/s/fotos/dog

(Not to say they are accessible).

I will update this issue back to high priority but also to clarify that problem goes beyond the text of the h1 to capture the layout issues you elaborate on in the comments.

@zackkrida No visual change required.

<h1 aria-hidden="true" class="visual-search-results">Search Term</h1>
<h1 class="screen-reader-text">Search results for: %s, Number of results: %d.</h1>

Since headings are not holding focusable content, you can create 2 different versions.

The more favorable approach would be to give all users the same experience but people often times don't like to do that in this project due to a set in stone visual design that apparently can never change. 😞

Thanks.

The more favorable approach would be to give all users the same experience but people often times don't like to do that in this project due to a set in stone visual design that apparently can never change. 😞

I agree this is the preferred approach, to unify the experience for all users. However, I'm not sure if this is a correct assessment of the situation for the Openverse project, that its maintainers are unwilling to make visual and/or non-visual changes that will unify the experience for as many users as possible (regardless of the tools they use to interact with the site). Please bear with us as we continue to learn about what kinds of changes fulfil requirements, we are pulled in many directions by many different forces, and sometimes get prioritisation wrong (not just on accessibility issues, even though for access issues it is much more important that we do get it right). I'm very grateful for your clarification about this particular issue and will open a PR today to get that change in.

If there are other specific instances where you noticed a lack of movement on an accessibility issue that appeared to be caused by maintainers avoiding making visual changes, please let me know. If more comfortable, you can ping me in WordPress Make Slack in DMs, whatever you prefer. I am eager to understand whatever issues Openverse has, whether the application services or the project management, and if there are problems with the way Openverse specifically makes decisions that prevent it from being able to quickly address accessibility problems, then I am happy to be the person to push the team towards a better approach and address immediately pressing issues. Your contributions and issue reports are invaluable. I can't speak 100% for Zack, but as the lead for the project, I would be surprised if they do not have the same feeling.

Heads up, @obulat I am going to work on this issue and implement the change Alex has suggested. I've reassigned the issue to myself to reflect that.

@sarayourfriend The comment I made was not Openverse specific, it was project-wide WordPress. If the change impacts visuals for accessibility, it's always a long back and forth when really, let's just come to a solution. :) Nothing I said in my previous comment was directed at Openverse contributors specifically, I still forget how some of this Openverse project isn't fully connected to the rest of WordPress so sorry for overlooking.

At the end of the day, I just want users to have the best experience possible.

Thanks.

As the most active designer contributor in this project, I would like to reiterate my openness to revisiting any decisions made if they did and/or do not address accessibility with the expectations we aim for.

I've been polishing my personal workflow to invite the accessibility team more proactively from the beginning. Yet, I need to do better, learn, and ask more.

Your feedback @alexstine is essential to make Openverse better.