You just clicked through a checkout flow four times to pin down why the discount code fails on the second attempt but not the first. Now you have to write it down. Typing that out, step by step, with the field names and the order of clicks, takes longer than the reproduction did. This is exactly where dictation earns its keep, and exactly where it can also make a report worse if you use it in the wrong spot.
Cobalt Capture lets you add a comment to any captured screenshot by typing or by dictating with the browser's built-in speech recognition. Both produce the same output: an item in a published review that a developer can read and act on. The choice between them is not about preference. It is about what kind of information you are recording.
Dictate the narrative, type the exact values
Steps to reproduce are a story: you did this, then that, then the thing broke. That maps well to speech. When you talk through a flow while looking at the screen you just captured, you naturally keep the order right and you include the small actions that get skipped in typing, like "I tabbed out of the field instead of clicking away." Speaking a nine-step repro takes maybe forty seconds. Typing the same thing, correcting as you go, takes two or three minutes.
The failure mode when you type long repro steps is compression. Under the friction of the keyboard you write "apply a code and check out," which is not a repro at all. The developer replays your shortened version, cannot reproduce the bug, and bounces it back to you as "works on my machine." Now you are doing the whole cycle again. A bug report a developer can actually act on lives or dies on whether the steps are complete, and dictation keeps them complete because talking is cheap.
Exact values are the opposite. Speech recognition will happily turn SAVE20 into "save twenty," a hex color into a sentence, and an error string into something almost but not quite right. Any time the precise characters matter, a coupon code, a URL, an amount like $19.99, a validation message, a field label, type it. The failure mode here is a developer copying a mangled value straight into a search and finding nothing. Ten seconds of typing beats an hour of confusion.
Split by item, not by whole review
You do not have to pick one method for the entire bug. Each screenshot becomes its own item, and you decide per item. A common pattern for one bug: capture the broken state, dictate the repro steps into that item, then add a second free-floating comment where you type the exact error text and the browser version. The review reads as one coherent report even though half of it was spoken and half typed.
Add numbered pins to the screenshot when the order of what you are describing matters. If you dictate "click the field at pin one, then the button at pin two," the pins anchor your spoken narrative to specific spots so the developer is not guessing which button you meant. That pairing, spoken steps plus pins that mark the exact spot, is where dictation is strongest.
The failure mode of dictating everything into one giant item is a wall of run-on speech with no structure. Speech does not insert paragraph breaks or headings for you. Keep each item to one thought and you avoid it.
What to do on Firefox
Dictation uses the browser's Web Speech API, which works in Chrome and Edge. Firefox does not support it, so the dictate option will not produce a transcript there. This is not a reason to switch browsers mid-task. Everything else in Cobalt Capture works in Firefox: capture the screen, crop the still, add pins, type your comments, publish.
If you are a Firefox reviewer and you have a long repro to write, the practical move is to type it with the same discipline you would speak it. Write the steps in order, one action per line, and do not compress. There is a full walkthrough of how a Firefox reviewer types and publishes without losing anything. The output is identical to a dictated one; you just spent a bit more time on the keyboard.
If dictation is central to how your team reports bugs and half the team is on Firefox, standardize on Chrome or Edge for the reporting step. That is a smaller ask than it sounds, because there is no install, no extension, and no signup. A reviewer opens a tab, captures, and publishes. Switching browsers for one task costs nothing.
Read it back before you publish
Speech recognition is fast but not perfect. It drops small words and occasionally hears something wrong in a way that flips the meaning of a step. Before you hit publish, read each dictated item once. You are looking for the two things speech gets wrong most: numbers that came out as words, and negations that vanished ("the button does not respond" turning into "the button does respond").
The failure mode of skipping the read-back is subtle. The report looks complete, the developer trusts it, and they chase a step that says the opposite of what happened. Thirty seconds of proofreading prevents that. Once you have a clean review, the public link, the PDF, and the markdown version an agent can read all carry the same corrected text.
Next bug you catch: capture the state, dictate the steps, type the exact values, read it back, publish. Start a new review and time how long it takes compared to typing the whole thing.