Why Your Public Signs Fail the Accessibility Test, and How to Fix It

Your public screens look compliant, but are they really?

A WCAG 2.2-compliant template on paper does not guarantee a compliant screen in practice. Facilities managers often assume that a pre-approved design, checked against contrast ratios, font sizes and colour schemes, will hold up once deployed. But real-world conditions expose three critical failures that no static review catches.

First, contrast checks assume a controlled environment. A screen in direct sunlight reflects glare, reducing perceived contrast even if the numbers pass. A template might meet the 4.5:1 minimum for normal text, but under bright lighting, the difference between black and grey can blur to the point where a visitor squints and still cannot read. The fix is not to tweak the template, it is to test the screen in its actual location, where lighting and viewing angles change the equation.

Second, font sizes are measured against a baseline of 12 pixels at 100% zoom. But most public screens are viewed from a distance, and many users, especially those with low vision, will not adjust their own devices. A 16px font may look clear on a laptop, but at three metres away, the letters merge. The template’s "compliant" size does not account for the physical space where it will be read.

Third, dwell time, the pause before an interactive element responds, is often set to a standard. Yet in a busy transport hub, a user with motor impairments may need more time to stabilise their pointer. A template’s dwell setting might pass automated testing, but in practice, it forces them to restart the interaction, breaking the principle of operability.

None of these issues appear in a template review. They only surface when the screen is live, the lighting shifts, the distance varies, or the user’s needs differ from the assumed case. By then, the cost of retrofitting, adjusting contrast curves, recalibrating fonts, or reprogramming dwell times, far exceeds the price of testing the design in context before it goes up.

Dwell time isn’t just for wayfinding, it’s a legal minefield

A static council notice or transport update can look compliant on paper, but it fails the moment someone with low vision tries to read it. WCAG 2.2’s dwell time rules, where a single tap or dwell activates interactive elements, are often ignored on screens that play loops without input. The problem isn’t just wayfinding. A transport hub’s delayed train times or a council’s public health warning must be readable on demand, not just scrolled past. If a screen plays a video or slideshow without a pause or dwell trigger, it violates Success Criterion 2.5.3 Label in Name and 2.5.1 Pointer Gestures, which require interactive controls for users who cannot hover or click quickly.

The gap appears when screens rely on autoplay. A loop of bus arrival times, for example, may meet contrast and font size standards, but if it has no dwell-sensitive hotspot, a screen reader user cannot pause or replay it. Worse, some systems treat alerts as queued content rather than interruptions. A fire drill announcement might appear after the next slide in a rotating queue, leaving critical seconds unaccounted for. The law does not mandate how fast an alert reaches a screen, but it does demand that users can interact with information when they need it, not when the system chooses.

Here’s how three common setups compare in practice:

The fix isn’t retrofitting a dwell button after the fact. A screen that cannot pause, replay, or accept interruptions, whether for alerts or accessibility, will face complaints or enforcement actions the moment a user with motor or cognitive impairments tries to engage with it. The solution lies in hardware that supports display over other apps and software that treats alerts as mandatory, not optional. That way, a dwell on any part of the screen triggers controls, and an emergency message appears before the next slide loads, without waiting for a network poll or a queue position.

Reading distance matters more than you think, especially in transport hubs

A screen at a bus stop and one on a train platform share the same content, but they do not share the same audience. The person standing on a platform can be farther away, while someone at a bus stop might be closer. That difference forces a choice: either the font is large enough for the farthest viewer, leaving the closer one staring at a wall of text, or it is legible at the nearer distance, risking the platform user missing critical information.

The problem is not just size. Glare from overhead lighting on a platform alters contrast, while a bus stop screen may face direct sunlight at midday. A font that reads clearly in one setting becomes a blur in another. The result is not just frustration, it is wasted effort. When staff later adjust the screens to meet accessibility standards, they are not fixing a one-off issue. They are correcting a design that assumed all viewers stand in the same place under the same light.

This rework often happens after complaints. A passenger reports they could not see the departure board, so the font is increased. But the next day, the closer viewer now struggles to read the smaller text at the bus stop. The solution is not to tweak the font size, it is to recognise that every screen has its own reading zone. A platform screen needs bold, high-contrast text for distance and brightness. A bus stop screen can use slightly smaller text if the distance and lighting allow. The cost of ignoring this is not just in the initial design, but in the repeated adjustments, the staff time spent fixing what should have been right first time, and the risk of non-compliance slipping through again.

The hidden cost of ‘quick fixes’: why retrofitting is worse than getting it right first time

When a screen fails to show an evacuation route, the cost isn’t just the missed compliance check, it’s the support tickets that follow. A manager calls IT after a member of staff reports the wrong floor number still displays during a drill. The technician checks the player, confirms the content was correct, and realises the screen had been set to queue alerts behind a looped video. The fix isn’t updating the software; it’s removing a permission the screen never had in the first place. By then, the drill has been logged as a failure, the responsible person has noted the gap, and the organisation is already planning a retrofit.

The real expense isn’t the initial setup. It’s the second attempt. Retrofitting accessibility means hunting for screens that can interrupt their own playback, then reconfiguring each one individually. Some devices lack the permission entirely, and the panel only reveals this after an alert fails to appear. Others need a factory reset to clear old software, which wipes any customisations. In a large estate, this turns a one-time compliance task into a recurring audit, every time a new screen is added, every time a loop is updated, every time a user reports a delay.

The alternative is designing for interruptions from the start. A screen that always acknowledges alerts, whether it’s a fire warning or a revised wayfinding card, eliminates the guesswork. The panel tracks which devices are live, which are stuck, and which have silently ignored a message. If a screen can’t override its own content, the system flags it before the next critical update. No tickets. No second checks. Just a guarantee that when seconds matter, the right information appears.

The trade-off is clear: a system built to fail gracefully costs more upfront than one that fails entirely. The difference is in the support logs.

WCAG 2.2 isn’t just about text, your public sign’s environment could invalidate compliance

WCAG 2.2 sets clear rules for text size, contrast and timing, but those standards only matter if the screen is visible. A sign that meets every technical requirement can still fail in the real world if its environment makes it unreadable.

Glare is the most common blind spot. A fluorescent tube or a south-facing window can turn a high-contrast display into a mirror. The screen’s own backlight may wash out text in bright daylight, even if it passes a lab test under artificial light. Reflective surfaces, glass doors, polished floors or even a nearby desk, can create ghosting, where text appears doubled or smeared. These issues are rarely caught in a static audit because they depend on the angle of view, the time of day and the surrounding light sources.

The problem is not just visibility but reliability. A sign that works at one time may be unusable at another, forcing staff to manually override it or print paper copies. This happens more often than expected because compliance checks typically assume a controlled environment. A screen mounted at waist height in a lobby might pass WCAG tests in an office, but in a transport hub or a shop front, the glare from passing vehicles or shop lights can render it illegible from a distance.

The fix is not just about the screen itself but where and how it is placed. A screen angled away from direct sunlight, positioned to avoid reflections, or fitted with an anti-glare filter can make all the difference. The key is testing in the actual location, not just in a meeting room, because what looks compliant on paper often fails in practice.

Three months in: when ‘good enough’ becomes a liability

Three months after a new public information screen was installed in a hospital’s main corridor, a patient’s family complained. The screen displayed emergency alerts, but the text was too small for someone with low vision to read from a distance. Staff had assumed the font size met accessibility standards, but the screen’s default settings had overridden the compliance template. When the family raised the issue, the hospital’s audit team found the same problem on every screen in the building. The fix required a firmware update, a staff retraining session and, worst of all, a public apology for the oversight.

In a transport hub, a similar blind spot emerged when a digital sign replaced paper notices. The screen’s high-contrast colour scheme worked in testing, but the backlight washout made it unreadable in bright sunlight. Passengers with visual impairments reported missing critical announcements, and the operator’s accessibility officer traced the issue to a cached content template that had never been reviewed under real-world lighting. The solution was not just adjusting the brightness, it meant recalibrating every screen’s colour profile and scheduling regular daylight checks, which the facilities team had overlooked in the initial rollout.

These examples share a common pattern: compliance checks are often performed in controlled environments, not where the screens will actually be used. A screen that meets accessibility standards in an office at lunchtime may fail in a busy atrium at dawn, or when an alert interrupts a scheduled loop. The problem is not the technology itself, but the assumption that once a screen is installed, it will remain compliant without ongoing verification. Alerts that take over a display, using Android’s display over other apps permission, can also disrupt playback in ways that affect readability. If an urgent message flashes too quickly, or if the contrast shifts when content is overlaid, users may miss critical information entirely. The risk is not just legal exposure; it is operational failure when a screen that was once ‘good enough’ becomes a liability the moment it is needed.

The one setting that breaks accessibility, and no one checks it

Public screens often pass accessibility checks in the lab but fail in the real world. The reason lies in a single setting that most organisations overlook: automatic brightness and contrast adjustments. These features, enabled by default on many Android devices, can undo WCAG 2.2 compliance in seconds. A screen that meets contrast ratios at one brightness may become unreadable if the system dims it for ambient light or boosts contrast to "enhance" visibility. The OS decides this in real time, without consulting the content or the user’s needs.

The problem is not theoretical. In a hospital corridor, a screen displaying emergency instructions may struggle against fluorescent lighting. In a factory, dynamic contrast scaling can turn a high-visibility alert into a flickering blur when workers move past. Neither scenario violates WCAG if tested statically, yet both break compliance the moment the device adjusts itself. The fix is simple but rarely applied: lock the display settings. On Android, this means disabling adaptive brightness entirely and setting a fixed contrast profile. The screen will then honour the contrast ratio you designed, not the algorithm’s guess.

The catch is that this setting is buried in device menus, often ignored during installation. A screen left on default will revert to automatic adjustments after a reboot or a software update. The solution is to enforce it at the OS level, either by configuring each device manually or, where possible, through a fleet management tool that flags screens that cannot draw over another app before they become an issue.

The next step is to audit your estate. Check one screen now: is the brightness fixed, or does it shift when you walk past? If it’s the latter, the compliance risk is already active. Lock the settings, test them again, and document the change. Accessibility is not a checkbox, it’s a state that requires maintenance. Start with the one adjustment that undoes everything else.