Written by: Nubank Editorial

A conversation with an AI assistant looks like a text interface, and that can make it seem inherently accessible: there are no complex menus to navigate, no dashboard full of widgets, and much of the interaction happens through words. However, it’s important to say that text and accessible text are not the same thing.

Many of the conventions we use when interacting with coding assistants assume that the person on the other side can visually scan the response. A comparison becomes a Markdown table. A change is communicated through a diff. Architecture is compressed into a diagram. A long build log is pasted into the conversation. References such as “see above” or “as shown below” assume that moving between different parts of the response is trivial.

For a developer consuming Claude primarily through a screen reader or read-aloud functionality, these conventions can behave very differently. Information that is visually organized may become a long sequence of disconnected words when spoken, while code that can be skimmed in seconds must instead be traversed linearly and a spatial reference loses much of its usefulness when there is no visual space to point to.

This initiative emerged in the context of NuPlural, Nubank’s Employee Resource Group (ERG) for people with disabilities. Created in 2021, the community grew from five people to more than 400 and provides a space for Nubankers with disabilities to exchange experiences, support one another, and contribute to building a safer and more inclusive workplace. NuPlural also works to strengthen belonging and support the career development of Nubankers with disabilities.

In this context, a Nubank employee with a different perspective and experience, specifically with  a low-vision Nubanker turned a recurring interaction challenge into a practical bundle of instructions they now use daily with Claude. The configuration has also been shared with other Nubankers and can be used by anyone who finds this interaction model useful.

The result is an internal instruction set called BLIND-CLAUDE.md, created in the development environment and referenced from CLAUDE.md. It does not modify Claude itself or introduce a new native accessibility feature. Instead, it adds a set of behavioral instructions on top of the other CLAUDE.md instructions already in scope.

The premise is stated directly in the file: responses in this context are “consumed primarily by ear (screen reader / read-aloud), not by eye.” Formatting decisions that may be harmless for sighted reading can therefore introduce friction when narrated aloud, and that changes what a good AI response looks like.

When good visual UX becomes difficult audio UX

Consider a Markdown table comparing three implementation options. For a sighted reader, the columns establish relationships almost immediately, as you can move from an option name to its advantages, disadvantages, and constraints, then jump horizontally or vertically to make comparisons.

A screen reader, however, has to turn that two-dimensional structure into a sequence. What looked concise on screen can become what BLIND-CLAUDE.md describes as “a wall of disconnected cell values with no structure.” The instruction therefore tells Claude to prefer short prose or plain lists instead of dense tables.

The same problem appears in less obvious places. Take “see the example above.” Visually, “above” is a location. Audibly, it is an instruction to navigate backward through a stream of information and determine which earlier section the author had in mind. The Skill instead requires references to be self-contained: briefly restate what matters rather than relying on where something appears on the screen.

Diagrams expose an even clearer assumption. A flowchart can convey relationships through position, arrows, grouping, and direction, but those relationships cannot be assumed to survive when the artifact is consumed linearly. BLIND-CLAUDE.md requires diagrams to have a plain-language textual equivalent so that the visual representation is never the only way to access the information.

The underlying question is what happens when the same information is heard rather than scanned.

Check our job opportunies

A simple principle: design the response to work linearly

The central rule in BLIND-CLAUDE.md provides a useful test for every response:

“Every response must make sense read top-to-bottom, out loud, in order.”

The file goes further: understanding the response should not require visually scanning it, jumping around, or repeatedly returning to a diagram. When a shortcut saves visual space but reduces clarity for someone listening, Claude should choose clarity instead.

That principle turns auditory consumption into an explicit engineering constraint. Instead of asking only, “Is this technically correct?” or “Is this concise?”, the assistant is effectively being asked another question: “If someone hears this response sequentially, does the information still work?”, and a real example from the workflow makes the distinction clearer. Claude was asked:

“Could you describe how the diplomat architecture works? I would like to have this answer with and without the BLIND-CLAUDE.md instructions.”

Without the accessibility instructions, part of the response compressed the architecture into structures designed to be scanned quickly. The data flow, for example, was represented with arrows:

wire.in → adapter → model → logic → controller

The response then separated information into sections such as “Data flow,” “Schema rules,” and “Anti-patterns to avoid,” using short bullets and compact notation.

For a sighted developer, that format has advantages. A single glance at the arrows communicates direction. The reader can jump between sections and selectively inspect whichever rule is relevant.

With BLIND-CLAUDE.md active, Claude reorganized essentially the same technical explanation as linear prose.

Instead of making the arrow diagram carry the relationship between components, the response first explained the architecture’s purpose and then introduced each area in sequence. It described how logic remains isolated from external I/O, what adapters do, how controllers orchestrate work, where external interactions happen, and how models and wire schemas fit into the architecture.

Only then did it narrate the data flow: an incoming request arrives through a wire schema, an adapter converts it into an internal model, logic and controllers operate on that model, and the process is reversed for outgoing data.

The important distinction is that the second response does not require the listener to reconstruct a visual relationship. The technical content remains, while the information architecture changes.

Encoding accessibility into Claude’s behavior

The implementation is deliberately lightweight: the accessibility instructions live in BLIND-CLAUDE.md, referenced from CLAUDE.md. The file explicitly states that its rules operate on top of the other CLAUDE.md instructions already in scope.

From there, the file translates one accessibility requirement — responses need to work when heard — into concrete behavioral rules for the assistant.

Code is a good example. Developers who can see a response may skim a snippet to recognize its purpose without reading every token. That assumption does not hold when the same snippet is narrated. For this reason, the Skill instructs Claude to explain what code does before or alongside the snippet. Even a short snippet should not be the sole carrier of the response’s meaning.

This creates a subtle but important change in how Claude communicates technical information. The explanation becomes primary; the code becomes evidence or implementation detail supporting that explanation.

The same reasoning applies to diffs. A developer looking at a diff can often understand the change by scanning additions and deletions. Listening to the same diff means encountering punctuation, line markers, syntax, and code sequentially. BLIND-CLAUDE.md therefore asks Claude to describe file changes in plain language rather than relying on the visual shape of the diff to explain what happened.

Noisy tool output receives similar treatment. Build logs, grep results, and long diffs are often useful precisely because a developer can scan them and identify the significant lines. Reading the same output from beginning to end changes the cost dramatically. The Skill directs Claude to first reduce long tool output to the two or three lines that actually matter rather than narrating raw output verbatim.

Conciseness itself becomes an accessibility consideration. The instructions favor “a few clear sentences” over unnecessarily elaborate structures unless the user specifically asks for a checklist or breakdown.

The goal is to stop relying on the visual properties of codes, diagrams, diffs, or other useful artifacts as the only path to understanding.

Accessibility as an engineering constraint

There is a broader idea behind these relatively small instructions. AI assistants are often optimized around the content of their answers: correctness, completeness, relevance, or tone. But the modality through which that answer is consumed also shapes whether the response works.

A technically correct answer can still be difficult to use, and that suggests another layer of context worth encoding into AI-assisted workflows: not only what the user wants to accomplish, but how the interaction itself needs to behave.

In this case, that requirement comes directly from lived use. The person who created the instruction bundle is low vision and uses it daily to interact with Claude. The configuration was then shared with other Nubankers.

That distinction is important because the instructions are not based solely on an abstract idea of what an accessible response should look like. They encode interaction choices being used in an actual development workflow.

At the same time, this is not yet evidence of a universally validated accessibility pattern. No feedback from other users has been collected so far, and the configuration should not be presented as representing every blind or low-vision developer’s preferences. Accessibility requirements can vary significantly between people, tools, workflows, and assistive technologies.

What the implementation demonstrates is more specific: characteristics of an interaction can be translated into explicit constraints on AI output.

In this case, the assistant is told that its responses will primarily be heard. That one constraint has downstream consequences for information architecture. Tables become prose, spatial references become explicit references, diagrams gain textual equivalents, and diffs become descriptions of changes. Code gains an accompanying explanation, while logs are summarized before details are surfaced.

The user no longer has to remind Claude of these preferences in every prompt. By moving them into the instruction layer, the interaction modality becomes part of the environment in which the assistant operates.

And although this particular bundle emerged from one person’s workflow, its use does not have to stop there. The instructions can be adopted by other Nubankers as well.

That also creates room for iteration. The next useful step would be to gather feedback from other people who use the configuration and refine the Claude instructions based on what works, what creates friction, and what different workflows require. This is an opportunity for the bundle to evolve through use rather than being treated as a finished set of rules.

What this teaches us about building AI tools

Generative AI makes producing information easy. That does not automatically make the resulting information easy to consume.

As AI assistants become more deeply integrated into development workflows, the shape of their responses matters alongside their technical accuracy. An answer might be perfectly understandable as a page and frustrating as an audio sequence. A compact visual abstraction can become verbose when narrated. A code-heavy answer can require substantial effort from someone who cannot skim it visually.

BLIND-CLAUDE.md addresses those problems with a relatively direct idea: if the primary interface is auditory, write instructions that make the assistant communicate for an auditory interface.

That means designing for sequence rather than position, explanation rather than visual inference, and signal rather than raw output.

It also points toward a useful way of thinking about AI configuration more broadly. Instructions can encode more than coding conventions, repository knowledge, or preferred workflows. They can encode constraints about how information needs to be presented and consumed.

The implementation described here is small, but the design question behind it is not:

What changes when we stop assuming that an AI response will be seen and start designing it to be heard?

Check our job opportunies