Accessibility#

Automexia is designed to remain usable with a keyboard, at high zoom, and on small or large displays. Accessibility claims stay limited to behavior the project can test and verify.

Try the essential path#

In a development build, test the controls that matter to your own setup:

Open the command palette and find an action by name rather than memorizing a key. Check its displayed binding.
Create a second pane, move focus between the panes, and identify which one will receive typing or paste.
Search retained output, move between results, then press Esc to return to the terminal. Search should not submit text to the shell.
Increase the terminal font size and resize the window. Check that essential input remains visible even if secondary chrome folds away.
If you use a screen reader, check the controls and terminal text with your actual operating system, desktop environment, and assistive technology.

See Shortcuts and input for the Linux development bindings and Workspaces, tabs, and panes for the focus hierarchy. Report an observed barrier rather than assuming one tested environment proves every combination works.

Keyboard access#

Core workspace actions have keyboard paths:

create and close tabs or panes;
move focus between visible panes;
open and dismiss search;
select and copy terminal text;
open the command palette;
leave dialogs without using a pointer.

Visible focus identifies the active pane and the control that will receive input.

Clear state#

Important states use text, shape, or position as well as color. Errors, selected items, active panes, and command results do not rely on color alone.

Flexible layout#

The interface is tested at narrow widths, large desktop sizes, high pixel density, and increased text scaling. Lower-priority chrome can move or disappear before the terminal becomes unusable.

Motion and contrast#

Short transitions avoid repeated flashing and do not move terminal content. Reduced-motion preferences keep persistent state cues while removing unnecessary animation.

Text and controls are checked against the project contrast rules in both light and dark surfaces.

Screen readers#

Standard text remains available through the terminal and operating-system text paths. Custom application surfaces use clear names and logical focus order where supported.

Native screen-reader behavior can vary by operating system, desktop environment, renderer, and assistive technology. Release notes must describe verified combinations instead of making a universal claim.

Reporting an accessibility issue#

Include the operating system, display scale, input method, assistive technology, the action you attempted, and the result. Do not include private terminal output, credentials, or personal paths.