ACCESSAI
Alarm and Haptics Concept Guide
A plain-language explanation and volunteer developer brief
Central principle: The certified alarm detects the danger. AccessAI communicates the verified alarm message in a form the user can perceive.
Prepared for AccessAI volunteer development discussions | August 2026
1. Purpose of This Guide
This guide consolidates the AccessAI discussion about connecting certified smoke, fire, and carbon monoxide alarms to haptic and other accessible notifications. It is intended to help explain the concept to volunteer developers in understandable language while keeping the safety and liability boundaries clear.
Important boundary: AccessAI is not intended to detect smoke, fire, or carbon monoxide. It is an accessibility communication layer that receives information from existing certified equipment and sends supplemental notifications.
How this fits the larger AccessAI vision
The original AccessAI concept routes information into user-selected formats, including captions, visual alerts, audio, Braille, haptic cues, structured summaries, tactile navigation, wearables, and emergency communication. Alarm integration is one future part of that larger multimodal platform, not the entire AccessAI idea.
2. The Idea in Plain Language
Think of a doorbell connected to a flashing light. The light does not detect the visitor. The doorbell detects the button press and tells the light to flash. AccessAI would use the same basic relationship for emergency information.
A certified alarm detects smoke or carbon monoxide and activates normally.
The alarm also sends an electronic status message through an approved interface.
AccessAI receives the message and identifies the event, location, urgency, and device status.
AccessAI routes the message to the outputs selected in the user’s accessibility profile.
The user receives the emergency through touch, movement, text, light, speech, or Braille.
3. The Three Essential Parts
The alarm remains independent
AccessAI should receive information from the alarm without controlling it. A failure in AccessAI must not silence, delay, disable, or otherwise interfere with the certified alarm. This one-way design is one of the most important safety principles.
4. What Haptics Mean
A haptic is information communicated through touch. A phone vibration is a simple haptic. AccessAI would use recognizable tactile patterns so the user can distinguish an emergency from an ordinary notification.
Not final standards: The patterns above describe the concept only. Emergency patterns would require standards review, research, and testing with Deaf and DeafBlind users before real-world deployment.
5. Accessible Outputs
A smartwatch alone is not enough. It may be removed, charging, disconnected, or too weak to wake someone. AccessAI should be capable of activating more than one selected output at the same time.
Smartwatch or haptic wristband for a person who is awake and wearing it.
Bed shaker or another purpose-designed tactile appliance for sleeping users.
Phone display with hazard, location, and action information in large readable text.
Flashing visual notification for users who can perceive it.
Refreshable Braille output for DeafBlind users.
Spoken output for blind or low-vision users when audio is appropriate.
Example emergency message
FIRE: Smoke detected in the kitchen. Leave the house now.
For a DeafBlind user, the system could combine a fire pattern, a location cue, and an evacuation cue, with fuller information sent to a connected Braille display. This is more meaningful than a generic vibration that only says that something happened.
6. How AccessAI Could Receive an Alarm Signal
Preferred: direct digital status
A compatible alarm or alarm system sends an electronic status such as “smoke detected,” “CO detected,” “test,” “low battery,” or “end of life.” A standards-based smart-home interface such as Matter may provide one possible route for compatible products. The exact integration would depend on the manufacturer, available interfaces, and applicable safety requirements.
Possible: approved physical interface
A qualified system integrator may be able to use a manufacturer-supported output, relay, or other approved interface to pass status information to the AccessAI connector. Volunteer developers should not improvise modifications to certified alarm hardware.
Supplementary only: sound recognition
A microphone could attempt to recognize the sound pattern of an existing alarm. This might improve compatibility in some settings, but sound recognition can fail because of distance, noise, microphone obstruction, or software error. It should not be treated as the primary life-safety connection.
7. Information AccessAI Needs
A useful alarm message would contain structured information such as:
AccessAI would use this information to decide which devices to activate, which haptic pattern to send, what visual or Braille message to display, and whether the system should escalate because a device did not respond.
8. User Accessibility Profiles
The user should choose how each type of message is delivered. A profile might contain:
Personalization should not allow a user to accidentally weaken or disable required emergency notifications. Emergency patterns and minimum escalation behavior would need controlled safety rules.
9. Reliability and Failure Design
Because alarm messages concern dangerous conditions, failure handling is part of the product, not an optional extra.
Local operation so an alarm can be communicated when internet or cloud service is unavailable.
Battery backup for the connector and appropriate receiving devices.
Immediate warning when a wearable, bed shaker, alarm interface, or local connection is unavailable.
A complete-chain test that verifies the alarm input, AccessAI processing, and every selected output.
Acknowledgment or delivery confirmation when a receiving device supports it.
Escalation to additional outputs if a wearable does not respond.
Secure event logs recording alarm receipt, delivery attempts, failures, and acknowledgments.
Controlled software updates with testing so an update cannot silently break compatibility.
Emergency messages prioritized over ordinary notifications.
No AccessAI function capable of silencing or delaying the original certified alarm.
The complete-chain test
A “Test my complete alert system” function should verify more than whether the phone app opens. It should check the alarm connection, AccessAI processing, wristband or watch, bed shaker, phone notification, Braille output, power status, and connection status.
10. Volunteer Developer Brief
Developer statement: We are building an accessibility notification layer that receives an alarm’s verified status and communicates it through touch, text, light, speech, or Braille. We are not building a smoke or CO detector, modifying certified alarms, or replacing code-required notification equipment.
What the software would do
Accept a structured alarm event from a simulator or approved interface.
Validate and classify the event type, location, urgency, and system state.
Read the user’s accessibility profile.
Send the correct message to one or more receiving devices.
Confirm delivery when possible and warn about failures.
Operate locally for critical functions.
Record test and delivery results securely.
Questions for the volunteer team
Which platform should host the first demonstration: Android, iPhone, or a local web interface?
Which smartwatch or haptic device offers the simplest documented developer interface?
How will the simulator represent fire, CO, low battery, test, and connection failure?
How will local operation work without internet access?
How will AccessAI determine that a receiving device is connected and responsive?
How can a bed-shaker demonstration be simulated without representing it as approved life-safety equipment?
What personal, location, and household information must be minimized or protected?
Which future steps require an alarm engineer, standards specialist, attorney, insurer, or certified manufacturer?
11. Safe First Prototype
The safest first version is a simulation. It demonstrates the accessibility communication method without connecting to real life-safety equipment or inviting anyone to rely on it during an emergency.
Required prototype label: Research prototype only. Not an emergency-warning system. Do not use for life-safety purposes.
12. Development Stages
13. Liability and Personal Protection
Plain answer: Providing AccessAI at no cost does not remove liability. A missed, delayed, incorrect, or confusing emergency notification could foreseeably contribute to serious harm.
The safest course is not to release a real alarm-connected system personally or casually. AccessAI can develop the need, interaction design, haptic concepts, user profiles, simulations, and Deaf/DeafBlind testing framework. A qualified life-safety partner should be responsible for the certified integration, validation, manufacturing, installation requirements, insurance, maintenance, and recall process.
What reduces risk
Keep the public-facing work at the simulation stage until qualified review occurs.
Do not modify certified alarm hardware or interfere with required notification functions.
Do not market the prototype as protecting users during a fire or CO emergency.
Use a formal legal entity and written volunteer roles before advanced development.
Obtain advice from a product-liability attorney and a fire-alarm or life-safety engineer before real integration.
Seek an established alarm, haptic-device, or accessibility manufacturer as the deployment partner.
Obtain appropriate insurance before public real-world use.
Document design requirements, testing, failures, changes, maintenance, and user instructions.
Retain certified audible, visual, and tactile alarm equipment required by law or code.
Make AccessAI supplemental unless and until qualified authorities determine otherwise.
What does not eliminate risk
Offering the service at no cost.
Calling the developers volunteers.
Placing a disclaimer in the application.
Forming a legal entity without appropriate design, testing, insurance, and professional review.
Saying the system is supplemental while promoting it in a way that encourages users to depend on it.
Federal volunteer-liability protections are limited, contain exceptions, and do not automatically protect an informal group. They also do not eliminate the potential liability of a nonprofit organization. Specific advice must come from a qualified attorney familiar with the planned organization, product, users, and jurisdiction.
Legal note: This guide provides planning information, not legal advice. No real alarm integration should be released or represented as ready for emergency use without qualified legal and life-safety review.
14. Recommended Partnership Model
AccessAI can remain a no-cost service for users while avoiding the role of an informal alarm manufacturer. The responsibilities can be divided as follows:
15. Suggested Opening for Volunteer Developers
Meeting script: I want AccessAI to provide a no-cost accessibility bridge between certified emergency alarms and people who cannot reliably hear or see them. The alarm will continue detecting the danger. AccessAI will receive a verified alarm status, identify the hazard and location, and send the information through haptics, a bed shaker, text, light, speech, or Braille according to the user’s needs. For now, we are building a safe simulation, not a deployable emergency product. We need to prove the communication concept first and involve qualified life-safety, legal, insurance, and manufacturing partners before any real-world use.
16. Developer Acceptance Checklist for the Simulation
The prototype is visibly labeled as a research demonstration.
No real emergency alarm or certified alarm circuit is modified.
Fire and CO simulations produce unmistakably different outputs.
The simulated event includes type, location, urgency, time, and device state.
At least two accessible output types can be demonstrated.
The prototype reports a disconnected receiving device.
The prototype can run its essential demonstration locally without internet.
Test results and delivery failures can be reviewed.
Privacy-sensitive information is minimized.
Documentation states what the prototype does and does not do.
17. Sources and Standards to Consult
These sources support the planning discussion but do not replace professional interpretation of the current codes, standards, listings, laws, or product requirements applicable to a particular design and installation.
Connectivity Standards Alliance. (2023). Matter 1.2 arrives with nine new device types and improvements across the board. Smoke and carbon monoxide alarms are among the supported device types. https://csa-iot.org/newsroom/matter-1-2-arrives-with-nine-new-device-types-improvements-across-the-board/
National Fire Protection Association. (2021). Fire alarm notification. https://www.nfpa.org/news-blogs-and-articles/blogs/2021/05/21/a-guide-to-fire-alarm-basics-notification
National Fire Protection Association. (2023). NFPA 72 technical committee materials addressing supplemental tactile notification appliances and activation through wiring or wireless methods. https://docinfofiles.nfpa.org/files/AboutTheCodes/72/72_A2024_SIG_AAC_SDminutes_12_23.pdf
U.S. Department of Justice. (2010). 2010 ADA Standards for Accessible Design, Section 702 and related residential communication provisions. https://www.ada.gov/law-and-regs/design-standards/2010-stds/
United States Code. (n.d.). 42 U.S.C. § 14503, limitation on liability for volunteers. https://www.law.cornell.edu/uscode/text/42/14503
Document table 1
| Part | Responsibility |
| Certified alarm | Detects smoke, fire, or carbon monoxide and produces the required alarm notifications. |
| AccessAI connector and software | Receives the verified alarm status, identifies the event and location, and routes the message. |
| Accessible receiving devices | Communicate the alert through a wristband, smartwatch, bed shaker, phone, light, speech, or Braille display. |
Document table 2
| Event | Illustrative tactile meaning |
| Smoke or fire | A forceful, unmistakable emergency pattern that repeats. |
| Carbon monoxide | A different forceful pattern so it cannot be confused with fire. |
| Severe weather or evacuation | A separate urgent pattern combined with location or instruction information. |
| Low alarm battery | A lower-priority maintenance pattern and a written message. |
| Connection failure | A clear warning that the accessibility link is not working. |
| Doorbell or ordinary notice | A gentle non-emergency pattern, clearly unlike life-safety alerts. |
Document table 3
| Field | Example |
| Event | Smoke detected |
| Location | Kitchen |
| Urgency | Emergency |
| Alarm identifier | Kitchen-01 |
| Time | 2:14 a.m. |
| System state | Active |
| Power or battery status | Normal |
Document table 4
| Event | Selected outputs |
| Fire | Wristband + bed shaker + phone text + Braille |
| Carbon monoxide | Wristband + bed shaker + phone text + Braille |
| Low battery | Phone text only |
| Connection failure | Wristband + phone text |
| Doorbell | Wristband only |
Document table 5
| Prototype control | Expected result |
| Simulate fire | Fire-specific haptic pattern and a screen message identifying the simulated location. |
| Simulate carbon monoxide | Different urgent haptic pattern and a clear simulated CO message. |
| Simulate low battery | Lower-priority maintenance cue and written warning. |
| Simulate device disconnection | Immediate accessibility warning that the receiving device is unavailable. |
| Run complete-system test | Checks each simulated input and selected output and records the result. |
Document table 6
| Stage | Scope and boundary |
| 1. Demonstration | Simulated alarm events only. No household or facility relies on AccessAI. |
| 2. Controlled research | Supervised testing in a controlled setting. Certified alarms and required notifications remain fully operational. |
| 3. Professional integration | Qualified life-safety engineers and an established manufacturer or integrator evaluate approved interfaces, standards, testing, cybersecurity, and failure behavior. |
| 4. Public deployment | Only after legal review, engineering validation, applicable certification or listing decisions, insurance, installation rules, maintenance plans, and user testing. |
Document table 7
| AccessAI leadership and community | Qualified life-safety partner |
| Define the accessibility problem and desired user experience. | Determine approved methods for connecting to certified equipment. |
| Design haptic meaning, accessibility profiles, and multimodal outputs. | Perform engineering verification, standards work, and reliability testing. |
| Organize Deaf and DeafBlind co-design and usability testing. | Carry appropriate product responsibility and insurance. |
| Build and demonstrate a non-emergency software prototype. | Handle manufacturing, installation requirements, maintenance, and recalls. |
| Protect the no-cost access mission and ethical requirements. | Deploy only when the complete system is judged ready for intended use. |