PaperlayerView exact revision on arXiv

Source-linked AI summary

Tact: A Zero-Cost, Browser-Based Pipeline for On-Demand Tactile Braille Storybooks

Iliano Fasolino

arXiv:2609.12272v1cs.HCcs.CY

TL;DR

Braille stories with tactile illustrations have historically depended on specialized labor, while an in-browser model download can itself create a substantial access barrier. Tact offers browser-based story generation with a hosted accelerator and an offline-capable path; the hosted path produced stories quickly with reported page-fit outcomes. The authors argue that the integrated system is within reach of an ordinary family, while emphasizing that real-reader testing remains necessary.

  • Problem

    A first-use in-browser model download of roughly 1.8 gigabytes can burden households and schools with slow, metered, or shared connections and exclude mobile devices.

    Source: B. What an Independent… · p. 4

  • Method

    Tact uses a browser-based pipeline that works without a server, with a hosted language-model path as an accelerator rather than a dependency.

    Source: §VI · p. 4, C. Holding a Key Without Holding a… · p. 5

  • Results

    A median 0.8 seconds, with 81 percent of stories fitting two cards and 92 percent leaving every page acceptably filled, followed prompt and provider-specific target changes on Groq.

    Source: D. Measured Effect of the Hosted Path · p. 6

  • Takeaways & Limitations

    The authors argue that browser-based inference, deterministic braille translation, hand-built tactile illustrations, and consumer FDM printing are mature and cheap enough to put personalized stories within reach of an ordinary family with a 70 euro printer.

    Source: §XIX · p. 16

    No blind or low-vision readers have tested Tact’s outputs, so tactile legibility, dot comfort, and illustration clarity remain unverified with real readers.

    Source: §XVIII · p. 16

Abstract

from arXiv · show

Braille literacy among blind school-age children has fallen sharply, in part because producing illustrated braille pages still requires specialized software and trained labor. We present Tact, a browser-based pipeline that converts a spoken or typed story idea into printable braille with a matching raised tactile illustration, without an account or mandatory cost and with an offline-capable path. The paper documents the engineering history of the system: its sighted-operator ethical model; hardware rationale for consumer fused-deposition modeling; physical braille geometry and printer calibration; local, hosted, and fallback language-model paths; a deterministic Grade 1 braille translator; verified page layout and pagination; a 93-shape hand-drawn tactile illustration library; and synthesized sound design for a voice-first interface. We report engineering verification, ethical commitments, limitations, and the work required before the system is ready for real blind and low-vision readers.

I. INTRODUCTION

Braille story production remains labor-intensive and leaves blind children with few personalized book options; Tact addresses the content gap through an integrated browser-based pipeline.

I. INTRODUCTION

  • Producing illustrated braille pages has required trained transcribers and specialized software, leaving children’s braille-book catalogs small and rarely personalized to their interests.The paper contrasts this with the many print-book options available to sighted children.Source: §I · p. 1
  • Braille literacy among legally blind U.S. school-age children fell from roughly 50 percent in 1960 to roughly 8.5 percent today, tracking mainstreaming and reduced teacher density.The paper distinguishes literacy through decoding from consumption through audio tools.Source: Figure 1 · p. 1, §I · pp. 1–2
  • Tact targets the content gap, not teacher supply, by turning a spoken or typed story idea into a printable braille page with a raised illustration in a browser tab.Teacher supply is explicitly outside the paper’s scope.Source: §I · p. 2

II. RELATED WORK

  • BrailleRAP and Tactipix rely on dedicated self-buildable hardware, while AltCanvas requires manual scene composition and tactile-svgdreamer requires a CUDA-capable GPU,.Tact instead composes pages automatically from a one-sentence prompt.Source: §II · p. 2
  • TaleVision was evaluated with children and demonstrates AI-assisted tactile content in a controlled study, but remains a research prototype rather than a deployable parent- or school-facing system.TactileNet supplies a purpose-built tactile-graphics dataset, not an end-user tool [7].Source: §II · p. 2
  • No related system combines personalized story generation, automatic braille translation, and tactile illustration in a tool deployable without an account or bill.Tact’s contribution is the integrated pipeline and its engineering decisions, rather than one novel algorithm.Source: §II · p. 2

III. TARGET POPULATION AND ETHICAL FRAMING

Tact is designed for young blind and low-vision readers, operated by a sighted adult, with community engagement and accessible, standards-based design treated as core requirements.

A. Primary and Secondary Users

  • The primary audience is blind and low-vision children roughly aged four to ten; deafblind people are secondary users for whom braille may be the only literacy channel.The project states that later braille acquisition becomes harder after the primary age window.Source: A. Primary and Secondary Users · pp. 2–3

B. Explicit Scope Boundaries

  • Tact is not targeted at deaf users or blind adults; it prioritizes young blind children in the literacy-acquisition window.The paper presents this narrow scope as a deliberate design choice.Source: B. Explicit Scope Boundaries · p. 3

C. The Operator Model

  • A sighted parent, teacher, or caregiver operates the software and printer, while the blind child is the reader.The printer is conceived as a shared household or classroom appliance; the interface is designed to be screen-reader-accessible and voice-first.Source: C. The Operator Model · p. 3

D. Nothing About Us Without Us

  • Blind and deafblind users and their representative organizations have not yet been consulted, and direct engagement is a prerequisite before the tool is called ready.The paper treats this as a real limitation, not a post-launch optional step.Source: D. Nothing About Us Without Us · p. 3

IV. DESIGN REQUIREMENTS

  • Requirements include a free path without dedicated GPU hardware, permissive licensing, bilingual Italian and English support, ISO 17049:2013 geometry, and hardware-agnostic STL output.A capable GPU may improve AI-written stories, but it must not be required for a working baseline.Source: §IV · p. 3

V. HARDWARE RATIONALE

  • FDM printing was chosen over braille embossing for durable, repeatedly read artifacts despite slower production; TPU 95A is the default, PETG a washable rigid alternative, and PLA is excluded.Recycled PETG is documented as a near-zero-cost option.Source: §V · pp. 3–4

VI. SYSTEM ARCHITECTURE

Tact runs as a single browser application that turns a spoken or typed story idea into printable braille with a matching tactile illustration. Its model path was revised after the first-use in-browser download proved a substantial access barrier for the intended households and schools.

VI. SYSTEM ARCHITECTURE

  • The single-file, no-backend application automatically turns a one-sentence story idea into Grade 1 braille and a matching tactile illustration, then lays out a preview and exports a binary STL for FDM printing.The braille and tactile-graphics paths execute in parallel before page layout and export.Source: §VI · p. 4, Figure 2 · p. 5
  • A structured data contract specifies story metadata, ordered pages, and optional typed illustration elements so capable backends can use the same downstream translation, illustration, layout, and export logic.The default in-browser model does not use this schema directly; it remains the target contract for more capable backends.Source: §VI · p. 4
  • The architecture avoids a recurring server bill and account setup, and can run from local disk or a static host without connectivity.The paper also notes that a server can be discontinued and that local files can be copied to portable storage for schools.Source: §VI · p. 4

A. Why the First Version Refused a Remote Server

  • The first version rejected a cloud-hosted model because it adds recurring cost, requires an API key, and sends stories about identifiable children through a third-party server.Instead, the system loaded a small model in the browser and ran inference on the visitor’s hardware.Source: A. Why the First Version Refused a… · p. 4

B. What an Independent Reimplementation Exposed

  • The in-browser model’s roughly 1.8-gigabyte first-use download is a heavier barrier than an account for target households and schools on slow, metered, or shared connections, and it almost entirely excludes mobile devices.The original analysis identified server costs but underweighted the cost of the in-browser alternative.Source: B. What an Independent… · p. 4
  • Story generation now tries a hosted model first, falls back to the in-browser model if unavailable, rate limited, or removed, and uses the reader’s own words if the device cannot run that model.The two fallback paths were retained from the earlier design.Source: B. What an Independent… · p. 5, Figure 2 · p. 5

C. Holding a Key Without Holding a Server

Tact isolates the hosted-model key in a stateless, restricted proxy, while keeping hosted generation optional despite provider instability. Provider-specific prompts and fallbacks shape the hosted experience, and runtime model selection avoids trusting misleading hardware signals.

C. Holding a Key Without Holding a Server

  • The proxy holds the API key, accepts a one-line idea, and returns prose; its fixed brief, origin restrictions, and stateless design limit misuse and data retention.The story brief stays inside the proxy, so callers cannot repurpose the endpoint as a general-purpose language model.Source: C. Holding a Key Without Holding a… · p. 5
  • On the hosted path, the one-line idea reaches a third party; the browser-based path transmits nothing and remains usable when the proxy is disabled.The hosted path is an accelerator rather than a dependency.Source: C. Holding a Key Without Holding a… · p. 5

D. Measured Effect of the Hosted Path

  • A free model tier alternated between six-to-nine-second replies, thirty-second replies, and timeouts, motivating a provider fallback chain with a 12-second first-provider timeout and a 40-second fallback timeout.The provider's API layer continued returning errors quickly, locating the fault in inference capacity rather than a client-correctable issue.Source: D. Measured Effect of the Hosted Path · p. 6
  • After provider-specific prompt changes, Groq output reached a median 0.8 seconds, with 81 percent of stories fitting two cards and 92 percent leaving every page acceptably filled.The revised brief used a longer example and provider-specific sentence counts and word targets.Source: D. Measured Effect of the Hosted Path · p. 6
  • At up to eight concurrent requests, 31 of 32 succeeded; 15 of 40 burst requests were rate-limited, while sequential use at about five requests per minute had no rejections.The paper states that the fallback chain makes a surge a slower story rather than no story.Source: D. Measured Effect of the Hosted Path · p. 6

E. Adaptive Model Selection and a False Positive Worth Documenting

  • Automatic model selection caps at the three-billion-parameter tier because reported adapter memory and deviceMemory values can misidentify ordinary laptops; the eight-billion tier requires informed manual choice.The system profiles WebGPU at runtime and falls back to smaller tiers when initialization fails.Source: E. Adaptive Model Selection and a… · p. 6

F. From a Structured Schema to Prose

Tact replaced a fragile structured-output approach with plain story text and deterministic client-side processing, after testing exposed failures in both the small model and its planned Liblouis translation dependency. The revised prompt improved the illustrated example, and the pipeline preserves a usable printable result when model generation is unavailable.

F. From a Structured Schema to Prose

  • The smallest in-browser model often ignored structured fields or truncated its response, causing parser failures and fallback to a fixed demonstration story.The redesign requests plain story text and moves pagination and illustration selection into deterministic client-side logic.Source: F. From a Structured Schema to Prose · pp. 6–7

G. Measured Effect of the Model Size and Prompt Changes

H. Graceful Degradation Without a Demonstration Trap

  • Without hosted generation or usable WebGPU, Tact paginates the visitor's own words, translates them to braille, matches an illustration by keyword, and exports a printable STL.A fixed demonstration is reserved for cases where every other step fails outright.Source: H. Graceful Degradation Without a… · p. 7

A. The Original Plan

  • The original plan was to use Liblouis compiled to WebAssembly, a mature, standards-aligned translator retained as the expected choice for a future locally installable package.The paper describes Liblouis as the correct default instinct, rather than a technology to casually reinvent.Source: A. The Original Plan · p. 7

B. A Root-Cause Investigation

  • The tested browser build's Grade 1 table failed to compile, alternative tables could abort the WebAssembly heap, and a null result could leave the application waiting indefinitely.The English table failure silently returned null; downstream decoding then threw inside a worker thread without resolving or rejecting the waiting promise.Source: B. A Root-Cause Investigation · p. 7

C. The Pivot

  • Tact replaced the unusable WebAssembly build with a pure-JavaScript lookup table because Grade 1 is an exact uncontracted one-character-to-one-cell mapping.The replacement works offline, including from a local file, and removes roughly 1.6 megabytes of WebAssembly download.Source: C. The Pivot · p. 7

D. Why Grade 1 Is the Right Default, Not a Limitation

The system’s design evolved through implementation and expert feedback, balancing page capacity against readable braille lines. Grade 1 is the developmentally appropriate default for beginning English readers, not a convenience-driven reduction.

D. Why Grade 1 Is the Right Default, Not a Limitation

  • English defaults to Unified English Braille Grade 1 because the intended readers are beginners; Grade 2 contractions follow Grade 1 fluency.Italian braille has no contracted Grade 2 form.Source: D. Why Grade 1 Is the Right Default,… · p. 8

B. An Honest Account of a Layout That Changed Three Times

  • A hidden portrait-versus-square page mismatch was corrected by making the page 150 by 150 millimeters and sharing one coordinate object between preview and exporter.The mismatch became visible when the preview rendered at true millimeter scale; the shared object prevents this category of preview-print divergence from recurring.Source: B. An Honest Account of a Layout That… · p. 8

C. The Denser Corner Layout and Balanced Pagination

  • The shipped corner layout fit about 37 words per page using seven 21-cell rows and six 12-cell rows beside a 54-by-54-millimeter illustration zone.Fig. 3 gives the dimensions and shared coordinate constants for that layout, which was later revised.Source: C. The Denser Corner Layout and… · p. 8, Figure 3 · p. 9
  • Evenly balancing words across pages removed sparse final cards but left five of twelve intermediate cards incomplete, so the fix was withdrawn.Because each page is a separate card and intermediate cards lack illustrations, the change replaced one sparse card with two incomplete ones.Source: C. The Denser Corner Layout and… · p. 8

D. A Third Revision from Expert Field Feedback

  • An experienced braille-reading educator found the corner layout’s short lines uncomfortable, prompting a revision to full-width braille lines above a bottom illustration band.The revised illustrated page holds about 14 percent fewer cells, a trade accepted to remove short lines and favor readability.Source: D. A Third Revision from Expert Field… · pp. 8–9

E. Sizing Text to a Page That Cannot Be Resized

Language-model word-count prompting could not reliably hit the narrow range needed to fill cards, so the pipeline handles fit through layout and pagination. The final-card illustration and shared preview/export geometry address sparse cards and trust in the printed result.

E. Sizing Text to a Page That Cannot Be Resized

  • The model varied by about ±20 words against a roughly ±5-word target window, and prompt revisions did not converge on reliable length control.The window for filling two cards was approximately 63–70 words in Italian and 74–80 in English; conformity shifted between 17 and 43 percent.Source: E. Sizing Text to a Page That Cannot… · pp. 9–10
  • The revised illustrated layout removes short lines by placing full-width braille above a full-width picture band, at a cost of about 14 percent of braille cells.The figure compares the earlier corner layout with the revised band layout.Source: Figure 4 · p. 10
  • 76 percent of stories fit two cards under the final scheme, with no sparse card left without a picture and every pre-final page full.Pages fill greedily; when remaining text fits the shorter illustrated profile, the final card receives an illustration in the unused band.Source: E. Sizing Text to a Page That Cannot… · p. 10

F. Why Preview-Print Fidelity Is Not a Cosmetic Concern Here

  • A preview-print mismatch is a trust failure when the sighted operator has no independent way to verify the physical page for the blind child.One shared coordinate object drives both preview and STL output to make fidelity structural rather than dependent on repeated manual checks.Source: F. Why Preview-Print Fidelity Is Not a… · p. 10

A. Illustration as a Second Literacy Channel, Not Decoration

C. A Frequency Study of Fairy-Tale and Bedtime-Story Subjects

The tactile library was expanded and audited against common story subjects and fingertip recognizability, while illustration matching and physical geometry were engineered for printable output. The reported dot measurements come from one reference build, not a multi-run calibration.

C. A Frequency Study of Fairy-Tale and Bedtime-Story Subjects

  • The library grew from roughly 46 categories to 93 hand-drawn shapes after a story-subject gap analysis and two expansion passes.A tactile audit found eleven shapes that needed redraw; four further high-frequency subjects were then added.Source: C. A Frequency Study of Fairy-Tale and… · p. 11

D. From Substring Matching to Whole-Word Bilingual Matching

  • Illustration matching tokenizes bilingual story text and matches whole words, avoiding substring errors such as Italian mare incorrectly triggering re, “king.”The revised matcher was checked against test phrases in Italian and English before shipping.Source: D. From Substring Matching to… · p. 11

E. From Vector Shape to Printable Relief

  • The SVG illustration is rasterized, aspect-preserved, and centered; dark pixels become pillars raised to 1.0 mm, 0.15 mm above designed braille dots.The height difference lets a fingertip distinguish illustration from text; the approximately 0.60 mm printed braille height is from a reference build.Source: E. From Vector Shape to Printable Relief · p. 11

A. Braille Dot Geometry

  • Printed dot diameter was 1.3 mm (−19%) and dot height was 0.60 mm (−29%) against designed values of 1.6 mm and 0.85 mm, respectively.The measurements fall within the ISO 17049:2013 tolerance band, but the over-design is documented from a single reference print, not a multi-run calibration.Source: A. Braille Dot Geometry · pp. 11–12, Figure 5 · p. 12, Table V · p. 12

B. Base Plate and Separation Rules

The page and sound design combine structural separation, material guidance, and deliberately synthesized audio. The printed cross-section distinguishes braille text from tactile illustration by relief height.

B. Base Plate and Separation Rules

  • The page uses a continuous 0.5 mm base plate with rounded corners, 4.4 mm gaps between braille cells, 3 mm illustration clearance, and 5 mm edge clearance.These separations are enforced structurally throughout the design.Source: B. Base Plate and Separation Rules · p. 12

C. Material Guidance

  • TPU 95A is the documented material recommendation, printed at about 220°C nozzle and 50°C bed temperatures at 25–35 mm/s without supports.The documentation presents it as the standard recommendation for clean dot definition; the geometry is self-supporting.Source: C. Material Guidance · p. 12

A. Why Sound Was Treated as a First-Class Design Surface

  • Every meaningful application state has a corresponding deliberately composed sound because the microphone-led, screen-reader-accessible interface treats audio as a first-class surface.Source: A. Why Sound Was Treated as a… · p. 12

B. Synthesis, Not Samples

  • Runtime Web Audio synthesis uses oscillator and noise-buffer primitives rather than sample files, adding no download weight and working offline.Exponential attack-and-release envelopes create softer onset and decay than linear ramps.Source: B. Synthesis, Not Samples · p. 12

C. The Sonic Vocabulary

  • The figure contrasts domed braille dots designed at 0.85 mm with flat-topped illustration relief at 1.0 mm, 0.15 mm higher for touch distinction.The measured post-shrinkage braille height is approximately 0.60 mm.Source: Figure 6 · p. 13

D. The Underlying Principle

Tact’s sound and visual design distinguish story content from interface feedback and help users understand the application without looking at the screen. Representative scenarios show how the pipeline serves different devices and input needs.

D. The Underlying Principle

  • A consistent sound grammar gives users who are not looking at the screen an accurate mental model of the application’s actions.Rising pitch signals beginnings, falling pitch signals endings, an ascending arpeggio marks story readiness, and filtered noise marks physical actions such as typing and printing.Source: D. The Underlying Principle · p. 13

XIII. VISUAL AND TYPOGRAPHIC DESIGN

  • The visual design separates story text from interface labels through distinct serif and monospaced type, while the result screen evokes a physical printed page.Warm offwhite tones and near-black ink keep the palette restrained.Source: §XIII · p. 13

A. A Parent With a Capable Laptop

  • A capable laptop can download and cache a three-billion-parameter model, generate a sensory-rich story, and produce a two-page illustrated braille book in under a minute of active waiting.Source: A. A Parent With a Capable Laptop · p. 14

B. A Classroom on Older Hardware

C. A Deafblind Child Working With a Caregiver

D. A Bilingual Household

The section describes multilingual and offline-capable use, engineering checks of the running pipeline, and boundaries on what those checks establish. It also contrasts Tact’s deployment choices with prior systems.

D. A Bilingual Household

  • Switching between Italian and English exercises the interface strings, braille tables, and illustration keywords in both languages rather than treating either language as secondary.Source: D. A Bilingual Household · p. 14

E. A Rural or Low-Connectivity Setting

  • After opening, translation, illustration matching, layout, and STL export work offline; story writing needs a network only for the hosted path, while the in-browser model needs connectivity for its initial download.Source: E. A Rural or Low-Connectivity Setting · p. 14

F. An Older, More Independent Reader

A. Verification Performed to Date

  • Every tested Italian and English braille comparison matched the original text exactly, and tested exports, pagination, shape selection, and full pipeline runs passed their stated checks.A 200-word input split into ten pages of twenty words with no words lost; no unhandled runtime errors were observed in a full run.Source: A. Verification Performed to Date · pp. 14–15, Table VIII · p. 15

B. What This Evaluation Does and Does Not Establish

C. Comparison With Prior Systems

  • Compared with BrailleRAP, FDM trades faster embossing for durable pages and general-purpose hardware; compared with cloud-only generation, in-browser inference avoids recurring cost and data transmission.The in-browser path requires a one-time model download and is bounded by the reader’s hardware, while the hosted path sends one sentence off-device.Source: C. Comparison With Prior Systems · p. 15

XVI. THE ZERO-COST ARCHITECTURE IN FULL

The section sets out a zero-cost default architecture and ethical commitments around privacy and dependency. It also identifies unfinished work, especially direct testing with blind and low-vision readers.

XVI. THE ZERO-COST ARCHITECTURE IN FULL

  • No step in the default pipeline gates basic functionality behind payment, and an optional larger-model or user-supplied API path is not required for basic use.Source: §XVI · p. 15

XVII. ETHICAL CONSIDERATIONS

  • The paper acknowledges that design choices so far were made without direct input from blind or deafblind users, leaving that input an open liability.Source: §XVII · p. 15
  • Default on-device story generation means there is no server-side log of the stories families generate, what a child asked for, or when.Source: §XVII · p. 15
  • A single static file, permissive license, and zero-cost default path avoid dependence on a subscription, a company continuing to operate, or an account remaining available.Source: §XVII · pp. 15–16

XVIII. LIMITATIONS AND FUTURE WORK

  • No blind or low-vision reader testing has occurred, so claims about comfort, legibility, and illustration clarity rest on standards and engineering checks rather than direct user observation.The paper identifies this as the most important open item before any claim of readiness.Source: §XVIII · p. 16
  • Batch-generation packaging, interpoint printing, and print-farm integration remain future work; the browser application itself is functional.The paper also notes that interpoint braille is harder in extruded 3D geometry than on paper embossers.Source: §XVIII · p. 16
  • Manual model selection and two-pass draft-and-revise generation are deferred; the latter was set aside to keep the default experience fast.Source: §XVIII · p. 16

XIX. CONCLUSION

  • The paper argues that browser-based inference, deterministic braille translation, a hand-built tactile illustration library, and consumer FDM printing are mature and inexpensive enough to put personalized stories within an ordinary family’s reach.The conclusion identifies a 70 euro printer and engineering-level verification, while treating a blind child’s hands-on assessment as the remaining finish line.Source: §XIX · p. 16

APPENDIX

The appendix specifies braille-cell geometry and defines braille grades and key technical terms used in the paper.

APPENDIX

  • A standard braille cell has six potential dots in a two-by-three grid, with dots 1–3 on the left and 4–6 on the right.The project uses 2.5 mm between dot centers within a cell, 6.0 mm between cell starts, and 10.0 mm between line baselines.Source: APPENDIX · p. 16
  • Grade 1 braille is uncontracted, one cell per character; Grade 2 is contracted English braille with roughly 180 shorthand contractions.Grade 1 is the standard for beginning readers and the only form of Italian braille.Source: APPENDIX · p. 16
  • FDM is layer-by-layer molten-filament printing, TPU and PETG are flexible and rigid filaments, STL is a widely understood 3D model format, and WebGPU accesses graphics hardware from a browser.Source: APPENDIX · p. 16
Loading 2609.12272v1…