Evoluindo a arquitetura do PsyHub com Monorepo + Nx + Module Federation

Gabriel Luiz — Tue, 17 Feb 2026 16:47:19 +0000

🚀 Migrando para Microfrontends sem reescrever o passado

Nos últimos dias compartilhei um material mostrando, na prática, como conduzir a migração de uma aplicação para microfrontends começando por uma página real: a tela de login.

Mas o ponto não é só técnico.
É sobre arquitetura como estratégia.

Mostro nos slides:
O que é host e o que é remote na prática
Como funciona o consumo de um microfrontend
Como estruturar o compartilhamento entre aplicações
Como migrar de forma incremental, sem “big bang”
E principalmente: como sustentar evolução sem reescrever tudo

Esse conteúdo é para:
👨‍💼 Lideranças que precisam tomar decisões arquiteturais sustentáveis
🧑‍💻 Devs que querem entender microfrontends além do hype
🎯 Recrutadores que buscam profissionais com visão de arquitetura e escalabilidade
🚀 Pessoas iniciantes que querem entender como grandes sistemas evoluem na prática

A leitura completa dos slides leva em média 5 a 7 minutos.

Se você acredita que arquitetura não é sobre o hoje, mas sobre viabilizar o amanhã — esse material é para você.

Depois me conta o que achou 👇

Acessibilidade na Prática

Gabriel Luiz — Tue, 30 Dec 2025 01:38:49 +0000

Um guia inicial

A acessibilidade digital vai muito além de cumprir regras técnicas.

Ela trata de incluir pessoas, garantir autonomia e permitir que todos naveguem, interajam e consumam conteúdo de forma justa.

Neste post, quero compartilhar conceitos práticos e aplicáveis sobre acessibilidade no desenvolvimento frontend — do HTML semântico ao uso consciente de ARIA e ferramentas essenciais.

O Papel do Desenvolvedor na Acessibilidade

O desenvolvedor tem um papel fundamental na construção de interfaces acessíveis.

É nossa responsabilidade garantir que produtos digitais sejam utilizáveis por todas as pessoas, incluindo usuários com deficiência visual, motora, auditiva ou cognitiva.

Acessibilidade envolve:

Boas práticas de código
Uso de padrões como WCAG e ARIA
Preocupação desde o início do desenvolvimento

No Brasil, acessibilidade digital é um direito garantido por lei.

Incluir no código é incluir no mundo.

O que é ARIA?

ARIA (Accessible Rich Internet Applications) é uma especificação do W3C que fornece atributos para tornar componentes dinâmicos mais acessíveis.

Ela permite que tecnologias assistivas entendam:

o papel de um elemento
seu estado
suas propriedades

Isso é essencial em interfaces modernas com muitos componentes customizados.

Documentação oficial:

Os 4 Princípios da Acessibilidade (WCAG)

Perceptível

A informação deve ser apresentada de forma que todos possam perceber.
Exemplo: Adicionar textos alternativos em imagens.

Operável

A interface deve ser utilizável por qualquer usuário.
Exemplo: Permitir navegação completa pelo teclado.

Compreensível

O conteúdo deve ser fácil de entender.
Exemplo: Formulários com instruções claras e mensagens objetivas.

Robusto

O código deve ser compatível com tecnologias assistivas.
Exemplo: Uso correto de HTML semântico e ARIA.

Ferramentas Essenciais para Acessibilidade

Axe DevTools

Extensão que analisa problemas de acessibilidade com base na WCAG.

Como usar:

Instale no Chrome ou Firefox
Abra o DevTools
Vá até a aba axe DevTools
Clique em Scan
Analise os problemas e sugestões

WCAG Color Contrast Checker

Verifica se o contraste de cores atende aos níveis AA ou AAA da WCAG.

Ideal para garantir legibilidade.

NVDA (Leitor de Tela)

Ferramenta essencial para testar a experiência de usuários cegos.

Dica: Pressione INSERT + S para alternar os modos de fala.
Site oficial: https://www.nvaccess.org/

HTML Semântico: A Base de Tudo

Evite usar <div> e <span> para tudo.

HTML semântico ajuda:

usuários
leitores de tela
SEO
manutenção do código

Elementos importantes:

<header>: Representa o cabeçalho de uma página ou de uma seção. Geralmente contém logotipo, título, introdução ou elementos de apoio à navegação. Pode existir mais de um <header> na página, desde que cada um esteja associado a um contexto diferente.
<nav>: Define um bloco de navegação principal ou secundário. Deve ser usado apenas para conjuntos de links que representam a navegação do site ou de uma seção específica, facilitando a identificação por leitores de tela.
<main>: Contém o conteúdo principal da página. Deve ser único e excluir conteúdos repetidos, como menus e rodapés. Ajuda tecnologias assistivas a pular diretamente para o conteúdo central.
<section>: Use quando você precisa agrupar conteúdos relacionados dentro de um tema maior. Deve possuir um título que descreva seu propósito, ajudando a criar uma hierarquia clara de conteúdo.
<aside>: Representa conteúdos complementares ou secundários ao conteúdo principal. Exemplos comuns incluem barras laterais, conteúdos relacionados, anúncios ou informações adicionais.
<footer>: Define o rodapé de uma página ou de uma seção. Geralmente contém informações institucionais, direitos autorais, links auxiliares ou metadados relacionados ao conteúdo.
<article>: Use quando o conteúdo faz sentido sozinho, fora da página. Ideal para posts, cards, notícias, produtos ou qualquer conteúdo que possa ser reutilizado, listado ou compartilhado de forma independente.

Hierarquia de Títulos

Uma boa hierarquia (<h1> → <h6>) facilita:

navegação por leitores de tela
compreensão do conteúdo
organização visual e semântica
Nunca pule níveis sem necessidade.

<main>
  <h1>Cursos Disponíveis</h1>

  <section aria-labelledby="frontend-title">
    <h2 id="frontend-title">Cursos de Frontend</h2>

    <article class="card">
      <h3>Angular com Acessibilidade</h3>
      <p>Aprenda a criar aplicações acessíveis usando Angular.</p>
    </article>

    <article class="card">
      <h3>React e WCAG na Prática</h3>
      <p>Boas práticas de acessibilidade aplicadas ao React.</p>
    </article>
  </section>

  <section aria-labelledby="backend-title">
    <h2 id="backend-title">Cursos de Backend</h2>

    <article class="card">
      <h3>APIs REST Acessíveis</h3>
      <p>Como documentar e estruturar APIs pensando em acessibilidade.</p>
    </article>
  </section>
</main>

O Poder do `alt` nas Imagens

O atributo alt descreve imagens para quem não pode vê-las.

<img 
  src="pizza.jpg" 
  alt="Pizza de pepperoni com queijo derretido e bordas crocantes">

Principais atributos ARIA

ARIA não cria comportamento, apenas informa semântica e estado para tecnologias assistivas.

Regra de ouro:
Use HTML semântico primeiro. ARIA só quando necessário.

aria-label

Fornece um nome acessível quando não há texto visível.

<button aria-label="Fechar modal">
  ✕
</button>

✔ Leitores de tela anunciam corretamente
❌ Não visível para usuários visuais

aria-labelledby

Usa um elemento existente como rótulo.

<h2 id="titulo-perfil">Perfil do usuário</h2>

<section aria-labelledby="titulo-perfil">
  ...
</section>

✔ Preferível ao aria-label
✔ Mantém conteúdo visível e reutilizável

aria-describedby

Fornece descrições adicionais, como ajuda ou erro.

<input type="email" aria-describedby="email-ajuda" />

<span id="email-ajuda">
  Insira um e-mail válido
</span>

Leitores de tela:

"Campo de edição, insira um e-mail válido"

aria-hidden

Oculta conteúdo apenas para leitores de tela.

<span aria-hidden="true">★</span>

✔ Útil para ícones decorativos
❌ Não substitui display: none

role

Define a função semântica de um elemento.

<ul role="menu" tabindex="0">
  <li role="menuitem">...</li>
</div>

Estados ARIA comuns

aria-expanded

<button aria-expanded="false" aria-controls="menu">
  Menu
</button>

<ul id="menu" hidden>
  ...
</ul>

✔ Indica estado aberto/fechado

aria-selected

<li role="option" aria-selected="true">
  Opção 1
</li>

aria-disabled

<button aria-disabled="true">
  Enviar
</button>

⚠️ Ainda recebe foco
Use junto com disabled quando possível.

Dica prática: Experiência visual com NVDA

Uma das formas mais eficazes de entender o impacto real da acessibilidade é simular a experiência de um usuário cego.

Exercício simples e poderoso

Abra uma implementação sua sem ajustes de acessibilidade
Inicie o NVDA
Feche os olhos
Tente navegar apenas com o teclado e o leitor de tela

Acessibilidade não é um detalhe visual, é uma experiência completa.
Quando projetamos pensando em quem navega sem ver, criamos interfaces melhores para todos.
Teste, escute o leitor de tela e deixe a inclusão guiar suas decisões.

Muito obrigado!
Gabriel Luiz da Silva.
https://www.linkedin.com/in/gabrielluizs1996/

DEV Community: Gabriel Luiz