Alerts for All: making CAP alerts accessible at the source

Thank you to the workshop organisers for inviting me to share our work. My name is Emmanuel Jacq. I am Deaf. I lead International Deaf Emergency, a Deaf-led nonprofit in the United States.

After the 2010 Haiti earthquake, we worked with the Red Cross to build an accessible camp for four hundred Deaf and disabled people. That experience taught us: people left out must help design the solution.

Today, I am here as an implementer. Our system receives live CAP alerts from IPAWS and the National Weather Service. We also work under a Memorandum of Agreement with FEMA's IPAWS program. We work on the last step: from the alert to the person.

Our focus is simple. How can a CAP alert become a signal people can notice through light, touch, or sound? CAP helps systems share a warning. But a message reaching a device does not mean it has reached the person. A siren needs hearing. A screen needs sight. For Deaf, DeafBlind, and blind people, warnings can still miss us.

We need to ask two questions. Can the person notice the warning? Can they understand what is happening and what to do? Reception is not communication.

Imagine you are inside a building. An alarm goes off. Fire? Tsunami? Tornado? Different dangers can require different actions. The alert may tell you which. One general signal does not. Getting attention is one step. Understanding is another.

Think of SOS. A rhythm can carry a learned, shared meaning. That idea inspired our work: the Three Senses Alerting Standard. It is a draft specification, published for anyone to review. Six families of danger, plus a test pattern, plus one defined fallback for anything we cannot place. One rhythm for each family. The same pattern through light, touch, and sound. Learn a pattern on one device. Recognise it on another.

Our application is called Deaflare. We are building it for Deaf, hard of hearing, and DeafBlind users. It is one implementation of the Three Senses approach.

Let me show you. Fire uses fast, short pulses. Water uses long, rolling waves. Watch the difference. That was water. Long, rolling waves. Now compare it with fire. Fast, short pulses. Two dangers. Two different patterns on the same phone. This video shows the visual pattern. Feeling the vibration needs a hands-on demonstration.

How does this connect to CAP? Start with the event information in the CAP alert. Our software maps that information to a hazard family. That family selects a rhythm. A water-related hazard maps to the water pattern. The original alert still carries the specific event and its instructions.

How would an originator say this in CAP? CAP 1.2 already gives us the parameter block. We propose one parameter. You may ask: CAP already has category. Why not just use that? Because the category Met can cover a flood and a tornado. Those need different rhythms. And the event string is free text. So the mapping must be written down and versioned. Our mapper reads the CAP event and category. It is unit tested against real National Weather Service event strings.

This is our proposed convention. It is not a CAP requirement. No schema change is needed. We can use CAP 1.2 as it stands. But each system must pass the parameter on, and the receiving software must understand it.

The rhythm is one part of the warning. It helps someone notice and recognise a family of danger. Then they need the message: What happened? Where? When? What should I do? That must stay accessible through the tools the person uses.

There are two limits I want to make clear. One. The rhythm identifies a danger family. It does not carry the full message. Water does not say which river, how high, or whether to climb or leave. The action comes from the alert.

Two. We cannot yet promise the same rhythm when the phone is locked or the app is in the background. That depends on the platform, the device, and our implementation. We need help testing and improving that last step. And for DeafBlind users especially, a vibration alone is not the full warning.

We can demonstrate the patterns. What we cannot do alone is test the whole path across your systems. Does the hazard mapping stay correct? Does the receiving software choose the intended pattern? What happens on a device that does not support it? These are questions we want to test with you.

Three requests. One. Review our mapping from CAP event information to hazard families. Choose an event you know well. Tell us where the mapping works and where it needs to change. Please send your feedback by 30 November 2026.

Two. Test passing the proposed parameter through your own system: from origination, to the receiving software, to the signal.

Three. Test with the people who will use the warning. Deaf, DeafBlind, and blind people must help design and test this. Check both halves: Can they notice the danger? Can they understand what to do?

Our draft specification is available to review and implement royalty-free. There is also a software library you can install. ideafe.org/standard

We want this work to be used and improved. CAP connects systems. Together, we can help those systems reach people. Deaf people know what happens when warnings fail us. We should be their engineers.

Please write your questions to my email. I will answer in writing. Emmanuel Jacq, International Deaf Emergency, emmanuel.jacq@ideafe.org

Thank you.