# Aula 1.5 - DevTools, acessibilidade, desempenho e segurança

## Identificação

- **Duração:** 2 horas
- **Tipo:** auditoria guiada e correção
- **Entrega:** relatório de auditoria da landing page
- **Lista de verificação:** [`../materiais/checklist-auditoria-web.md`](../materiais/checklist-auditoria-web.md)
- **Auditoria de referência:** [`../exemplos/aula-1.5/relatorio-auditoria.md`](../exemplos/aula-1.5/relatorio-auditoria.md)

## Introdução

### O que é DevTools?

DevTools é o conjunto de ferramentas de desenvolvimento incluído nos navegadores. Ele permite inspecionar o HTML renderizado, descobrir quais regras CSS foram aplicadas, acompanhar requisições, ler erros e depurar JavaScript.

Normalmente pode ser aberto pelo menu do navegador ou por um atalho de teclado. Ele não modifica permanentemente os arquivos do servidor: alterações feitas durante a inspeção são temporárias.

### Qualquer pessoa pode abrir o DevTools?

Sim. O código enviado ao navegador pode ser observado pelo usuário. Por isso, nunca devemos considerar HTML, CSS ou JavaScript do front-end como secretos.

Uma chave de API colocada no JavaScript do navegador pode ser encontrada. Ocultar um botão com CSS também não substitui autorização no servidor.

### Usar DevTools é “hackear”?

Inspecionar uma aplicação própria ou um ambiente autorizado faz parte do desenvolvimento. A ferramenta também pode ser usada para estudar problemas de acessibilidade, desempenho e segurança.

Ter acesso ao DevTools não concede autorização para atacar sistemas, acessar contas ou explorar serviços de terceiros.

### O que significa segurança nesta aula?

Segurança significa reduzir riscos previsíveis:

- não expor credenciais;
- validar entradas;
- não confiar no navegador para autorização;
- evitar inserção insegura de conteúdo;
- controlar recursos carregados;
- registrar e corrigir falhas.

Acessibilidade, desempenho e segurança não são ajustes finais. São critérios de qualidade que acompanham todo o desenvolvimento.

## Objetivos

Ao final da aula, o aluno deverá conseguir:

1. utilizar DevTools para investigar uma página;
2. identificar requisições, status e recursos;
3. analisar erros e avisos no console;
4. inspecionar elementos, estilos e acessibilidade;
5. testar navegação por teclado;
6. detectar rolagem horizontal;
7. reconhecer problemas básicos de desempenho;
8. identificar exposições comuns de dados e credenciais;
9. compreender a função inicial de uma Content Security Policy;
10. registrar evidências e priorizar correções.

## Pré-requisitos

- landing page semântica;
- CSS responsivo;
- formulário controlado por JavaScript;
- noções de HTTP, DOM e eventos.

## Pergunta orientadora

> Como demonstrar, com evidências, que uma página funciona corretamente além de apenas “parecer pronta”?

## Roteiro sugerido

| Etapa | Duração |
|---|---:|
| Preparação e critérios | 10 min |
| Elements e estilos | 15 min |
| Network e Console | 20 min |
| Acessibilidade e teclado | 25 min |
| Desempenho e responsividade | 20 min |
| Segurança básica | 20 min |
| Relatório e priorização | 10 min |

## 1. Auditoria baseada em evidências

Uma revisão técnica não deve terminar em “funcionou para mim”.

Uma evidência pode ser:

- status HTTP;
- captura de tela;
- mensagem do console;
- sequência reproduzível;
- medida de largura;
- elemento do DOM;
- resultado de um teste;
- comparação antes e depois.

Cada achado deve responder:

1. o que foi observado;
2. como reproduzir;
3. qual é o impacto;
4. qual é a prioridade;
5. como corrigir;
6. como confirmar a correção.

## 2. Painéis principais do DevTools

Os nomes podem variar entre navegadores, mas os conceitos permanecem.

| Painel | Uso |
|---|---|
| Elements | HTML renderizado, estilos e acessibilidade |
| Console | erros, avisos e mensagens |
| Network | requisições, status, tamanho e tempo |
| Sources | arquivos carregados e depuração |
| Application | armazenamento e recursos do navegador |
| Performance | execução, renderização e tarefas |
| Lighthouse ou auditorias | diagnóstico automatizado complementar |

Ferramentas automatizadas ajudam a encontrar indícios. Elas não substituem testes com teclado, leitura do conteúdo e análise de risco.

## 3. Elements

### Inspeção do DOM

Verifique:

- existe apenas um `main`;
- o título principal é coerente;
- IDs são únicos;
- rótulos estão associados aos campos;
- elementos interativos possuem nome acessível;
- estados ocultos utilizam o atributo correto;
- não existem elementos interativos aninhados.

### Estilos calculados

Utilize a área de estilos para identificar:

- regra aplicada;
- regra sobrescrita;
- arquivo e linha de origem;
- herança;
- box model;
- dimensões finais.

### Alterações temporárias

Modificar o CSS no DevTools é útil para experimentar, mas não altera o arquivo original. Registre a decisão e aplique-a no código.

## 4. Console

O console deve permanecer limpo durante o fluxo principal.

Problemas comuns:

- arquivo não encontrado;
- variável inexistente;
- seletor que retorna `null`;
- promessa rejeitada sem tratamento;
- política de segurança bloqueando recurso;
- uso de API obsoleta;
- erro provocado por extensão do navegador.

### Diferencie origem

Antes de corrigir, confirme se a mensagem vem:

- do seu código;
- do navegador;
- de uma extensão;
- de um recurso de terceiro.

Não esconda erros com um `try/catch` vazio:

```js
try {
  await operation();
} catch {
  // Nada acontece
}
```

Trate a falha e apresente uma resposta segura ao usuário.

## 5. Network

Recarregue a página com o painel aberto e observe:

- documento HTML;
- CSS;
- JavaScript;
- SVG;
- método;
- status;
- tipo;
- tamanho;
- tempo.

### Perguntas

- algum recurso retornou `404`?
- algum recurso foi redirecionado?
- existe arquivo que não é utilizado?
- recursos são carregados por HTTPS em produção?
- dados pessoais aparecem na URL?
- a página depende de domínio externo?
- o formulário realizou uma requisição inesperada?

### Preserve registro

Quando uma navegação ou redirecionamento apagar a lista, utilize a opção de preservar o registro durante a investigação.

## 6. Depuração

Um breakpoint pausa a execução.

No envio do formulário:

1. abra `main.js`;
2. localize o evento `submit`;
3. adicione breakpoint;
4. preencha com dados fictícios;
5. envie;
6. observe `formData`, `payload` e o estado do botão;
7. continue a execução.

Não capture ou compartilhe valores pessoais durante uma depuração.

## 7. Acessibilidade por teclado

Teste:

1. recarregue a página;
2. pressione `Tab`;
3. utilize o link “Pular para o conteúdo”;
4. percorra a navegação;
5. abra e feche perguntas frequentes;
6. preencha o formulário;
7. envie com `Enter`;
8. identifique a mensagem de resultado.

Verifique:

- foco sempre visível;
- ordem de foco coerente;
- nenhum foco preso;
- todos os controles alcançáveis;
- conteúdo não depende apenas de hover;
- mensagem de resultado anunciável.

## 8. Zoom e redimensionamento

Teste:

- 200% de zoom;
- largura de 320 px;
- orientação vertical;
- textos maiores;
- conteúdo longo.

O objetivo não é manter a mesma composição visual, mas preservar:

- leitura;
- funcionalidade;
- ordem;
- foco;
- ausência de sobreposição;
- ausência de perda de conteúdo.

## 9. Árvore de acessibilidade

A árvore de acessibilidade é derivada do DOM.

Observe:

- papel;
- nome acessível;
- estado;
- descrição;
- relacionamento.

Exemplo:

```text
button "Quero participar"
textbox "Nome"
textbox "E-mail profissional"
combobox "Qual opção representa melhor seu perfil?"
checkbox "Concordo em receber informações..."
status "Cadastro simulado com sucesso"
```

Se o elemento não possui nome compreensível, revise HTML, rótulo e atributos antes de adicionar ARIA.

## 10. Desempenho

Problemas iniciais comuns:

- imagens muito maiores que o espaço exibido;
- JavaScript que bloqueia a página;
- fontes externas desnecessárias;
- bibliotecas usadas para tarefas simples;
- layout que muda durante o carregamento;
- arquivos duplicados;
- animações excessivas.

### Inspeção inicial

Registre:

- quantidade de requisições;
- tamanho aproximado;
- erros;
- recursos externos;
- estabilidade visual;
- capacidade de interação.

### Regra prática

Não otimize sem evidência. Primeiro identifique o gargalo, depois faça uma alteração mensurável.

## 11. Segurança no front-end

O navegador é um ambiente controlado pelo usuário. Tudo que chega ao front-end pode ser observado.

Nunca coloque no código do navegador:

- chaves privadas;
- senha de banco;
- token administrativo;
- credencial de provedor de IA;
- regra de autorização considerada secreta;
- dado sensível desnecessário.

### Validação

Validação no navegador melhora a experiência, mas pode ser alterada ou removida pelo usuário. O back-end deverá validar novamente.

```text
Front-end valida para ajudar.
Back-end valida para proteger.
```

### XSS

Evite inserir entrada externa com `innerHTML`.

```js
status.textContent = message;
```

Quando HTML dinâmico for indispensável, será necessário um processo adequado de sanitização.

### Dados em URLs

URLs podem aparecer em:

- histórico;
- registros;
- favoritos;
- analytics;
- cabeçalhos de referência.

Não coloque senha, token ou dado sensível em cadeias de consulta.

## 12. Content Security Policy

Uma Content Security Policy, ou CSP, restringe as origens autorizadas para recursos e execução.

Na página estática de laboratório:

```html
<meta
  http-equiv="Content-Security-Policy"
  content="
    default-src 'self';
    img-src 'self';
    style-src 'self';
    script-src 'self';
    object-src 'none';
    base-uri 'none';
    form-action 'self';
  "
>
```

Essa versão:

- permite recursos da mesma origem;
- bloqueia plugins embutidos;
- impede alteração de URL base;
- restringe o destino do formulário.

Em produção, a política normalmente é enviada como cabeçalho HTTP. Uma política precisa ser adaptada aos recursos reais e testada antes de ser aplicada de forma restritiva.

## 13. Referrer Policy

A política de referência controla parte das informações enviadas ao navegar para outro endereço.

```html
<meta name="referrer" content="strict-origin-when-cross-origin">
```

Ela não substitui a decisão de evitar dados sensíveis na URL.

## 14. Armazenamento do navegador

Inspecione cookies, `localStorage` e `sessionStorage`.

Pergunte:

- por que o dado está armazenado?
- por quanto tempo?
- quem consegue acessá-lo?
- ele é sensível?
- pode ser removido?

A Knowledge AI não grava nome ou e-mail no armazenamento local.

## 15. Auditoria da Knowledge AI

Execute:

### Estrutura

- título e descrição;
- landmarks;
- hierarquia de títulos;
- rótulos;
- texto alternativo;
- idioma.

### Interação

- envio inválido;
- sucesso;
- erro simulado;
- recuperação;
- teclado.

### Responsividade

- 320 px;
- 375 px;
- 768 px;
- 1280 px;
- ausência de rolagem horizontal.

### Recursos

- HTML;
- CSS;
- JavaScript;
- SVG;
- status HTTP;
- console.

### Segurança

- ausência de credenciais;
- ausência de dados em registros;
- `textContent`;
- CSP inicial;
- destino de formulário restrito;
- sem armazenamento de dados pessoais.

## 16. Priorização

Utilize:

| Prioridade | Definição |
|---|---|
| Crítica | exposição de dados, credenciais ou controle indevido |
| Alta | impede fluxo essencial ou acesso |
| Média | degrada experiência, compreensão ou manutenção |
| Baixa | melhoria sem impacto imediato relevante |

Corrija primeiro segurança e bloqueios de fluxo.

## 17. Modelo de achado

```markdown
### A-01 - Foco invisível

- Prioridade: alta
- Área: acessibilidade
- Evidência: ao navegar com Tab, não é possível identificar o link ativo
- Impacto: usuários de teclado perdem a posição
- Correção: adicionar estilo para `:focus-visible`
- Validação: repetir o fluxo completo usando apenas teclado
```

## 18. Exercício de fixação

Audite uma página anterior ou outro pequeno projeto.

Registre no mínimo:

- um achado de acessibilidade;
- um achado de desempenho;
- um achado de segurança;
- uma evidência de funcionamento correto;
- prioridade;
- correção proposta.

## 19. Desafio individual

Remova temporariamente o arquivo `main.js` da referência no HTML.

Observe:

- Network;
- Console;
- comportamento do formulário;
- experiência do usuário.

Depois restaure o arquivo e documente:

1. como o problema foi detectado;
2. qual foi a evidência;
3. qual foi a causa;
4. como foi validada a correção.

Não deixe a referência removida na entrega final.

## 20. Erros comuns

### Corrigir somente o sintoma

Um `404` não deve ser ocultado. Corrija o caminho ou remova a referência.

### Confiar apenas em pontuação automática

Uma nota alta não garante usabilidade, segurança ou conteúdo correto.

### Testar somente com mouse

Inclua teclado em todo fluxo.

### Ignorar mensagens do console

Mesmo que a interface pareça funcionar, um erro pode indicar fluxo incompleto.

### Aplicar CSP sem testar

Uma política incorreta pode bloquear CSS, JavaScript, imagens ou integrações legítimas.

### Expor dados em captura

Utilize dados fictícios e revise evidências antes de compartilhá-las.

### Otimizar sem medir

Registre o antes e o depois.

## 21. Lista de verificação de entrega

- [ ] O fluxo principal foi testado.
- [ ] O console não apresenta erros da aplicação.
- [ ] Todos os recursos retornam sucesso.
- [ ] A navegação funciona por teclado.
- [ ] O foco é visível.
- [ ] O formulário comunica sucesso e erro.
- [ ] Não existe rolagem horizontal em 320 px.
- [ ] A página funciona com zoom.
- [ ] Não existem credenciais no front-end.
- [ ] Dados pessoais não aparecem na URL ou console.
- [ ] O armazenamento do navegador foi inspecionado.
- [ ] A CSP foi compreendida e testada.
- [ ] Os achados possuem evidências.
- [ ] Correções foram revalidadas.

## 22. Critérios de aceite

A entrega será aceita quando:

1. apresentar um relatório reproduzível;
2. incluir evidências de rede e console;
3. testar teclado e responsividade;
4. classificar prioridades;
5. registrar correções;
6. repetir os testes após as correções;
7. não expor dados pessoais;
8. explicar por que a validação do front-end não protege o back-end;
9. explicar a finalidade de uma CSP;
10. demonstrar o fluxo principal sem erros.

## 23. Perguntas para revisão

1. Qual é a diferença entre DOM original e DOM renderizado?
2. O que deve ser observado no painel Network?
3. Como diferenciar um erro da aplicação de um erro de extensão?
4. Por que o teste por teclado é indispensável?
5. O que a árvore de acessibilidade representa?
6. Por que validação no navegador não é suficiente?
7. Qual risco existe ao utilizar `innerHTML` com entrada externa?
8. Para que serve uma CSP?
9. Por que dados sensíveis não devem aparecer em URLs?
10. O que torna um relatório de auditoria reproduzível?

## Próxima aula

Na Aula 1.6, o projeto será versionado, documentado, publicado e apresentado. O aluno concluirá o primeiro módulo com uma entrega de portfólio.