It Passed The Tests, But Nobody Can Use It.
I watched a shop worker try to take a required training module on his phone during a break once. The screen was cracked. The shop was loud enough that the audio was useless. He had work gloves on, so every tap landed half an inch off. He gave up about four screens in and marked it complete later from a buddy's account, which tells you exactly how much of it stuck. That course passed every accessibility check it was given. The screen-reader labels were correct. The color contrast met the standard. And the person it was built for still couldn't use it, because the checks it passed weren't measuring the things that stopped him. Designing for the floor is important, too.
Compliance Accessibility Is Necessary And Not Enough
I want to be careful here, because accessibility work is my lane and I'm not about to talk down the standards. The Web Content Accessibility Guidelines (WCAG) exist for good reasons, and a screen reader user who can't get through your course is a real failure you need to fix. None of that is in question. Meeting those standards is the floor you build on, not a thing to skip.
But "accessible" got quietly narrowed somewhere along the way to mean "passes the automated scan." And on a shop floor, that definition leaves out most of the people you're actually trying to reach. The standard is necessary. It just isn't the whole job. Designing for the floor means accounting for the real-world conditions.
The Conditions The Course Never Met
Think about who's really taking frontline training and where. A lot of them read English as a second language (ESL), and a module written at a college reading level loses them on vocabulary long before the content gets hard. A lot of them have no computer at work and will only ever see the course on a phone, often an old one with a small screen. The shop has spotty signal, so a video-heavy module that assumes a steady connection stalls and buffers until they quit.
And there is usually no quiet place to do it. The course was designed by someone sitting at a desk, in a quiet room, on a big monitor, with a fast connection, and nobody waiting on them. It gets consumed standing up, in noise, on a cracked phone, in a stolen ten minutes between tasks. Almost none of the design assumptions survive the trip from the desk to the shop.
None of those assumptions are wrong on their own. They're just invisible to the person making them, because they're the conditions that person works in every day. The trouble is that every one of them is a small bet on the learner's environment, and where the work actually happens those bets quietly lose. A module that needs a steady connection breaks where the signal is thin. The careful tapping it assumes goes out the window under gloves, and the quiet minute it was paced for never arrives in the noise. The design didn't account for the place the learning actually happens, so it falls apart there.
Designing For The Floor, Not The Desk
Most of the fixes that help in designing for the floor aren't exotic. Write to the reading level of the people on the floor, not the people who signed the contract, and check it against an actual frontline worker rather than guessing. Assume a phone first, a small screen, and gloves, which means bigger tap targets and less precision needed. Assume the connection drops, so the module works in short pieces that don't lose progress when the signal does. Assume noise, so nothing critical lives only in audio.
For ESL workers specifically, plain language does more good than any feature you can bolt on. Keep the sentences short and the words common, and put one idea in front of someone at a time. Be clear about what plain language means here, though, because it's easy to get wrong. The simplifying you're doing is to the sentence structure and the connective tissue around the necessary terms. The terms themselves stay. A coatings worker still needs to read "pot life" and the real product names, because that's the language the job and the safety data are written in. The nouns carry precision, and so does the logic around them, the "only if," the "before you," the order the steps have to happen in. Simplifying the language must not blur those into something vague, because on a safety-relevant task an "after" softened into a "when" can hurt someone. Lowering the reading level should never cost technical precision. You make the sentences easier to follow while leaving both the exact terms and the exact conditions intact.
And for crossing a language gap, the most accessible move is often to stop making words the only way in. I want to be precise about that, because the tempting shortcut is to replace the text with a picture, and that's a step backward. A screen-reader user, anyone searching for a term, a reader who processes written steps better than visual ones, they all still need the words. So you keep the words and you pair them with a clear diagram or a short demonstration, so the meaning has more than one route into someone's head. A worker who's decoding a second language under time pressure can lean on the picture; the reader who needs the text still has it. Showing alongside telling beats telling alone more often than people expect. And the plain-language work underneath it turns out to help everyone, the same way curb cuts ended up helping a lot more people than the ones they were drawn for.
The Real Test
There's one check that catches almost all of this, and it isn't a scan. Put the finished module on a cheap phone, take it to the actual environment where it'll be used, the noise and the gloves and the spotty signal included, and try to get through it yourself. You'll find the problems in about five minutes, and they won't be the ones any automated tool flagged. This is a crucial test for succesfully designing for the floor.
Passing the scan tells you a course can be opened by assistive technology, which matters and which you should keep doing. Whether the person doing the job can get through it under real conditions is a separate question, and right now most of the industry only answers the first one. Answer both, and you've built something your frontline can actually use.
