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, the blog on 13 October 2026, its video on 23 October 2026, the free-trial box on 24 October 2026, the pricing page on 26 October 2026 and the home page’s video on 30 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, or clicking into one of the free-trial box’s fields, shows the header, the demo board and the box 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 videos on the home page and the blog play only when you press a play button. Neither starts by itself, and once one starts it uses your browser’s own controls for pausing, volume and full screen. Pressing Enter on the play button moves keyboard focus into the video, so the space bar pauses it. The enlarge button grows the video to fill the window and shrinks it back (on a phone held upright, where there is no room to grow, it goes full screen); Escape shrinks it too, and so does moving keyboard focus on to the page behind. When the video ends, it goes back to its picture and the play button, and focus that was in the video moves to that button.

Every field in the free-trial box has a label you can see. The box asks for your shop’s name, your name and your sign-in email, and each label is tied to its field in the page’s code, which is how assistive technology knows what to call the field. None of the three is required: the button always takes you on to our signup page, which checks what you typed, so the box shows no error messages. The fields are 46 pixels tall with 16-pixel text, and they tell your browser what each one holds, so it can fill them in for you. The keyboard reaches the three fields and then the button in reading order, each with a visible focus ring, and the box works with JavaScript switched off. We measured its text, its field edges and its focus rings as if the photo behind the box were pure white, the worst case, and each 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.
• The videos have their captions drawn into the picture. They show the whole time, and you cannot turn them off, enlarge them or change their colors. The videos have no written transcripts, and their narration does not describe everything the picture shows.
• 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 one of the free-trial box’s fields, 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.

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 waiting-list form the page had then, 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.

On 23 October 2026 we added the blog’s first video and checked it on a production build in Microsoft Edge: the keyboard from the play button into the video and back to the button at the end, the enlarge button with Escape and with focus moving away, that nothing of the video downloads before you press play, and its layout from 375 to 1440 pixels wide. Under the browser’s emulation of reduced motion, the video grows and shrinks at once instead of moving.

On 30 October 2026 we added a second video at the end of the home page’s Overview tab, on the same player, and ran the same checks on a production build in Chromium.

On 24 October 2026 the free-trial card at the top of the home page and at the foot of each blog page became a box with three fields. We checked the box on 24 October 2026 on a production build of the site: the label each field shows and the name it gives the field, the order the keyboard reaches the fields and the button from the top of each page, the focus ring on every field and on the button, the contrast of its text, field edges and focus rings over a pure white background, its layout from 320 to 2560 pixels wide with and without the wider text spacing, the browser’s emulation of reduced motion, a click into a field ending the opening’s hold, and the button sending the details with JavaScript switched off. We checked all of it in Chromium, the engine inside Google Chrome and Microsoft Edge, and not in Safari or Firefox.

On 26 October 2026 we added the pricing page, a Pricing link beside Sign in at the top of the home page, and a picture of the app’s inventory window on the home page’s Product tab. We checked them on a production build, in Chromium: the order the keyboard moves through the pricing page, that a screen reader is told which plan each plan’s button starts, the order of the pricing page’s headings, its layout from 320 pixels wide to a desktop, the two links at the top of the home page fitting on one line from 320 pixels wide, and the inventory picture reading as a single image with a description of what it shows. The same day, the home page’s top section began to stack on a phone held sideways, headline over the dashboard over the free-trial box, as it does on a phone held upright, and the home page’s Pricing tab began to show everything the pricing page shows under its cards. We checked that tab’s headings, its layout at 375 and 768 pixels wide and on a desktop, and that its link to the part recipe builder opens the Product tab at the builder.

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