DEV Community: Demir Ajvazi

20 Years with a Screen Reader: What Developers Still Get Wrong

Demir Ajvazi — Mon, 05 Oct 2026 20:57:15 +0000

I am blind, and I have used the JAWS screen reader every day for about twenty years. I fix phones and computers, and I build accessible software: the Ultra suite, a set of creative tools like a video editor and an audio editor that blind and sighted people can both use.

Blind people talk about accessibility problems all the time. We talk about them on mailing lists, in forums, in private groups. The people who could actually fix them almost never read those places. So this time I am writing in public, for every developer, designer and product team who will ever build a button.

None of what follows is rare. I hit these problems almost every week.

1. Buttons and fields with no name

This is the most common problem, and the easiest to fix. A sighted person sees a magnifying glass and knows it means search. My screen reader sees an image with no text and says "button". Or "button, button, button", ten times in a row. Which one sends the form? Which one deletes my account? I have to guess.

Text fields are the same. I land in an edit box and JAWS says "edit". Is it my name, my email, my phone number? If the label is just grey text placed near the field, a screen reader does not know they belong together.

The fix takes seconds:

<!-- Bad: a screen reader says only "button" -->
<button><svg>...</svg></button>

<!-- Good: a screen reader says "Search, button" -->
<button aria-label="Search"><svg aria-hidden="true">...</svg></button>

<!-- Bad: placeholder is not a label -->
<input type="email" placeholder="Email">

<!-- Good: the label is tied to the field -->
<label for="email">Email</label>
<input type="email" id="email" autocomplete="email">

The same rule applies in mobile apps: contentDescription on Android, accessibilityLabel on iOS. Every control a person can touch needs a name a person can understand. Not "btn_submit_2". Not nothing.

2. The CAPTCHA wall

A CAPTCHA asks me to prove I am human by doing the one thing I cannot do: look at a picture. Pick all the traffic lights. Type the blurry letters. The audio version, when it exists, is often so distorted that it fails too.

So the test meant to stop robots stops me. And when it sits in front of registration, login or payment, it locks me out of the whole service.

There are better options. Rate limiting, email or SMS verification, invisible risk checks, and passkeys all stop bots without asking anyone to see. If you must use a challenge, test it with a screen reader before you ship it, and give people another way through.

3. Sites I simply cannot use

Recently I wanted to subscribe to a water dispenser from Knjaz Natura, a water delivery service here in Serbia. A simple task: open the site, register, choose a plan. I could not do it. Unlabeled fields, controls my screen reader could not reach, a page that did not behave like a page. In the end I had to call someone who can see to finish the registration for me.

Think about what that means. I am a developer. I have used screen readers for twenty years. And I still needed help to sign up for water. Every person who gets stuck like this is a customer you lose, and most of them will never write to tell you why.

Before you launch, try this: turn off your monitor, start NVDA (it is free) or VoiceOver, and complete your own main task using only the keyboard. If you cannot finish it, neither can we.

4. Redesigns that take it all away

KupujemProdajem is the biggest classifieds site in Serbia. For years it was fantastic with a screen reader. I could search, read listings and message sellers with no problems at all.

Then came the redesign. Since then, neither the website nor the app works for me. Content my screen reader cannot read, pages I cannot navigate, the same problems everywhere.

This hurts more than a site that was never accessible, because it shows the work had already been done, and then it was thrown away. A new design is a chance to improve accessibility, not a reason to lose it. Put screen reader testing in your redesign checklist, next to performance and browser testing. And keep the users who relied on the old version in the loop.

5. It can be done: Microsoft

I do not want this to be only complaints, because some companies get it right. Microsoft is the best example I know. Office is fully accessible to me: I write, edit and work in it every day with JAWS. Windows is solid too.

That did not happen by accident. It happens when accessibility is part of how a company builds, not a fix added after launch. If a company as big as Microsoft can do it across products used by hundreds of millions of people, a registration form can do it too.

What I ask of every developer

Whatever you build, a website, an app, a small internal tool, check it with someone who uses a screen reader. If you cannot find that person, at least ask an AI assistant to review your interface for accessibility. Either one will catch most of what I described here.

The checklist is short:

Every button has a clear name a screen reader can say.
Every field has a real label tied to it, not just a placeholder.
Everything works with the keyboard alone.
No CAPTCHA that depends only on sight.
Every redesign is tested with a screen reader before release.

None of this is hard. It costs minutes when you build it, and hours, or customers, when you do not. And if you want to know what it is really like, ask us. We have been waiting a long time for someone to ask.

I am Demir Ajvazi, a blind developer from Serbia building the accessible Ultra suite. You can find my work on GitHub.

Ultra Bridge: Translating JAWS Keyboard Commands to NVDA with Sanity Context

Demir Ajvazi — Sat, 26 Sep 2026 01:09:54 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Ultra Bridge is an agent for screen reader users. You ask it things like "What is the NVDA equivalent of JAWS Insert+F7?" or "Which keys do different jobs in JAWS and NVDA?", and it answers from a Sanity dataset through Sanity Context MCP. Every answer says how well the underlying command is verified, so you know whether to trust it or check it yourself first.

I built it because I rely on a screen reader myself, and moving between JAWS and NVDA means relearning keys that look the same but are not. That gap costs real time and real confidence, and it is exactly the kind of problem structured content is good at closing. Ultra Bridge is part of the Ultra suite of accessible software I am building.

The reason it needs structured content: a keyword search can find a page that mentions both screen readers, but it cannot tell you which keys collide, which ones translate cleanly, or which ones simply do not exist yet on the other side. In Ultra Bridge an action ("show a list of all links") is separate from a command (the keys one screen reader uses for that action). Equivalents are found through the shared action, so a relationship question becomes one query instead of a guess.

This query lists every single letter key that exists in both screen readers but does a different job:

*[_type=="command" && screenReader->slug.current=="jaws" && context=="browse-mode"]{
  keys,
  "jawsAction": action->title,
  "nvdaMeansSomethingElse": *[_type=="command" && screenReader->slug.current=="nvda" && keys==^.keys && action._ref != ^.action._ref]{"action": action->title}
}[count(nvdaMeansSomethingElse)>0]

Against the seed data it returns six keys. R is "region" in JAWS and "radio button" in NVDA. Q is "main content" in JAWS and "block quote" in NVDA. A, O, S and D collide too. That is exactly the kind of thing that costs a person time when they switch, and exactly the kind of question a keyword search cannot answer.

Demo

https://ultra-bridge-xm71.vercel.app/

The page has example questions you can press. Open "How this was found" under any answer to see the exact GROQ query the agent ran to get there — nothing is hidden between the question and the data.

Code

https://github.com/demirajvazi10-max/Ultra-Bridge

How I Used Sanity

Schema. Seven document types: screenReader, source, action, command, concept, difference and guide. The dataset currently has 229 documents: 60 actions, 127 commands, 13 concepts, 12 differences, 7 guides and 8 sources.

Trust as data, not as an afterthought. Every command has a verification field (tested-by-author, cross-checked, first-party, third-party, recalled) and references to source documents. The system prompt tells the agent to say the verification level out loud whenever it uses a command, and to point to input help (Insert+1 in JAWS, NVDA+1 in NVDA) whenever a command is not yet confirmed. When two sources disagree, the disagreement is written on the command instead of hidden. Right now 11 commands are tested-by-author, 58 cross-checked, 44 first-party and 14 third-party — zero are still sitting at the weakest "recalled" level, because I keep a running checklist of what still needs a hands-on pass on a real screen reader.

Sanity Context, two modes.

GROQ mode serves the structured dataset. The agent fetches /initial-context over HTTP, puts it in its system prompt, and uses groq_query and schema_explorer for anything that names a specific command, key or action.
Knowledge Base mode serves seven guides written in prose, reserved for open-ended questions like "what should I learn first" or "how are the two screen readers different overall," where a single structured query would not be the right shape of answer. The Knowledge Base is created and built from the CLI (sanity context create, imports create, build --watch).

The two initial_context tools have the same name, so the agent drops both and inlines their content directly into the system prompt instead. If the Knowledge Base endpoint is unavailable, the agent falls back to the structured dataset only rather than failing the whole request.

Engineering for free-tier reality. The public demo runs on free model tiers, which cap tokens per minute hard enough that a naive integration falls over under real traffic. So the agent only exposes the two tools it actually needs (groq_query, knowledge_base_read), compacts every tool result before it goes back to the model (stripping fields the model does not need and hard-capping length), and chains four model providers (Google, Groq, Cerebras, Anthropic) so a rate limit on one provider fails over to the next instead of failing the request. The public page also rate-limits per visitor.

What I learned.

One endpoint serves one source type, so the structured data and the Knowledge Base need separate access paths.
GROQ match is tokenised text matching, so I use equality (==) for keys that contain +, or the match would silently split "Insert+F7" into pieces.
The Sanity CLI covers almost everything I needed: project, schema deploy, dataset import, tokens and the Knowledge Base. That mattered because I work from the command line.
Because Sanity's API was not reachable from where I built the first version, I wrote a small local server that speaks the Context MCP tool names and evaluates real GROQ with groq-js. It let me test the agent, the prompt queries and the whole interface offline, and it ships in the repo so anyone can try the project without accounts.

Accessibility. I am blind and use JAWS day to day, and I tested this myself before anyone else touched it. The interface has a skip link, real headings for every question and answer, one polite live region that announces the full answer once when it is complete, a "read last answer again" button, and stable focus in the question box. An end-to-end test drives it in Chromium and runs axe-core in light and dark colour schemes, so accessibility is checked automatically, not just by hand.

Sanity Project Details

Project ID: u2f7mbu5
Dataset: production (public)

AI Camera — Fan Edition: it hypes up your jersey like a stadium commentator 🏆

Demir Ajvazi — Sun, 12 Jul 2026 00:24:13 +0000

This is a submission for Weekend Challenge: Passion Edition

AI Camera — Fan Edition 🏆📷

What I Built

AI Camera is a phone-camera app that describes what it sees, out loud, in real time — powered by Google's Gemini vision model. It started as an assistive tool for blind and low-vision users (general scene description, reading text aloud, describing an item for a marketplace listing, describing a person's appearance). For this challenge, I added a fifth mode built specifically around passion:

🏆 Fan Mode — point your phone at a jersey, scarf, flag, or any fan gear, and the app turns into a hyped-up stadium commentator, calling out colors, team details, and team spirit with real enthusiasm. With the World Cup happening right now, it felt like the right moment to build it.

📱 Important: this is a mobile-first app. It's built around your phone's rear camera and needs to be held up and pointed at real things — please try it on a phone, not a desktop, for the intended experience.

Demo

🔗 Live app (open on your phone): https://demirajvazi10-max.github.io/ai-camera-fan-edition/

You'll need a free Gemini API key from aistudio.google.com/app/apikey — paste it in when the app asks. It's stored only in your browser and never leaves your device except to call Google's API directly.

(I wasn't able to put together a screen recording for this submission — camera-based apps are a bit awkward to record on a phone! Since the whole thing runs client-side with no backend, the live link above lets you try Fan Mode yourself on your own phone in about 30 seconds.)

Code

https://github.com/demirajvazi10-max/ai-camera-fan-edition

How I Built It

Passion shows up in different ways. Sometimes it's the quiet kind — building something so a person who can't see can still "see" the world around them. Sometimes it's the loud kind — losing your mind over your team's jersey during a World Cup year. I already had the first one built. Adding Fan Mode let the same engine carry both.

Vanilla HTML/CSS/JS — no framework, no build step, no backend
Camera access via getUserMedia, photo captured to a canvas and sent as base64 to the Gemini API (gemini-flash-latest) with a mode-specific prompt
Each mode is just a different prompt string — Fan Mode's prompt asks Gemini to respond "like a hyped-up sports commentator hyping up the crowd"
Responses are read aloud via the browser's Web Speech API (free, works offline once the page is loaded)
The whole thing is one static index.html, so it deploys straight to GitHub Pages with HTTPS — which matters, because phones require a secure context for camera access

Prize Categories

Best Use of Google AI — Gemini's vision model is the core of the app; every one of the five modes depends on it to analyze the photo.

Notes for judges: please test on a phone if possible — that's the intended experience (rear camera + held up to real objects). Fan Mode is the new addition for this challenge; the other four modes existed before as an accessibility tool.

Reviving Ultra Creative Suite: The First Fully Accessible Video Editor for Blind Users

Demir Ajvazi — Sat, 30 May 2026 00:13:16 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Ultra Creative Suite is a professional video and audio editor for Windows, built from the ground up for blind and low-vision users. Every feature works equally for sighted and non-sighted users — no compromises, no stripped-down accessible mode.

I am blind. I use JAWS for Windows daily. I built this because no professional video editor on the market — Adobe Premiere, DaVinci Resolve, Final Cut — is actually usable with a screen reader.

The project includes an AI video generator that takes a single audio file and produces a complete 4K video: lyric analysis, automatic stock footage download, mood-based color grading, ambient sound mixing, and GPU-accelerated rendering.

Demo

GitHub: https://github.com/demirajvazi10-max/Ultra-Creative-suite

The demo video in the repository was created entirely by me — blind, using JAWS only. AI analyzed the lyrics, selected stock footage, applied color grading, mixed ambient sounds, and rendered to 4K. Zero sighted assistance.

The Comeback Story

The project existed and worked, but had several critical issues that made real-world use unreliable:

Before:

Audio fade timing was broken — afade filter used absolute timestamps instead of stream-relative timing, causing ambient sounds to fade incorrectly
totalDuration was not adjusted for AudioStartSeconds, so videos were consistently shorter than expected (2:57 audio rendered as 2:49)
SmartOutroPool had no cap on clip repetition, causing the same outro clip to repeat endlessly
Temp files were written directly to D:\ drive instead of system temp folder, cluttering the disk
IskraSync used incorrect timing references, causing beat-locked edits to drift

After (with GitHub Copilot):

afade now uses st=0 relative to stream start — ambient sounds fade correctly
totalDuration is now corrected immediately after beat detection: rawDuration - AudioStartSeconds
SmartOutroPool has repetition cap, recycle pool, and ultra-safe fallback queries
All temp audio batches now go to %TEMP%\UVE_MixAudio_* with automatic cleanup after render
IskraSync rebuilt to use timelineSpan as primary measure with proper beat-lock offset

GitHub Copilot helped me understand the scope of changes across three files simultaneously and generated a precise commit description that captured every fix — something that would have taken me much longer to write manually while navigating with a screen reader.

My Experience with GitHub Copilot

As a blind developer, navigating code with a screen reader is significantly slower than visual inspection. GitHub Copilot changed my workflow in a concrete way.

When I modified three files — AIVideoCreator.xaml.cs, RenderEngine.cs, and SkiaAnimationEngine.cs — Copilot generated this commit description automatically:

"Multiple fixes across AIVideoCreator, RenderEngine and SkiaAnimationEngine: correct audio fade timing (afade) relative to asetpts/stream start; adjust totalDuration by subtracting AudioStartSeconds so -ss trimming doesn't shorten output unexpectedly; implement SmartOutroPool with max clip duration, recycle pool, ultra-safe fallback queries and fade-out tagging..."

That level of detail would have required me to re-navigate every changed file manually. Copilot gave me that summary instantly, which I could then use directly as a commit message.

For accessibility, this is not a convenience — it is a genuine productivity multiplier.

I'm Blind. I Built a Professional Video Editor. Here's Why.

Demir Ajvazi — Fri, 29 May 2026 12:41:14 +0000

Every time I opened Adobe Premiere, DaVinci Resolve, or any other professional video editor, I hit the same wall. Buttons without labels. Timelines that exist only as visual elements. Drag-and-drop workflows that assume you can see where you're dragging. For a sighted user, these tools are industry standard. For me — a blind developer using JAWS for Windows — they are practically unusable.
I got tired of waiting for someone else to fix this.
So I built Ultra Creative Suite.
What it is
Ultra Creative Suite is a professional video and audio editor for Windows, built from the ground up with one rule: every single feature must work equally for blind, low-vision, and sighted users. No "accessible mode" that hides features. No stripped-down alternative workflow. The same full editor, for everyone.
What it can do
Give it an audio file — a song, a narration, anything — and it will:

Analyze lyrics using a local AI model (Ollama / Qwen 2.5 14B)
Detect mood, season, and energy per lyric line
Automatically download matching stock footage from Pixabay
Apply per-lyric color grading via FFmpeg curves
Mix ambient sounds from a library of 1,279+ categorized clips
Render the finished video to 4K

All of this is controllable entirely through the keyboard. Every action is announced by the screen reader. No mouse required for any core workflow.
The technical decisions that made accessibility possible
The most important decision was the timeline. Most video editors use custom-drawn UI elements for their timelines — visually rich, but completely invisible to screen readers. I used a Win32 native ListView control instead. The same Windows control used in File Explorer. JAWS and NVDA read every clip natively, without plugins or workarounds: clip name, type, duration, position, and AI-generated audio description.
Every dialog has proper focus management. Every action produces a live region announcement. The entire application is navigable with standard keyboard shortcuts.
The demo
The demo video linked in the repository was created entirely by me — blind, using JAWS only. No sighted assistance at any point. AI analyzed the lyrics, selected the footage, applied the effects, mixed the audio, and rendered to 4K. I controlled every step through the keyboard.
Why open source
Because I'm not the only blind developer who has hit this wall. And I'm not the only blind person who wants to create. Ultra Creative Suite is GPL-3, fully open source, and designed to be a reusable foundation for accessible creative software.
If you've ever thought "why isn't there accessible software for X" — maybe this is the starting point.
Links
GitHub: github.com/demirajvazi10-max/Ultra-Creative-suite
If you want to support the project: ko-fi.com/ultra-creativesuite or paypal.me/demirajvazi10