Clinisys-Wide · Case study

Keyboard Accessibility & Interaction Strategy

CLS was built on a dense, spreadsheet-style Data Grid, while the rest of Clinisys's application suite used a simpler Table pattern. I found the keyboard inconsistency while documenting shortcuts, then built the audit and strategy to determine where each pattern belonged.

01 · Executive summary

Two patterns that looked alike side by side were, underneath, entirely different keyboard experiences.

Clinisys began migrating its design system from Kendo UI to Google Material while CLS was simultaneously expanding beyond scientific testing into healthcare laboratories. Together, those initiatives turned what had been an implementation detail, Data Grid versus Table, into a real UX decision: should CLS standardize on one pattern, or genuinely support both?

While documenting keyboard shortcuts, I found that Data Grid already behaved like a spreadsheet in production, but Table's accessibility spec had never defined equivalent behavior at all. I audited CLS's full keyboard behavior, built the evidence base, and proposed supporting both patterns as first-class citizens, with clear guidance for when each applies.

The diagnosis was reinforced twice, by an internal escalation and a client accessibility report, but the full system-wide fix hadn't shipped when I left Clinisys.

02 · Context

A distinction that had gone unquestioned for years, until two initiatives converged.

CLS had always relied on a Data Grid: dense, spreadsheet-like, built for scientific batch-oriented laboratory workflows. Other Clinisys applications had simpler list needs and used a standard Table instead. For years there was little reason to question that distinction, since the two rarely coexisted in the same application.

That changed when Clinisys began migrating to Google Material while CLS was expanding to serve healthcare laboratories. The broader differences between scientific and healthcare laboratory workflows are documented in Designing a Shared Laboratory Experience.

What was already known

Scientific's batch data-entry workflows depend on Data Grid's spreadsheet-style interaction, not Table's simpler list behavior.
Healthcare's needs looked simple by comparison: a table with a small number of cells supporting inline edits.

03 · The discovery

Data Grid already behaved like a spreadsheet in production. Table's accessibility spec never defined an equivalent.

While writing keyboard-interaction documentation for CLS's components, I found that Data Grid already behaved like a spreadsheet in production: arrow keys moved cell to cell, Ctrl+Space selected a row, Enter moved focus downward. When I went to document the equivalent behavior for Table, there wasn't one. The existing spec's accessibility section for Table said only "keyboard navigation considerations," a placeholder standing in for a real answer.

ShortcutData Grid (in production)Table (undocumented)

Arrow keysArrow keys move one cell at a time

Up/Down move focus to the previous/next row, standard baseline behavior, but never formally specified in Table's own spec

Row selectionCtrl+Space toggles selection of the focused row (CLS's own remap; spreadsheet convention is Shift+Space)

Undefined

Grid edgesCtrl+Home / Ctrl+End jump to first/last cell

Undefined

Header controlsAlt+B moves to grid header buttons, preserving row selection

Undefined

Basic focusTab / Shift+Tab move cell to cell

Presumed to move control to control, never specified

Edit modeF2 triggers edit mode on the focused cell

No equivalent state to define

Why it mattered

Migrating to Material without resolving this meant either carrying the inconsistency forward or rebuilding it by accident in a new framework. Documenting the keyboard behavior exposed a decision the existing specification had never actually resolved.

04 · Building the case

A complete keyboard inventory, cross-referenced against platform convention.

A gap like this is easy to wave off if it's argued abstractly. Before proposing anything, I audited CLS's actual keyboard behavior end to end, every shortcut across the grid, the actions menu, the mega menu, and date filters, and cross-referenced it against standard OS and browser keyboard conventions (Windows, macOS, Safari, Chrome, and common productivity tools). That gave me a complete inventory of what CLS actually did and a baseline for what users would already expect.

68CLS shortcuts audited

21Grid shortcuts

17Actions menu shortcuts

13Date filter shortcuts

CLS keyboard shortcuts from the audit, grouped by component: Grid, Actions Menu, Date Filter, Mega Menu, and General — CLS keyboard shortcuts from the audit, grouped by component

OS, browser, and productivity-app keyboard shortcuts used as the audit baseline: Browser, Safari, macOS, Firefox, Chrome, Windows and Linux, Word, Table, Excel and Sheets, Word and Docs, Docs, and Edge — The OS, browser, and app conventions CLS was benchmarked against

05 · The organizational decision

A concern raised early didn't make it into the direction that shipped.

Around the same time, Clinisys began scoping CLS's expansion into healthcare laboratories. I raised the concern that standardizing on a simplified table wouldn't hold up once Scientific's batch, spreadsheet-style workflows moved onto the same design system. That concern didn't make it into the final direction at the time: design leadership aligned around the simpler approach because it was easier to develop, and engineering built primarily toward Table.

What I'd already flagged

A table built for healthcare's limited data wouldn't scale to Scientific's dense, editable datasets.
The keyboard audit already showed the two patterns diverging in ways users would notice immediately.

Where the gap showed up

Development began migrating CLS Scientific onto the new design system using the table-first direction.
Table alone couldn't support Scientific's batch, spreadsheet-style data entry.

06 · Two independent signals

The same root cause surfaced from two directions that had no reason to coordinate.

Two independent events arrived close together. Internally, the Scientific business group escalated once the migration made the table-only approach's limits concrete. Separately, a client reported a keyboard accessibility issue tied to exactly the Grid-versus-Table inconsistency documented months earlier. Neither escalation referenced the other, which is what made them convincing together.

07 · The strategy

The Grid-versus-Table problem was the most visible symptom; the design system had no shared point of view on keyboard interaction at all.

I wrote a Keyboard Accessibility Strategy defining principles meant to guide every component going forward, not just patch the one gap I'd found. View the full strategy plan ↗

Focus management

Visible focus indicators, logical order, predictable focus return after actions like closing a modal.

Navigation patterns

Skip links, consistent layouts, global shortcuts for common actions like search or menus.

Keyboard shortcuts

Context-sensitive, discoverable shortcuts with on-screen hints and room for customization.

Complex interactions

Full keyboard operability for grids, sliders, carousels, multi-select, and context menus.

User education

A discoverable shortcut guide, onboarding, and contextual help.

Dictation compatibility

Shortcuts that coexist with dictation software rather than conflicting with it.

08 · The proposal

Support both patterns as first-class citizens, because the keyboard audit proved their interaction is fundamentally different underneath.

The two patterns already have a lot in common: both can sort, filter, select, act on records, edit, configure columns, and paginate. The real difference is how a user works with the data. Table fits workflows built around records: reviewing information, searching or filtering a list, selecting a record, taking an action on it, the shape of most healthcare workflows. Data Grid fits workflows built around values: moving between cells, entering or editing a series of numbers, selecting cells or ranges, copying and pasting, the shape of Scientific's batch data-entry workflows. Editing alone doesn't require a Data Grid; Table supports editable content too. Data Grid earns its extra complexity only when cell-level interaction is actually part of the job.

Real CLS Data Grid cell states: Normal, Required, Link, Input field, Above Max, and Hover, shown in Normal, Selected-row, and Focus contexts — A real component state sheet pulled from CLS's Data Grid, not recreated for this write-up

Proposed pattern: Table for record-oriented review versus Data Grid for cell-level values, sharing the same Density, Filter, Default view, and Saved view controls — The proposed Table vs. Data Grid pattern

View the full proposal document ↗

Use Table when

The primary task is reviewing or finding records.
Actions apply mainly to a row or record.
Users need sorting, filtering, search, or row selection.
Editing is occasional and doesn't require moving through cells.

Use Data Grid when

Users need to enter or edit multiple values.
Users need to move between cells with the keyboard.
Repeated or batch data entry is part of the workflow.
Cell or range selection, or copy and paste between cells, is needed.

Why focus vs. edit mode isn't academic

A client whose lab pushes results straight from a connected balance into CLS put the current friction plainly: "You actually have to put this box into edit mode first. You basically just have to hit zero, or F2 or whatever, and then you hit the button on the balance. Not a big deal, but it's one of those little things that just makes a huge difference in your day." Multiply that one extra keystroke by every interfaced result, every day, and it stops being a small thing.

09 · What clients kept bringing up

Real, recurring evidence that Table and Grid both had usability gaps of their own.

The same concerns came up in almost every client interaction and demo, and they showed that neither pattern was inherently better. Table and Data Grid each introduced usability problems depending on the workflow.

Table settings reset after navigation or commenting

"I always resize columns, but every time I come back, they're back to default." (Participant B)

Errors got lost in dense grids

"Failures aren't always obvious in the grid. You often have to click into each analyte to see what's wrong." (Participant D)

Wanted more keyboard, less mouse

"I dislike having to go from the mouse to the keyboard all the time. That slows everybody down." (Participant D)

10 · Outcome

Reinforced twice, but not fully shipped when I moved on.

By the time I left Clinisys, the keyboard strategy hadn't been formally adopted system-wide. Fixing the Grid/Table inconsistency properly meant reworking a meaningful amount of already-built code, and leadership was hesitant to commit to that all at once, so smaller, one-off fixes kept shipping instead of the systemic solution.

What it did accomplish

The audit and strategy created an evidence-backed reference for the Grid-versus-Table distinction grounded in actual keyboard behavior. Clinical Pathology Results Review later ran into the same gap: it was built as a Table but needed to behave like a Data Grid, because multiple cells could be edited.

Next case studyData Visualization Requirements & Design System →