TL;DR: AI coding tools can help people build small accessibility tools around needs they understand firsthand. A lyric reader and a VoiceOver utility show the opportunity—and why working code still needs testing with the person, device and settings it is meant to serve.

Start with the interruption

Ashley takes a braille display to singing lessons. Listening to spoken lyrics through an earpiece would compete with the lesson; reading them makes more sense. But ordinary lyric websites bring navigation and formatting that get in the way of moving through a song line by line.

In an October 28 account, Ashley describes building Lyrx with Codex, specifying native Apple interfaces, keyboard shortcuts and development rules. The useful idea is modest: find the words and present them in a form suited to the task. AI helps turn knowledge of that task into software.

Lyrx source and build instructions 

What makes a lyric reader different?

Lyrx uses native text controls, actual line breaks and an adjustable line-length limit. It preserves whole words rather than chopping them to fit. Its documentation makes a consequential distinction: text characters are not the same as translated braille cells. Contractions and translation settings can change how much fits on the physical display.

That is a useful product lesson. “Show forty characters” is a software rule; “let me read the next phrase comfortably” is the user's goal. The two need checking together.

Lyrx is an early source-code project requiring Xcode, rather than a ready-to-download public release. Its verification notes report software and simulator checks, while explicitly leaving physical braille-display validation outstanding. It is a promising worked example, with that boundary visible.

A second example: make one setting predictable

In September, Paul Martz published vo-ignore, a small AI-assisted utility for a frustrating VoiceOver behaviour. It sets mouse-pointer tracking to a known state and speaks a confirmation, so the user need not work through a cycling setting to discover where it landed.

vo-ignore source 

The implementation uses an undocumented Apple framework and was tested on macOS 27. That makes compatibility an ongoing maintenance question. The repository explains both its purpose and its dependence on those private interfaces.

The response produced another practical example: community member mr grieves reported using Claude to create scripts that speak a line's indentation and make long PascalCase words easier to understand. That is a specific adaptation inspired by the original project, rather than a claim that every accessibility problem has been solved.

Martz's original account and the follow-up discussion 

A useful way to approach your own small tool

1. Describe the task that fails. Give the starting state, the action, the interruption and the result you need. A concrete reproduction is more useful than asking an agent to “make it accessible.”
2. Keep the first version narrow. Reading one lyric or restoring one setting gives you a result you can judge directly.
3. Test the interaction, not just the output. Can you reach the result by keyboard? Does focus land where reading should begin? Does an error leave you somewhere understandable?
4. Keep a compatibility record. Note the operating system, assistive software, hardware and settings actually tested. Treat a passing simulator check and a successful physical-device session as different evidence.

For web projects, W3C's guidance recommends combining accessibility standards with evaluation involving disabled users. It also cautions against generalizing one person's experience to everyone. The same practical question is valuable here: whose task did we actually make easier, under which conditions?

W3C: involving users in accessibility evaluation 

Ashley's original Lyrx account