WCAG 2.2 is the minimum, what actually fails when screens go live?
WCAG 2.2 sets a baseline for digital signage, but real-world conditions expose its limits. A high-contrast warning sign on a bright day fails when sunlight washes out the screen, even if the contrast ratio meets the standard. The issue isn’t the specification, it’s the physics. A 4:1 contrast ratio is readable in a dark room, but under direct glare, the difference between white text and a light grey background collapses. A staff member scanning the screen for an urgent alert may miss it entirely, not because the design is wrong, but because the ambient light turns the text into a uniform blur.
Colour blindness filters help, but only if the user knows to apply them. A screen displaying a red "exit" sign with a green "entry" sign may appear as two shades of grey under protanopia. The filter works in isolation, but in a busy corridor, a distracted visitor won’t pause to adjust settings. Even if they do, a quick glance at a moving train schedule, where red and green convey critical timing, becomes unreadable without intervention. The filter doesn’t account for the user’s attention span or the speed at which they need to act.
Text scaling solves one problem but creates another. A wayfinding screen with 24-point font may resize to 36 points for a visually impaired user, but the layout breaks. Labels shift, icons overlap, and the hierarchy of information collapses. In a hurry, a user may abandon the screen entirely, assuming it’s malfunctioning rather than recognising it as an accessibility feature gone wrong. The trade-off isn’t just readability, it’s usability under pressure.
These failures aren’t theoretical. They happen when a screen is mounted in a high-traffic area, when a user is moving, or when an alert demands immediate action. WCAG 2.2 ensures a static, idealised test passes, but the real test is what happens when the screen is live, the lighting is poor, and the user has three seconds to understand it.
Dwell time on public screens: why users ignore what they can’t read in 3 seconds
WCAG 2.2 sets a minimum for font size and contrast, but real-world readability depends on more than pixels on a page. A user standing 10 metres from a screen with 18-point text at 1.4:1 contrast will still abandon it in seconds, even if the content technically complies. The issue is not just the numbers on a checklist but how they interact with distance, glare and the time it takes to process dense information.
A 65-inch screen with 24-point text at 1.4:1 contrast may meet WCAG, but if the text wraps into three lines of a dense paragraph, a user scanning for key details will struggle to extract meaning before walking away. The same screen with single-line headlines and bullet points, even at the same font size, becomes usable because the brain processes sparse information faster. The trade-off is clear: compliance without readability leads to ignored screens, and ignored screens waste the hardware and electricity they consume.
Distance compounds the problem. A 55-inch screen with 20-point text at 1.4:1 contrast might pass WCAG at 3 metres, but a reception desk at 6 metres turns it into a blur. Doubling the font size to 40 points improves visibility, but now the screen needs to cut content to a single line or a large icon. The solution is not a fixed rule but a balance between size, spacing and the user’s expected position, something WCAG does not account for.
The table below compares three common approaches to public-facing text, showing how each handles distance, density and dwell time, the actual time a user spends engaged.
| Approach | Font Size (at 3m) | Line Length | Dwell Time | Real-World Use Case |
|---|---|---|---|---|
| WCAG minimum | 18pt | Full width | <3s | Compliance checkbox only |
| Single-line headlines | 36pt | One line | 5 to 8s | Wayfinding or alerts |
| Icon + short text | 24pt (icons) | Bullet points | 4 to 6s | Staff notices or menus |
A screen displaying a single line of 36-point text will hold attention longer than a dense paragraph, even if the paragraph technically meets contrast. The key is reducing cognitive load: fewer words, more white space, and content designed for a glance rather than a read. When every second counts, such as during an emergency, the difference between a screen that is seen and one that is ignored comes down to these choices.
Glare is the silent accessibility killer, and no one tests for it
Sunlight through a shop window at 11 a.m. turns a white-on-blue alert into a grey blur. The screen is positioned too close to the cash desk, and the overhead spotlights reflect off its anti-glare coating at a shallow angle. A customer squints, then walks past without seeing the staff call for extra help. The signage system logged the alert as delivered, but no one read it.
This is how glare defeats accessibility. WCAG guidelines cover contrast ratios and text size, but they do not account for real-world lighting conditions. A screen in a transport hub may pass every automated test at night, yet become unreadable by midday when fluorescent tubes and skylights combine to create a wash of light. The issue is not the screen’s brightness setting, it is the angle of incidence. Light hitting the display at 45 degrees or less scatters across the surface, turning sharp edges into halos. Even a matte finish, designed to reduce reflections, can scatter light unpredictably when struck from multiple directions at once.
Retail stores often place digital signs at waist height to catch the eye of passers-by. This works for advertisements but fails for alerts. A low-mounted screen under a ceiling light reflects glare directly into the eyes of someone standing in front of it. The problem worsens with multiple screens in the same space. A bank branch might install three displays: one at the entrance, one near the tellers, and one in the waiting area. The entrance screen, bathed in natural light from the door, becomes a mirror at certain times of day. The waiting area screen, positioned under a row of downlights, turns into a source of its own glare when viewed from the side.
The mechanism is simple: light reflects off the display surface at the same angle it hits it. If a screen is angled towards a window, sunlight reflects back towards the viewer. If it is perpendicular to a row of ceiling lights, those lights create a secondary source of brightness that overwhelms the content. The result is not just reduced visibility, it is functional blindness. A user may see that something is on screen, but not what it says. This is why wayfinding signs in transport hubs, often placed near ticket machines under strip lighting, fail to help travellers with visual impairments. The text remains legible in a lab test, but in practice, it disappears under glare.
No compliance checklist catches this. Automated tools measure contrast in a controlled environment, not in a space where lighting shifts with the sun’s position or the flicker of artificial sources. The only way to identify glare issues is to observe screens in place at different times of day, from multiple angles, and under varying conditions. A display that works at 3 p.m. may be unusable at 9 a.m. or 3 p.m. in winter. The fix is not always technical, it can be as basic as repositioning the screen, adding a light-diffusing panel, or adjusting the angle of mounting. But without testing for glare in the real world, these solutions remain unknown.
The second-order cost: when accessibility complaints trigger legal risks three months in
A single accessibility audit catches glare, contrast and font size. It does not catch the person who squints at the screen for three months before complaining, or the staff member who reports a headache every time they pass the lobby. These are not failures of the initial check, but of the process that follows it. A complaint logged in month three is not a one-off irritation, it is evidence of a pattern the system failed to detect.
The problem is not that the signage does not meet WCAG. It is that no one is watching whether it continues to meet it. A screen that works perfectly in a lab may develop issues in use: a new light fixture casts reflections no one noticed during testing, or a cleaning schedule leaves residue on the glass. The first user to mention it is often the third person to experience it, because the first two assumed they were seeing things wrong. By the time a formal complaint arrives, the issue has already caused enough disruption to trigger a formal investigation, one that could lead to a claim under the Equality Act or the Disability Discrimination Act, even if the original design complied.
The solution is not to re-run compliance tests. It is to track which screens are actually being used, and by whom. If a particular display is flagged repeatedly for the same issue, whether glare, unreadable text or a timeout that cuts off wayfinding instructions, it is not a user error. It is a systemic failure the system should have caught earlier. The panel must show not just what is scheduled to play, but what is actually visible on the screen, including whether the device can interrupt a video or app when an alert arrives. A screen that cannot overlay an emergency message because it lacks the necessary permission does not just fail in theory, it fails in practice, every time. The difference between a one-off complaint and a legal risk is whether someone is paying attention to the cumulative evidence before the third person speaks up.
This is why the panel needs to distinguish between screens that can display content and those that will. A device that silently ignores alerts because it lacks the overlay permission is not just non-compliant, it is a blind spot in the system. The moment a user reports that an alert did not appear, the question is not whether the screen should have shown it. It is whether the panel can prove it did. Without that visibility, the first sign of trouble is often the complaint itself.
Wayfinding screens with 10-second dwell times, why most users still can’t find their way
A wayfinding screen with a 10-second dwell time meets WCAG’s static contrast and timing requirements, but that does not mean a user can read it in that time. WCAG tests text on a blank screen, not in the context of a busy public space. The real failure happens when the screen is already displaying an alert, a news ticker or a rotating advertisement, and the wayfinding content must interrupt it.
The problem is not just that the user has less than 10 seconds to absorb information. It is that the screen’s primary task, delivering urgent updates, conflicts with the secondary task of navigation. A lost visitor does not pause to wait for the screen to finish its current loop. They scan for a moment, then move on if the text does not resolve immediately. The screen’s compliance with WCAG does not change this: the user’s urgency does.
Cognitive load compounds the issue. A wayfinding screen in a hospital or transport hub must convey multiple pieces of information at once, directions, floor numbers, emergency exits, while the user is already stressed by their situation. If the screen flickers between an alert about a delayed train and a static map, the user’s brain discards one or both. WCAG’s static contrast checks do not account for the distraction of overlapping content. A screen that meets the letter of the standard may still fail in practice because the user cannot process what it shows when it is not the only thing on it.
The mechanism is simple: if a screen must interrupt its loop to display wayfinding, the interruption itself creates a new barrier. A user who glances at the display for three seconds sees a partial update, half an alert, half a map, and walks away confused. The dwell time is irrelevant if the content is not stable. WCAG assumes the user will engage fully with a single, unchanging element, but real-world wayfinding requires immediate, uninterrupted clarity. Without it, compliance becomes meaningless.
Accessibility overlays are a band-aid, what breaks when they’re disabled by IT policies?
Accessibility overlays rely on browser extensions or plugins to adjust contrast, resize text or read content aloud. These tools fail when IT policies block them. A common rule disables all extensions by default, treating them as a security risk. The result is not just a screen that looks inaccessible, it’s one that cannot be made accessible without manual intervention.
Take a public information display in a hospital. A visitor with low vision might enable an overlay to increase text size, but if the network admin has locked down browsers, that option disappears. The screen still shows the same small text, the same poor colour contrast. The overlay’s settings panel vanishes entirely. The visitor now faces a choice: either leave the information unread, or ask staff for help, adding unnecessary delay to an already stressful situation.
The problem worsens when overlays depend on JavaScript. Many IT departments strip out scripts to prevent malware or data leaks. A screen designed with WCAG-compliant fonts and spacing may render unusable if the overlay’s dynamic adjustments are blocked. The text reflows incorrectly, captions fail to appear, and audio descriptions, if they exist, cut out mid-sentence. The screen now meets compliance standards on paper, but in practice, it excludes the very users it was meant to serve.
Even when overlays work, they often require user action. A policy that disables extensions may also prevent users from installing them in the first place. A temporary fix in one browser does not help someone who relies on a different device or operating system. The overlay becomes a one-time solution, not a reliable one.
The deeper issue is that overlays assume users can override restrictions. In reality, most cannot. The result is a false sense of compliance, screens that pass automated checks but fail in the real world. The gap between theory and practice is not a technical limitation. It is a policy one.
The hidden audit: how to catch accessibility failures before the first complaint
Accessibility checks in a lab or a spreadsheet miss what happens when a screen is live. A high-contrast text test on a desk lamp does not show how glare from a window or a fluorescent light turns that same text into a blur. A colour-blind simulator does not reveal whether the red and green used for wayfinding actually look identical under the shop’s neon lighting. The only way to catch these failures is to test under real conditions, with the same hardware and the same environment where the screens will run.
Start with a light meter. Measure the brightness of each screen’s surroundings at different times of day, and note where reflections or ambient light wash out text. A screen in a north-facing office may be perfectly readable at midday, but the same screen in a south-facing lobby becomes unreadable by 11 a.m. unless the content adjusts dynamically. Test with a contrast checker app, but do it in the actual space, where the screen sits, not where the tester stands. If the app flags a failure, the screen will too, but only when someone is actually trying to read it.
Next, observe how people interact with the content. Place a screen in a high-traffic area and watch who stops, who glances, and who walks past without noticing. If most users fail to register an announcement within three seconds, the font is too small, the contrast is insufficient, or the message is buried under other visual noise. Record a few users, without telling them you are, and ask one question: Did you see the screen? Their answers will reveal what the automated tools cannot.
For edge cases, use automated tools but run them against real media. A screen that passes WCAG checks with a static image may fail when that image is part of a moving playlist. Test with the actual content that will run on the screens, not placeholder graphics. If the system supports it, enable the offline playback mode and check that cached media still meets contrast and readability standards when the network drops. A screen that looks fine online may become unreadable when it relies on local files.
Finally, simulate interruptions. If the system must display emergency alerts, test how they appear when a video or slideshow is already playing. Some screens will queue the alert, delaying it by minutes. Others will ignore it entirely if they lack the necessary permissions. The panel should show which screens can interrupt what is on display, so you know which ones will fail when it matters. Run these tests with the exact content and permissions that will be live, not with a simplified demo.
The next step is simple: pick one screen in each environment and test it this way before rolling out the rest. Do not assume the first one works because the second one will. If the audit finds failures, fix them on that screen first. Then move to the next. The goal is not perfection in the lab, but reliability in the real world, where the light changes, the users vary, and the network sometimes goes away.
