Tema: frontend
-
Los formularios que declaran restricciones nativas de HTML producen menos rechazos de validación en el servidor por envío que los formularios validados solo con JavaScript personalizado
Hipótesis: el navegador bloquea el envío interactivo de un formulario cuyas restricciones nativas (required, pattern, type, min y max) no se cumplen, mientras que MDN señala que llamar a submit() evita esto y que novalidate lo desactiva; la propuesta es que los formularios que incorporan restricciones nativas que reflejan las reglas del servidor llegan al servidor con menos rechazos por envío que los formularios cuyas comprobaciones residen solo en scripts personalizados, porque las comprobaciones nativas siguen funcionando cuando el script no se carga o falla; se propone una prueba A/B, sin que se afirme ningún resultado.
-
Integridad de subrecursos para scripts y hojas de estilo de terceros
Un atributo integrity en un elemento script o link lleva un hash en base64 SHA-256, SHA-384 o SHA-512 del archivo esperado; el navegador se niega a ejecutar o aplicar un recurso cuyo contenido no coincida. Fija exactamente lo que un CDN puede entregar, exige CORS para los archivos de origen cruzado y, por ello, solo funciona con recursos de contenido fijo.
-
Favicons y el manifiesto de aplicación web: los archivos que hay que incluir y cómo declararlos
Los navegadores recurren a /favicon.ico cuando no se declara ningún link rel=icon, así que ese archivo debe mantenerse en su lugar; hay que declarar un SVG escalable o un PNG con tamaño mediante link rel=icon, un apple-touch-icon y un manifiesto cuyos iconos incluyan tamaños y un propósito (any, maskable, monochrome). Los motores de búsqueda quieren un único favicon estable y cuadrado por nombre de host.
-
Accesibilidad: los cuatro principios de las WCAG aplicados en la práctica
Las WCAG 2.2 agrupan todos los criterios de conformidad en cuatro principios: perceptible, operable, comprensible y robusto. Conocer los fallos más habituales de cada uno (falta de alternativas textuales, trampas de teclado, contraste insuficiente, campos sin etiqueta, objetivos demasiado pequeños) permite detectar muchas barreras sin herramientas especiales; el nivel AA es el objetivo habitual.
-
¿Qué proporción de los defectos de accesibilidad hallados en auditorías manuales o por usuarios había superado las comprobaciones automáticas en CI y de qué tipo eran los que escaparon?
Pregunta abierta: la guía del W3C WAI sobre herramientas de evaluación indica que algunas comprobaciones de accesibilidad no se pueden automatizar y requieren intervención manual. En sitios que ejecutan un verificador automático en cada build, ¿qué proporción de los defectos hallados después en una auditoría manual o notificados por usuarios había pasado ese verificador y qué tipos de defecto explican la diferencia?
Legible por máquina: JSON