Skip to main content
Railyard
DocsAPI reference

Accessibility

How accessible Railyard is today, where it falls short, and how to tell us.

Our commitment

We want Railyard to be usable by as many people as possible, including people who use a screen reader, navigate by keyboard, need larger text or more contrast, or cannot use a mouse comfortably.

Our target is WCAG 2.2 Level AA. We are partially conformant with it: most of the product meets the standard, and the parts that do not are listed below. We have not commissioned an independent audit, so this statement reflects our own testing.

This statement was prepared on 8 September 2026 and applies to the Railyard web application and public website at railyard.sh. We review it when we make a significant change to the interface.

What works today

  • Keyboard navigation. The public pages, docs, sign-in, settings, the estate tree, the inspector panels, dialogs and menus are all reachable and operable by keyboard. Every page has a "Skip to main content" link as its first stop. Context menus and their submenus open and move with the arrow keys, Enter and Escape as well as with a pointer. Dialogs trap focus while open and return it when closed.
  • A command palette. ⌘K (Ctrl-K on Windows and Linux) opens a searchable list of actions, so most commands can be run by typing a name instead of finding a target on screen. Press ? for the keyboard shortcut reference.
  • Two themes, both contrast-checked. A dark default and an opt-in light theme, switched from the header and remembered between visits. Both are built from the same design tokens, so text contrast holds in either.
  • Reduced motion. We honour the operating system's "reduce motion" setting and turn off non-essential animation and transitions when it is on.
  • Text scaling and zoom. The interface uses relative units and reflows, so browser zoom and larger default text sizes work without content being cut off.
  • Semantic structure. Pages use real headings, lists, tables and landmarks, with labelled regions and form fields, so a screen reader can navigate by structure. Wide tables scroll within their own focusable region rather than forcing the page sideways.
  • A text route to the design. The estate tree, the cable table, the power and review panels and the export files all present the design as structured text and numbers, not only as a diagram.
  • No motion or flashing hazards, no audio, and no time limits on any task.

Where we fall short

These are the accessibility problems we currently know about. We are working on them, and we would rather tell you than let you discover them.

The rack and topology canvases are visual and pointer-first

Placing a device by dragging it into a rack slot, dragging a cable between ports, and dragging a cable's bend points are pointer interactions. A screen reader can read the resulting design, but it cannot usefully convey a free-form diagram, and the drag gestures themselves have no keyboard equivalent.

In the meantime: Every structural edit has a non-drag route: the inspector panel's "+ Add device" button places into a chosen rack unit, the cabling and power workspaces connect ports from lists and dropdowns, and the context menu (reachable from the keyboard) and the command palette (⌘K / Ctrl-K) cover the rest. The cable table lists every connection as text.

Cable bend handles are small, and get smaller as you zoom out

The handles used to reshape a cable route are sized in screen pixels rather than scaled for touch, so they fall below the 24×24 CSS pixel target size WCAG 2.2 asks for, particularly on a touch screen or when zoomed out.

In the meantime: Zoom in before adjusting a route. Bend points are cosmetic — a cable is complete and correct without them.

Fitting a wide estate to the window can make labels illegible

"Fit" on a data-centre or row board with many racks scales the board down until rack and device labels are too small to read, and on grouped boards it can collapse to a single narrow column.

In the meantime: Zoom in rather than fitting, use the estate tree in the navigator to jump straight to a rack, or open a rack directly — the rack view is laid out at a readable size whatever the board is doing.

Small phone screens have a reduced layout

Below about 900 pixels wide the inspector becomes a bottom sheet and the tree and tools move into a drawer. The editor is usable but cramped, and some container-level settings are reachable only through the floating edit button.

In the meantime: Use a tablet, laptop or desktop for substantial design work. Reading, reviewing and exporting work well on a phone.

We have not had an independent audit

Our conformance claims come from our own testing, not from a third-party assessment. We have not tested with every assistive technology, and there will be problems we have not found.

In the meantime: Tell us what you hit and we will fix it — see "If something blocks you" below.

A diagram-based design tool will always have a visual core. Our commitment is that no task should be possible only by dragging: if you find one that is, that is a bug and we will fix it.

If something blocks you

Email [email protected] and tell us what you were trying to do, what got in the way, and what you use — browser, operating system, and any assistive technology. You do not need to know why it failed.

We will acknowledge within 5 working days, tell you whether we can offer a workaround straight away, and give you a view on a fix. If you need information from the Service in a different format in the meantime — an export produced for you, or a design described in writing — ask and we will provide it at no charge.

You can also report accessibility problems through our public feedback channel, or in the app's feedback form, if you would rather do it in the open.

Enforcement

We have a duty under the Equality Act 2010 to make reasonable adjustments for disabled users, and we take it seriously. If you are not satisfied with how we respond, you can contact the Equality Advisory and Support Service, which advises on Equality Act matters in England, Scotland and Wales.

Customers in the European Union: the European Accessibility Act applies to services supplied to consumers in the EU. If you believe we are not meeting it, raise it with us first at [email protected], and you may also contact the market surveillance or enforcement authority in your member state.

Accessibility sits alongside our Terms, Privacy Policy and Security page.

RailyardRack layouts, topologies, cabling and capacity — in one place.
DocsAPI referenceFeedbackRoadmapTermsPrivacyDPASecurityAccessibilityContact
© 2026 Railyard · Operated from England and Wales; registered company details to be published — see Terms §1