Tema: frontend
-
Formulários com restrições HTML nativas geram menos rejeições de validação no servidor por envio do que formulários validados apenas com JavaScript personalizado
Hipótese: o navegador bloqueia o envio interativo de um formulário cujas restrições nativas (required, pattern, type, min e max) falham, embora a MDN note que chamar submit() contorna isso e novalidate o desativa. A proposta é que formulários com restrições nativas que espelham as regras do servidor chegam a ele com menos rejeições por envio do que formulários cujas verificações estão só em scripts personalizados, porque as verificações nativas continuam a funcionar quando o script não carrega ou dá erro; propõe-se um teste A/B, sem alegar resultado.
-
Subresource Integrity para scripts e folhas de estilo de terceiros
Um atributo integrity em um elemento script ou link contém o hash SHA-256, SHA-384 ou SHA-512 em base64 do arquivo esperado; o navegador se recusa a executar ou aplicar um recurso cujo conteúdo não corresponda. Ele fixa exatamente o que uma CDN pode entregar, exige CORS para arquivos de outra origem e, por isso, só funciona com recursos de conteúdo fixo.
-
Favicons e web app manifest: quais arquivos publicar e como declará-los
Sem um link rel=icon declarado, os navegadores recorrem a /favicon.ico, então mantenha esse arquivo no lugar. Declare um SVG escalável ou um PNG com tamanho definido via link rel=icon, um apple-touch-icon e um manifest cujos ícones tenham sizes e purpose (any, maskable, monochrome). Os mecanismos de busca querem um favicon quadrado e estável por hostname.
-
Acessibilidade: os quatro princípios das WCAG aplicados na prática
As WCAG 2.2 organizam todos os critérios de sucesso em quatro princípios: perceptível, operável, compreensível e robusto. Conhecendo as violações mais comuns de cada princípio (falta de alternativas em texto, armadilhas de teclado, contraste insuficiente, campos sem rótulo, alvos pequenos demais), é possível encontrar muitas barreiras sem ferramentas especiais; o nível AA é o objetivo habitual.
-
Que parcela dos defeitos de acessibilidade encontrados em auditorias manuais ou por usuários já tinha passado nas verificações automáticas do CI, e que tipos escaparam?
Pergunta em aberto: a orientação do W3C WAI sobre ferramentas de avaliação afirma que algumas verificações de acessibilidade não podem ser automatizadas e exigem intervenção manual; em sites que executam um verificador automático a cada build, que parcela dos defeitos encontrados depois numa auditoria manual ou reportados por usuários tinha passado nesse verificador, e que tipos de defeito explicam a diferença?
Legível por máquina: JSON