I built Richtext2Markdown in Angular to make rich text conversion feel simple and dependable. Accessibility was part of the build from the start, the output stays predictable, and the import and export flows hold up across browsers.
Product Outcome: It made writing and converting content less frustrating, especially for people using the keyboard or assistive technology.
This project focused on proving that accessibility and performance can both be first-class in rich-text tooling. Instead of retrofitting a11y after feature work, keyboard parity and semantic output were treated as release requirements from the beginning.
Rich text editors are notoriously hard to make accessible. Most popular libraries (CKEditor, TinyMCE) embed their own DOM structures and event handlers, making it difficult to control focus management, ARIA roles, or keyboard behavior. On top of that, I had strict startup-performance constraints that ruled out loading everything upfront.
Scope: Delivered an end-to-end editing surface: editor lifecycle, conversion/import/export pipeline, alert and theme systems, and cross-browser validation.
Ownership: Owned architecture, accessibility standards, implementation, and automated verification as a solo engineer.
Angular was selected for deterministic, testable UI behavior around editor state. Signals simplified synchronous interactions, while side-effectful flows stayed in focused services for import, alerts, and error handling.
The architecture centered on a service-driven core (`EditorService`) so editor lifecycle, conversion logic, and import/export rules remained testable and predictable. A headless editor stack gave full control over keyboard flow and semantics, while lazy-loaded concerns kept initial payload and interaction latency inside budget.
Rationale: I tried CKEditor first. It rendered beautifully but fighting its internal focus management to make custom keyboard shortcuts work was painful. TinyMCE had similar issues. Tiptap's headless architecture meant more setup work upfront, but I could control every ARIA attribute and keyboard interaction directly.
Outcome: Accessibility-compliant keyboard navigation validated by automated audits and cross-browser testing.
Rationale: Editor state like cursor position, active formatting, and panel visibility changes synchronously and frequently. Signals handled this cleanly without the subscription management overhead of RxJS. I kept RxJS for genuinely async work like network requests.
Outcome: Cleaner components with less boilerplate. A clear boundary between sync UI updates and async data flows.
Rationale: The URL import feature fetches content from third-party servers. During testing, simple retries on failure would sometimes hammer a slow server with requests. Backoff with jitter spaces out retries and avoids thundering herd effects.
Outcome: URL imports recover from transient failures without hanging the editor or overwhelming external servers.
Rationale: Syntax highlighting adds significant weight but is not needed on first render. Most users start typing before they paste code. Deferring the extension load kept TTI within budget.
Outcome: Protected startup performance and kept the app within release bundle budgets.
Before: N/A (new build)
After: Accessibility-compliant baseline
Impact: Full compliance validated by axe-core, not just automated checks
After: Consistently strong
Impact: Lazy extensions and bundle discipline
After: Within target budget
Impact: Deferred syntax highlighting and startup trimming
After: Within target budget
Impact: Code splitting and lazy imports
After: Within release budget
Impact: Deferred non-critical dependencies
After: Comprehensive automated suite
Impact: Unit tests, cross-browser E2E, and automated accessibility audits running in CI
Decision: Headless editor architecture
Risk: Prebuilt editor abstractions can hide focus/keyboard behavior and create accessibility regressions.
Change: Used Tiptap/ProseMirror with service-oriented orchestration for explicit interaction control.
Result: Accessibility-focused keyboard and conversion flows validated through automated and manual checks.
Source: Source
Decision: Cross-browser E2E matrix
Risk: Editor, import/export, and keyboard behavior can fail differently across browser engines.
Change: Validated critical flows across Chromium, Firefox, WebKit, Mobile Chrome, Mobile Safari, and Edge.
Result: Release confidence improved for cross-browser interaction parity.
Source: Source
Decision: Deferred non-critical startup work
Risk: Loading every editor feature upfront risks slower startup and lower responsiveness.
Change: Deferred non-critical modules and enforced startup performance budgets through iteration.
Result: Startup behavior stayed within release targets while retaining feature depth.
Source: Source
| Decision | Risk | Change | Result | Source |
|---|---|---|---|---|
| Headless editor architecture | Prebuilt editor abstractions can hide focus/keyboard behavior and create accessibility regressions. | Used Tiptap/ProseMirror with service-oriented orchestration for explicit interaction control. | Accessibility-focused keyboard and conversion flows validated through automated and manual checks. | Source |
| Cross-browser E2E matrix | Editor, import/export, and keyboard behavior can fail differently across browser engines. | Validated critical flows across Chromium, Firefox, WebKit, Mobile Chrome, Mobile Safari, and Edge. | Release confidence improved for cross-browser interaction parity. | Source |
| Deferred non-critical startup work | Loading every editor feature upfront risks slower startup and lower responsiveness. | Deferred non-critical modules and enforced startup performance budgets through iteration. | Startup behavior stayed within release targets while retaining feature depth. | Source |
Incident: A keyboard-navigation regression broke focus flow after a formatting toolbar refactor shortly before release.
Response: Stopped rollout, reproduced across browsers, and traced the issue to missing focus handoff in custom command handlers.
Rollback: Reverted the affected toolbar interaction patch and released with stable keyboard behavior while a corrected implementation was validated.
Prevention: Added focused accessibility regression tests and a pre-release checklist for keyboard and screen-reader interaction paths.
Stack