Voice is useful where typing is slow: dictating notes, booking by speaking, reading articles aloud, or helping people who find reading difficult. Gulf businesses also ask for Arabic voice, where dialect matters far more than most people expect.
This guide explains the building blocks, what to test before launch, and how to ask Uttra for a first working version.
A voice app does one of three jobs: turns speech into text, turns text into spoken audio, or does both to hold a conversation. You can describe the job to Uttra in plain language, but accent accuracy, microphone permission and recording privacy need deliberate decisions.
The three building blocks
Speech to text listens through the microphone and returns written words. Text to speech reads written words aloud in a chosen voice. A voice assistant chains them: listen, send the text to an AI model, then speak the answer.
- Dictation: the user speaks, the text appears in a form or note.
- Read aloud: a button on an article or lesson plays the text as audio.
- Voice assistant: ask a question by voice and hear the answer.
- Voice commands: short phrases such as “open my orders”.
Accents and dialects: test with real voices
Recognition quality varies by language, dialect, background noise and microphone. A model that handles formal Arabic well may stumble on Najdi or Hijazi speech, names and mixed Arabic-English sentences. Do not trust a demo; record ten real sentences from your actual users and see what comes back.
Always show the recognised text so the user can correct it before anything important, such as an order or appointment, is confirmed.
Permission, HTTPS and privacy
Browsers only allow microphone access on secure pages and only after the user agrees, so explain why you need it before the prompt appears. Voice is personal data. Say whether audio is stored, for how long and who can hear it, and do not keep recordings you do not need.
Voice and text services from outside providers need an API key that you supply as a project secret. Check the provider’s terms on how audio is handled, especially for children or health content.
- A clear microphone button with a visible listening state.
- A typed fallback for noisy places and for users who decline permission.
- A short privacy note next to the button.
A prompt you can paste
Start small and describe the user’s moment. For example:
“Add a dictation button to the notes page of my clinic app. The user speaks in Arabic, the text appears in the note field, and they can edit it before saving. Add a read-aloud button for each note, a typed fallback if the microphone is blocked, and a short line saying audio is not stored.”