[chanellebingham]

Description

Fixes the two critical axe findings in the grade range editor on Settings → Grading (#3232):

• button-name: the handles between grade ranges are role="slider" buttons with aria-valuemin/max/now but no name, so a screen reader announced "slider, 50" without saying which cutoff it moves. Each handle is now named after the boundary it moves, using the grade names shown on the scale, e.g. "Boundary between A and B", or "Boundary between Pass and Fail" on the default range. The name follows the grade names, so renaming "B" to "Merit" makes it "Boundary between A and Merit".
• label: the grade name fields had no label, placeholder or aria-label. Each field is now labelled "Grade name".

Both strings are new messages in grading-scale/messages.ts, with descriptions for translators. The handle's name is built in GradingScale.jsx, which already holds the grade names, and passed to GradingScaleHandle as a new ariaLabel prop. GradingScaleHandle was converted from .jsx to .tsx, so the new prop is typed and its PropTypes are replaced by an interface.

User roles affected: Course Author (and staff), particularly people using a screen reader or other assistive technology. There is no visual change, so before and after screenshots would look the same.

Supporting information

• Fixes a11y (critical) - grading grade-range editor is unlabelled #3232
• The finding came from Open edX's end-to-end axe suite: Upstream: a11y(critical) Authoring grading grade-range editor is unlabeled end-to-end-tests#52

Testing instructions

Manual check (needs a running Open edX backend, e.g. Tutor):

1. Open a course's Settings → Grading page.
2. Inspect the handle between two grade ranges. It should have aria-label="Boundary between <higher grade> and <lower grade>", e.g. "Boundary between Pass and Fail" on a new course.
3. Rename a grade in its text box. The names of the handles on either side of it should change to match.
4. Inspect a grade name text box. It should have aria-label="Grade name".
5. Run an axe scan of the page. The button-name and label violations from a11y (critical) - grading grade-range editor is unlabelled #3232 should be gone.

These manual steps have not been run in a browser or with a screen reader for this PR. The checks below are automated only.

Automated checks run on this branch:

• TZ=UTC npx fedx-scripts jest --coverage=false src/grading-settings/grading-scale/GradingScale.test.jsx: 14 passed. The 5 new tests fail without the fix (5 failed, 9 passed).
• TZ=UTC npx fedx-scripts jest --coverage=false src/grading-settings: 8 suites, 58 tests passed. Without the fix: 5 failed, 53 passed.
• Each half was also broken on purpose and the tests caught it: removing the handle's aria-label fails the 3 handle tests; removing either field's aria-label fails its field test; shifting the handle-to-grade mapping by one fails the handle-name tests.
• axe-core 4.12.1 (button-name and label rules only), run against the rendered component in jsdom: both rules reported critical violations before the change and none after, on a Pass/Fail scale and on an A/B/C scale.
• npm run types (tsc --noEmit): no errors.
• dprint check and oxlint --type-aware --deny-warnings on the changed files: clean.
• npm run i18n_extract: both new messages are extracted with their descriptions.

Not run: the full make validate (whole test suite and production build), and stylelint (no style changes).

Other information

• No dependencies on other changes, no migrations, no visual change.
• The topmost handle, which sits at 100, is always hidden (display: none) and disabled, because that boundary can't move. It also gets a name now, built the same way, which doesn't describe a real boundary (e.g. "Boundary between A and A"). Because it's display: none, it isn't exposed to assistive technology. Happy to leave it unnamed instead if you prefer.
• The jsdom axe run above counts that hidden handle too, because src/setupTest.js replaces window.getComputedStyle for the whole test suite, so nothing counts as display: none in tests. In a browser it is hidden, which matches the issue's count of one button-name node per draggable boundary.
• AI disclosure: this change was made with Claude Code. It investigated the issue, wrote the code and tests, ran the checks above, and drafted this description. I reviewed it before opening. The commit carries Co-authored-by: Claude <claude@anthropic.com>.

Best Practices Checklist

• Any new files are using TypeScript (.ts, .tsx). (No new files. GradingScaleHandle was converted from .jsx to .tsx.)
• Avoid propTypes and defaultProps in any new or modified code. (None added. GradingScaleHandle's PropTypes were replaced by a TypeScript interface. GradingScale.jsx keeps the PropTypes and defaultProps it already had.)
• Tests should use the helpers in src/testUtils.tsx (specifically initializeMocks). (Not ticked: the new tests are in the existing GradingScale.test.jsx and reuse its existing setup, initializeMockApp plus an IntlProvider wrapper, rather than initializeMocks.)
• Do not add new fields to the Redux state/store. Use React Context to share state among multiple components. (No state changes.)
• Use React Query to load data from REST APIs. See any apiHooks.ts in this repo for examples. (No data loading changes.)
• All new i18n messages in messages.ts files have a description for translators to use.
• Avoid using ../ in import paths. To import from parent folders, use @src, e.g. import { initializeMocks } from '@src/testUtils'; instead of from '../../../../testUtils'. (No ../ imports added. GradingScaleHandle.tsx and GradingScaleSegment.tsx keep their existing ../utils and ../messages imports.)

[openedx-webhooks]

Thanks for the pull request, @chanellebingham!

This repository is currently maintained by @bradenmacdonald.

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

🔘 Submit a signed contributor agreement (CLA)

⚠️ We ask all contributors to the Open edX project to submit a signed contributor agreement or indicate their institutional affiliation.
Please see the CONTRIBUTING file for more information.

If you've signed an agreement in the past, you may need to re-sign.
See The New Home of the Open edX Codebase for details.

Once you've signed the CLA, please allow 1 business day for it to be processed.
After this time, you can re-run the CLA check by adding a comment below that you have signed it.
If the CLA check continues to fail, you can tag the @openedx/cla-problems team in a comment for further assistance.

🔘 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.

[bradenmacdonald]

Hi @chanellebingham, thanks for the fixes! Could you please sign the CLA?

[chanellebingham]

Hi @bradenmacdonald, I've signed the CLA! :)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.30%. Comparing base (93207d2) to head (99a4482).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3323   +/-   ##
=======================================
  Coverage   96.30%   96.30%           
=======================================
  Files        1450     1450           
  Lines       35523    35530    +7     
  Branches     8510     8512    +2     
=======================================
+ Hits        34209    34216    +7     
  Misses       1272     1272           
  Partials       42       42           

☔ 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.

[chanellebingham]

Hi @bradenmacdonald, quick one about the CLA: on the form I only put my first name, "Chanelle", instead of my full name, Chanelle Bingham, and I couldn't change it after submitting. The openedx/cla check is still red. Could you send me a fresh agreement so I can sign it with my full name, or let me know who I should contact to fix it? Thanks!

[bradenmacdonald]

@mphilbrick211 could you please help @chanellebingham out ^ ? :)

[chanellebingham]

Thanks @bradenmacdonald! I'll get this CLA done PROPERLY this time 💀

[mphilbrick211]

Thanks @bradenmacdonald! I'll get this CLA done PROPERLY this time 💀

Hi @chanellebingham! You can submit a new form here. Please make sure to include your full name, github username, and full address. Thanks!

[chanellebingham]

Thank you soooooooo much @bradenmacdonald & @mphilbrick211 !! CLA is signed. Again, thanks for that. :) Warm regards!

[mphilbrick211]

Hi @chanellebingham! Your CLA should be all set. Sometimes it can take up to 24 hours to reflect in Github, but the check should turn green soon.

[mphilbrick211]

@chanellebingham @bradenmacdonald re-running the checks might also help prompt the CLA check to go through.

[bradenmacdonald]

The fix looks good! Thanks :)

[bradenmacdonald]

@mphilbrick211 I rebased the PR which triggered all the checks again, but the CLA check is still not passing, so I can't merge it. I also tried closing and re-opening the PR but that didn't work either.

[chanellebingham]

@bradenmacdonald & @mphilbrick211

Sorry, must have fat fingered that close button. So sorry! But I definitely have signed it. I am not sure if I have done something wrong on my end, but I made sure to fill everything out correctly, signed and dated the CLA.

(sorry again about the muck around)

[bradenmacdonald]

It might just be delayed; we can check again on Monday.

[chanellebingham]

Thanks mate! Fingers crossed.