Convert accessibility options unit tests to Vue Testing Library #5794

[LightCreator1007]

Summary

• Migrated to vue-testing-library.
• Adhered to VTL's query priorities whenever and wherever possible (example: using getByRole instead of getByTestId).
• Added new user-interaction test, to explicitly test the checking and uncjecing of options and verifying v-model emissions.

Screencast.From.2026-05-09.20-37-55.mp4

References

Closes #5794

Reviewer guidance

• Run

  pnpm test channelEdit/components/edit/__tests__/accessibilityOptions.spec.js

  to test whether all 10 tests are passing or not.

• Note on Tooltips: Tooltip elements currently seem to render as SVGs inside spans . So i thought of falling back to using getByTestId for the tooltip assertions.

AI usage

Code was adjusted, troubleshot and tested for bugs iteratively in collaboration with gemini and claude. Reviewed and audited to the best of my abilites to ensure integrity and correctness of code.

[learning-equality-bot]

👋 Hi @LightCreator1007, thanks for contributing!

For the review process to begin, please verify that the following is satisfied:

• Contribution is aligned with our contributing guidelines

• Pull request description has correctly filled AI usage section & follows our AI guidance:

  AI guidance

  
  

  State explicitly whether you didn't use or used AI & how.

  If you used it, ensure that the PR is aligned with Using AI as well as our DEEP framework. DEEP asks you:

  • Disclose — Be open about when you've used AI for support.
  • Engage critically — Question what is generated. Review code for correctness and unnecessary complexity.
  • Edit — Review and refine AI output. Remove unnecessary code and verify it still works after your edits.
  • Process sharing — Explain how you used the AI so others can learn.

  
  

  Examples of good disclosures:

  "I used Claude Code to implement the component, prompting it to follow the pattern in ComponentX. I reviewed the generated code, removed unnecessary error handling, and verified the tests pass."

  "I brainstormed the approach with Gemini, then had it write failing tests for the feature. After reviewing the tests, I used Claude Code to generate the implementation. I refactored the output to reduce verbosity and ran the full test suite."

Also check that issue requirements are satisfied & you ran pre-commit locally.

Pull requests that don't follow the guidelines will be closed.

Reviewer assignment can take up to 2 weeks.

[learning-equality-bot]

📢✨ Before we assign a reviewer, we'll turn on @rtibblesbot to pre-review. Its comments are generated by an LLM, and should be evaluated accordingly.

[rtibblesbot]

Clean VTL migration with real improvements over the original.

CI passing. No UI files changed — Phase 3 skipped. Screenshot and video confirm the Accessibility section in the Edit Details modal, matching what the tests cover.

• suggestion: mockConstantsMixin = {} is a no-op — see inline
• suggestion: audio test drops tooltip-absence assertion from original — see inline
• nitpick: v-model in describe block name — see inline
• praise: semantic role queries and new interaction coverage — see inline

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Reviewed the pull request diff checking for:

• Correctness: bugs, edge cases, undocumented behavior, resource leaks, hardcoded values
• Design: unnecessary complexity, naming, readability, comment accuracy, redundant state
• Architecture: duplicated concerns, minimal interfaces, composition over inheritance
• Testing: behavior-based assertions, mocks only at hard boundaries, accurate coverage
• Completeness: missing dependencies, unupdated usages, i18n, accessibility, security
• Principles: DRY (same reason to change), SRP, Rule of Three (no premature abstraction)
• Checked CI status and linked issue acceptance criteria
• For UI changes: inspected screenshots for layout, visual completeness, and consistency

[rtibblesbot]

Prior findings

Resolved:

• Empty mockConstantsMixin in mixins array (suggestion) — removed entirely
• Audio test missing queryByTestId('tooltip-captionsSubtitles') absence assertion (suggestion) — added at line 88
• 'User Interactions and v-model' describe block name (nitpick) — simplified to 'User Interactions'

3/3 prior findings resolved. 0 re-raised.

---

All three suggestions addressed cleanly. CI failures (JS Tests, Linting, Build) are a repo-wide infrastructure issue — pnpm requires Node.js ≥ 22.13 but CI runners are on v20.20.2; the Use Node.js step fails before any PR code runs. This is not caused by this PR.

• praise: interaction tests replaced within(getByTestId(...)).getByRole('checkbox') with direct getByRole — see inline

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Compared the current PR state against findings from a prior review:

• Retrieved prior bot reviews deterministically via the GitHub API
• Classified each prior finding as RESOLVED, UNADDRESSED, ACKNOWLEDGED, or CONTESTED
• Only raised NEW findings for newly introduced code
• Reviewed the pull request diff checking for correctness, design, architecture, testing, completeness, and adherence to DRY/SRP principles
• Checked CI status and linked issue acceptance criteria

[akolson]

Hi @LightCreator1007! Great work on this pr, its looking good! I've left a few comments for your action. Thanks you!

[akolson]

Hi @LightCreator1007! Just checking in to see if you're able to follow up on the review feedback. Please note that if we don't hear back from you, we'll assume you're unable to continue with the follow-up. Thank you!

[LightCreator1007]

Hi @LightCreator1007! Just checking in to see if you're able to follow up on the review feedback. Please note that if we don't hear back from you, we'll assume you're unable to continue with the follow-up. Thank you!

Hello @akolson!
I am really sorry to have been out of touch this whole time. I had a few personal affairs to attend to alongside various other things, and I regret the delay this preoccupation caused. :(
I have now addressed the suggestions you made earlier. Kindly let me know if further changes or improvements are to be made!

[akolson]

Hi @LightCreator1007! Thank you for getting back so quickly, much appreciated. I’ve left a few more comments, after which we should be ready to merge. Thanks!

[akolson]

Hi @LightCreator1007! Just checking in to see if you're able to follow up on the review feedback. Please note that if we don't hear back from you, we'll assume you're unable to continue with the follow-up. Thank you!

Hello @akolson! I am really sorry to have been out of touch this whole time. I had a few personal affairs to attend to alongside various other things, and I regret the delay this preoccupation caused. :( I have now addressed the suggestions you made earlier. Kindly let me know if further changes or improvements are to be made!

No worries at all, @LightCreator1007! We’re glad you’re able to continue supporting your PR, so thank you!

Also noting that the tests are failing not sure, but work having a look. You might also need to rebase your branch on top of upstream/unstable as the failures could be related to that (not sure).

[LightCreator1007]

Hi again, I think the reasons the tests are failing based on my experiments locally are these:

1. The KDS componets internally seem to expect a router to exist, the old version used a different testing tool so it did not require this, since VTL is rendering the entire thing the tests immediately fail with -- Cannot read properties of null (reading 'init').
2. The checkboxes have a label and a tooltip, the tooltip lies in the ceckbox's area of html so the name it has accrd to the browser is the label+tootip. So we were looking for the exact match but now I have modified it for looking only for the label prefix.

All these changes exist locally rn and pnpm run tests passes.

[akolson]

For (1), initializing the component with an instance of VueRouter should resolve the issue (const router = new VueRouter()).

For (2), I think creatively using getByTestId should address this concern without needing to test against label prefixes, which is something we should avoid as it is also a form of hardcoding.

[LightCreator1007]

For (2), I think creatively using getByTestId should address this concern without needing to test against label prefixes, which is something we should avoid as it is also a form of hardcoding.

I see what you mean about relying on the label prefix being a form of hardcoding. My main hesitation with switching to getByTestId is that the VTL guidelines explicitly recommend it as a last resort, whereas the regex helper (my current implementation locally) still lets us test the actual accessible roles using the dynamic translation strings.

I am perfectly happy to go with getByTestId if you feel it keeps the tests cleaner here, I just wanted to share my reasoning and make sure we were on the same page. Let me know what you think!

[akolson]

@LightCreator1007 That's a valid concern, getByTestId as a blanket replacement for getByRole would not be acceptable. But the approach I had in mind is more nuanced than that, and I think it actually addresses your concern about losing dynamicity in translation strings.

The idea is to split the two concerns as we can't treat all tests the same way:

• For presence checks: use getByText(metadataStrings.$tr(...)) instead of either the regex or getByTestId. This tests what the user actually reads, and uses the dynamic translation strings correctly.
• For interaction tests (clicking, checking state): we can use getByTestId. The problem is that with multiple checkboxes in the tree, getByRole('checkbox') alone is ambiguous (and obviously this problem spills into their respective tooltips). The pattern within(screen.getByTestId(...)).getByRole('checkbox') uses getByTestId only to scope the query — getByRole still does the actual selection. This in my opinion is an acceptable use case of the getByTestId.

[akolson]

Great work on this PR, @LightCreator1007! Your persistence is greatly appreciated, so thank you. This is looking really good, and migration is understand.