At 6:12 in the evening, a storm alert appears on a phone screen. It is written in Spanish, tells people to avoid paths near the stream, and links to a map that takes time to load. In a village where Catalan is the language of everyday conversation, many people do not open the link: coverage drops, batteries are low, and the message looks like one more administrative notification. At seven, when rain forces the school bus onto a different route, a resident learns that the underpass is closed only because her sister calls. The information existed, but it did not arrive as information she could use.
This is not an argument that one language matters more than another, nor an assumption that every rural resident is offline. It identifies a decisive detail: a public message has not done its job merely because it has been sent. It does its job when a person who needs to act can understand it, receive it in time, and check what to do without clearing new obstacles. An alert designed around the connection, language, and experience of the majority may be technically accurate while leaving part of the territory more exposed. Inequality does not arrive after the system. It can travel inside seemingly minor choices about format, file weight, and channel.
An alert is more than a sentence#
In a risky situation, information competes with practical realities: noise in a kitchen, an older person who does not use apps, a screen with weak signal, caring for children, field work, and uncertainty about whether the warning actually concerns that valley. That is why translating a sentence at the end of the process is not enough. A Catalan version must appear with equal priority, in familiar language, alongside locally understandable directions. “Avoid flood-prone areas” is less useful than naming the affected crossing, the expected time window, and a safer alternative when those details are known.
In a risky situation, information competes with practical realities: noise in a kitchen, an older person who does not use apps, a screen with weak signal, caring for children, field work, and uncertainty about whether the warning actually concerns that valley.
Accessibility is not only linguistic. An app full of animated maps, autoplay video, and notices that require account creation turns urgent communication into a test of patience. If the signal fails before the page finishes loading, the design has moved responsibility onto the recipient: they must try again, search for data, call someone, or accept not knowing. In an emergency, requiring those extra steps distributes time and risk unequally. A low-data option is not an inferior edition of the service. It is a condition for the service to work in the conditions people actually face.
The storm example also separates redundancy from noise. Receiving the same notice in an app, on a website, and through a social-media account does not offer much protection if all three routes depend on the same data connection. A brief text message, a lightweight page that opens without registration, local radio, a municipal noticeboard, and a calling network run by trusted organisations create genuinely different routes to the same decision. No route should invent a competing instruction. Each should point to a coordinated source, show when it was updated, and distinguish what is known from what is still being checked.
Design before the emergency begins#
The useful question is not, “Can we add a translation if something happens?” It is, “Who is excluded when we prepare the warning this way?” Answering it means bringing together people who know the routes, languages in use, and connectivity constraints before storm season starts. Local radio, family associations, primary-care teams, farming cooperatives, libraries, and transport organisers can all contribute. They are not there to endorse a finished product. They are there to describe how people actually hear important news when the usual channel fails.
That work can become a simple communications map. It does not require collecting personal data or publicising who receives help. It can identify places with unreliable coverage, buildings where people may need extra support, times when travel is most common, and groups able to pass along a verified instruction. The map needs careful review because a community is not a catalogue of deficits. Some bilingual people prefer Catalan, others read Spanish more easily, and others need audio, pictograms, or a phone call. Designing for plurality is not the same as assigning one fixed label to every village.
It also matters to decide who can authorise and update a message. In the first minute of a weather event, it is unreasonable to debate who may correct a street name or whether a phrase needs adaptation. A prior protocol can prepare short message patterns, local glossaries, and clear owners for each channel. A pattern does not replace judgment: it leaves room for a specific instruction, a time, and a source. Its value is that the message does not depend on one person remembering every necessary form of access while under pressure.
Community channels must not offload public duties#
A community network can save crucial minutes, but it must not become an excuse for public institutions to abandon their duty to inform. A local station, neighbourhood association, or cooperative may extend reach because it already has relationships of trust. It needs timely official information, a quick way to resolve doubts, and an unmistakable signal when something changes. It should not have to interpret ambiguous data or decide whether a rumour received through a messaging group is safe to broadcast.
In the imagined village, the station could interrupt its programme with a thirty-second bulletin in Catalan and Spanish. It would say which road to avoid, until when the alert applies, and where a listener can obtain an update by telephone. A support group could call people without smartphones using an agreed and protected list. The school could send a morning note explaining the return-home plan if the forecast worsens. These are distinct pieces, not substitutes for resilient infrastructure. Each offers another door without requiring anyone to install an app.
Trust also requires a channel that can acknowledge uncertainty. If nobody yet knows whether a footbridge will close, the message can say so and explain when the next check will occur. False certainty travels fast and weakens later warnings. Plain language is not language that sounds definitive at any cost. It is language that separates an immediate instruction, a prudent recommendation, and a pending fact, so the community knows what kind of response each situation calls for.
Test exclusion, not only the platform#
Teams often test whether an app crashes and whether its send button works. Those checks are necessary, but they answer a narrow question: whether the system operates under ideal conditions. An exclusion test asks something else: can a person with a limited data plan, an older screen, a different language, or intermittent service understand the warning and act on it? It does not require staging a disaster. A rain alert can be rehearsed with clear consent while observers note where the experience breaks down and what explanation is missing.
Time matters as much as clicks. How many minutes did it take a family to learn that the bus route had changed? Did the lightweight page open on a slow connection? Could the audio be understood without headphones? Was the Catalan version visible on the first screen or buried in a menu? Did anyone mistake a county-level caution for an evacuation order? These answers should not grade participants. They should repair the design. If five people stumble at the same point, the problem is not that five people “do not know how to use” the system.
The review should also look for unintended effects. A message asking users to share location may help a response team while excluding people who cannot or do not wish to do so. A public list of assisted households may improve coordination while revealing sensitive circumstances. Accessibility does not authorise extracting more data from people who already face a barrier. Every feature should explain what information it needs, how long it will keep it, and who can see it. Protecting privacy is part of making people willing to use the channel at all.
A duty that can be sustained#
The rural community in this example does not need a spectacular solution. It needs an alert in Catalan and Spanish, readable with little data, confirmed through radio or a phone call, and paired with a visible way to correct errors. That requires funding for translation and maintenance, agreements with local media, staff training, and repeated testing. It also requires accepting that some warnings will not reach everyone on the first attempt, and that this fact calls for improvement rather than blame directed at the people left out.
The next step can be modest and testable. Before the next period of heavy rain, an authority could publish an emergency version smaller than 100 kilobytes, agree two short radio scripts, and invite residents who use different devices and languages to take part in a test. Afterwards, it should say what failed, what was repaired, and when it will repeat the exercise. Then informing ceases to mean the act of sending an alert. It becomes responsibility for the conditions that let people receive it. An informed democracy is not measured by the number of messages it issues, but by how many people can turn those messages into a safe decision.
