Update UI Coverage documenation #6236
Conversation
marktnoonan
commented
Jul 31, 2025
marktnoonan
commented
- Update element identification and interaction commands docs to reference addition ways of managing what is considered interactive, and what commands count towards coverage.
- Fix incorrect docs for significant attributes format.
cypress-documentation
|
||||||||||||||||||||||||||||||||||||||||
| Project |
cypress-documentation
|
| Branch Review |
marktnoonan/significant-attributes
|
| Run status |
|
| Run duration | 03m 27s |
| Commit |
|
| Committer | marktnoonan |
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
Failures
|
0
|
Flaky
|
0
|
Pending
|
0
|
Skipped
|
0
|
Passing
|
309
|
| View all changes introduced in this branch ↗︎ | |
UI Coverage
10.95%
|
|
|---|---|
|
Untested elements
|
2455
|
|
Tested elements
|
3
|
Accessibility
96.98%
|
|
|---|---|
|
Failed rules
|
1 critical
3 serious
4 moderate
0 minor
|
|
Failed elements
|
25
|
| "attributes": ["aria-*"] | ||
| } | ||
| ] | ||
| "significantAttributes": ["aria-*"] |
There was a problem hiding this comment.
IIRC this doesn't support wildcarding
There was a problem hiding this comment.
I'm not totally sure if this API exactly matches what unique-selector accepts, but if it does, it would be something like['attribute:aria-label', 'attribute:role', 'id', 'class']
There was a problem hiding this comment.
@jennifer-shehane That's abstracted away by UICov logic here https://github.com/cypress-io/cypress-services/blob/develop/discovery/packages/common/src/elementProcessingUtils.ts#L72
There was a problem hiding this comment.
yeah I didn't verify on the wildcarding, I'll remove this from the PR
| <div data-cy-ui-interactive="include">Custom interactive widget</div> | ||
| ``` | ||
|
|
||
| It most cases we recommend **not** using this override, and instead updating the HTML to be something the browser would already consider to be interactive. This will likely produce better overall behavior, including for accessibility purposes. `data-cy-ui-interactive` is a fallback for situations where that may not be possible. |
There was a problem hiding this comment.
Personally I would word this a bit more strongly - something like "use of this attribute is a strong signal there is an issue with the HTML structure of your application which likely has real-world impacts for users, particularly those using screen readers or with disabilities. If possible we recommend updating your HTML to better convey the interactive nature of this element; this would improve the functionality of your application for these users as well as automatically detect the element in the report. As a fallback for scenarios where this isn't possible......."
There was a problem hiding this comment.
I'm not so sure about this. Since we can now support requiring custom commands and the "assert" command - you might have a totally valid reason to want to change the definition of what we consider interactive without it implying the elements themselves are broken.
Still might need another pass at this though - the framing of everything in terms of "interactions" might not be the most accurate, long term. Will think on it a bit.
| "attributes": ["aria-*"] | ||
| } | ||
| ] | ||
| "significantAttributes": ["aria-*"] |
There was a problem hiding this comment.
I'm not totally sure if this API exactly matches what unique-selector accepts, but if it does, it would be something like['attribute:aria-label', 'attribute:role', 'id', 'class']
…om/cypress-io/cypress-documentation into marktnoonan/significant-attributes
