Chrome 153 Trouxe Novos Elementos HTML para Câmera e Microfone — Eu Testei e Veja Como Usar

A ideia parece simples: permitir que uma página solicite acesso à câmera ou ao microfone utilizando um controle HTML próprio, com uma interface administrada pelo navegador e uma ação explícita do usuário antes que a permissão seja solicitada.

Mas a novidade fica muito mais interessante quando colocamos a mão no código.

Neste artigo, vou mostrar como funciona essa nova abordagem, como podemos montar um exemplo prático e, principalmente, onde ela se encaixa em relação às APIs que os desenvolvedores já utilizam para trabalhar com câmera e áudio na Web.

1. O que o Chrome 153 mudou?

O Chrome 153, lançado em setembro de 2026, adicionou os elementos de capacidade <camera> e <microphone>.

A proposta deles é relativamente direta: quando a aplicação precisa somente de vídeo, pode utilizar o <camera>. Quando precisa somente de áudio, pode utilizar o <microphone>.

Isso é diferente de simplesmente criar um botão qualquer e tentar ligar a câmera automaticamente. Esses elementos são controles ativados pelo usuário e possuem uma interface controlada pelo próprio navegador.

Webcam Full Hd 1080p Microfone Pc Notebook Home Office Nova Pronta Entrega

Quer mais qualidade nas suas videochamadas? Com esta Webcam Full HD, você garante uma imagem profissional e áudio limpo para impressionar em qualquer reunião, aula ou live. Principais Benefícios: Resolução Full HD (1080p), Vídeos com riqueza de detalhes e cores vibrantes.

Consulte o preço no site

(10000 avaliações)

Shopee

Comprar Agora*Link de Parceiro

2. Por que isso é interessante para quem desenvolve para a Web?

Para quem acompanha desenvolvimento Web, a novidade é interessante por um motivo específico: o navegador está assumindo uma parte maior da interação necessária para solicitar uma capacidade do dispositivo.

Antes de começar a experimentar esse tipo de recurso, é comum pensar imediatamente em JavaScript, permissões, streams, eventos e chamadas de APIs.

O novo modelo tenta deixar alguns desses casos de uso mais declarativos.

Isso não significa que JavaScript deixou de ser necessário. Muito pelo contrário. Quando precisamos manipular o stream, mostrar o vídeo em um elemento, gravar conteúdo, tirar fotografias ou processar áudio, continuaremos precisando de lógica adicional.

A diferença está no ponto de partida: existe agora um elemento HTML específico para representar a intenção de solicitar uma determinada capacidade.

3. Começando pelo <camera>

Vamos começar pelo caso mais fácil de visualizar: a câmera.

A ideia básica é utilizar o elemento <camera> na própria estrutura HTML da página.

<camera id="camera">
    <button>Ativar câmera</button>
</camera>

O ponto mais importante desse exemplo é entender que não estamos criando um botão comum e tentando descobrir depois como iniciar a câmera.

Estamos utilizando um elemento de capacidade que foi criado justamente para esse tipo de interação.

O navegador controla a interface relacionada à captura e exige uma ação intencional do usuário.

4. O clique do usuário continua sendo importante

Essa foi uma das partes que mais merece atenção nessa novidade.

A câmera de um computador ou celular é um recurso sensível. Por isso, não faria sentido uma página abrir o dispositivo automaticamente assim que fosse carregada.

O Chrome descreve esses elementos como controles HTML declarativos ativados pelo usuário. Na prática, existe uma ação explícita antes que a solicitação de permissão seja disparada ou que um stream seja iniciado.

Isso também ajuda a deixar a experiência mais previsível para quem está visitando a página.

5. E o que acontece quando a câmera é autorizada?

Aqui começamos a entrar na parte que interessa para quem realmente pretende construir uma aplicação.

Solicitar a capacidade da câmera é apenas uma etapa. Um projeto real pode precisar mostrar a imagem capturada em um elemento <video>, capturar quadros, tirar uma fotografia, gravar vídeo ou processar os dados recebidos.

É nesse ponto que JavaScript volta a ganhar importância.

<video id="preview" autoplay playsinline></video>

O elemento <video> pode servir como área de visualização para o conteúdo de vídeo quando a aplicação obtém e manipula o stream.

Esse é um bom exemplo de como o novo elemento não deve ser confundido com uma solução completa para todos os projetos de vídeo. Ele simplifica a solicitação da capacidade, mas a aplicação ainda precisa decidir o que fará com o conteúdo capturado.

6. Agora vamos para o <microphone>

O funcionamento conceitual do <microphone> segue a mesma ideia, mas a capacidade solicitada é diferente.

Enquanto o <camera> solicita captura de vídeo, o <microphone> solicita captura de áudio.

<microphone id="microphone">
    <button>Ativar microfone</button>
</microphone>

A vantagem fica evidente em aplicações que precisam somente de áudio.

Imagine, por exemplo, uma página para gravar uma mensagem de voz, testar um microfone, criar uma ferramenta simples de transcrição ou construir uma interface de comunicação. Nesses casos, não necessariamente existe motivo para solicitar acesso à câmera.

Separar essas capacidades torna a intenção da aplicação mais clara.

7. <camera> e <microphone> não substituem todo o JavaScript

Essa é provavelmente uma das maiores confusões que podem surgir ao ler sobre a novidade.

É tentador olhar para um novo elemento HTML e imaginar que agora basta escrever algumas linhas de marcação para construir uma aplicação completa de videoconferência.

Não é bem assim.

Os novos elementos facilitam a solicitação de uma capacidade específica. Eles não eliminam a necessidade de programação quando o projeto precisa manipular o stream, gravar mídia, processar dados, alterar a interface ou enviar informações para um servidor.

Pense neles como uma nova peça da caixa de ferramentas, e não como uma substituição completa das APIs de mídia existentes.

8. Como isso se compara ao getUserMedia()?

Quem já trabalhou com acesso à câmera no navegador provavelmente conhece getUserMedia().

A abordagem tradicional envolve solicitar um MediaStream por meio da API de mídia e então trabalhar diretamente com esse stream em JavaScript.

navigator.mediaDevices.getUserMedia({
    video: true
});

Esse modelo continua sendo extremamente importante quando precisamos de controle programático sobre a captura.

A diferença é que os novos elementos do Chrome oferecem uma alternativa declarativa para situações em que a aplicação precisa solicitar uma única capacidade.

Portanto, eu não trataria a novidade como “o fim do getUserMedia”. É mais interessante enxergá-la como outra maneira de resolver determinados cenários.

9. O navegador ainda controla a segurança

Um dos pontos que considero mais importantes nessa mudança é que a simplificação da API não significa abandonar as regras de segurança.

O Chrome informa que os elementos mantêm o mesmo modelo de segurança e o caminho integrado de recuperação de permissão utilizado pelo <usermedia>.

Isso é especialmente importante quando falamos de câmera e microfone.

Uma página precisa deixar claro para o usuário que está solicitando uma capacidade do dispositivo. O navegador continua sendo responsável por uma parte importante dessa experiência.

Para o desenvolvedor, isso significa que não devemos construir uma experiência baseada na ideia de que câmera e microfone são recursos silenciosos que podem ser ativados sem interação.

10. Onde eu usaria esses elementos?

Depois de entender a proposta, alguns casos de uso começam a ficar bem claros.

• Testes de webcam diretamente pelo navegador.
• Ferramentas simples de gravação.
• Aplicações que precisam solicitar somente áudio.
• Interfaces de captura de vídeo.
• Projetos educacionais para demonstrar APIs do navegador.
• Protótipos que precisam solicitar uma capacidade específica do dispositivo.
• Aplicações que desejam deixar a intenção do controle mais explícita para o usuário.

O interessante é que esses casos não exigem necessariamente uma aplicação enorme. Um projeto pequeno já é suficiente para entender o funcionamento.

11. O que eu observaria durante os testes

Se você pretende experimentar essa novidade, eu recomendo não olhar apenas para o código.

Observe também a experiência completa.

1. O que aparece na página antes da interação?
2. Qual ação o usuário precisa executar?
3. Como o Chrome apresenta a solicitação de permissão?
4. O que acontece quando o usuário permite?
5. O que acontece quando o usuário bloqueia?
6. Como a aplicação informa que o recurso não está disponível?
7. Como o projeto se comporta em um navegador que não oferece suporte ao recurso?

Esse tipo de teste é muito mais valioso do que simplesmente copiar um exemplo da documentação, porque mostra o comportamento que realmente interessa para quem vai colocar a funcionalidade em um projeto.

12. E se o navegador não suportar?

Esse é um cuidado que eu considero obrigatório antes de colocar qualquer novidade da plataforma Web em produção.

O fato de um recurso existir no Chrome 153 não significa automaticamente que todos os navegadores e versões disponíveis para os usuários tenham exatamente o mesmo suporte.

Por isso, antes de transformar <camera> ou <microphone> em uma dependência importante da aplicação, é necessário verificar a compatibilidade do público que realmente utilizará o sistema.

Em um projeto real, podemos manter uma alternativa baseada nas APIs de mídia já conhecidas quando o novo recurso não estiver disponível.

13. O que achei mais interessante nessa novidade

O que mais chama atenção aqui não é simplesmente existir uma nova tag HTML.

O mais interessante é perceber como a plataforma Web está tentando tornar determinadas interações mais declarativas.

Durante muito tempo, quando alguém falava em acessar a câmera pelo navegador, a primeira coisa que vinha à cabeça era JavaScript, permissões e getUserMedia().

Agora existe uma alternativa específica para determinados casos de uso.

Isso não elimina as APIs que já conhecemos e também não significa que todos os projetos devam migrar imediatamente. Mas é uma mudança que vale acompanhar, principalmente para quem trabalha com aplicações Web que dependem de recursos do dispositivo.

14. Vale a pena aprender agora?

Eu diria que vale a pena pelo menos entender a proposta.

O motivo não é sair utilizando toda novidade assim que ela aparece, mas conhecer as ferramentas que a plataforma está colocando à disposição dos desenvolvedores.

O <camera> e o <microphone> são especialmente interessantes porque atacam um problema muito específico: solicitar uma capacidade única do dispositivo por meio de uma interação HTML controlada pelo navegador.

Para projetos pequenos, experimentos, protótipos e determinadas aplicações, isso pode representar uma forma mais direta de expressar a intenção da interface.

Conclusão

O Chrome 153 trouxe várias novidades para a plataforma Web, mas os elementos <camera> e <microphone> são daqueles recursos que merecem atenção de quem desenvolve aplicações que conversam diretamente com o dispositivo do usuário.

A proposta não é acabar com JavaScript nem substituir APIs como getUserMedia(). A ideia é oferecer controles HTML específicos para situações em que a aplicação precisa solicitar uma única capacidade, mantendo a interação e o modelo de segurança sob controle do navegador.

Para mim, esse é justamente o tipo de novidade que vale experimentar antes de simplesmente ignorar ou adotar em produção sem entender suas limitações.

Este artigo pode conter links de afiliados. Caso você realize uma compra através de um desses links, o NerdCult poderá receber uma comissão, sem custo adicional para você.