Leveraging Generative AI to Design Accessible Interactive Visualizations for Undergraduate Mathematics: A Six-Phase Workflow

arXiv cs.AI Papers

Summary

This paper develops and evaluates a six-phase workflow using generative AI to create accessible interactive visualizations for undergraduate mathematics without programming, achieving WCAG 2.2 Level AA compliance across multiple tools.

arXiv:2608.28601v1 Announce Type: new Abstract: Interactive visualizations support conceptual understanding in undergraduate mathematics, but building them has required programming expertise most instructors lack. Using a design-based research approach, we develop, deploy, and evaluate a six-phase workflow (Foundation, Customization, Mathematical Depth, Application, Accessibility, Pedagogical Control) that uses generative AI to build WCAG~2.2 Level~AA compliant visualizations without programming. The six phases structure every prompt, scaffold the AI's code generation, and define where human verification is applied. We ask whether the structure reliably yields correct and accessible tools, whether it runs both backward (reverse-engineering prompts from a finished tool) and forward (generating a tool from a plain-language idea), and what verification each phase requires. Across four deployed tools spanning calculus, multivariable calculus, and differential equations, we evaluate mathematical correctness against closed forms, accessibility through automated and manual screen-reader testing, and the errors that recurred. The structure produces structurally complete first-pass tools, but human verification remains mandatory at every phase: each output must be checked for mathematical correctness, accessibility, and pedagogical fit before the next phase begins. The workflow is platform-independent and serves both instructors and students.
Original Article
View Cached Full Text

Cached at: 09/01/26, 12:29 PM

# Leveraging Generative AI to Design Accessible Interactive Visualizations for Undergraduate Mathematics: A Six-Phase Workflow
Source: [https://arxiv.org/html/2608.28601](https://arxiv.org/html/2608.28601)
\\DocumentMetadata

lang=en, pdfversion = 2\.0, pdfstandard = ua\-2, tagging=on, tagging\-setup=math/setup=mathml\-SE

Mahesh Sunkula and Kuan\-Hua \(Joseph\) Chen

###### Abstract\.

Interactive visualizations support conceptual understanding in undergraduate mathematics, but building them has required programming expertise most instructors lack\. Using a design\-based research approach, we develop, deploy, and evaluate a six\-phase workflow \(Foundation, Customization, Mathematical Depth, Application, Accessibility, Pedagogical Control\) that uses generative AI to build WCAG 2\.2 Level AA compliant visualizations without programming\. The six phases structure every prompt, scaffold the AI’s code generation, and define where human verification is applied\. We ask whether the structure reliably yields correct and accessible tools, whether it runs both backward \(reverse\-engineering prompts from a finished tool\) and forward \(generating a tool from a plain\-language idea\), and what verification each phase requires\. Across four deployed tools spanning calculus, multivariable calculus, and differential equations, we evaluate mathematical correctness against closed forms, accessibility through automated and manual screen\-reader testing, and the errors that recurred\. The structure produces structurally complete first\-pass tools, but human verification remains mandatory at every phase: each output must be checked for mathematical correctness, accessibility, and pedagogical fit before the next phase begins\. The workflow is platform\-independent and serves both instructors and students\.

###### Key words and phrases:

generative AI, interactive visualization, mathematics education, accessibility, educational technology, constructivism

###### 2020 Mathematics Subject Classification:

97U50, 97D40, 97C70

## 1\.Introduction

As mathematics instructors, we face a persistent gap between what we can visualize mentally and what we can communicate to students\. The gradient perpendicular to level curves, a saddle point’s instability, the way a linear map shears a parallelogram: these are vivid to us and opaque on a whiteboard\. Interactive visualizations close that gap: students manipulate parameters in real time and build the geometric intuition that supports their analytical work\. The problem has always been that creating such tools requires programming expertise most of us do not have and time none of us can spare\.

Generative AI changes this\. We can now describe what we want in the same language we use with a colleague and receive working code\. The key, we found, is structure\. A single large prompt produces mediocre results\. Breaking the task into six focused phases, each with a clear deliverable validated before the next begins, produces tools that are mathematically correct, pedagogically purposeful, and fully accessible\. This article documents that six\-phase workflow and the two modes in which we use it\.

### 1\.1\.The pedagogical challenge

The visualization problem extends across the undergraduate curriculum\. In differential equations, students who can write down a solution formula often cannot describe what it looks like\. In linear algebra, matrix transformations become meaningful when students watch a map stretch and shear a region in real time\. The research literature supports what we observe: students who engage with interactive visualizations develop deeper conceptual understanding than those who work exclusively with symbolic representations\[[20](https://arxiv.org/html/2608.28601#bib.bib20),[17](https://arxiv.org/html/2608.28601#bib.bib17),[9](https://arxiv.org/html/2608.28601#bib.bib9)\]\. Duval’s theory of semiotic representation argues that mathematical understanding requires coordination between symbolic, graphical, numerical, and verbal registers\[[8](https://arxiv.org/html/2608.28601#bib.bib8)\]; interactive tools support exactly that coordination\.

Not all visualizations help, however: poorly designed tools can introduce extraneous cognitive load and hinder rather than support understanding\. Pedagogically principled design remains essential even when AI handles the implementation\.

### 1\.2\.Research questions and approach

We treat the workflow as the object of a design\-based research \(DBR\) study\. DBR develops and refines an intervention through iterative cycles of design, deployment, and analysis in authentic instructional settings, producing both a usable artifact and transferable design principles\[[7](https://arxiv.org/html/2608.28601#bib.bib7),[2](https://arxiv.org/html/2608.28601#bib.bib2)\]\. That is exactly the situation here: each tool was built, deployed in a real course context, and revised across the six phases, and each cycle surfaced design principles about where the AI succeeds and where human expertise remains indispensable\. Our unit of analysis is the workflow itself, evaluated through the tools it produces\.

We address three research questions:

- •RQ1\.Does the six\-phase structure reliably yield visualizations that are mathematically correct and WCAG 2\.2 Level AA compliant?
- •RQ2\.Does the workflow operate in both directions \(backward, reverse\-engineering a phase\-aligned prompt set from a finished tool, and forward, generating a tool from a plain\-language pedagogical idea\), and is it independent of the particular AI platform?
- •RQ3\.What human verification does each phase still require, and what categories of error recur?

To answer them we provide explicit phase\-by\-phase prompts from four deployed tools, an account of the two\-directional pipeline with worked examples, and an evaluation of mathematical correctness, accessibility compliance, and pedagogical fit, organized phase by phase\. The contribution is both practical and methodological: instructors gain adaptable prompts and a verification protocol, while the field gains a set of design principles for AI\-assisted educational tool creation\. Our aim is that a reader finishes ready to describe a first visualization idea to an AI system and use the result, with a clear\-eyed sense of what must be checked before it reaches students\.

## 2\.Theoretical Background

### 2\.1\.Visualization in mathematics learning

Tall and Vinner’s\[[21](https://arxiv.org/html/2608.28601#bib.bib21)\]distinction between concept definition and concept image illuminates why visualization matters: students frequently build concept images that conflict with formal definitions, particularly in multivariate calculus, where geometric intuition is hard to develop from symbolic manipulation alone\. Dynamic visualizations enrich concept images by providing varied examples and making abstract relationships visible\[[20](https://arxiv.org/html/2608.28601#bib.bib20)\]\. Empirical support is strong: Martínez\-Planell and Trigueros\[[15](https://arxiv.org/html/2608.28601#bib.bib15)\]found that coordinating algebraic and geometric representations of two\-variable functions is strongly correlated with conceptual understanding, and that dynamic software facilitates this coordination\. Weber and Thompson\[[24](https://arxiv.org/html/2608.28601#bib.bib24)\]similarly document how students’ images of two\-variable functions and their graphs shape, and often constrain, the conceptual understanding they are able to build\.

### 2\.2\.Active learning and student\-created representations

Constructivist theory holds that learners build understanding through active engagement rather than passive reception\[[16](https://arxiv.org/html/2608.28601#bib.bib16),[22](https://arxiv.org/html/2608.28601#bib.bib22)\]\. When students create visualizations, they must articulate mathematical relationships precisely enough for the AI to implement them, a form of mathematical communication that surfaces implicit gaps and misconceptions\[[11](https://arxiv.org/html/2608.28601#bib.bib11)\]\. The productive struggle involved in this process is itself pedagogically valuable\[[10](https://arxiv.org/html/2608.28601#bib.bib10)\]\. The capacity to describe a mathematical relationship precisely enough for a machine to act on it also connects to broader efforts to define computational thinking for mathematics and science classrooms\[[25](https://arxiv.org/html/2608.28601#bib.bib25)\]\.

### 2\.3\.Accessibility and Universal Design for Learning

Universal Design for Learning principles advocate for accessible materials from the outset\[[18](https://arxiv.org/html/2608.28601#bib.bib18),[4](https://arxiv.org/html/2608.28601#bib.bib4)\]\. Most web\-based mathematics materials fail basic accessibility standards\[[1](https://arxiv.org/html/2608.28601#bib.bib1)\], and mathematics accessibility requires particular attention to conveying relationships through non\-visual channels\[[12](https://arxiv.org/html/2608.28601#bib.bib12)\]\. WCAG 2\.2\[[23](https://arxiv.org/html/2608.28601#bib.bib23)\]provides concrete success criteria\. This workflow enables instructors to specify accessibility requirements in natural language, with AI implementing the technical details, though human testing with assistive technology users remains essential\[[19](https://arxiv.org/html/2608.28601#bib.bib19)\]\.

### 2\.4\.Generative AI in education

Large language models offer real opportunities for educational content generation, with important caveats about accuracy and overreliance\[[13](https://arxiv.org/html/2608.28601#bib.bib13)\]\. Code generation research demonstrates high success rates for well\-specified tasks but reveals that generated code may contain subtle bugs or fail on edge cases\[[5](https://arxiv.org/html/2608.28601#bib.bib5),[14](https://arxiv.org/html/2608.28601#bib.bib14)\]\. Specificity, iterative refinement, and domain knowledge significantly improve output quality\[[6](https://arxiv.org/html/2608.28601#bib.bib6)\]\. Our six\-phase structure is a direct response to these findings: it maximizes AI effectiveness while preserving human oversight at every stage\.

## 3\.The Six\-Phase Workflow

The six\-phase workflow addresses a fundamental challenge in AI\-assisted development: giving an AI system a single complex prompt produces mediocre results\. Breaking the same task into six targeted phases, each with a clear deliverable and a validation step, consistently produces tools that are mathematically correct, pedagogically purposeful, and fully accessible\. The phases are constant whether you are prompting interactively \(Stage 1\) or asking the AI to generate all six prompts from a pedagogical idea \(Stage 2\)\.

### 3\.1\.Phase structure and rationale

Phase 1: Mathematical Foundation and Core Interactivity\.Establish the fundamental mathematical concept and basic user interaction\. Focus on correctness of mathematical implementation without additional features that could complicate debugging\. The deliverable is a working visualization that accurately represents the core mathematical relationship, even if pedagogically incomplete\.

Phase 2: Customization and User Control\.Add mechanisms for users to modify parameters, select from preset examples, or input custom functions\. This phase transforms a demonstration into an exploration tool\. Validation logic for user inputs \(domain restrictions, syntax checking\) is implemented here to prevent downstream errors\.

Phase 3: Mathematical Depth and Connections\.Incorporate related mathematical concepts that deepen understanding of the core idea: derivative information, related geometric objects \(tangent planes, normal vectors\), or abstract relationships \(orthogonality, optimization directions\)\. The goal is to connect isolated concepts into a coherent mathematical framework\.

Phase 4: Applications and Algorithmic Connections\.Bridge abstract mathematics to applications or computational methods: optimization algorithms, numerical integration, physical simulations\. This phase makes concrete the student question “when would we use this?”

Phase 5: Accessibility and Inclusive Design\.Implement WCAG 2\.2 Level AA compliance: keyboard navigation with visible focus indicators \(SC 2\.4\.7\), minimum touch target sizes of44×4444\\times 44CSS pixels \(SC 2\.5\.8\), ARIA live regions for dynamic content announcements, skip\-to\-content links, andprefers\-reduced\-motionsupport\. Accessibility is addressed here rather than retrospectively, but it should never be treated as optional\.

Phase 6: Pedagogical Control and Scaffolding\.Add layer management or progressive disclosure: checkboxes or toggles that let instructors build up complexity incrementally during a lecture\. Reset functionality allows students to experiment freely\. This phase transforms a tool that displays mathematics into one that teaches it\.

### 3\.2\.Tool selection: Claude and Gemini

We used both Anthropic’s Claude and Google’s Gemini\. Each has strengths: Claude excels at React\-based component architecture, accessibility implementation, and Three\.js 3D graphics; Gemini is particularly strong with Plotly\.js visualizations and HTML5 Canvas animations\. Both produce high\-quality results when prompts follow the six\-phase structure\. The technology stack matters more than the platform\. This holds in Stage 2 as well: both Claude and Gemini can generate the full six\-phase prompt set from a plain\-language description of a pedagogical idea and then build the tool from it\. We deliberately carried the two Stage 2 examples end\-to\-end on different platforms, Example 3 entirely with Gemini and Example 4 entirely with Claude and Claude Code, to show that the phase structure, not the choice of model, is what carries the work \(see §[6](https://arxiv.org/html/2608.28601#S6)\)\.

## 4\.Interactive Visualizations

Two worked examples follow: a Directional Derivatives and Gradient Vectors explorer \(§[4\.1](https://arxiv.org/html/2608.28601#S4.SS1)\) and a Dynamical Systems Phase Portrait Laboratory \(§[4\.2](https://arxiv.org/html/2608.28601#S4.SS2)\)\. Both were built using the six\-phase methodology, working through each phase iteratively with multiple prompts until each deliverable was correct and verified\. Section[5](https://arxiv.org/html/2608.28601#S5)documents the reverse\-engineered six\-phase prompts that reproduce each tool from scratch\. Section[6](https://arxiv.org/html/2608.28601#S6)describes how those verified prompts enabled Stage 2, with two additional worked examples\.

A note on naming: the paper presents four independent example tools, numbered 1 through 4\. Examples 1 and 2 \(in this section and §[5](https://arxiv.org/html/2608.28601#S5)\) are the Stage 1 tools, built interactively and then reverse\-engineered into prompts\. Examples 3 and 4 \(in §[6](https://arxiv.org/html/2608.28601#S6)\) are distinct tools built the other direction, in Stage 2, from an idea to a generated prompt set to a finished visualization\.

### 4\.1\.Example 1: Directional Derivatives and Gradient Vectors

#### Pedagogical context

Anyone who has taught multivariable calculus knows the moment: students who can compute∂f/∂x\\partial f/\\partial xand∂f/∂y\\partial f/\\partial ygo quiet when asked what those quantities mean geometrically\. Martínez\-Planell and Trigueros\[[15](https://arxiv.org/html/2608.28601#bib.bib15)\]trace downstream struggles with optimization and Lagrange multipliers directly to weak geometric intuition at this stage\. The tool was built to address that gap\.

#### Learning objectives

Visualizez=f​\(x,y\)z=f\(x,y\)with user\-controlled viewing angles; read∂f/∂x\\partial f/\\partial xand∂f/∂y\\partial f/\\partial yas slopes of coordinate cross\-sections; connect the tangent plane to the linear approximation; understand∇f\\nabla fas perpendicular to level curves; computeD𝐮​f=∇f⋅𝐮D\_\{\\mathbf\{u\}\}f=\\nabla f\\cdot\\mathbf\{u\}for arbitrary unit vectors; run gradient ascent as a live optimization demonstration\.

### 4\.2\.Example 2: Dynamical Systems Phase Portrait Laboratory

#### Pedagogical context

Differential equations courses have the mirror problem\. Students can produce explicit solution formulas yet often cannot describe what those solutions look like\. Phase portraits are the standard remedy, but hand\-drawn portraits are slow and inflexible\. An interactive tool removes that friction entirely\.

Students must read the vector field as encoding instantaneous velocity, understand trajectories as integral curves, and connect Jacobian eigenvalues at a critical point to the phase portrait geometry on screen\. Done well, this stability intuition transfers to physics, engineering, and biology\.

#### Learning objectives

Readd​x/d​tdx/dtandd​y/d​tdy/dtas velocity components; observe how initial conditions shape long\-term behavior; connect Jacobian eigenvalues to local geometry; read nullclines as the curves where each component of the velocity vanishes; classify equilibria; and contextualize ideas in preloaded systems spanning the standard equilibrium types: a linear saddle, a stable spiral, the pendulum, the Van der Pol and Duffing oscillators, and the Lotka–Volterra predator\-prey model\.

## 5\.Reverse\-Engineered Six\-Phase Prompts

Once each tool in §[4\.1](https://arxiv.org/html/2608.28601#S4.SS1)and §[4\.2](https://arxiv.org/html/2608.28601#S4.SS2)was complete and verified, we presented the finished visualization to the AI and asked it to write one prompt per phase that would regenerate the tool from scratch\. The prompts below are those reconstructions\. They are not verbatim records of the original development conversations, which involved multiple iterative exchanges per phase; rather, they are distilled starting points that colleagues can adapt and build from\.

### 5\.1\.Example 1: Directional Derivatives and Gradient Vectors

Phase 1: Mathematical Foundation and Core Interactivity\.

Prompt:“Create an interactive HTML/JavaScript tool using Plotly\.js to visualize a 3D surfacez=f​\(x,y\)z=f\(x,y\), specifically the paraboloidz=x2\+y2z=x^\{2\}\+y^\{2\}\. Include two sliders to control the coordinates\(x0,y0\)\(x\_\{0\},y\_\{0\}\)of a movable point on the surface\. Display two traces: one showingf​\(x,y0\)f\(x,y\_\{0\}\)parallel to thex​zxz\-plane \(thexx\-direction cross\-section\), and another showingf​\(x0,y\)f\(x\_\{0\},y\)parallel to they​zyz\-plane\. Include numerical displays of∂f/∂x\\partial f/\\partial xand∂f/∂y\\partial f/\\partial yevaluated at\(x0,y0\)\(x\_\{0\},y\_\{0\}\)\.”

Result\.Gemini produced complete HTML with embedded JavaScript implementing the Plotly surface, slider controls, and correctly computed partial derivatives\. A slider range of\[−5,5\]\[\-5,5\]caused visual clutter; narrowing to\[−2,2\]\[\-2,2\]resolved this\.

Validation\.Partial derivative values verified against hand calculations at several points; trace curves confirmed to align visually with the surface cross\-sections\.

Phase 2: Customization and User Control\.

Prompt:“Add a tangent plane at\(x0,y0,f​\(x0,y0\)\)\(x\_\{0\},y\_\{0\},f\(x\_\{0\},y\_\{0\}\)\)via the linear approximationL​\(x,y\)=f​\(x0,y0\)\+fx​\(x−x0\)\+fy​\(y−y0\)L\(x,y\)=f\(x\_\{0\},y\_\{0\}\)\+f\_\{x\}\(x\-x\_\{0\}\)\+f\_\{y\}\(y\-y\_\{0\}\)\. Add a dropdown with preset functions \(Paraboloid,x2\+y2x^\{2\}\+y^\{2\}; Saddle,x2−y2x^\{2\}\-y^\{2\}; Gaussian,e−x2−y2e^\{\-x^\{2\}\-y^\{2\}\}; Wave,sin⁡\(x\)​cos⁡\(y\)\\sin\(x\)\\cos\(y\)\) and a text input for user\-defined functions in JavaScriptMathsyntax with syntax validation\.”

Result\.Tangent plane rendered as a separate Plotly surface\. Try\-catch validation provided readable error messages for malformed input\.

Validation\.Confirmed first\-order contact at\(x0,y0\)\(x\_\{0\},y\_\{0\}\), tested each preset, and deliberately entered malformed expressions to verify error handling\.

Phase 3: Mathematical Depth and Connections\.

Prompt:“Add computation of the directional derivativeD𝐮​fD\_\{\\mathbf\{u\}\}f\. Include a slider forθ∈\[0,2​π\]\\theta\\in\[0,2\\pi\]defining a unit vector𝐮=⟨cos⁡θ,sin⁡θ⟩\\mathbf\{u\}=\\langle\\cos\\theta,\\sin\\theta\\rangle\. Display∇f=⟨fx,fy⟩\\nabla f=\\langle f\_\{x\},f\_\{y\}\\rangleas a blue arrow in thex​yxy\-plane with length proportional to‖∇f‖\\\|\\nabla f\\\|, the direction vector𝐮\\mathbf\{u\}as a red arrow, and the level curve tangent in orange\. Compute and displayD𝐮​f=∇f⋅𝐮D\_\{\\mathbf\{u\}\}f=\\nabla f\\cdot\\mathbf\{u\}\.”

Result\.All features implemented\. Gradient arrow rendered as a cone\-cylinder pair\. Level curve tangent direction⟨−fy,fx⟩\\langle\-f\_\{y\},f\_\{x\}\\ranglederived correctly\.

Validation\.Confirmed thatD𝐮​f=‖∇f‖​cos⁡θD\_\{\\mathbf\{u\}\}f=\\\|\\nabla f\\\|\\cos\\thetaattains its maximum when𝐮\\mathbf\{u\}aligns with∇f\\nabla f; verified numerically that∇f⋅\(level curve tangent\)=0\\nabla f\\cdot\(\\text\{level curve tangent\}\)=0\.

Phase 4: Applications and Algorithmic Connections\.

Prompt:“Add a ‘Run Gradient Ascent’ button that animates\(x0,y0\)\(x\_\{0\},y\_\{0\}\)following\(xn\+1,yn\+1\)=\(xn,yn\)\+k​∇f​\(xn,yn\)\(x\_\{n\+1\},y\_\{n\+1\}\)=\(x\_\{n\},y\_\{n\}\)\+k\\,\\nabla f\(x\_\{n\},y\_\{n\}\)with step sizek=0\.05k=0\.05\. Draw the trajectory as a black path\. Stop when‖∇f‖<0\.01\\\|\\nabla f\\\|<0\.01or after 100 iterations\. Include Stop and Clear Path buttons\.”

Result\.Animation implemented viarequestAnimationFrame; both stopping conditions checked at each step\.

Validation\.Tested on all four preset functions: paraboloid diverges under ascent \(as expected\), Gaussian converges to its maximum, saddle surface shows the characteristic indecision near the critical point\.

Phase 5: Accessibility and Inclusive Design\.

Prompt:“Make this fully compliant with WCAG 2\.2 Level AA: \(1\) skip\-to\-content links per SC 2\.4\.1; \(2\) all interactive controls at least44×4444\\times 44CSS pixels per SC 2\.5\.8; \(3\) visible focus indicators with3:13\{:\}1contrast per SC 2\.4\.7 and 2\.4\.11; \(4\) ARIA live regions announcingx0x\_\{0\},y0y\_\{0\},f​\(x0,y0\)f\(x\_\{0\},y\_\{0\}\),fxf\_\{x\},fyf\_\{y\}, andD𝐮​fD\_\{\\mathbf\{u\}\}fon change; \(5\) full keyboard navigation; \(6\)prefers\-reduced\-motionsupport; \(7\)4\.5:14\.5\{:\}1text contrast throughout\.”

Result\.Skip links positioned off\-screen until focused; ARIA live regions withrole="status"andaria\-live="polite"; animation suppression viaprefers\-reduced\-motionin JavaScript\.

Validation\.Tested with NVDA on Windows; confirmed keyboard\-only navigation; axe DevTools found no violations\.

Phase 6: Pedagogical Control and Scaffolding\.

Prompt:“Add a collapsible Layer Manager with checkboxes to toggle: \(1\)xx\-direction trace, \(2\)yy\-direction trace, \(3\) tangent plane, \(4\) gradient vector, \(5\) direction vector, \(6\) level curve tangent, \(7\) path history\. Add a ‘Reset All’ button restoring the point to\(0\.5,0\.5\)\(0\.5,0\.5\),θ\\thetato0, and all layers to visible\.”

Result\.Each checkbox toggles the corresponding Plotly trace; reset restores all initial conditions\.

Validation\.Each layer verified to toggle independently; reset tested for reliable state restoration; full panel navigated by keyboard alone\.

#### Final review

Before deployment: mathematical spot\-checks at edge\-case parameter values; manual NVDA walkthrough to confirm ARIA announcements fire correctly; a pedagogical check against each stated learning objective; minor visual refinements from a student pilot\.

### 5\.2\.Example 2: Dynamical Systems Phase Portrait Laboratory

Phase 1: Mathematical Foundation and Core Interactivity\.

Prompt:“Create an interactive HTML5/JavaScript tool using the Canvas API to visualize a 2D vector field ford​x/d​t=ydx/dt=y,d​y/d​t=−xdy/dt=\-x\. Render a grid of normalized direction arrows\. Implement a simple Euler method so that clicking on the canvas draws a trajectory from that initial condition\.”

Result\.Clean HTML with canvas, coordinate transformation, normalized arrow grid, and mousedown listener\. Euler integration caused trajectories to spiral outward, a known numerical artifact that motivates the RK4 upgrade in Phase 2\.

Validation\.Clicking produced closed circular orbits, as expected for a simple harmonic oscillator\.

Phase 2: Customization and User Control\.

Prompt:“Replace the Euler integrator with fourth\-order Runge–Kutta \(RK4\)\. Add text input fields for user\-definedf​\(x,y\)f\(x,y\)andg​\(x,y\)g\(x,y\)in JavaScriptMathsyntax with try\-catch error handling\. Add a Clear button to remove all trajectories\.”

Result\.RK4 implemented cleanly; error handling functional\.

Validation\.Tested with the Van der Pol oscillator: RK4 maintained the limit cycle without drift\.

Phase 3: Mathematical Depth and Connections\.

Prompt:“For the current critical point, compute and display the eigenvalues of the Jacobian matrix in a side panel, using finite differences to approximate the partial derivatives, and render the eigenvalues with MathJax\. Overlay the two nullclines \(x′=0x^\{\\prime\}=0andy′=0y^\{\\prime\}=0\) and the eigenvector directions at the critical point, with a panel that classifies the equilibrium \(saddle, node, spiral, center\) from the eigenvalues\.”

Result\.MathJax integrated; finite\-difference Jacobian computed; eigenvalues from the2×22\\times 2quadratic formula; nullclines and eigenvector rays drawn over the field; equilibrium type reported from the sign and nature of the eigenvalues\.

Validation\.Verified on the saddle systemx′=xx^\{\\prime\}=x,y′=−yy^\{\\prime\}=\-y, for which the Jacobian has eigenvaluesλ1=1\\lambda\_\{1\}=1,λ2=−1\\lambda\_\{2\}=\-1and the nullclines are the coordinate axes; displayed values and classification matched exactly\. Spiral and center cases checked against the stable\-spiral and harmonic\-oscillator presets\.

Phase 4: Applications and Algorithmic Connections\.

Prompt:“Add a companion time\-series plot showingx​\(t\)x\(t\)andy​\(t\)y\(t\)for the most recent trajectory alongside the phase portrait, and visual indicators distinguishing forward and backward time integration\. Add export buttons: ‘Export CSV’ for the trajectory data and ‘Save PNG’ for the current portrait\.”

Result\.A linked time\-series panel renderedx​\(t\)x\(t\)andy​\(t\)y\(t\)for the latest integral curve; forward/backward integration distinguished by rendering state; CSV export wrote the trajectory samples and PNG export captured the portrait\.

Validation\.Time\-series curves checked against the phase portrait for the harmonic oscillator \(sinusoidalx​\(t\)x\(t\),y​\(t\)y\(t\)in quadrature\) and the saddle \(exponential divergence\); exported CSV and PNG opened correctly\.

Phase 5: Accessibility and Inclusive Design\.

Prompt:“Bring to WCAG 2\.2 AA compliance: \(1\) ARIA live regions for coordinate and eigenvalue updates; \(2\)4444px minimum touch targets; \(3\) keyboard navigation for a virtual cursor via arrow keys; \(4\) high\-contrast color palette meeting the4\.5:14\.5\{:\}1ratio requirement\.”

Result\.aria\-live="polite"on math output panel; CSS:focus\-visiblefor keyboard tracking; high\-contrast black\-and\-blue color scheme\.

Validation\.Full functionality confirmed without a mouse; screen reader testing confirmed real\-time stability classification announcements\.

Phase 6: Pedagogical Control and Scaffolding\.

Prompt:“Add a library of preset systems as buttons: Linear Saddle, Stable Spiral, Pendulum, Van der Pol, Duffing Oscillator, and Lotka–Volterra \(Predator\-Prey\), each auto\-populating the equation fields and view bounds\. Add toggles to show or hide the nullclines, eigenvectors, and critical points so an instructor can introduce each overlay in turn\. Apply a clean dashboard layout with mobile\-responsive math blocks and a reset\.”

Result\.Preset buttons auto\-populate the equations and bounds and reset the view; the nullcline, eigenvector, and critical\-point overlays toggle independently; layout is mobile\-responsive\.

Validation\.Each preset reproduced its characteristic portrait: the saddle’s crossing separatrices, the stable spiral’s inward winding, the pendulum’s separatrix and centers, the Van der Pol limit cycle, and the Lotka–Volterra closed orbits in the first quadrant; each overlay toggled independently; layout held on desktop and mobile\.

#### Final review

Eigenvalue accuracy spot\-checked across all preset systems and at manually chosen phase\-plane points; keyboard cursor and screen reader stability announcements tested manually; each learning objective checked for legibility to a student using the tool without guidance\. Minor label and color adjustments followed\.

## 6\.The Two\-Stage Pipeline

The six\-phase methodology makes both stages of the pipeline reliable\. In Stage 1, the six phases structure iterative development: one focused conversation per phase, each validated before the next begins\. In Stage 2, the six phases become the schema a generative AI system uses to generate a complete prompt set from a plain\-language pedagogical idea\. The phases are constant; what changes is the direction of travel\.

### 6\.1\.Stage 1: Building and reverse\-engineering

We built the tools in §§[4\.1](https://arxiv.org/html/2608.28601#S4.SS1)–[4\.2](https://arxiv.org/html/2608.28601#S4.SS2)by working through the six phases iteratively, with multiple prompts per phase, refining until each deliverable was correct\. The six\-phase structure kept each conversation focused and made errors easy to catch before they compounded\. Once each tool was complete and verified, we asked the AI:

> Write one prompt per phase of our six\-phase workflow that someone could use to regenerate this tool from scratch\.

The AI’s ability to reverse\-engineer the finished tool back into six phase\-aligned prompts confirmed that the methodology was robust enough to run forward: describe an idea, get six prompts, build the tool\.

### 6\.2\.Stage 2: Idea to prompts to visualization

Stage 2 runs the pipeline forward using the six phases as the template\. The instructor describes a pedagogical idea to a generative AI system in plain language: which concept, which course, what students struggle with\. The system generates six prompts, one per phase, grounded in that idea, and those prompts go to an AI code generator that produces a complete standalone HTML visualization\. We use Claude and Claude Code as the running example here, but the same pipeline runs end\-to\-end on Gemini, which is how Example 3 was built\. Because the six\-phase structure is always the scaffold, the first\-pass output is always structurally complete: all phases represented, mathematically grounded, accessible, with pedagogical controls\. The instructor supplies the idea; the AI handles the prompt architecture and the code\.

### 6\.3\.Editing the output

The first\-pass output is structurally complete but not finished\. Phase 1 and 3 issues are usually mathematical: a boundary case computed incorrectly, a normalization wrong\. Phase 2 and 6 issues are usually about fit: presets that work generically but not for your course, layer controls that do not match how you teach the topic\. Phase 5 issues require manual testing that automated tools miss: ARIA regions present but firing at the wrong time, focus indicators invisible in practice\. Two or three focused revision exchanges, targeting specific phases, are usually enough\. These edits are where your disciplinary expertise enters the tool\.

### 6\.4\.Mandatory human verification

No amount of prompt engineering removes this: AI makes mistakes, and human verification is mandatory at every phase\. The three categories of errors map directly onto the six phases\.

Mathematical errors \(Phases 1, 3, 4\)are the most consequential: a derivative at a boundary incorrect, an off\-by\-one in an iterative algorithm, a vector normalized wrong\. Check outputs against hand calculations at representative points, including edge cases, before moving to the next phase\.

Accessibility errors \(Phase 5\)are equally silent: an ARIA region present but firing at the wrong time; a focus indicator passing axe DevTools but invisible in practice\. A manual screen reader test is non\-negotiable\.

Pedagogical gaps \(Phases 2, 6\)are the most insidious: the tool may be correct and compliant but fail to surface the specific insight students need\. Walk through each stated learning objective and confirm it is realized in the interface before deployment\.

### 6\.5\.Stage 2 worked examples

The two examples below show Stage 2 in practice: each started with a plain\-language description of a pedagogical idea, from which a generative AI system produced the six phase\-aligned prompts and then built the tool\. The two examples were carried out end\-to\-end on different platforms, illustrating that the phase structure, not the platform, is what carries the work\. Example 3 was generated and built entirely with Gemini; Example 4 was generated with Claude and built with Claude Code\. The complete six\-phase prompt set is reproduced with each example below\.

#### Stage 2 Example 3: The 1\-D Heat Equation as Mode\-by\-Mode Decay

Pedagogical motivation\.In an introductory PDE or applied mathematics course, students can write down the Fourier\-series solution of the heat equationut=κ​ux​xu\_\{t\}=\\kappa u\_\{xx\}but often cannot say what the series*does*: that each mode decays at its own ratee−λn2​κ​te^\{\-\\lambda\_\{n\}^\{2\}\\kappa t\}, that high\-frequency modes vanish first, and that this is why an initial profile smooths and flattens over time\. The plain\-language idea given to Gemini was: “I teach the heat equation\. Students can compute the Fourier coefficients and write the series solution, but they do not see diffusion as the differential decay of modes, with sharp features disappearing before smooth ones\. I want a tool where a student picks an initial temperature profile on a rod, scrubs time forward, and watches the profile relax to equilibrium while a side\-by\-side panel shows the individual modes shrinking at their own rates\.” The learning objectives that fell out of this description were: readu​\(x,t\)u\(x,t\)as a superposition of decaying modes; connect each mode’s decay rate toλn2=\(n​π/L\)2\\lambda\_\{n\}^\{2\}=\(n\\pi/L\)^\{2\}; see why high modes die first and the profile smooths; relate the choice of boundary condition \(Dirichlet, Neumann, periodic\) to the admissible series; and connect the abstract solution to a concrete sensor reading through probe time histories\.

Gemini generated six phase\-aligned prompts from this single description, which were then run, also through Gemini, to produce a standalone HTML tool in six successive builds\. Phase 1 fixed the core mathematics and a deliberately raw debugging UI: the analytic Dirichlet series for a flat initial profile, drawn on a single canvas with a time slider, play, and reset, and with the math engine heavily commented so errors would be easy to localize\. Phase 2 turned the demonstration into an exploration tool, adding editableLL,κ\\kappa, amplitude, and mode count; a boundary\-condition selector; four initial\-profile presets \(flat, Gaussian, triangular, square pulse\) with center and width controls; and a rod color strip alongside the profile plot, with all user input validated and clamped\. Phase 3 added the mathematical\-depth panels that motivated the whole tool: a Fourier\-coefficient bar chart, a per\-mode decay display renderinge−λn2​κ​te^\{\-\\lambda\_\{n\}^\{2\}\\kappa t\}, and a live readout of the active series form for the selected boundary condition\. Phase 4 connected the picture to applications by adding movable probe points on the rod, a time\-domain chart ofu​\(xprobe,t\)u\(x\_\{\\text\{probe\}\},t\), a CSV export of the current profile samples, and a metrics panel \(mean, max, and an energy proxy\)\. Phase 5 brought the tool to WCAG 2\.2 AA orientation: a skip link, landmark roles, explicit labels, keyboard\-first control with visible focus, high\-contrast defaults, ARIA live announcements of simulation changes, and suppression of autoplay underprefers\-reduced\-motion\. Phase 6 refactored the result into a no\-scroll teaching dashboard with a Basic/Advanced tablist for progressive disclosure: in Basic mode the advanced parameters are pinned to scaffold defaults and visibly disabled, so an instructor can open on a clean view and reveal complexity \(extra modes, probe placement, animation speed\) only when the class is ready\.

Editing and verification\.The first\-pass output from Gemini was structurally complete at every phase but needed focused correction\. The most consequential issues were mathematical, concentrated in Phases 2–3: with non\-flat profiles the series coefficients are computed by a discrete quadrature over the rod, and we verified the coefficient panel against hand\-computed values for the flat Dirichlet case \(wherebn=4​A/\(n​π\)b\_\{n\}=4A/\(n\\pi\)for oddnnand zero otherwise\) before trusting it on the Gaussian and square\-pulse profiles\. We confirmed that the per\-mode decay panel and the profile plot stayed consistent as time advanced, with the high modes flattening first, and checked the Neumann and periodic series for the correct constant \(a0a\_\{0\}\) term, which an early build normalized inconsistently between boundary conditions\. A Phase 4 fit edit clamped the probe positions to the rod and corrected the energy proxy, which had been summing unnormalized samples\. The mandatory manual screen reader pass \(NVDA\) on the Phase 5 build revealed the recurring timing problem: the ARIA live region re\-announced on every slider tick during a time scrub, overwhelming the listener, so we throttled it to fire on meaningful state changes only\. A Phase 6 pedagogical adjustment fixed the Basic\-mode defaults so that toggling back from Advanced reliably restored the scaffolded view rather than leaving stale parameter values in place\.

AI\-generated six\-phase prompt set \(Example 3\)\.The six prompts below are the ones Gemini produced from the plain\-language idea; they were then executed in sequence, also with Gemini\.

Phase 1 \(Mathematical Foundation and Core Interactivity\)

Create a single\-page 1\-D heat equation demo focused only on mathematical correctness and a minimal debugging UI\. Use the analytical Fourier\-series solution for Dirichlet boundaries onx∈\[0,L\]x\\in\[0,L\]\. Start with a flat initial profileu​\(x,0\)=Au\(x,0\)=Aand showu​\(x,t\)u\(x,t\)on a canvas\. Provide only essential controls: a time slider, play/pause, and reset\. Use no heavy styling or extra panels; keep the UI intentionally raw\. Include clear inline comments around the numerical/math engine to aid debugging\.

Phase 2 \(Customization and User Control\)

Expand the Phase 1 app into an exploration tool with robust input logic\. Add editable parametersLL,κ\\kappa, amplitudeAA, and mode countNN\. Add a boundary\-condition selector \(Dirichlet, Neumann, periodic\) and initial\-profile presets \(flat, Gaussian, triangular, square pulse\)\. Support center and width controls with validation and clamping\. Keep one main solution plot and one rod color\-strip visualization\.

Phase 3 \(Mathematical Depth and Connections\)

Extend Phase 2 by visualizing the related objects that explain why diffusion behaves as observed\. Add a Fourier\-coefficient view \(a bar chart over modes\), a per\-mode decay display showinge−λn2​κ​te^\{\-\\lambda\_\{n\}^\{2\}\\kappa t\}, and a readout of the active series form for the selected boundary condition\. Keep the controls and all math panels synchronized in real time\.

Phase 4 \(Applications and Algorithmic Connections\)

Bridge the mathematics to applied analysis and computational workflows\. Add probe points on the rod and a time\-domain chart ofu​\(xprobe,t\)u\(x\_\{\\text\{probe\}\},t\), CSV export of the current profile samples, and a practical metrics panel \(mean temperature, max temperature, energy\)\. Keep interaction smooth during animation and parameter changes\.

Phase 5 \(Accessibility and Inclusive Design\)

Upgrade Phase 4 to WCAG 2\.2 AA\-oriented interaction and semantics\. Add a skip link, landmark roles, explicit labels, and a keyboard\-first flow\. Provide visible focus states and high\-contrast defaults, ARIA live status updates for key simulation changes, and respect for the reduced\-motion preference \(disable autoplay animation\)\. Ensure controls have touch targets of at least24×2424\\times 24CSS pixels, preferring44×4444\\times 44\.

Phase 6 \(Pedagogical Control and Scaffolding\)

Refactor Phase 5 into a structured teaching dashboard that manages cognitive load\. Build a no\-scroll desktop layout with distinct panel regions and use progressive disclosure \(Basic/Advanced tabs or toggles\)\. Keep all Phase 5 accessibility features intact\. Let instructors reveal complexity gradually during a lecture while preserving full experimentation capability for students\.

#### Stage 2 Example 4: Triple Integrals as a Sweep of Cross\-Sectional Areas

Pedagogical motivation\.In multivariable calculus, students learn to evaluate a triple integral as an iterated integral but frequently lose the geometric meaning of the outer integral: that∭Ef​𝑑V=∫A​\(v\)​𝑑v\\iiint\_\{E\}f\\,dV=\\int A\(v\)\\,dvsweeps a moving cross\-section through the solid, accumulating area \(or a weighted area, whenf≠1f\\neq 1\) as it goes\. Setting up the limits is exactly where this intuition is needed and most often missing\. The plain\-language idea given to Claude was: “I teach triple integrals in Calculus III\. Students can grind through an iterated integral but cannot see the solid being swept out, and they cannot see where the inner limits come from\. I want a tool where a student picks a solid, drags a cross\-section plane through it along a chosen axis, and watches the cross\-sectional areaA​\(v\)A\(v\)trace out alongside the 3D region, so the outer integral becomes the area under thatA​\(v\)A\(v\)curve\.” The learning objectives were: read a triple integral as an accumulation of cross\-sectional areas; connect the slice position to the outer variable of integration and the slice geometry to the inner limits; see how the choice of integration direction \(X, Y, or Z first\) reshapes the cross\-section and the limits; extend the picture from volume \(f=1f=1\) to a general integrandf​\(x,y,z\)f\(x,y,z\)via a heat\-map coloring of the slice; and classify how different standard solids \(sphere, cylinder, cone, paraboloid, tetrahedron, and regions between two surfaces\) produce qualitatively differentA​\(v\)A\(v\)profiles\.

Claude generated the six phase\-aligned prompts from this description, and Claude Code produced the tool in six builds\. Phase 1 established the core 3D scene and the central interaction: a rotatable, zoomable solid with a draggable cross\-section plane and a live readout of the slice position\. Phase 2 added the eight region presets, an integration\-direction selector \(X/Y/Z first\), and a slice\-position slider with validation, turning the demonstration into an exploration tool\. Phase 3 added the mathematical\-depth layer that carries the lesson: a liveA​\(v\)A\(v\)side chart, the explicit cross\-section description and inner limits for the active solid \(for the sphere,x2\+y2≤4−z02x^\{2\}\+y^\{2\}\\leq 4\-z\_\{0\}^\{2\}withA​\(z0\)=π​\(4−z02\)A\(z\_\{0\}\)=\\pi\(4\-z\_\{0\}^\{2\}\)\), and the iterated\-integral notation kept in sync with the geometry\. Phase 4 generalized from volume to a user\-entered integrandf​\(x,y,z\)f\(x,y,z\)with a numerical value for the accumulated integral and a heat\-map coloring offfon the slice, connecting the geometry to the analytic computation\. Phase 5 implemented WCAG 2\.2 AA features: a skip\-to\-controls link, keyboard control of the plane via Tab and arrow keys, ARIA\-labeled layers, and high\-contrast display options\. Phase 6 added pedagogical scaffolding: a Display\-Layers panel that toggles the solid mesh, cross\-section plane, disk,A​\(v\)A\(v\)chart, integral notation, heat\-map coloring, and numerical values independently, plus an Instructor Mode and animation controls \(step and sweep\) so complexity can be introduced incrementally during a lecture\.

Editing and verification\.The first pass was structurally complete but required focused correction, again concentrated in the mathematical phases\. The most important checks were on theA​\(v\)A\(v\)computation\. We verified the reported cross\-sectional area against closed\-form values for the presets where they are known: the sphere’sπ​\(4−z02\)\\pi\(4\-z\_\{0\}^\{2\}\), the cylinder’s constant disk, and the cone’s and paraboloid’s quadratic and linear\-in\-radius profiles\. Only then did we trust the slicer on the compound regions \(between two cones, and cone–paraboloid\), where an early build mis\-ordered the inner limits when the integration direction was switched away fromzz\. A Phase 4 mathematical fix corrected the numerical integral for non\-constant integrands, which initially sampledffat the slice centroid rather than integrating it over the slice\. A Phase 2 fit edit constrained the slice\-position range to each solid’s actual extent so the plane could not be dragged outside the region\. The manual screen reader pass on the Phase 5 build confirmed that the slice\-position and area announcements were legible but, as in Example 3, fired too frequently during a drag or sweep; we throttled them to announce on release and on discrete steps\. The tool is deployed in the Spring 2026 offering of MA 261 at Purdue\.

AI\-generated six\-phase prompt set \(Example 4\)\.The six prompts below are the ones Claude produced from the plain\-language idea; they were then executed in sequence with Claude Code\.

Phase 1 \(Mathematical Foundation and Core Interactivity\)

Create a single\-page tool that renders an interactive 3D solid region \(start with the spherex2\+y2\+z2≤4x^\{2\}\+y^\{2\}\+z^\{2\}\\leq 4\) using Three\.js \(WebGL\), with mouse rotation and scroll zoom\. Add a horizontal cross\-section plane that the user can move through the solid with a slider, and display the current slice positionz0z\_\{0\}\. Focus on geometric correctness of the region and the slicing plane; keep the rest of the UI minimal\.

Phase 2 \(Customization and User Control\)

Expand the Phase 1 tool into an exploration tool\. Add a library of region presets \(sphere, cylinder, cone, box, paraboloid, tetrahedron, region between two cones, and a cone–paraboloid region\) and a selector for the integration direction \(integrate alongxx,yy, orzzfirst\), reslicing the solid accordingly\. Constrain the slice\-position slider to each solid’s actual extent so the plane cannot leave the region\. Validate all inputs\.

Phase 3 \(Mathematical Depth and Connections\)

Extend Phase 2 with the mathematical objects that explain the iterated integral\. For the current solid and direction, render the cross\-section disk on the plane and a live side chart of the cross\-sectional areaA​\(v\)A\(v\)as the slice moves\. Display the explicit cross\-section description and the inner integration limits for the active solid \(for the sphere,x2\+y2≤4−z02x^\{2\}\+y^\{2\}\\leq 4\-z\_\{0\}^\{2\}withA​\(z0\)=π​\(4−z02\)A\(z\_\{0\}\)=\\pi\(4\-z\_\{0\}^\{2\}\)\), and show the iterated\-integral notation kept synchronized with the geometry\. Add a complementary “shadow” \(projection\) view that shows the region’s shadowDDon a chosen coordinate plane, where clicking a point draws the inner integration segment and reports its bounds, so students see where the innermost limits come from\.

Phase 4 \(Applications and Algorithmic Connections\)

Generalize from volume to a weighted integral\. Add a text input for a user\-defined integrandf​\(x,y,z\)f\(x,y,z\)\(supportingxˆ2,sin,cos,exp,sqrt,abs,pi,e\) with validation, color the cross\-section by the value offfas a heat map with a color legend, and compute and display the numerical value of∭Ef​𝑑V\\iiint\_\{E\}f\\,dVvia a midpoint\-rule sum over the region\. Connect the algebra to the iterated\-integral order by letting the user choose which variable is integrated first and updating the displayed limits accordingly\.

Phase 5 \(Accessibility and Inclusive Design\)

Bring the tool to WCAG 2\.2 AA\. Add a skip\-to\-controls link, landmark roles, and explicit labels; make the cross\-section plane controllable from the keyboard with Tab and arrow keys with visible focus; add ARIA live announcements of the slice position and area; provide high\-contrast display options; and respect the reduced\-motion preference\.

Phase 6 \(Pedagogical Control and Scaffolding\)

Refactor Phase 5 into a teaching dashboard\. Add a Display\-Layers panel whose checkboxes independently toggle the solid mesh, the cross\-section plane, the cross\-section disk, theA​\(v\)A\(v\)side chart, the integral notation, the heat\-map coloring, and the numerical values, so an instructor can introduce one element at a time\. Add an Instructor Mode and step/sweep animation controls, plus a reset, while preserving full student experimentation\.

Table[1](https://arxiv.org/html/2608.28601#S6.T1)summarizes the full pipeline\. You can enter at Stage 1 if you already have a finished tool to reverse\-engineer, or directly at Stage 2 if you are starting from a new idea\.

Table 1\.The two\-stage AI\-assisted visualization pipeline\.

## 7\.Evaluation and Findings

We evaluate the workflow through the four deployed tools and the assessment prototype, organizing the evidence around the three research questions\. Because the unit of analysis is the workflow rather than student learning, our evidence concerns the correctness, accessibility, and pedagogical fidelity of what the workflow produces, together with the verification each phase required\. A controlled study of student outcomes is a separate undertaking, outlined in §[9\.2](https://arxiv.org/html/2608.28601#S9.SS2)\.

### 7\.1\.RQ1: Mathematical correctness and accessibility compliance

Mathematical correctness\.Every tool was checked against closed\-form results at representative points and edge cases\. For the directional\-derivatives explorer, partial derivatives and the identityD𝐮​f=‖∇f‖​cos⁡θD\_\{\\mathbf\{u\}\}f=\\\|\\nabla f\\\|\\cos\\thetawere verified against hand computation, and the orthogonality∇f⋅\(level\-curve tangent\)=0\\nabla f\\cdot\(\\text\{level\-curve tangent\}\)=0confirmed numerically\. For the phase\-portrait laboratory, Jacobian eigenvalues were checked on the saddle systemx′=x,y′=−yx^\{\\prime\}=x,\\,y^\{\\prime\}=\-y\(eigenvalues1,−11,\-1\) and on the stable\-spiral and harmonic\-oscillator presets\. For the heat\-equation tool, the Fourier coefficients were verified against the closed formbn=4​A/\(n​π\)b\_\{n\}=4A/\(n\\pi\)\(oddnn\) for the flat Dirichlet case before trusting the quadrature on other profiles\. For the triple\-integral slicer, the cross\-sectional areaA​\(v\)A\(v\)was checked against closed forms for every preset where one exists \(the sphere’sπ​\(4−z02\)\\pi\(4\-z\_\{0\}^\{2\}\), the cylinder’s constant disk, the cone’sπ​z02\\pi z\_\{0\}^\{2\}, and the paraboloid’sπ​z0\\pi z\_\{0\}\) before trusting the numerical slicer on the compound regions\. In each tool the first\-pass output contained at least one mathematical error that these checks caught \(detailed under RQ3\)\.

Accessibility compliance\.Each tool was audited against WCAG 2\.2 Level AA using a combination of automated tooling \(axe DevTools\) and manual testing\. Automated audits flagged no violations after the Phase 5 revisions\. Manual testing told a different story\. Keyboard\-only operation and screen\-reader walkthroughs with NVDA were decisive: in every tool they revealed timing problems in ARIA live regions that automated tools did not catch, where announcements fired on every increment of a drag and overwhelmed the listener\. Throttling announcements to meaningful state changes resolved these\. The tools implement skip\-to\-content links \(SC 2\.4\.1\),44×4444\\times 44CSS\-pixel touch targets \(SC 2\.5\.8\), visible focus indicators at3:13\{:\}1contrast \(SC 2\.4\.7, 2\.4\.11\), keyboard navigation, andprefers\-reduced\-motionsupport\. In short, the structure reliably produces correct and compliant tools*after*the verification built into Phases 1–5, not before; the phase boundaries are where correctness and compliance get established rather than assumed\.

### 7\.2\.RQ2: Bidirectional operation and platform independence

The workflow ran in both directions\. Backward \(Stage 1\): the directional\-derivatives and phase\-portrait tools were built iteratively, then presented to the AI, which reconstructed a phase\-aligned prompt set for each; the reconstructed prompts appear in §[5](https://arxiv.org/html/2608.28601#S5)\. The AI’s ability to recover the six\-phase structure from a finished artifact indicated the schema was robust enough to drive construction forward\. Forward \(Stage 2\): the heat\-equation and triple\-integral tools were each produced from a single plain\-language description, from which the AI generated six phase\-aligned prompts that were then built into a complete tool\. In every forward case the first\-pass output was structurally complete, with all six phases present, mathematically grounded, accessible, and equipped with pedagogical controls, though not error\-free\.

Platform independence held\. Two tools were generated and built end\-to\-end with Gemini and two with Claude and Claude Code, with no change to the phase structure; the only platform\-specific observation was a division of strengths \(Claude with component architecture and 3D graphics via Three\.js, Gemini with Plotly\.js and Canvas\)\. The six phases, then, function as a platform\-independent schema, equally usable for reconstruction and for generation\.

### 7\.3\.RQ3: Required human verification and recurring errors

The errors that recurred across the four tools fell into the three categories the workflow anticipates, mapped to specific phases\.

Mathematical errors \(Phases 1, 3, 4\)were the most consequential and appeared in every tool\. Representative cases: a midpoint rule that sampled the integrand at the slice centroid rather than integrating it over the slice; inner integration limits mis\-ordered when the integration direction was switched; a defective \(repeated\-eigenvalue\) case drawn as two eigendirections rather than one; and an early Euler integrator whose numerical drift had to be replaced with RK4\. None of these produced a visibly broken tool; each required a check against a hand computation to detect\.

Accessibility errors \(Phase 5\)were silent to automated tools\. The recurring case was ARIA\-live timing, present in all four tools: the region existed and passed automated audits but fired announcements at the wrong cadence, intelligible only through a manual screen\-reader pass\.

Pedagogical\-fit issues \(Phases 2, 6\)concerned defaults and disclosure rather than correctness: presets that worked generically but not for the target course, layer controls whose default visibility did not match how the topic is taught, and progressive\-disclosure defaults that needed reordering so complexity could be introduced in lecture order\. Two to three focused revision exchanges per tool, targeting specific phases, were sufficient\.

The lesson from RQ3 is that human verification is not a final quality\-control step but a per\-phase requirement: a mathematical error in Phase 1 propagates silently through Phases 2–6, an accessibility defect in Phase 5 is invisible to automated tooling, and pedagogical fit cannot be judged by the AI at all\. The verification protocol is therefore part of the method, not an addendum to it: hand\-computation spot\-checks at phase boundaries, a mandatory manual screen\-reader pass, and a walkthrough against each stated learning objective\.

## 8\.Discussion

### 8\.1\.Effective prompting

The six\-phase structure is itself the most important prompting principle: it prevents the most common failure mode, giving the AI too much at once\. Within that structure, several additional principles consistently improved results\.

Mathematical specificity\.Generic requests yield incomplete implementations\. Provide explicit mathematical definitions with equations, not just concept names: “compute∇f=⟨fx,fy⟩\\nabla f=\\langle f\_\{x\},f\_\{y\}\\rangleand display it as a vector arrow with length proportional to‖∇f‖\\\|\\nabla f\\\|” rather than “show the gradient\.”

Technology stack specification\.Name the library explicitly: “using Plotly\.js” or “with the HTML5 Canvas API\.” Without this, the AI may mix incompatible frameworks\.

Concrete accessibility criteria\.Cite specific WCAG success criteria: “ensure44×4444\\times 44px touch targets \(SC 2\.5\.8\), visible focus with3:13\{:\}1contrast \(SC 2\.4\.11\), ARIA live regions for dynamic content\.” Generic “make it accessible” prompts yield minimal compliance\.

Pedagogical framing\.Explain why features matter: “display orthogonality to help students understand the gradient\-level curve relationship” produces more thoughtful implementations than “show gradient and level curve tangent\.”

Phase\-by\-phase validation\.A mathematical error in Phase 1 propagates silently through Phases 2–6\. Each phase boundary is a checkpoint, not just a formatting convention\.

### 8\.2\.Quality assurance and the irreplaceable role of human expertise

AI dramatically accelerates implementation\. It does not replace mathematical and pedagogical expertise\.

Mathematical edge cases\.AI\-generated code handles typical inputs correctly but fails at boundaries: division by zero when the gradient magnitude approaches zero, incorrect limiting behavior near discontinuities, numerical instability with poor step\-size selection\. Testing must deliberately probe these cases\.

Accessibility nuances\.Announcement timing in ARIA live regions requires judgment \(too frequent overwhelms; too infrequent misses changes\); logical tab order through complex interfaces is easy to get wrong; appropriate ARIA roles for custom widgets are not always correctly inferred\. Screen reader testing by a human is essential\.

Pedagogical appropriateness\.AI cannot judge cognitive load, determine which details to emphasize, or sequence information for learning\. These decisions require understanding of student difficulties and course context\.

### 8\.3\.Student creation: from consumption to construction

The workflow’s most significant implication may be enabling students to create visualizations themselves\. Without programming knowledge, students can articulate a mathematical relationship, describe it to Claude using the six\-phase framework, and produce an interactive tool to test their intuition\. This articulation process is itself pedagogically valuable\[[11](https://arxiv.org/html/2608.28601#bib.bib11)\]: students who must describe a relationship precisely enough for the AI to implement it are engaging in mathematical communication that surfaces implicit gaps\.

Practical opportunities include exploratory projects \(“create a visualization showing the relationship between curvature and the second derivative test”\), conjecture testing, and peer teaching through shared tools\[[3](https://arxiv.org/html/2608.28601#bib.bib3)\]\. A multi\-course pilot planned for 2026–2027 will have students create visualizations as course projects across calculus, differential equations, and linear algebra, with rubrics focused on mathematical reasoning and accessibility rather than programming skill\.

### 8\.4\.Accessibility as standard practice

Historically, accessibility in instructor\-created materials has been aspirational rather than standard, with well\-documented barriers: specialized technical knowledge, limited institutional support, and the sheer time required\[[1](https://arxiv.org/html/2608.28601#bib.bib1)\]\. By enabling AI to implement accessibility features from natural language descriptions, this workflow makes WCAG compliance the default rather than an exceptional effort\.

Technical implementation alone does not guarantee genuine accessibility, however\. Partnerships with disability resource centers and testing with assistive technology users remain central to the validation process\. When students create visualizations, they must also engage with accessibility principles, a challenge that doubles as an opportunity to build inclusive design thinking into their future practice\.

## 9\.Applicability and Future Directions

### 9\.1\.Across the mathematics curriculum

The six\-phase structure transfers intact to any mathematical domain\. The only adaptation is in Phase 1: name the concept and specify the core interactive behavior for that course\. Phases 2–6 follow the same pattern regardless of domain\. This is exactly why Stage 2 works: current generative AI systems know the six\-phase schema well enough to generate all six prompts from any plain\-language mathematical idea\.

The same approach can be adapted to:

- •Differential equations:phase portraits, direction fields, bifurcation diagrams, numerical method comparisons\.
- •Linear algebra:matrix transformation visualizations, eigenvalue/eigenvector geometry, SVD and PCA animations, Gram–Schmidt orthogonalization\.
- •Complex analysis:conformal mapping demonstrations, contour integration with interactive path selection, residue visualization\.
- •Numerical analysis:root\-finding convergence \(Newton, bisection, secant\), Runge phenomenon, adaptive quadrature comparisons\.
- •Discrete mathematics:graph algorithm animations \(Dijkstra, BFS, minimum spanning tree\), recurrence relation behavior\.
- •Abstract algebra:group operation tables with subgroup highlighting, coset visualization, symmetry group demonstrations\.

### 9\.2\.Future research

Several questions warrant systematic investigation, and they define the next cycle of this design\-based research program\. The present study establishes that the workflow produces correct, accessible, pedagogically purposeful tools; the natural next cycle moves the unit of analysis from the artifact to the learner\. Do students who use AI\-generated visualizations demonstrate different conceptual understanding compared to those using traditional instruction or commercially developed tools? Does the creation process, as opposed to mere use, enhance understanding, and if so through what mechanisms? What factors facilitate or inhibit instructor adoption, and what professional development models are most effective? The multi\-course pilot planned for 2026–2027 across calculus, differential equations, and linear algebra \(§[8\.3](https://arxiv.org/html/2608.28601#S8.SS3)\) is designed to begin answering the first two, with pre/post conceptual measures and comparison against business\-as\-usual instruction\.

One direction we find genuinely exciting, though it needs considerably more thought before it is ready, is the addition of a seventh phase: Student Reflection and Assessment\. The idea is straightforward: once a visualization is deployed, a short quiz and a reflection prompt are embedded directly into the same tool\. The quiz ties to the learning objectives already specified in Phase 1, so the AI has everything it needs to generate reasonable assessment items from a single additional prompt\. The reflection prompt asks students to articulate, in their own words, the key relationship the tool was designed to surface\. We have experimented with a rough prototype built on the directional\-derivatives tool of §[4\.1](https://arxiv.org/html/2608.28601#S4.SS1), which embeds a dynamic quiz and free\-text reflection prompts directly in the visualization \([https://www\.math\.purdue\.edu/˜msunkula/MA261/Sp26/pd\-quiz](https://www.math.purdue.edu/~msunkula/MA261/Sp26/pd-quiz)\), and the early results are encouraging enough to pursue further\. That said, what counts as a good reflection prompt, how to assess responses without creating grading overhead, and how tightly the quiz should couple to the specific visualization rather than the broader topic are all open questions we have not yet answered well\.

## 10\.Conclusion

Using a design\-based research approach, we have developed, deployed, and evaluated a six\-phase workflow \(Foundation, Customization, Mathematical Depth, Application, Accessibility, Pedagogical Control\) that uses generative AI to build WCAG 2\.2 compliant interactive visualizations in undergraduate mathematics without programming expertise\. Across four deployed tools and an assessment prototype, we found that the phase structure reliably yields mathematically correct and accessible tools once the verification built into each phase is carried out, that it operates both backward and forward and independently of the AI platform, and that human verification remains mandatory at every phase\. The six phases are the core contribution\. They structure prompts, scaffold code generation, and define where human verification is applied\. In Stage 1 they organize iterative development and enable reverse\-engineering of reproducible prompt sets\. In Stage 2 they are the template a generative AI system uses to produce a complete prompt set from any plain\-language mathematical idea\.

The workflow removes the technical barrier to building custom visualizations, but it does not remove the need for mathematical and pedagogical judgment\. Across the four tools, the work that mattered most was the verification: the hand calculations that caught a wrong boundary case, the screen\-reader pass that caught an announcement firing at the wrong time, the walkthrough that caught a default no instructor would want\. That work is where a mathematician’s expertise enters, and it is why the tools are usable in a real classroom rather than merely plausible on a first pass\.

What has changed is the cost of a first draft\. An instructor can now go from an idea to a working, accessible, mathematically grounded tool in an afternoon, and spend the saved time on the questions that actually need a human: which concept to target, how to sequence the disclosure of complexity, what a good reflection prompt looks like\. Those are mathematics\-education questions, not software\-engineering ones\. A reasonable place to start is to pick one concept students reliably struggle with, describe it to a generative AI system using the six\-phase framework, verify the result against the protocol above, and try it in the next offering of the course\.

## Disclosure of AI use

Generative AI as the studied method\.The interactive visualizations reported in this article were produced with generative AI tools, which are the object of the study rather than an aid to writing it\. Two tools \(the directional\-derivatives explorer and the triple\-integral slicer\) were generated and built using Anthropic’s Claude \(Claude Opus 4, accessed via Claude and Claude Code, 2025–2026\), and two tools \(the phase\-portrait laboratory and the heat\-equation lab\) were generated and built using Google’s Gemini \(Gemini 2\.5, 2025–2026\)\. In each case the AI was used to generate the six\-phase prompt sets and the underlying HTML, CSS, and JavaScript\. All AI\-generated mathematics, code, and accessibility features were reviewed and verified by the authors against closed\-form results, manual screen\-reader and keyboard testing, and the stated learning objectives, following the verification protocol described in §[7](https://arxiv.org/html/2608.28601#S7); the authors take full responsibility for the correctness and integrity of all reported artifacts\.

Manuscript preparation\.The authors conceived, structured, and wrote the manuscript\. Generative AI tools were used only for language refinement and copyediting of author\-written text\. No text, data, or citations were generated by AI without author review, and the authors are accountable for the originality, accuracy, and integrity of the entire manuscript, including all references\.

## References

- \[1\]N\. Alajarmeh,Evaluating accessibility of web\-based learning material for students with visual impairments, J\. Comput\. Educ\.7\(2020\), no\. 3, 343–363\.
- \[2\]T\. Anderson and J\. Shattuck,Design\-based research: A decade of progress in education research?, Educ\. Res\.41\(2012\), no\. 1, 16–25\.
- \[3\]J\. A\. Bargh and Y\. Schul,On the cognitive benefits of teaching, J\. Educ\. Psychol\.72\(1980\), no\. 5, 593–604\.
- \[4\]CAST,Universal Design for Learning Guidelines version 2\.2, 2018,[http://udlguidelines\.cast\.org](http://udlguidelines.cast.org/)\.
- \[5\]M\. Chen et al\.,Evaluating large language models trained on code, arXiv:2107\.03374, 2021\.
- \[6\]G\. Cooper,Examining science education in ChatGPT: An exploratory study of generative artificial intelligence, J\. Sci\. Educ\. Technol\.32\(2023\), no\. 3, 444–452\.
- \[7\]Design\-Based Research Collective,Design\-based research: An emerging paradigm for educational inquiry, Educ\. Res\.32\(2003\), no\. 1, 5–8\.
- \[8\]R\. Duval,A cognitive analysis of problems of comprehension in a learning of mathematics, Educ\. Stud\. Math\.61\(2006\), no\. 1, 103–131\.
- \[9\]S\. Habre,Visualization in multivariable calculus: The case of 3D surfaces, Focus Learn\. Probl\. Math\.23\(2001\), no\. 1, 30–47\.
- \[10\]J\. Hiebert and D\. A\. Grouws,The effects of classroom mathematics teaching on students’ learning, inSecond Handbook of Research on Mathematics Teaching and Learning\(F\. K\. Lester, ed\.\), Information Age, Charlotte, NC, 2007, pp\. 371–404\.
- \[11\]J\. J\. Kaput,Representation systems and mathematics, inProblems of Representation in the Teaching and Learning of Mathematics\(C\. Janvier, ed\.\), Erlbaum, Hillsdale, NJ, 1987, pp\. 19–26\.
- \[12\]A\. Karshmer and C\. Bledsoe,Access to mathematics by blind students, inProc\. ICCHP, Springer, Berlin, 2002, pp\. 471–476\.
- \[13\]E\. Kasneci et al\.,ChatGPT for good? On opportunities and challenges of large language models for education, Learn\. Indiv\. Differ\.103\(2023\), 102274\.
- \[14\]W\. Liang et al\.,Can large language models provide useful feedback on research papers? A large\-scale empirical analysis, arXiv:2310\.01783, 2023\.
- \[15\]R\. Martínez\-Planell and M\. Trigueros,Students’ understanding of the general notion of a function of two variables, Educ\. Stud\. Math\.81\(2012\), no\. 3, 365–384\.
- \[16\]J\. Piaget,Genetic Epistemology, Columbia Univ\. Press, New York, 1970\.
- \[17\]N\. C\. Presmeg,Research on visualization in learning and teaching mathematics, inHandbook of Research on the Psychology of Mathematics Education\(A\. Gutiérrez and P\. Boero, eds\.\), Sense, Rotterdam, 2006, pp\. 205–235\.
- \[18\]D\. H\. Rose and A\. Meyer,Teaching Every Student in the Digital Age: Universal Design for Learning, ASCD, Alexandria, VA, 2002\.
- \[19\]K\. Shinohara and J\. O\. Wobbrock,In the shadow of misperception: Assistive technology use and social interactions, inProc\. CHI, ACM, New York, 2011, pp\. 705–714\.
- \[20\]D\. Tall,Intuition and rigour: The role of visualization in the calculus, inVisualization in Teaching and Learning Mathematics\(W\. Zimmermann and S\. Cunningham, eds\.\), MAA, Washington, DC, 1991, pp\. 105–119\.
- \[21\]D\. Tall and S\. Vinner,Concept image and concept definition in mathematics with particular reference to limits and continuity, Educ\. Stud\. Math\.12\(1981\), no\. 2, 151–169\.
- \[22\]E\. von Glasersfeld,Radical Constructivism: A Way of Knowing and Learning, Falmer Press, London, 1995\.
- \[23\]W3C,Web Content Accessibility Guidelines \(WCAG\) 2\.2, 2023,[https://www\.w3\.org/TR/WCAG22/](https://www.w3.org/TR/WCAG22/)\.
- \[24\]E\. Weber and P\. W\. Thompson,Students’ images of two\-variable functions and their graphs, Educ\. Stud\. Math\.87\(2014\), no\. 1, 67–85\.
- \[25\]D\. Weintrop et al\.,Defining computational thinking for mathematics and science classrooms, J\. Sci\. Educ\. Technol\.25\(2016\), no\. 1, 127–147\.

Similar Articles

AI Co-Mathematician: Accelerating Mathematicians with Agentic AI

Hugging Face Daily Papers

This paper introduces the AI Co-Mathematician, a workbench that uses agentic AI to support mathematicians in open-ended research tasks like ideation and theorem proving. Early tests show the system achieving state-of-the-art results on hard problem-solving benchmarks, including a 48% score on FrontierMath Tier 4.

See Before You Code: Learning Visual Priors for Spatially Aware Educational Animation Generation

arXiv cs.AI

This paper introduces OmniManim, a render-feedback-aware framework for generating educational animations from natural language descriptions using large language models. It addresses visual defects like element overlap and misalignment by incorporating explicit visual planning, post-render diagnostics, and localized repair, demonstrating improved render quality on newly constructed datasets.

AI-Generated Slides: Are They Good? Can Students Tell?

arXiv cs.AI

This paper examines using generative AI tools (NotebookLM, Claude, M365 Copilot, Cursor, Claude Code) to generate slides from instructor notes, finding that coding assistants produce the best slides and that students cannot reliably distinguish AI-generated slides from human-created ones.