Associate search input with visible heading label

[jacobo-dominguez-wgu]

Description

Fixes an accessibility issue in the Courseware Search modal where the search input had a visually-hidden "Search" label that duplicated the placeholder, while the visible "Search this course" heading was not programmatically associated with the input. Screen reader users heard redundant label information and missed the more descriptive visible title.

Problem

• The search field had a visually hidden label ("Search") rendered by <SearchField.Label /> that repeated the placeholder text — screen readers announced the same label twice.
• The visible <h1>Search this course</h1> above the input was not connected to it via for/id or aria-labelledby, so assistive tech users never received that context.
• The placeholder text ("Search") was also non-informative — it just repeated the hidden label instead of hinting at what could be searched.

Fix

Associate the visible heading with the input via aria-labelledby, remove the redundant hidden label, and repurpose the placeholder as a real hint describing what the search covers.

Testing

1. Open a course and launch the Courseware Search modal.
2. With a screen reader, focus the search input.
3. Expected: the input is announced once with the name "Search this course, search" (name from the visible heading, role searchbox), followed by the placeholder hint. No duplicate "Search" announcement.
4. Inspect the input in DevTools — confirm aria-labelledby="courseware-search-title" and no sibling element with an sr-only child.

Screenshots

AI usage notice

Used Claude Opus 4.7 to assist on this creation of this pr.

[openedx-webhooks]

Thanks for the pull request, @jacobo-dominguez-wgu!

This repository is currently maintained by @openedx/committers-frontend-app-learning.

Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review.

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

Details

---

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.53%. Comparing base (020a3ee) to head (07265fe).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2027   +/-   ##
=======================================
  Coverage   93.53%   93.53%           
=======================================
  Files         363      363           
  Lines        5905     5905           
  Branches     1367     1367           
=======================================
  Hits         5523     5523           
  Misses        367      367           
  Partials       15       15           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

This PR improves accessibility in the Courseware Search modal by making the visible “Search this course” heading the programmatic label for the search input, removing the prior redundant hidden label behavior, and updating the placeholder to be a more informative hint.

Changes:

• Associate the search input with the visible heading using aria-labelledby and a stable heading id.
• Remove the SearchField.Label rendering to avoid duplicate SR label output.
• Update i18n placeholder text and add/adjust tests to validate the accessible name and label association.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/course-home/courseware-search/messages.ts	Updates placeholder message to a more descriptive hint for the search input.
src/course-home/courseware-search/CoursewareSearchForm.jsx	Removes SearchField.Label and adds aria-labelledby support via a new labelledBy prop.
src/course-home/courseware-search/CoursewareSearch.jsx	Adds id to the visible heading and wires it into the form via labelledBy.
src/course-home/courseware-search/CoursewareSearchForm.test.jsx	Adds tests for aria-labelledby and guarding against reintroducing the duplicate hidden label.
src/course-home/courseware-search/CoursewareSearch.test.jsx	Adds an integration-style assertion that the input’s accessible name includes the visible heading text.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[brian-smith-tcril]

Thanks for the PR!

It does seem there are some a11y things to address here, I just don't fully agree the changes in this PR are the best way to address them.

I'd like to get @kblemel's thoughts on the screenreader label aspects of this.

[brian-smith-tcril]

Do we need to change the placeholder text here? Having "Find topics across this course" as placeholder text feels odd to me, and this would require new translations.

[jacobo-dominguez-wgu]

The suggestion from a11y internal team was: If placeholder text is used, it should provide a helpful example or hint rather than repeat the accessible label. 'Find topics across this course' was AI generated but I am open to hear options for placeholder text.