About getting good accessible output

There’s a gap between a description that technically exists and one that’s actually useful to a blind viewer, and between a PDF that’s technically tagged and one a screen reader user can actually navigate with confidence. Our tool closes part of that gap on its own, but not all of it — the rest comes from how you use the tools around it, and from what you check before you publish. What follows is opinion, shaped by what tends to produce the better outcome, not a specification. Take it as a point of view, not a rulebook.

Give our tool real context, not restated facts

The custom instructions field on a video project — up to 10,000 characters — is the single highest-leverage thing you can do before generating anything, and it’s also the thing people underuse most. Our tool can only guess at the things that aren’t visible in the frame: how a recurring character should be referred to, whether the tone should read as warm or matter-of-fact, which visual details actually matter to the story versus which are noise, brand or domain terms it wouldn’t otherwise know. Good custom instructions answer those questions up front. What’s not worth the space is restating things our tool would already infer correctly from the video itself — that wastes the field on facts it didn’t need help with, instead of the judgment calls it did.

Choose Enhanced deliberately, not by default

Enhanced processing re-checks each description before finalizing it, at a higher credit cost than Standard. I’d reach for it when the output is actually going out to a real audience, when the project is long enough that one bad description early on tends to propagate through the rest (a wrong assumption about a character or setting gets carried forward), or when a scene has a lot of visual information competing for a short pause. I wouldn’t reach for it automatically on every project — for a quick internal draft or something you’re still deciding whether to publish at all, Standard is usually the more sensible spend. Treat it as a cost-versus-stakes decision made per project, not a setting you leave cranked up out of habit.

Build the glossary before you need it, not after

A glossary defined at the start of a project is cheap. A glossary added after you’ve noticed the same character described three different ways across a long or multi-part project is expensive, because fixing it properly means going back and checking everything already generated, not just adding an entry going forward. The value of the glossary compounds with project length — on a short single video it barely matters, but on anything long-form or split into parts, defining recurring characters and terms early is the difference between consistency by default and consistency as cleanup work.

Don’t take generated output on faith

Generated content should be checked before it’s published, and how carefully depends on what’s riding on it. For most content, a reasonable skim against the source is enough. For anything where wrong information could actually mislead someone relying on it as their only channel — a safety instruction, a quantity, a direction, the identity of a person — I’d treat a quick skim as insufficient and actually verify the specific claim against the source material. It also helps to have that check done by someone other than whoever wrote the custom instructions; a second pair of eyes is more likely to catch confident-sounding wrong text than the person who already has a mental model of what our tool was supposed to produce. This applies across all three project types — audio descriptions, alt text, and PDF remediation output alike — see Generate and edit audio descriptions, Generate image alt text in bulk, and Fix PDF accessibility issues in the editor for where to make corrections.

Principles worth holding onto regardless of tooling

A few things are true about accessible content independent of what generated it:

• Alt text should describe function or content, not just appearance. An icon that triggers an action needs alt text describing what it does; a chart needs alt text describing what it shows, not just that it’s “a chart”; a purely decorative flourish often needs no alt text at all. The right description depends on the image’s role, not just what’s visually in it.
• Captions need speaker labels and sound cues, not just dialogue. If it isn’t obvious from context who’s talking, say so. Significant non-dialogue sound — a door slamming, tense music, an off-screen alarm — carries meaning too and belongs in the caption track, not just the words being said.
• PDF reading order should match the order a sighted reader would actually follow, not the order content happens to sit in the underlying file. Visual and logical order usually agree, but not always — multi-column layouts and pull-quotes are the common places they diverge, and that’s exactly where reading order needs a deliberate check.
• A logical reading order isn’t just for screen readers. The same structure that makes a PDF navigable with a screen reader also makes it navigable by keyboard alone and with switch-access devices — getting reading order right pays off for more than one audience at once. See About assistive technology for how these tools relate.

None of this replaces judgment with a checklist. Treat the tools as leverage — they get you most of the way there fast — and treat the review step as the part that decides whether “most of the way” was actually good enough.

Working efficiently inside Content Studio’s own editors is a separate question from the accessibility of your output, but if you want to speed up your own workflow, see Editor keyboard shortcuts.