A layered accessibility project giving blind and visually impaired pregnant people an independent, private way to read a pregnancy test result. No sighted assistance required.
A blind or visually impaired person taking a home pregnancy test cannot independently read the result.
Every current path — line tests, digital tests, dip tests — produces a visual output only. Reading it means handing the test to someone else, describing a live camera feed to a volunteer service, or hoping for help. There is no standard, private, independent route.
This matters because pregnancy is one of the most private moments in a person's life. The gap is structural, not accidental — and it's solvable.
Be My Eyes / Aira — These connect blind users with sighted volunteers or AI via live camera. Technically usable, but they require streaming video of a pregnancy test to a third-party server or stranger. The privacy cost is prohibitive. These are valuable tools; this is not their right use case.
Clearblue Digital — The closest existing product. High-contrast LCD text ("Pregnant" / "Not Pregnant") helps low-vision users with magnification, but produces no audio, no haptic, no screen-reader output. The hardware for an audio edition is practically already inside the stick.
Voice assistants — Siri and Google Assistant describe what they see generally. They are not calibrated for the specificity required here: one line vs. two, or reading a small LCD in poor lighting. General is not good enough for this.
We work in layers: starting with what requires no new hardware, moving toward purpose-built solutions if the accessible path proves unreliable.
Point your phone at the test. The app reads the result using on-device ML — no image leaves the phone. Works with tests you already buy, on hardware you already own.
Clearblue Digital tests already contain a microcontroller and battery. Research track: can audio output be added via hardware revision, firmware change, or manufacturer collaboration?
A small clip-on accessory: holds the test in position, reads line intensity via colour sensor, outputs audio and haptic. No phone required. Estimated BOM under £5 at volume.
A false positive or missed positive is not acceptable. Any recognition system must meet a defined reliability threshold before it replaces the confidence a sighted person would have. The MVP ships with a confidence score and an explicit "re-check recommended" path below that threshold.
No image, result, or metadata leaves the device without an explicit user opt-in. On-device processing is a design requirement, not an optimisation. Any cloud fallback requires informed, active consent — not buried in a settings menu.
PregVoice reads the visual output of a completed test. The test itself is the regulated product. This distinction must be maintained in product design and all public language to stay clear of FDA (US) and MDR (EU) medical device classification.
Line tests are valid within a 3–10 minute window. Faint lines fade. The reader must work on first attempt — no boot sequences, no repositioning loops. Digital tests hold results for ~6 minutes, which gives more working time.
A bathroom at 3am looks nothing like one at noon. The recognition model must handle low light, overhead fluorescents, and warm incandescent reliably — all are common in real use conditions.
The people who need this most may not have the latest phone or disposable income for accessories. Layer 1 must work on mid-range Android from 2020 onwards. Layer 3 must be priced as an essential, not a peripheral. The tool itself is and will remain free.
A formal look at what can go wrong, how likely it is, and what we do about it. These are living entries — updated as the build progresses and new risks surface.
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| False positive result | Medium | Critical | Confidence threshold with mandatory "re-check recommended" prompt below it. Always advise confirming with a healthcare provider. Never present a result as certain. |
| False negative result | Medium | Critical | Same threshold mechanism. Faint-line detection is the hardest case — the model must be calibrated to err toward "inconclusive" rather than "negative" when confidence is borderline. |
| Privacy breach via image | Low | Critical | On-device ML only. No image is written to disk, no screenshot taken, no data sent anywhere. Camera frames are processed in memory and immediately discarded. Open source code is the verification mechanism. |
| Audio disclosure in public | High | High | Tap-to-hear model as the default (see Privacy Architecture). Result is never spoken without active user trigger. Earphone-only mode available. Haptic-first fallback available. |
| Language output error | Medium | High | Result strings professionally translated, not machine-generated. Clinical phrasing ("The test shows a positive result") is less culturally ambiguous than personal phrasing. Language set is user-selectable, not assumed from locale. |
| Accessibility failure on low-end hardware | Medium | High | Minimum spec target: Android 10, 2GB RAM, 8MP camera. Model benchmarked on low-spec devices before release. Graceful degradation: if confidence is persistently low, the app directs the user to an alternative approach rather than silently returning a bad result. |
| Regulatory misclassification | Low | High | Legal review before any public release. The "reads visual output, does not perform test" distinction is maintained in code (no modification of test hardware) and in all product language. Documented legal basis kept in the repository. |
| Training data bias | Medium | High | Dataset must cover all major test brands, lighting conditions, orientations, and phone camera quality levels. Results must not systematically vary by any of these factors. Equity testing is a release requirement, not a post-launch audit. |
| OS-level data retention | Low | High | App never requests camera roll permission — uses live camera feed only. No screenshot API called. On PWA: no localStorage, no sessionStorage, no IndexedDB write for results. On native: no Photos library access requested. |
| Project abandonment / hosting failure | Low | Medium | Open source under a permissive licence means any fork can survive the original going down. Hosting on GitHub Pages can migrate to GitLab Pages, Cloudflare Pages, or self-hosting — all free, all trivial for a static site. The tool runs entirely client-side; there is no server to lose. |
Health data is uniquely sensitive. A pregnancy test result is arguably among the most personal data a person can generate. The privacy model here isn't a policy document — it's a set of technical commitments built into the architecture from day one.
The app reads a live stream from the camera. No frame is written to disk, no screenshot is captured, no image file is created at any point in the process.
The classification model runs locally via TensorFlow.js (PWA) or ML Kit (native). The pixel data from the camera frame is processed in JavaScript memory or native memory buffers and immediately released. No API call is made. No network request is sent.
The classification result is passed to the audio/haptic output layer and displayed momentarily on screen. It is not stored in localStorage, sessionStorage, IndexedDB, or any other persistence mechanism. Closing the app leaves no trace of a result.
The app does not load any third-party scripts — no Google Analytics, no Sentry, no Hotjar, nothing. There are no network requests at all during normal use. This is verifiable by anyone: the source is open and the Network tab in DevTools will be empty.
Privacy policies are promises. Code is evidence. The repository is public specifically so any developer can verify that what the app claims to do is what it actually does. No closed binaries, no obfuscated code.
A key design question: should the app speak the result immediately, or should the user actively choose to hear it? Blurting a result aloud in a shared bathroom, a public toilet, or with a partner nearby strips the user of control at exactly the moment they need it most. Our answer: the user decides when they hear the result.
The RNIB's 2020 finding that blind users rejected audio deserves a closer reading. The prototypes they tested used a voice saying "Pregnant" or "Not Pregnant." The problem was not audio — it was linguistic content with inherent emotional weight. Any word carries meaning. "Pregnant" said in any voice, with any inflection, is a statement about someone's body and their future. Users did not want a machine making that statement at a moment they hadn't controlled.
A bleep has none of that. A single tone is not a word. It carries no linguistic valence, no implied emotion, no cultural connotation. It is information in the most neutral possible form. This is the same reason airport security uses tones not voices, and why medical monitors use alarms not announcements — neutrality by design.
The other concern the RNIB finding raises — which is separate and equally valid — is that not all pregnancy results are good or wanted. A positive result can mean joy, or devastation, depending entirely on context. A negative result can be a relief or a loss. The system cannot know which, and must not presume. A bleep says nothing about how to feel. A voice saying "Congratulations — you are pregnant" says everything. Even a clinical voice saying "The test shows a positive result" has linguistic content the user must process in the moment they receive unexpected or unwanted news. Tones sidestep this entirely.
Simple, unambiguous, learnable in one read. The number of bleeps maps to the number of possible outcomes — not a Morse pattern, not a rising/falling cadence, just a count. Counts are cognitively the simplest possible encoding and work across every language and culture.
Tone frequency, duration, and spacing will be validated with blind and low-vision users. The schema above is the starting hypothesis.
Phone haptic motors are not standardised. A flagship iPhone produces crisp, precise vibration. A mid-range Android from 2020 may have a motor that barely registers at full volume. A budget phone may not differentiate reliably between a long and short pulse. The user holding the phone at an angle, through a case, or with reduced sensation in their hand compounds this further.
Phone speakers are far more consistent. Even a cheap handset from 2018 will produce a clearly audible bleep through its speaker, and a clearly audible bleep through connected earphones. The gap in reliability between a £50 phone speaker and a £1,000 phone speaker is far smaller than the gap in their haptic motors.
Haptic remains in the design as a genuine fallback — for silent environments, for users with hearing impairments, for moments when earphones aren't available and the speaker isn't an option. But it is not the primary delivery mechanism, and the design acknowledges its device-dependency rather than assuming it works uniformly.
Haptic is a genuine and important output modality — for users in silent environments, with hearing impairments, or in situations where audio of any kind isn't possible. It is not a degraded experience; it is a different one. The caveat is that it is device-dependent in a way that tones are not, and the design must acknowledge this rather than paper over it.
Haptic motor quality varies significantly across phone models, ages, and price points. The patterns below are designed to remain distinguishable even on weaker motors — but user testing across a range of devices is required before these are finalised.
Haptic patterns will be tested across a range of phone models before finalising — including budget Android devices where motor quality is lowest. If patterns cannot be reliably distinguished on a defined minimum spec device, the design will be revised.
A tool for accessibility that only works in English is not an accessibility tool. Language is not a secondary concern — it is as fundamental as the audio output itself. Every person who needs this tool deserves to hear the result in their own language, delivered with cultural sensitivity.
Language detection approach: The browser's navigator.language suggests a starting point, but it reflects the device locale — not necessarily the user's spoken language. On first launch, PregVoice will present a language selection with a voice preview ("Tap to hear how the result will sound in this language") so the user confirms their preference explicitly. This choice is stored locally and does not require network access.
Prioritised by global spoken prevalence, Web Speech API support quality, and the blind/low-vision community representation in each language group.
Professional translation, not machine output. Result strings will be translated by native speakers with awareness of clinical and medical language in their cultural context. Machine translation is used for first-draft reference only — no string ships to production without human review.
Clinical phrasing, not personal. "The test shows a positive result" is less culturally variable than "You are pregnant." The latter carries weight that lands differently in different cultural contexts. Clinical language is more consistently interpretable across languages and more defensible from a regulatory standpoint. The user can customise phrasing in settings.
Grammatical gender. Many languages (French, Spanish, Arabic, German, Portuguese) have grammatically gendered constructions. The tool is not the place to make assumptions about the user's gender — result strings will be structured to be grammatically neutral where possible, or will offer an explicit preference setting where the language makes neutrality difficult.
RTL layout support. Arabic, Hebrew, Urdu, and Persian are right-to-left scripts. The UI must respond correctly to RTL direction — this is a layout requirement, not a post-launch fix.
PregVoice handles a sensitive health moment for a marginalised group. The standard "be nice to each other" code of conduct isn't enough here — we need explicit commitments about what we will and won't do, and those commitments must be enforced in code, not just in policy.
Every design decision is tested against a single question: could this harm the person using it? A false result, a privacy breach, a confusing output in a stressful moment — all qualify as harm. This axiom overrides convenience, speed to market, and cost.
The tool is free. There is no premium tier, no in-app purchase, no advertising, no data brokering, no partnership that generates revenue from user behaviour. If sustaining the project requires money, the source will be disclosed and users will never be the product.
Privacy promises are words. Code is evidence. The full codebase — including the ML model architecture, the inference logic, and every audio string — is publicly auditable. Anyone can verify that the app does exactly what it says and nothing else.
Blind and low-vision users must be involved at every major UX decision point — not as a post-launch survey, but as participants in the design process itself. Decisions made without this input will be revisited when it is available.
The recognition model must perform equally across all major test brands, lighting conditions, device camera qualities, and any other axis that could create a two-tier experience. If performance is systematically worse for any subgroup, the tool does not ship.
Pregnancy has different cultural weight in different communities. The tool must not assume a single emotional register — neither congratulatory nor clinical by default. Phrasing is neutral and configurable. No emoji, no exclamation marks, no assumptions about how someone might want to receive this information.
Public changelog, public roadmap, public issue tracker. Maintainers are named. Decisions are documented — including ones that turned out to be wrong. The devlog you are reading is part of this commitment.
A documented, public process for reporting security or privacy vulnerabilities. Reports are acknowledged within 48 hours. Confirmed issues are addressed before public disclosure. No reporter is penalised for finding a problem.
Contributors working in this space must understand the sensitivity of the domain. Contributions that trivialise the use case, introduce privacy-reducing features, or fail equity testing standards will not be merged regardless of technical quality.
An accessibility tool that costs money to use has already failed at its primary goal. Every architectural decision is evaluated partly through the lens of: does this create a running cost that would eventually force us to charge users or find commercial backing?
Why PWA first: The camera API and TensorFlow.js have matured enough to support reliable on-device inference in a browser context. PWA removes every barrier to access — no account, no download, no OS version restriction, no app store approval. It can be shared as a URL and used immediately. If Phase 1 proves that camera-based recognition is reliable enough, Phase 2 (native) may never be necessary.
What if GitHub changes their pricing? The app is pure static HTML, CSS, and JS. It can run from any file host — GitLab Pages, Cloudflare Pages, Netlify, or a self-hosted NGINX server. The open source licence means any fork can survive the original going down. The tool has zero lock-in to any single provider because it has zero server dependencies.
Open source without governance is a bus-factor problem. The project will maintain: a named maintainer group, a documented contribution process, a clear licence (MIT or Apache 2.0 — to be confirmed with legal review), a security disclosure policy, and a public changelog. Anyone can fork; the canonical version will be the one that maintains the ethics and privacy standards above.
Multiple independent teardowns (Foone/Hackaday 2020, wemakethings.net 2014, and others) have documented the PCB in detail. We no longer need to speculate about what's inside.
Optical system: 3–4 red/infrared LEDs illuminate the test strip from below. 1–2 phototransistors sit between them, measuring reflected light intensity from the strip lines. A plastic light baffle prevents direct LED-to-sensor coupling — the sensor only reads reflected light. The Weeks Indicator variant quantifies hCG level from the analogue intensity of the reflected signal, not just line presence or absence.
Display: A small segment LCD — not dot-matrix or OLED. Displays "Pregnant" / "Not Pregnant" in text segments plus a Smart Countdown progress bar. The positive result is held on screen for up to one month; negative for approximately 24 hours. Both are firmware timers running in MCU HALT mode, drawing microamp-level current. No separate discrete timing hardware exists.
Battery: Either a single CR1616 lithium coin cell (3V, ~55 mAh) or two LR44 alkaline cells in series (~3V, ~190 mAh) depending on variant. A passive piezo buzzer playing a short result beep would consume approximately 5–15 mC — less than 0.03% of the CR1616's capacity. Power is not the constraint.
The microcontroller is confirmed across multiple teardowns as either the Holtek HT48C06 or Holtek HT48R065B. Neither is a custom ASIC — both are standard off-the-shelf 8-bit OTP parts with full public datasheets.
The HT48C06 has native buzzer drive pins built into the silicon.
Pins PB0 and PB1 are a dedicated complementary buzzer driving pair with a built-in programmable frequency divider (PFD). Connecting a passive piezo element to these pins requires no external driver transistor and no additional circuitry. The hardware to make the stick beep on a result is already specced into the chip that is already inside the device.
The reason Clearblue Digital makes no sound is not a hardware limitation. It is a product decision.
OTP stands for one-time programmable. The firmware is burned into the chip at manufacture and cannot be read out or overwritten. Any third party — or SPD themselves for a new SKU — would need to write replacement firmware from scratch. The optical sensing algorithm, the threshold logic, the countdown timing: all of it would need to be reverse engineered and reimplemented. This is not impossible, but it is a significant engineering undertaking.
Some units use a COB (chip-on-board) package where the MCU die is encapsulated in an epoxy blob. In these variants the chip cannot be physically removed or identified without destroying the board — specifically designed to prevent modification.
The stick enclosure is moulded to extremely tight tolerances. A passive piezo disc (even a 10mm diameter, 0.3mm thick SMD type) adds physical volume that does not currently exist inside the stick. Any audio addition to an existing Clearblue Digital reading stick requires a new enclosure revision — new injection moulding tooling. The electronics are not the blocker. The plastic is.
Hardware modification (third party): Technically possible in principle — the chip has the buzzer pins — but OTP firmware means the sensing logic must be rewritten from scratch, COB variants cannot be touched, and the enclosure must be redesigned. Not a hobbyist project. A significant embedded systems engineering effort with regulatory complications for any commercial product.
Parallel MCU path: A small secondary microcontroller reads the LCD segment outputs optically and drives audio independently, without touching the original firmware. Avoids the OTP problem. Still requires enclosure modification to accommodate the extra electronics. The most realistic third-party hardware path.
Manufacturer partnership (recommended): SPD/P&G holds the cleared IP, manufacturing relationships, and existing 510(k) submissions. A new SKU — same strip, same optical reader, new enclosure with a speaker cavity, new firmware using the buzzer pins already in the chip — is the cleanest path. The incremental BOM cost of a passive piezo in mass production is approximately £0.10–0.30. Enclosure tooling change and firmware rewrite are one-time costs. The regulatory path is a new 510(k) with the existing Clearblue system as a strong predicate.
We are not the first people to work on this problem. Three significant prior efforts are documented — and one of them directly challenges our audio-first instinct in a way we have to take seriously.
The RNIB commissioned a prototype in 2020. The design team conducted user research with blind and visually impaired people before building anything. Their finding changed the output modality entirely: blind users did not want audio output.
The reason: any tone or voice has emotional valence. A beep sounds either positive or negative. A spoken result — however clinically framed — carries an emotional register. Users taking the test are often hoping for a specific outcome. They did not want a machine to telegraph that outcome through tone before they had a moment to process it themselves.
The RNIB prototype used tactile output — a mechanical button that physically raises when the result is positive. Emotionally neutral. Physically unambiguous. No sound, no screen. The prototype was never commercialised.
The APT design reached the same conclusion independently. The result is communicated via haptic vibration: one pulse for negative, two pulses for positive. No audio. The privacy and emotional neutrality reasoning matches the RNIB finding exactly. The design won the James Dyson Award in 2022 and remains at prototype stage.
AMY takes a different approach entirely — it is a saliva-based (not urine/hCG) test that uses NFC tap to phone. The phone's existing screen reader (VoiceOver or TalkBack) reads the result aloud. Audio output is delegated to infrastructure the user already has and has already configured to their preference. AMY won the Universal Design Grand Challenge in 2025.
The RNIB finding directly challenges our audio-first design. We cannot ignore it.
If the most thorough user research in this space found that blind users prefer tactile or haptic output over audio — specifically because audio has emotional valence — we need to take that seriously before we build anything. Our existing tap-to-hear model partially addresses this: the user controls the moment they receive the result rather than having it announced at the machine's timing. But "audio on demand" is still audio, and the RNIB finding suggests some users may not want it at all regardless of timing.
Revised position: Haptic output is not a fallback — it is a first-class output modality, and for some users it will be the preferred primary mode. The design must support haptic-only use as a complete, uncompromised experience. Community research (which we have not yet done) will determine whether the RNIB finding generalises or is specific to their user group. We do not design around this finding before doing our own research.
SPD Swiss Precision Diagnostics GmbH (the P&G entity behind Clearblue) holds patents covering the optical reader mechanism, the immunoassay system, the digital display integration, and the product industrial design. Key grants include WO2016156981A1 (digital optical reader) and US20150094227A1 (Weeks Indicator quantification).
SPD holds no patent covering audio output from a pregnancy test. This is a gap in their portfolio. It means the concept is not legally blocked from their side — but it also means anyone pursuing audio output (including SPD) needs to assess the third-party patent below.
"Diagnostic Test Device with Audible Feedback" — granted patent, not assigned to SPD. This patent describes a lateral flow assay device (explicitly including pregnancy tests) with an audio output component: an audio chip with stored digitised speech and a microcontroller that signals the chip to play an audible result. It covers both a beep/tone result signal and a spoken word announcement.
This is a freedom-to-operate concern for anyone adding audio to a lateral flow test reader — including our Layer 3 standalone reader device, and including SPD if they pursue a licensed audio edition. A freedom-to-operate analysis is required before any hardware with audio output on a lateral flow result is commercialised. This does not affect the smartphone Layer 1 (which is not a lateral flow device).
FDA (United States): Clearblue Digital is Class II, product code LCX, regulated under 21 CFR 862.1155. The complete kit — strip, sampler, and electronic reader — is cleared under a single 510(k) submission. Adding audio output to the reader is a user interface change to a cleared Class II IVD — this requires a new 510(k) submission. Estimated regulatory timeline: 12–24 months. Estimated cost: $250K–$1M depending on clinical data required. SPD holds clearances K060128, K200913, K213379, and others.
EU (IVDR): OTC hCG pregnancy tests are Class B under EU 2017/746 (IVDR Annex II and Rule 4). Class B requires Notified Body involvement. Adding audio would require updating the technical documentation and CE certificate via the Notified Body.
For PregVoice specifically: Our smartphone Layer 1 is an accessibility reading aid, not a modification to the test itself — it does not fall under these regulatory paths. Layer 3 (standalone reader accessory) sits in the same "reads visual output of completed test" category, but if designed to work with a cleared lateral flow device, it may attract regulatory scrutiny as an accessory to that device. Legal review before any Layer 3 commercialisation is required.
The right entry point for a partnership conversation is the Clearblue Innovation Centre, Bedford, UK (Stannard Way, Priory Business Park, Bedford MK44 3UP) — SPD's primary R&D facility. P&G has a documented accessibility commitments programme and disability inclusion function within their ESG structure. Engaging via that channel may open a faster route than a cold commercial approach.
The RNIB's 2020 prototype generated significant press. Clearblue's team is almost certainly aware of the unmet need. The question is whether the 510(k) regulatory cost and niche SKU economics make a business case. A compelling prototype and quantified market size data strengthen that conversation significantly.
Decision Starting narrow: one gap, one user group, one moment. "Making pregnancy tests accessible" is too broad to build from. "A blind pregnant person cannot independently read a home pregnancy test result" is buildable. Everything else follows.
Note Primary user: blind or severely visually impaired person taking a home pregnancy test alone. Secondary: low-vision users who can see something but not enough to read a faint second line confidently. Both share the same core need: a reliable, private, independent result.
Tried Mapped existing solutions: Be My Eyes, Aira, VoiceOver/TalkBack (can't describe test results), Clearblue Digital (visual text only). None provide independent, private result reading. Be My Eyes and Aira require a third party to see the result — not acceptable as a default for this use case.
Decision Phase 1 targets hardware everyone already owns. The recognition problem is constrained: we're classifying a small number of specific visual states (one line, two lines, digital text). That's well-defined classification, not open-ended computer vision. Tractable.
Issue Cloud vision APIs require uploading a photo of the test to a remote server. This image carries health information tied to a specific moment — arguably among the most sensitive data a person generates. Sending it anywhere, even with strong privacy policies, is the wrong default. Non-negotiable.
Pivot TensorFlow.js (PWA) and ML Kit (native) both run inference on-device with no data leaving the phone. For line detection and LCD text classification, the model complexity is low — well within what a mid-range phone from 2020 can handle offline. Privacy preserved by architecture, not policy.
Decision Auto-speaking on the phone speaker is never acceptable. A result announced in a shared bathroom, a public toilet, or with a partner in the next room removes the user's control at exactly the moment they need it most. Default: haptic signal when ready, audio only on tap. This is not a setting — it is the architecture.
Note Two optional audio modes beyond tap-to-hear: (1) Earphone mode — auto-speaks only if headphones are connected, silent on speaker. (2) Delay timer — user configures a pause (10–60s) between scan completion and haptic signal, giving time to move somewhere private or emotionally prepare. Both are opt-in. Neither changes the default.
Issue A false positive or false negative in this context isn't an inconvenience — it has real psychological and medical consequences. The model must ship with a confidence threshold below which it returns "inconclusive, re-check recommended" rather than a result. It must also never present a result as certain. The language is always "the test shows" not "you are."
Decision This risk is rated High likelihood if not actively mitigated — bathrooms are shared, speakers are loud. Addressed by the tap-to-hear model as the unconfigurable default. Earphone mode and delay timer are the user-level mitigations. Added to the risk register as a closed risk (architecturally resolved), not an open one.
Note
Potential gap: even if we don't save images, could the OS? Investigated: camera roll access is a separate permission from live camera access. The app will only request getUserMedia (live stream). No Photos library permission is ever requested. localStorage, sessionStorage, and IndexedDB will never receive a result value. Crash reporting is explicitly excluded.
Decision PregVoice reads the visual output of a completed test. It does not perform or interpret the diagnostic process. The test is the regulated product. The reader is an accessibility tool. This distinction is enforced in code (we never touch the test hardware) and in all public language. Filed as a standing constraint.
Decision
Browser locale is a hint, not a confirmed preference. First launch presents a language selection with a voice preview. The user confirms before proceeding. Choice stored in localStorage (language preference only — no health data). No network request required at any point.
Decision Result strings use clinical framing: "The test shows a positive result" not "You are pregnant." This is less culturally variable, grammatically easier to keep gender-neutral, and more defensible from a regulatory language standpoint. Personal phrasing is available as a user preference for those who want it.
Note All result strings require professional human translation with clinical/medical language awareness. Machine translation is a first-draft reference only. Priority languages for release: English, Spanish, Arabic, French, Portuguese, Hindi. RTL layout support (Arabic, Urdu, Hebrew) is a layout requirement, not a post-launch fix.
Decision Progressive Web App for Phase 1. No app store, no approval gatekeeping, no install friction. Shareable as a URL. GitHub Pages hosting is free. TensorFlow.js handles on-device inference. Service worker enables offline use — critical, because the app must work with no network connection during the reading window. If camera recognition proves unreliable in the browser, Phase 2 is native (React Native or Flutter) for better ML Kit/Vision framework access.
Note Hosting: GitHub Pages (free). Inference: on-device (free per use). Audio: Web Speech API (free). Analytics: none (by design). The only real costs are a domain (~£10/year) and professional translations (one-time per language, seeking grant/volunteer funding). The tool has no server, no database, no API calls — nothing to pay for month to month.
Decision The repository will be public and auditable from day one. Not as a contribution invitation (though contributions are welcome) but because users handling sensitive health data deserve to be able to verify what the tool does. Privacy policies are words. Code is evidence.
Decision The recognition model must be tested across all major test brands, lighting conditions, device camera qualities, and result types before any public release. If performance is systematically worse for any subgroup, the tool does not ship. Equity testing is a release requirement, not an audit. This applies to multilingual output too — "Inconclusive" in English and Arabic must both be as clear.
Note Ordered a Clearblue Digital reading stick for PCB examination. Working hypothesis: the electronics to support audio are simpler to add than a full redesign — the MCU, battery, and optical sensor are already there. Key unknowns: chipset, GPIO availability, firmware lock status. Findings will be documented here.
Note Draft haptic patterns established: long-short-short (negative), short-short-long (positive), six rapid (inconclusive), three long (error). Rationale: simple enough to learn once, distinctive enough not to misread under stress, compatible with standard phone vibration APIs. Pending validation with blind and low-vision community members before finalising.
Done Multiple independent teardowns confirm the Clearblue Digital reading stick contains a Holtek HT48C06 or HT48R065B — a standard off-the-shelf 8-bit OTP MCU, not a custom ASIC. Full public datasheets available. This is a significant finding: it means the chip can be sourced, studied, and potentially replaced. It is not a black box.
Done The HT48C06 has a dedicated complementary buzzer drive pair (PB0/PB1) and a built-in programmable frequency divider — native silicon features for driving a piezo element directly, no external driver required. The hardware to make the stick beep on a result is already specced into the chip inside the device. The reason Clearblue Digital makes no sound is a product decision, not a hardware limitation. This changes the manufacturer partnership conversation significantly.
Issue The stick enclosure is moulded to extremely tight tolerances. Adding any speaker or piezo disc — even a thin SMD type — requires a new enclosure revision and injection moulding tooling. The PCB also uses COB (epoxy blob) packaging in some variants, making chip-level modification impossible without destroying the board. The electronics are not the constraint. The plastic is. Any Layer 2 partnership conversation needs to lead with this: a new enclosure SKU, not a modification to the existing one.
Issue OTP (one-time programmable) means the firmware is burned at manufacture and cannot be read out or overwritten. Any new firmware — for a partnership audio SKU or a parallel MCU approach — must be written from scratch. The optical sensing algorithm, threshold logic, and countdown timing all need to be reverse engineered and reimplemented. The chip is standard and purchasable; the firmware knowledge is not transferable. This is the largest engineering unknown for any hardware path.
Issue The RNIB's 2020 accessible pregnancy test prototype conducted user research before building. Finding: blind users did not want audio output. Reason: any tone or voice has emotional valence — it sounds either positive or negative — and users did not want a machine to telegraph the outcome before they had a moment to process it. The RNIB chose tactile output (a mechanical button that raises on positive). The APT (James Dyson Award 2022) reached the same conclusion independently and used haptic vibration. This is a direct challenge to our audio-first design that we cannot design around without our own community research.
Pivot The RNIB and APT findings shift haptic from "audio fallback" to "first-class output modality." The tap-to-hear model we designed (haptic signals ready, audio only on tap) partially addresses the valence concern — the user controls the emotional moment, not the machine. But some users may never want audio regardless of timing. The design must support haptic-only as a complete, uncompromised experience. This does not remove audio from the design; it removes audio as the assumed primary output. Community research will determine the right default.
Note Three documented accessible pregnancy test projects exist: RNIB (tactile, 2020), APT (haptic, 2022), AMY (NFC to phone screen reader, 2025 award). None are commercially available. AMY's approach — delegating audio to the phone's existing screen reader via NFC — is elegant: it leverages infrastructure the user has already configured to their preference, rather than building a new audio system from scratch. Worth considering for our Layer 1 alongside direct camera recognition.
Issue WO2014158850 / AU2014241791B2 ("Diagnostic Test Device with Audible Feedback") is a granted patent covering audio output on a lateral flow assay device — explicitly including pregnancy tests — not assigned to SPD. Anyone adding audio to a lateral flow test reader, including our Layer 3 standalone device and any SPD audio SKU, needs a freedom-to-operate analysis against this patent before commercialisation. Our smartphone Layer 1 is not a lateral flow device and is not affected. Filed as a standing legal risk — not blocking research, but blocking any commercial hardware launch without FTO clearance.
Note SPD's patent portfolio covers the optical reader, immunoassay, display integration, and industrial design. There is no SPD/Clearblue patent on audio output from a pregnancy test. This means the concept is not legally blocked from their side. A partnership conversation about an audio SKU is not walking into their existing IP. The conversation needs to address the third-party WO2014158850 FTO question, but that's a solvable problem (license or design around), not a veto.
Note FDA classification confirmed: Class II, product code LCX, 21 CFR 862.1155. The electronic reader and strip are cleared together under a single 510(k). Adding audio output to the reader is a user interface change — not a minor modification under 21 CFR Part 820. A new 510(k) is required, using the existing Clearblue system as predicate. Timeline: 12–24 months. Cost: $250K–$1M. EU path: IVDR Class B, Notified Body update required. This is the realistic regulatory cost SPD would face for an audio SKU. It is not prohibitive for a company of P&G's scale, but it needs a clear commercial case to justify it.
Decision Primary target for a partnership conversation: Clearblue Innovation Centre, Bedford, UK (Stannard Way, Priory Business Park). This is SPD's R&D home. Secondary route: P&G's disability inclusion and ESG function, which has a documented accessibility commitments programme and may open faster than a cold commercial approach. The RNIB's 2020 work generated significant press — Clearblue's team is aware of the need. The conversation needs: (1) a working prototype demonstrating the concept, (2) quantified market size data, (3) a regulatory summary showing the 510(k) path is clear. We do not yet have all three.
Pivot Closer reading of the RNIB finding: their prototype used a voice saying "Pregnant" or "Not Pregnant." The issue was not that sound played — it was that words carry inherent emotional weight. Any voice, however clinical, is making a statement about the person's body and future at a moment they may not be ready for. A bleep carries no linguistic content, no cultural connotation, and no implied emotional register. The RNIB found against voice. They did not test tones. The design implication is not "no audio" — it is "no words."
Note This point cannot be designed around — it must be designed from. A positive result can be the best news of someone's life or devastating news depending entirely on context: wanted pregnancy, unwanted pregnancy, fertility treatment, contraceptive failure, post-miscarriage monitoring. A negative result is equally context-dependent. The system cannot know which situation it is in and must not presume. A bleep says nothing about how to feel. A voice saying anything — however carefully worded — says something. Tones are the only audio format that stays genuinely neutral.
Decision Primary audio output is now simple tones: 1 bleep = positive, 2 bleeps = negative, 3 bleeps = inconclusive, 4 rapid bleeps = error. Count-based, not cadence-based — a count is the simplest possible encoding, learnable in one read, universal across languages and cultures. No linguistic valence. No words. The user receives the count and applies their own emotional context to it. Voice announcement remains available as an explicit opt-in for users who want it, using clinical framing, but is not the default and will never auto-play.
Issue Phone haptic motors are not standardised. A flagship device produces precise, differentiated vibration. A budget Android may not reliably distinguish between a long and short pulse — and the user holding the phone through a case, at an angle, or with reduced hand sensation compounds this. Phone speakers are far more consistent across device tiers: a £50 phone speaker and a £1,000 phone speaker both produce a clearly audible bleep. The gap in haptic motor quality across devices is much larger than the gap in speaker quality. This is why tones are primary and haptic is secondary — not because haptic is less important, but because it is less reliable as a universal baseline.
Decision Final output hierarchy: (1) Tones — primary audio, neutral, universal, device-consistent, played through earphones for privacy or phone speaker on user tap; (2) Haptic — secondary, genuine fallback for silent environments and hearing impaired users, acknowledged as device-dependent; (3) Voice — opt-in only, clinical phrasing, user-configured language, never the default; (4) Auto-announce — does not exist in any form. All outputs are triggered by user action, never by the system. The tap-to-hear model applies to tones, not just voice.