Right panel table tab: make most items keyboard-usable #1777
Conversation
This file contains hidden or 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
manuhabitela
force-pushed
the
creator-panel-kb
branch
from
b06b30a to
b3e2635
Compare
|
Most stuff in the table config tab should be handled for now. I'll add some code to handle the other table subtabs. And maybe I'll end up here for this PR in order to not have too many unrelated things. I'll split everything in its own commit to better understand when I'm finished. But these are mostly straight-forward changes. |
manuhabitela
force-pushed
the
creator-panel-kb
branch
4 times, most recently
from
461be66 to
00050c0
Compare
manuhabitela
changed the title
|
So, this is close to be ready for review I think. I need to fix some remaining tests and verify a few things manually, but I shouldn't work on any more thing besides that. Every change is in a contained commit. Noticeable things:
|
manuhabitela
force-pushed
the
creator-panel-kb
branch
3 times, most recently
from
d19c139 to
56c6cb6
Compare
this helps screen reader users correctly understand what the inputs are for. Without this, they might miss the description of the inputs depending on how they navigate with their SR.
adding some 'group' roles around … groups of related inputs, help screen readers users a bit by better understanding the related and unrelated inputs following each others.
- the grid option checkbox labels were not actually tied to their inputs. Now they are so that they are correctly vocalized by screen readers - add a group role around the section to help SR users
- tie inputs and labels together in the code for better screen reader support - make sure we can focus everything with keyboard correctly (before, we could focus the "expand all rows" checkbox even while it was visually hidden, now it is disabled and those unfocusable when hidden)
- better expose semantics to screen readers (grouping inputs, labelling them correctly) - make sure to correctly explain to screen readers the meaning of the button visually labelled with the widget name, as it's not obvious what it does without visual hints - make sure everything is kb focusable
before this commit, we could not press the space key to trigger the "open configuration" button of a custom widget (which is in the right panel). this was because the viewAsCard command, mapped on the space key, was always enabled. Now the command is enabled only when we focus the widget, allowing to correctly use the space key in the right panel for that specific case.
The "mapped fields" (in a form) and the "visible columns" (in a table) sections in the right panel are can now be correctly navigated through with keyboard, and expose correct information to screen readers (ie. icon buttons have alt texts).
- put the keyboard-focus-highlight class in its own variable to prevent errors - add the class to simple list items so that more things show their focus ring when needed by default
the linkSelect menu helper is seemlingly only used by controls for the chart config in the right panel. With the tabindex removal, it prevented keyboard users to focus this select for I guess a reason we can challenge. Lets just make them kb focusable normally like other selects.
in a few cases, `<li>` tags were rendered as `<div>` children, something that doesn't make much sense. The containers were actually list containers, so we might as well use actual `<ul>` els so that screen reader users get the benefits of it correctly.
these improve screen reader users like a tiny bit when dealing with things in a draggable list. they better get the relation between elements in each draggable row, and can navigate through the items quicker if needed
lots of stuff in the sort and filter UI in the right panel was not keyboard focusable or hard to understand with a screen reader. it's still not ideal with a screen reader because there are lots of interactions, but at least now everything is focusable and correctly text-labelled.
it seems there is a bug in weasel when a menu is composed of non-selectable items. If we open a sort item dots menu and try to use the arrow down/up keys, it goes into an infinite loop. As a workaround for now, prevent keyboard selection. Not ideal but at least it doesn't crash.
manuhabitela
force-pushed
the
creator-panel-kb
branch
from
56c6cb6 to
978589c
Compare
funny bug: the 'Remove' icon codename was wrongfully passed to the translation system. When using Grist in French for example, this resulted in the system trying to find a "Retirer" icon (French translation for "Remove"). That obviously didn't work and made a gray square appear in place of a bin icon.
|
After a bit of manual testing and e2e tests, this is ready for review on my hand 👍 Stumbled upon a small, rather unrelated bug, but allowed myself to include here (see commit |
manuhabitela
moved this from In Progress
to Needs Internal Feedback
in French administration Board
|
Deployed commit |
hexaltation
approved these changes
Sep 2, 2025
hexaltation
moved this from Needs Internal Feedback
to Needs feedback
in French administration Board
georgegevoian
requested changes
Sep 8, 2025
There was a problem hiding this comment.
Thanks for these improvements @manuhabitela.
Notes so far from testing:
- Visible/hidden fields appears disabled when editing card layout, but if you change focus to creator panel and use the keyboard to navigate to it, you can still interact with it. (It's intentionally disabled because the card layout editor can't currently reconcile changes made after it was opened.)
| cssFieldLabel(dom.text(col.label)), | ||
| cssRemoveIcon( | ||
| t('Remove'), | ||
| 'Remove', |
There was a problem hiding this comment.
Thanks for fixing that!
manuhabitela
moved this from Needs feedback
to In Progress
in French administration Board
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.
Context
Some interactive elements are currently not usable with keyboard, or not correctly described for assistive technologies like screen readers. That makes the right panel sometimes impossible to use without a mouse.
Proposed solution
This PR does not fix everything as some components will require more specific work (like custom selects), but this should include all the rather quick-and-easy fixes.
Has this been tested?
I didn't add specific keyboard-nav tests, not sure it's really valuable on a case by case basis.
Screenshots / Screencasts