Skip to main content
For Blind Researchers

Terminal Workflows for Blind STEM Researchers

How blind PhD researchers use Emacs, LaTeX, and CLI tools for accessible academic work. Real workflows, real solutions.

"Terminal is pure text... universally accessible. I can do anything in the terminal."

— Blind PhD in Astrophysics, r/accessibility

Why This Guide Exists

Most accessibility tools are designed by sighted developers for sighted users. They assume:

  • GUIs are easier than terminals (false for screen reader users)
  • Drag-and-drop is intuitive (impossible without vision)
  • Visual feedback is essential (meaningless to blind users)
  • LaTeX is the problem (it's actually the solution for blind authors)

This guide is different. It's based on real workflows from blind STEM researchers, particularly AudioThrive (blind PhD in Astrophysics) who shared their experiences on Reddit.

Our Approach

  • Terminal-first - CLI tools, not GUIs
  • Workflow integration - Fits into existing Emacs/LaTeX workflows
  • Screen reader compatible - Pure text output, no visual dependencies
  • Respects expertise - You know your workflow better than we do

Typical Blind PhD Workflow (Without Aelira)

Here's how AudioThrive described their daily research workflow:

Terminal Setup

# Text editing and coding

emacs manuscript.tex

# With Emacspeak for audio feedback

emacspeak-toggle-auditory-icons

# Compile LaTeX

pdflatex manuscript.tex

# Python data analysis

python analyze_spectra.py

# Version control

git commit -m "Add statistical analysis"

What Works

  • LaTeX source is fully accessible - Screen readers handle plain text perfectly
  • Terminal commands work seamlessly - No GUI dependencies
  • Compilation is straightforward - Same commands as sighted users
  • Python/data analysis accessible - Text-based output, numpy/pandas work fine

What Doesn't Work

  • Generated PDFs aren't accessible to readers - "journals will not accept braill"
  • Presentations are a nightmare - #1 pain point, PowerPoint/Keynote are GUI-only
  • Collaborator files are inaccessible - Receiving PDFs from sighted colleagues
  • Output format limitations - Can write accessible LaTeX, but can't ensure output is accessible

How Aelira Integrates (Terminal-First)

Aelira doesn't disrupt your workflow. It adds one command to your existing terminal routine:

LaTeX Accessible HTML/MathML

# Your existing workflow

emacs paper.tex

pdflatex paper.tex

# Add one command for accessible output

aelira latex-to-mathml paper.tex --output paper-accessible.html

# Equations converted to MathML

# Structure preserved

# ARIA labels added automatically

# Output: 98/100 accessibility score

Why This Works

  • You keep using LaTeX - No workflow change for you
  • Pure terminal command - No GUI, no mouse, no visual dependencies
  • Screen reader compatible output - Generates accessible HTML for readers
  • Works with Emacs - Can add to compilation hooks

Presentations (The #1 Pain Point)

AudioThrive said presentations are the worst accessibility problem, worse than PDFs. Here's why:

  • PowerPoint/Keynote require GUI manipulation
  • Beamer (LaTeX presentations) output isn't accessible
  • No good terminal-based presentation creation tools
  • Collaborators send inaccessible PPTX files

Aelira provides two solutions:

Option 1: Convert Beamer to Accessible HTML

# Create slides in Beamer (LaTeX)

emacs presentation.tex

# Convert to accessible HTML slides

aelira beamer-to-html presentation.tex --output slides/

# Each slide becomes an HTML page

# Keyboard navigation (arrow keys)

# Screen reader announces slide numbers

Option 2: Fix Collaborator PPTX Files

# Collaborator sends you slides.pptx

curl -O https://collaborator.edu/slides.pptx

# Generate accessible text summary

aelira pptx-to-text slides.pptx --output slides.txt

# Extracts all text content

# Generates alt text for images (AI)

# Describes slide layouts

# Terminal-readable format

Complete Research Paper Workflow

Here's how a blind astrophysics researcher might prepare a paper for publication:

# 1. Write paper in LaTeX (your normal workflow) emacs spectrum_analysis.tex pdflatex spectrum_analysis.tex # 2. Generate accessible HTML version for reviewers aelira latex-to-mathml spectrum_analysis.tex \ --output spectrum_analysis_accessible.html \ --include-pdf-link # 3. Create conference presentation emacs presentation.tex # Beamer slides aelira beamer-to-html presentation.tex --output slides/ # 4. Process supplementary materials aelira batch fix pdf ./supplementary/ --output ./accessible-supp/ # 5. Verify compliance before submission aelira validate spectrum_analysis_accessible.html # <Check className="w-4 h-4 text-[var(--feature-success-content)] inline-block" /> WCAG 2.1 Level AA: PASS # <Check className="w-4 h-4 text-[var(--feature-success-content)] inline-block" /> All equations have MathML: PASS # <Check className="w-4 h-4 text-[var(--feature-success-content)] inline-block" /> Images have alt text: PASS # <Check className="w-4 h-4 text-[var(--feature-success-content)] inline-block" /> Semantic structure: PASS # 6. Package for journal submission tar -czf submission.tar.gz \ spectrum_analysis.pdf \ spectrum_analysis_accessible.html \ supplementary/ \ slides/

Time Saved

Manual accessibility work: 40+ hours (if you could even do it)
With Aelira CLI: 5 minutes of terminal commands
Difference: You focus on research, not accessibility bureaucracy

Emacs Integration

Add Aelira to your LaTeX compilation hooks:

~/.emacs.d/init.el

;; Add Aelira compilation to LaTeX mode (add-hook 'LaTeX-mode-hook (lambda () (add-to-list 'TeX-command-list '("Aelira" "aelira latex-to-mathml %s --output %s-accessible.html" TeX-run-command nil t :help "Generate accessible HTML")))) ;; Keybinding: C-c C-a (compile with Aelira) (define-key LaTeX-mode-map (kbd "C-c C-a") (lambda () (interactive) (TeX-command "Aelira" 'TeX-master-file)))

Now you can compile accessible versions with C-c C-a.

Why Terminal > GUI for Accessibility

AudioThrive's insight: "Terminal is pure text... universally accessible."

GUI Tools

  • Require mouse/pointer
  • Visual layout dependencies
  • Screen reader compatibility varies
  • Drag-and-drop impossible without vision
  • Button labels often unclear
  • Modal dialogs interrupt workflow
  • Keyboard shortcuts inconsistent

Terminal Tools

  • Pure text input/output
  • Screen readers work perfectly
  • Scriptable and automatable
  • Keyboard-only (no mouse needed)
  • Command history with arrows
  • Pipes and redirection work
  • Same commands across systems

Real Quote from AudioThrive

"I can do anything in the terminal... The problem comes with GUI point and click stuff... I feel like modern software is getting less accessible for blind power users."

This is exactly why we built Aelira with a CLI-first approach. We respect your workflow.

Community & Resources

Documentation

Get Help

Thank You, AudioThrive

This guide wouldn't exist without AudioThrive's generosity in sharing their experiences on Reddit. Their insights about terminal workflows, LaTeX accessibility, and the presentation pain point fundamentally shaped how we built Aelira.

To AudioThrive and all blind STEM researchers: We see you. Your workflows matter. Your expertise matters. We're building tools that work the way YOU work, not forcing you to adapt to tools designed for sighted users.

Aelira is offering free academic licenses to blind STEM researchers. No application required - just email us at academic@aelira.ai with your .edu email.

Try Aelira CLI Today

Built by developers who understand that terminal accessibility isn't a limitation - it's a feature.

Request Academic LicenseRead CLI Docs

Related Resources

CLI Getting Started

Get started with Aelira CLI

LaTeX Accessibility

Command-line LaTeX accessibility workflows