Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Text overflow management #75

Open
mkrause opened this issue Dec 23, 2024 · 1 comment
Open

Text overflow management #75

mkrause opened this issue Dec 23, 2024 · 1 comment
Labels

Comments

@mkrause
Copy link
Collaborator

mkrause commented Dec 23, 2024

In scenarios where text overflows, we may hide it and cut off with something like a text-overflow: ellipsis. This may be fine, for example if the user has alternative ways of viewing that content (e.g. navigating to a detail page). But in other cases we should consider adding a mechanism that allows users to view the full text content. For example, showing a tooltip if the text has overflow.

As an example, we might want to fix this for accordion titles:

image

To determine whether there is overflow we would need to use some JS. This could be done lazily on hover of the text.

@mkrause
Copy link
Collaborator Author

mkrause commented Dec 29, 2024

Interesting accessibility question: for non-interactive elements (like <div>) with overflow: auto, axe will complain because we should make the element focusable (with tabindex="0") for keyboard accessibility, see explanation here.

However, Biome's a11y rules will complain if we use <div tabIndex={0}> because non-interactive elements shouldn't be focusable. And if we consider that with overflow: auto, the content may not even be scrolling (it's conditional), it may not be the best idea to make everything with overflow: auto focusable by keyboard.

Discussion:
https://stackoverflow.com/questions/53597209/tabindex-on-elements-that-are-interactive-only-under-certain-conditions

Also note that Chrome will automatically make all scrolling content focusable by default. Firefox already does this as well, but Safari does not.

UPDATE: Important to note is that for accessibility it is only required to make the scroll container focusable if there are no focusable elements (shallowly) inside the scroller. This is because a focusable element (e.g. button) inside a scroller can be used to scroll the parent scroller through the arrow keys. So we could consider allowing the tabindex="0" to removed if we know that there is a suitable focusable element inside it.

UPDATE 2: As of Chrome v132, both Chrome and Firefox support keyboard-focusable scroll containers. I did some testing, and both browsers automatically make elements focusable only if the elements are actually scrollable (so not just not if overflow: auto was applied). It would be great if we can just rely on this, because dynamically checking this in JS is essentially impossible. Perhaps we should do a user agent check and only enable the tabindex="0" for Safari?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant