testing-library / testing-library/dom-testing-library

Re-export computeAccessibleName and computeAccessibleDescription for UMD uses

Open
#1,142 2 comments 7 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
JavaScript
Stars
3.3k
Forks
474
PR merge metrics
No merged PRs in 30d

Description

Describe the feature you'd like:

I would like it if @testing-library/dom would re-export the computeAccessibleName and computeAccessibleDescription functions from dom-accessibility-api. At least as part of the dist/dom.umd.js bundle.

computeAccessibleName is what findByRole uses for the name option. In the UMD bundle dom-accessibility-api is bundled together with @testing-library/dom's code, but in a way it cannot be used outside the library.

I was using @testing-library/testcafe and had a use case where instead of finding an element by it's accessible name I wanted to assert the accessible text of an element.

Unfortunately while investigating I found that:

  • computeAccessibleName from dom-accessibility-api is the function that would match findByRole's behaviour
  • @testing-library/testcafe injects the @testing-library/dom/dist/dom.umd.js bundle into the client
  • The computeAccessibleName defined in dist/dom.umd.js is not accessible outside of the bundle
  • dom-accessibility-api itself does not export a UMD or any other format that
Suggested implementation:

computeAccessibleName and computeAccessibleDescription could be included as part of the dom-testing-library API, perhaps under names like getAccessibleName and getAccessibleDescription to match getNodeText.

Not part of this issue, but perhaps @testing-library/testcafe could also include a custom selector property for these.

Describe alternatives you've considered:

I considered using dom-accessibility-api directly. However dom-accessibility-api does not include a UMD build and TestCafe will not accept any of the formats that dom-accessibility-api does include in its dist folder.

The only option I seem to have right now would be to build my own UMD bundle of dom-accessibility-api just to inject a duplicate definition of code that @testing-library/dom's bundle has already included in the page, but kept hidden.

Teachability, Documentation, Adoption, Migration Strategy:

The functions should be documented on https://testing-library.com/docs/dom-testing-library/api-custom-queries/ along with getNodeText.

getAccessibilityName should be documented as returning the same accessibility name that getByRole's name option matches, documented on https://testing-library.com/docs/queries/about.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting the dist/dom.umd.js bundle and the public @testing-library/dom API exports to determine how the bundled accessibility functions could be exposed. Review the custom queries and query guidance documentation URLs named in the issue. Done means both functions are available to UMD consumers and documented with their relationship to getByRole's name option.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
api, documentation, testing
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.