How A Blind Person Creates 3D Models in CAD

The primary engineering challenge in developing many of my projects, most notably Leoht Version 2, has been component modelling in CAD (computer-aided design). While Leoht Version 1 relied on hand-fabricated templates remodelled into CAD, this workflow lacked the dimensional precision required for tighter tolerances and prevented direct design iteration.

I was heavily reliant on my ability to explain my ideas concisely and accurately, and other people’s ability to interpret those ideas and turn them into accurate, visual models. I couldn’t work alone to tweak models to perfection.

To meet the rigorous requirements of Version 2, I had to transition to a full CAD workflow. Crucially, it had to be one where I am able to produce the designs myself.

This presented a significant barrier. As a blind engineer, I interact with computers using a Screenreader – software that parses the Operating System’s accessibility tree to convert text and UI elements into synthesised speech. Visual CAD software is fundamentally incompatible with this workflow.

Visual CAD Accessibility

The incompatibility stems from how visual CAD applications render content. Screen readers rely on the accessibility API (such as UI Automation on Windows or the Accessibility Protocol on macOS) to retrieve semantic information about controls (buttons, input fields, tree views etc).

However, the viewport in software like Fusion 360 or SolidWorks is typically a hardware-accelerated canvas (OpenGL, Metal or even DirectX). To a screen reader, this canvas is a “black box” – a single graphic element containing no semantic data about the 3D geometry rendered within it.

There are no DOM elements for “Vertex A” or “Face B” that assistive technology can programmatically identify or interact with. And sadly none of these programs helpfully expose a list of objects in a list or tree view for easy selection, besides FreeCAD which has a GUI built on the Qt Framework which brings many accessibility challenges of its own, especially under MacOS with the native Voiceover screenreader.

Furthermore, many CAD interface elements are custom-drawn widgets that bypass standard OS accessibility hooks, leaving them unlabelled and invisible to non-visual users.

To overcome this, I adopted a code-CAD paradigm: defining geometry through algorithms rather than direct manipulation.

My initial tool of choice was OpenSCAD. It operates on the principle of Constructive Solid Geometry (CSG), where complex shapes are created by combining primitive objects via boolean operations (union, difference, intersection etc).

For a blind engineer, this is ideal because the “model” is purely semantic text. Precision is handled not by mouse clicks, but by mathematical definition.

Example: OpenSCAD Script

In this workflow, I can ensure printability by programmatically linking mesh resolution to physical hardware constraints. For instance, determining the facet count ($fn) dynamically based on a 3D printer’s 0.2mm nozzle size ensures a smooth surface without unnecessary computational load.

// Dynamic resolution function based on 0.2mm nozzle size
// Ensures segment length is never larger than the nozzle width
function get_fn(rad) = max(100, ceil((2 * PI * rad) / 0.2));

module mounting_bracket() {
    hole_rad = 5;
    outer_rad = 10;
    height = 5;

    difference() {
        // Outer cylinder with dynamic resolution
        cylinder(r=outer_rad, h=height, $fn=get_fn(outer_rad));

        // Bore hole, centered
        translate([0, 0, -1])
            cylinder(r=hole_rad, h=height + 2, $fn=get_fn(hole_rad));
    }
}

mounting_bracket();

The Mesh Limitation

While OpenSCAD excels at generating STL files for additive manufacturing (3D printing), it relies on tessellation. It represents curves as a series of planar triangles (a mesh). This is analogous to a raster image or a lossy audio file: it approximates the geometry.

This creates a critical bottleneck for CNC machining. Computer-Aided Manufacturing (CAM) software typically requires boundary representation (B-Rep) data – mathematically exact curves and surfaces (NURBS) – found in formats like STEP or IGES. OpenSCAD’s mesh output is generally unsuitable for generating the G-Code paths required for CNC milling.

CadQuery

To generate industry-standard STEP files, I migrated to CadQuery. Unlike OpenSCAD, CadQuery is built on the Open Cascade Technology (OCCT) kernel. It creates topological B-Rep solids rather than meshes, allowing for infinite precision and proper export to visual CAD suites like Fusion 360 or Onshape.

CadQuery utilises Python, offering a robust, imperative programming environment.

Example: CadQuery Script

The transition involves shifting from boolean declarations to a workplane-based stack approach:

import cadquery as cq

# Define dimensions
thickness = 10.0
dia_outer = 20.0
dia_inner = 5.0

# Generate B-Rep Solid
result = (
    cq.Workplane("XY")
    .circle(dia_outer / 2)
    .extrude(thickness)
    .faces(">Z")
    .hole(dia_inner)
)

# Export to STEP for CNC/CAM usage
# This generates a mathematically perfect solid, not a mesh
cq.exporters.export(result, "bracket.step")

The GUI disconnect

While CadQuery is powerful, the associated GUI, CQ-Editor, reintroduced accessibility issues. Exporting specific features in the editor often requires selecting the rendered geometry in the visual viewport – an action impossible for a screen reader user.

However, because CadQuery is natively a Python library, the GUI is optional. I can circumvent the visual interface entirely by handling the export logic directly within the script (as seen in the code example above). This allows me to execute the Python script via the command line, generating precise STEP and STL artefacts without ever interacting with an inaccessible canvas.

This workflow isn’t without its challenges. Programmatically building 3D models requires a great deal of imagination to picture an object in 3D space as you code each element.

Most designers who create models this way will still use a GUI to view the rendered design, thereby confirming that their code achieves the intended result. For a blind designer, code quality and correct syntax are paramount.

Some AI models can do a reasonable job of describing the model if you provide them your code. They can’t verify that the code is dimensionally accurate, or that the object will render correctly as a 3D object, but they can interpret the intent of the code and at least give you an idea of what the object might look like.

However, at least the barrier to CAD for those of us without sight has been lifted, if not entirely set aside. I will continue to use OpenSCAD for models that are to be 3D printed, and don’t need to be shared with users of visual CAD software who intend to manipulate the models or make edits to them. For everything else, CadQuery gives me the ability to produce designs to my specification, and to iterate over my designs until I’m confident I have the perfect part.