Accessibility

This statement covers partscheduler.com, the website you are reading, and the PartScheduler app at app.partscheduler.com. We build the two separately and their gaps differ, so each has its own part below, described as it stood on 2 October 2026. The tabs under the website’s top section came later; we checked them on 5 October 2026, and the blog on 13 October 2026.

What we design toward

We design PartScheduler, and this website, toward Level AA of the Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab), the World Wide Web Consortium’s published guidelines for accessible websites. We aim for that standard without claiming to reach it.

On a shop floor, a screen near a window or under shop lights catches glare, and somebody reads the schedule from a few steps away, between machines. Color blindness is common too, and the usual kind makes red and green hard to tell apart, the two colors a schedule leans on hardest.

So we design by plain rules: say a job’s status in words as well as in color, keep text readable against whatever sits behind it, and make every action reachable without a mouse. Where the site or the app breaks those rules today, the lists below say so.

What works today

On the website

The demo board stops when you tell it to. A Pause button sits on its corner, and once you press it the board stays put until you press Play. The board also holds still while your keyboard focus is anywhere inside it, and starts again a few seconds after you leave. If you have reduced motion turned on in your device’s settings when the page loads, the board never moves, a still photo stands in for the film, everything appears at once, and sections stop fading in as you scroll. You cannot pause the film, but it has no sound and is gone in about four seconds.

You can work the demo board and the recipe builder from the keyboard. The board’s five views form one set of tabs that takes a single Tab stop. The Left and Right arrow keys move between them, as do Home and End, and each view has a one-sentence text description for screen readers. Pressing Tab during the page’s opening shows the header, the demo board and the form at once and lets the page scroll.

Move earlier and Move later reorder a step in the recipe demo without dragging, and each time box has its own full name for screen readers, such as “Cycle time minutes”. Removing a step moves focus to the step beside it, and closing the editor puts focus back on the step you opened.

The tabs under the top section work like the demo board’s. They take one Tab stop, and the Left and Right arrow keys, Home and End move between them. A link to something inside a closed tab, such as the footer’s link to the recipe builder, opens that tab and scrolls to it. While the old section slides away, nothing in it can take keyboard focus, and with reduced motion turned on the new section replaces it at once instead of sliding in. Without JavaScript the tabs do not appear and every section shows, one under the other.

The waiting-list form tells you what happened. Every field has a visible label, and the email field’s label ends in “(required)”. If the form turns down an address, the message appears as an alert, which screen readers normally read out at once. What you typed stays in the form, as long as the page had finished loading before you sent it. When you join, the page marks the confirmation for screen readers to read out and moves keyboard focus to “You are on the list.” We calculated the contrast of the text on the form’s glass card as if the photo behind it were pure white, the worst case, and the text stays at or above the contrast we aim for.

The page holds up under wider text spacing and on narrow screens. With the extra line, paragraph, letter and word spacing that WCAG tests for, the top section grows taller instead of cutting anything off. At 320 pixels wide, the width of a small phone, the home page fits with no sideways scrolling, and the page never blocks zoom.

The headline’s words also have real spaces between them in the page’s text, so software reading it gets “Ship parts on time” instead of one run-together word. The headings run in order under one main heading, and the page declares its language as English. The feature comparison works without seeing its grid, since every answer is also written out as Yes or No.

In the app

• In the main views (job cards, the jobs list and the board’s count tiles) the app writes a job’s status in words, such as “3d late”, “Due today” or “On hold”, so color is not the only signal there.
• One focus ring marks keyboard focus across the app, drawn for both light and dark mode.
• We built drag-and-drop on the Operations board, the Schedule, the machine queue and the recipe builder to work from the keyboard too: Space or Enter picks an item up and the arrow keys move it, and the app gives screen readers instructions and announcements along the way.
• The app builds its standard dialogs on a component library designed to hold keyboard focus while a dialog is open, close it with Escape, and put focus back where it was.
• The app respects your device’s reduced-motion setting. It makes transitions near-instant, and it switches off smooth scrolling along with the entrance animations on cards and pages.
• The app builds form fields with labels and links each field’s hint and error message to it, so a screen reader reads them together. It also flags fields in error as invalid and marks status and error messages for screen readers to read out.
• Nine accessibility lint rules check every change pushed to the app’s code. Lint reads the source without running it and catches problems such as an image with no description or a clickable element the keyboard cannot reach; one warning fails the check. We switched off three related rules because existing code would trip them. A failed check does not by itself stop a change going live, and lint cannot judge contrast or focus order, let alone what a screen reader actually says.

Known limitations

These are the main gaps we know about, most serious first; we have left some smaller faults off.

On the website

• When the demo board is drawn small, its tabs ignore taps and clicks. That happens on phones about 380 pixels wide or narrower and on phones turned sideways. It also happens in a desktop window that is short or zoomed in, and in one just over 900 pixels wide. There the tabs shrink to under 24 pixels wide and sit close together, too small to hit on purpose, so we switched taps and clicks off for them. They still work from a keyboard, and the Pause button and the light and dark switch still respond to taps and clicks.
• The job card in the recipe demo has a striped bar that never stops moving. The green bar on the step in progress flows for as long as the page is open, and no control on the page pauses it. Only your device’s reduced-motion setting stills it.
• The board can keep moving for a screen reader user. A screen reader that moves focus into the board right after a mouse click on the page may not trigger the focus hold, and the board can then change views. The Pause button still stops it.
• Some text follows the window’s width. The headline and the demo board’s labels scale with the window, so zooming in on a wide monitor can make them smaller rather than larger.
• Find in page does not search a closed tab. Your browser skips the text in the tabs that are not open, so searching for a word from another tab finds nothing until you switch to that tab.
• “Get in touch” needs JavaScript and a mail app. The button opens a new email in your mail app. Without JavaScript it does nothing, and on a device with no mail app set up it may do nothing visible either.
• On a desktop the home page holds still for its opening. For up to five seconds the page will not scroll, and it hides everything below the top section from screen readers and the keyboard. The keyboard still works in the top section, and the first press of Tab, or a click into a form field, ends the hold at once. Reduced motion, a window 900 pixels wide or narrower, or arriving by a link to a section skips it entirely. So does any visit that has already seen the website: the opening plays only when a visit starts on the home page, and coming back to it from another page, reloading it or returning to it with Back shows the finished page at once.
• After a rejected signup, the form does not mark the email field itself. The error message appears as an alert, but the form does not flag the email field as the one in error or link the message to it.

In the app

Things that depend on seeing the screen:

• Schedule calendar chips show risk by color only. On the Schedule, a thin colored stripe on a job’s chip marks how at risk it is. Screen readers skip the stripe, and the chip’s text and tooltip give the job number and details but not the risk.
• Hint text in empty fields is pale. We made the gray example text inside an empty field lighter than other text on purpose, so nobody mistakes it for something typed, but that puts it below the contrast we aim for.
• Loading placeholders keep animating with reduced motion on. The pulsing placeholders and the loading bar speed up rather than stop, and we have not checked whether that looks still or flickers.
• Live pages refresh on their own. The home dashboard, the boards, the Schedule and the shipping queues update in place every so often. Refreshing waits while the tab sits in the background, while you are offline, or in the middle of a drag or a save, but no control pauses it.
• PDF drawings are only as accessible as the file. Prints open in your browser’s own PDF viewer. Many drawings are scans, pictures of a page that a screen reader cannot read, and PartScheduler cannot change what is in the file.
• The map beside an address comes from Google. Opening it loads Google Maps in a frame, so how accessible it is depends on Google.

Things that depend on how you reach the controls:

• Hidden buttons can take keyboard focus on the Operations board. On a desktop, a job card’s action buttons stay hidden until you point at the card, but keyboard focus can still land on them. Screen readers skip them while they are out of sight, so a screen reader user can land on a button that goes unannounced. The card itself also acts as a button with buttons inside it, which can confuse screen readers further.
• The Schedule calendar’s grid is incomplete for screen readers. It announces itself as a grid but leaves out the rows a grid needs, so a screen reader may not move through it as a calendar, and the arrow keys move between days only while you drag a job.
• Reordering recipe steps or a machine’s queue needs dragging. Dragging works with a pointer or from the keyboard, but no buttons move a step or a job up or down, so someone who can point but not drag cannot reorder them. On the Operations board, though, a click can assign a job to a machine without dragging.
• Free rotation in the 3D part viewer needs a mouse or touch. Spinning the model works only with a pointer, as do zooming and panning; from the keyboard, preset view buttons turn the model to set angles. The model has no text description of its shape, though the app writes out the part’s number and revision elsewhere and lists its files.
• A few icon buttons on the job page are small. The buttons for uploading and archiving files and for material certificates measure 20 pixels square, under the 24-pixel minimum WCAG 2.2 sets unless the space around them makes up for it, which we have not measured.

How we checked

We assessed both ourselves, on 2 October 2026. For the website, we read its code and measured the live home page in a browser at window sizes from 320 to 1920 pixels wide. We fixed most of what that turned up the same day and then tested the main fixes on a production build of the site, including keyboard use of the demo board, both outcomes of the signup form, the recipe demo’s step buttons, wider text spacing, and a check at twelve window sizes that the fixes left the layout unchanged. For the app, we reviewed its code.

The website check covered only the home page; we added or rewrote the other pages, this one included, afterward.

On 5 October 2026 we added the tabs under the home page’s top section and tested them on a production build: the arrow keys, Home and End, links into a closed tab, where keyboard focus goes while a section slides, the reduced-motion swap under the browser’s emulation of that setting, and the page at 320 pixels wide.

On 13 October 2026 we added the blog and checked its first post on a production build: the order the keyboard moves through it, the text that describes each picture, the order of its headings, its layout from 375 to 1600 pixels wide, and the browser’s emulation of reduced motion. The line beside a post that follows your scrolling, and the green ring it draws round each heading, are decoration: screen readers skip them, the keyboard never stops on them, and their animations stop when you ask your device for less motion.

Tell us

If something on the website or in the app gets in your way, use the Get in touch button below. Say which page you were on, what you were trying to do and what happened, and if you use assistive technology such as a screen reader or magnifier, say which one and in which browser.

The button needs JavaScript and a mail app set up on your device. If you already use PartScheduler, the question-mark help button inside the app sends your message straight to us with no mail app needed. If you do not use the app and the button does nothing for you, this website has no other way to reach us.

Need a page of this site, or a page or document from the app, in another format, such as plain text in an email? Ask through the same button and say which format would work for you.

Get in touch