MiddleTextTruncation: preserve original text in accessibility tree #2339
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mayank99
requested review from
r100-stack and
smmr-dn
and removed request for
a team
mayank99
force-pushed
the
mayank/middletextprops
branch
from
3b7190e to
75b8148
Compare
r100-stack
approved these changes
Nov 14, 2024
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
This PR improves the accessibility of the
MiddleTextTruncationcomponent. This component is meant for visual truncation and should not affect the accessibility tree because it would make the text confusing and nonsensical. While truncation in general should be avoided for even better accessibility, this is at least better than before.The behavior of
MiddleTextTruncationis now consistent with the browser's built-intext-overflow: ellipsismechanism, so the same set of UX guidelines could be applied in both cases to tackle the truncation problem. Right now, there is no such UX pattern documented in the design system, but it's becoming clear that there needs to be one.It might be easier to review the first three commits separately:
27d4deb: Code reorganization only; no outward behavior changes.399ed24: This is the most interesting part. Uses shadow DOM to inject the untruncated text while keeping it visually hidden. The truncated text is removed from the accessibility tree usingaria-hidden.75b8148: I needed to addpointer-events: none, because otherwise the shadow-tree was blocking clicks (problematic when<MiddleTextTruncation>is used inside an interactive element).301885b: Removestitleattribute from stories and examples.titleis not a cure for bad design and should not be shown in any code examples.Testing
Updated e2e tests and added a new one to verify the new behavior.
Manually tested that the full text is part of the accessibility tree.
Before:
After:
Note: With this change, the information in the accessibility tree can become very verbose, which could be potentially annoying for screen-reader users. But I think this is the safer default (and consistent with default overflow behavior), because otherwise there would be no way for the user to access the full text. "verbosity vs content loss" is a topic I would expect to be covered by any truncation UX pattern.
Docs
Added
patchchangeset.I also think we should mention this behavior on the documentation page (#2329).