DEV Community: Demir Ajvazi

Ultra Video Editor 2.0: a professional video editor you can use with the keyboard alone

Demir Ajvazi — Sun, 01 Nov 2026 23:05:19 +0000

A few weeks ago I wrote about the audio description feature in Ultra Video Editor. Since then the editor has grown up. Version 2.0 is out, and it is the biggest release so far: the jump from "an editor that works with a screen reader" to "a professional editor that works with a screen reader".

You can use the whole program with the keyboard only, and every action is spoken back to you. Sighted users can work with it like any other app, using the mouse and a normal visual interface.

Tracks, layers and live playback

Up to 60 video and 60 audio tracks, each with a name, a lock and an on/off switch.
Live playback of the whole timeline, without rendering first: layers, colour, titles, subtitles, transitions and the full sound mix, in picture sizes up to 1920×1080.
J, K and L work the way editors expect: L plays faster with every press, J plays backwards at 1×, 2× and 4×.
F4, "Where am I", tells you what is under the playhead on every track.

Editing

Ripple delete, slip, roll and slide edits, J and L cuts, speed ramps with smooth slow motion, keyframe animation with ease-in, ease-out and hold curves, compound clips, and multicam: up to nine cameras, lined up automatically by their sound. You cut between them live with the keys 1 to 9.

Colour, described in words

Curves, colour balance for shadows, mid-tones and highlights, changing a single colour, and power windows that correct only an oval, a rectangle or a graduated part of the picture, such as the sky. Instead of scopes there is a spoken colour analysis: brightness, contrast, lost blacks and whites, colour cast and the main colours. It can also match one shot's colour to another.

Masks and object tracking

Masks of any shape, including your own points, that can move or follow an object. Describe an object in words ("the man in the red jacket") and the picture AI finds it and follows it through the clip, so you can blur it, pixelate it, light it up or attach a label to it.

Sound

A track mixer with EQ, compressor, pan, noise reduction, de-esser, echo and limiter on every track, plus volume automation from the keyboard.

Formats and exchange

H.264, H.265 and H.265 10-bit, ProRes, DNxHR and lossless FFV1. Timelines go to other editors and come back as OpenTimelineIO, EDL or Final Cut 7 XML, in both directions.

Help you can actually read

The keyboard shortcuts (F1) and the manual (Ctrl+F1) are now web pages with headings and tables, so any screen reader reads them completely. The shortcut page is built from the program's own menus, so it never goes out of date. Every menu command is read together with its shortcut, as in other Windows programs.

Three languages, all the way through

English, Serbian and German. The whole interface follows your choice: dialogs, spoken messages, key names and the manual.

Try it

Ultra Video Editor is free and open source, part of the Ultra Creative Suite:
https://github.com/demirajvazi10-max/Ultra-Creative-suite/releases

Feedback is very welcome, especially from people who edit video with JAWS or NVDA, and from sighted editors who want to try a keyboard-first workflow.

My Video Editor Now Writes Audio Description for Your Videos

Demir Ajvazi — Wed, 21 Oct 2026 23:31:15 +0000

A while ago I wrote about Ultra Video Editor, the free, open-source video editor I've been building. This post is about its newest feature, and the one I'm proudest of: built-in audio description.

The problem nobody fixes

Almost no video on the internet has audio description: the extra narration, like on Netflix, that tells you what is happening on screen. "She opens the door. A man in a grey coat is waiting outside." For blind and visually impaired viewers, that narration is the difference between following a story and listening to music with random sounds in it.

It's rare because it's expensive and slow. Someone has to watch the video, write a script, find the pauses, record a voice and mix it in. Small creators simply don't do it.

My wife writes children's songs, and we make music videos for them. I wanted every child to be able to follow those videos, not only hear the songs. So I built audio description into the editor.

What it does

In Ultra Video Editor 1.4.6, you press Ctrl+Alt+A, choose a video (the finished render, a clip from the timeline, or any file), and press one button.

Gemini watches the whole video, with its sound. Not frame by frame: the whole thing. It sees movement and what happens across shots, keeps characters consistent, reads on-screen text, and hears the singing or dialogue, so it places each description into a pause. In a song that is sung almost all the way through, it speaks briefly over the singing, so the picture is never left undescribed for long.
You get a script you can edit. Plain text, one line per description: time | text. Change anything you like.
A natural voice reads it. Microsoft's neural voices are free and need no key; Google's Chirp 3 HD voices work with a Google Cloud key.
The editor mixes it into the video. The music is lowered under each description. You also get a .txt for the YouTube description and a .vtt description track.

Long videos, films and series, are described in 10-minute parts, and each part knows what was described before it, so names stay the same.

Here's the beginning of the real script it wrote, in Serbian, for one of our songs ("A Song About Walking"), translated for this post:

00:01 | Title: "Iskra – A Song About Walking".
00:03 | A smiling boy.
00:06 | A playground from above, then soap bubbles against a blue sky.
00:14 | A girl in a ball pit, then a girl running through a fountain.
00:20 | The wind turns the pages of a book on the sand; people walk across a courtyard.
00:25 | A baby sleeps, then the sun lights up the grass.
00:31 | A father plays with his daughter in the park.
00:46 | In winter, a father hugs his little daughter, then the mother carries her on her back.

Thirty descriptions for a three-minute song, in natural Serbian, ending with the closing credits read out loud.

It didn't start this good

The road was bumpy, and I think that part is worth sharing.

The first version only described the beginning and the end of the video. The next one described every shot, but cut sentences to fit: "A girl walks through the forest with a." Then I switched to Serbian, and a small local vision model gave me gems like "in the sky there are bubbles", with invented words and grammar from the wrong language.

The fix was to stop describing pictures one at a time and let a model watch the whole video with its sound, the way a human describer works. The difference wasn't small. It was a different product.

The offline option is still there for videos that should never leave your computer: it now uses Qwen3-VL through Ollama, and runs even on a 6 GB laptop GPU.

Works with a screen reader, start to finish

I use a screen reader every day, so everything in the editor is built to work with JAWS and NVDA as well as with a mouse. The audio description window says what it's doing ("Sending the video: 50 percent", "Gemini is describing part 3 of 12"), the focus always lands on the next step, and a short sound plays when the work is done.

Try it, and tell me what breaks

Ultra Video Editor is free and open source (GPLv3), in English, Serbian and German:
👉 https://github.com/demirajvazi10-max/Ultra-Creative-suite

A Gemini key is free from Google AI Studio, and the Flash models have a free tier. A friend is already testing it on films. I'd love to hear how it does with your videos, especially in other languages.

If you'd like to support the project, you can do it on GitHub Sponsors.

Thanks for reading, and if you make videos, describe them. Someone is listening.

My GitHub Sponsors Is Live: Help Me Build Creative Tools Blind People Can Actually Use

Demir Ajvazi — Wed, 14 Oct 2026 16:45:21 +0000

After months of waiting, my GitHub Sponsors profile is finally live! 🎉

Who I am

I'm Demir Ajvazi, a blind developer from Serbia. I've been using the JAWS screen reader for about 20 years. For most of that time, I've watched creative software lock out people like me: professional video, audio and photo editors are nearly impossible to use with a screen reader.

What I'm building

So I started building the Ultra Creative Suite: open-source creative tools designed from the ground up to work equally well for blind and sighted users. Not a stripped-down "accessible mode", and not a workaround, but real tools that both blind and sighted creators can use side by side.

Alongside the suite, I'm working on other accessible tools:

UltraShield: an accessible digital self-defense app for Windows
Ultra Uninstaller: a Windows uninstaller and cleaner that is fully usable with a screen reader
Ultra Bridge: a JAWS and NVDA command-mapping helper

You can find everything here: github.com/demirajvazi10-max

How you can help

If you believe blind people deserve the same creative tools as everyone else, you can now support my work directly:

👉 github.com/sponsors/demirajvazi10-max

Monthly sponsorships start at $3, and one-time support is welcome too. Every contribution goes directly into development and keeps everything free and open source.

Can't sponsor? That's completely fine. Sharing this post, starring a repo, or trying the apps with a screen reader and telling me what doesn't work helps just as much.

Thank you for reading!

If you want the full story of why I started, I wrote about it here: I'm Blind. I Built a Professional Video Editor. Here's Why.

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.

Creative Tools That Start With the Keyboard: Why I Built My Own Video Editor

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 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