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

Email: [email protected]
Discord: Blind Researchers Channel (coming soon)
GitHub: aelira-cli issues
Mailing List: [email protected]

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 [email protected] 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 License Read CLI Docs

Related Resources

CLI Getting Started

Get started with Aelira CLI

LaTeX Accessibility

Command-line LaTeX accessibility workflows