Accesibilidad web en Brasil: qué exigen la LBI y la NBR 17225

En Brasil, el art. 63 de la LBI exige sitios accesibles a empresas con sede o representación en el país. Qué pide la NBR 17225 y cómo revisar errores comunes.

Verificar mi sitio gratisVer los planes
En esta página 13 min de lectura
  1. Qué dice el art. 63 de la Ley Brasileña de Inclusión
  2. Quién tiene que cumplir
  3. Qué es la ABNT NBR 17225
  4. Cómo se relaciona la NBR 17225 con las WCAG 2.x
  5. Otras reglas que pueden aplicarse
  6. Los errores más comunes y cómo comprobar cada uno
  7. Cuándo no se aplica la ley y qué queda fuera
  8. Cómo evaluar la accesibilidad de un sitio
  9. Cómo verificar tu sitio

Sí: si tu empresa tiene sede o representación comercial en Brasil, su sitio web tiene que ser accesible para personas con discapacidad. Lo establece el art. 63 de la LBI (Lei Brasileira de Inclusão, la Ley Brasileña de Inclusión, Ley 13.146/2015), que también se aplica a los sitios de organismos de gobierno. La ley no trae una lista técnica: remite a las directrices de accesibilidad adoptadas internacionalmente. Las directrices internacionales del W3C se llaman WCAG y también son norma ISO (ISO/IEC 40500). Desde marzo de 2025, Brasil cuenta con la ABNT NBR 17225, que adopta las WCAG 2.2 y organiza esas directrices en 96 requisitos y 50 recomendaciones. Cumplir todos los requisitos equivale a los niveles A y AA de las WCAG 2.2.

Este texto explica la ley y la norma tal como estaban publicadas en octubre de 2026. No es asesoramiento jurídico. Para un caso concreto, consulta a un abogado.

Qué dice el art. 63 de la Ley Brasileña de Inclusión

La LBI, también llamada Estatuto de la Persona con Discapacidad, se sancionó el 6 de julio de 2015 y, según el art. 127, entró en vigor 180 días después de su publicación. El caput del art. 63 dice (traducción libre del portugués):

"Es obligatoria la accesibilidad en los sitios de internet mantenidos por empresas con sede o representación comercial en el País o por organismos de gobierno, para uso de la persona con discapacidad, garantizándole acceso a la información disponible, conforme a las mejores prácticas y directrices de accesibilidad adoptadas internacionalmente."

(Ley 13.146/2015, art. 63)

"Sitio de internet" es el término de la ley para un sitio web. Persona con discapacidad, según el art. 2º de la misma ley, es quien tiene un "impedimento de largo plazo de naturaleza física, mental, intelectual o sensorial" que, en interacción con barreras, puede obstruir su participación plena en la sociedad. Entre esas barreras, el art. 3º, IV, "d", incluye las que dificultan la recepción de información "por intermedio de sistemas de comunicación y de tecnología de la información". Un sitio que no funciona con teclado o con lector de pantalla encaja en esa descripción.

El mismo artículo tiene tres párrafos más:

  • el § 1º dice que "los sitios deben contener símbolo de accesibilidad en lugar destacado";

  • los §§ 2º y 3º tratan de telecentros comunitarios y cibercafés (las lan houses), con equipos y computadoras accesibles, y no de sitios web.

El art. 64 añade una consecuencia práctica: la accesibilidad de los sitios a los que se refiere el art. 63 debe observarse para obtener financiamiento con recursos públicos, como renuncia o incentivo fiscal, contrato o convenio (art. 54, III). El texto del art. 63 no fija multa ni plazo propio de adecuación. Crea la obligación y remite a las directrices internacionales para decir cómo cumplirla.

Quién tiene que cumplir

Por la redacción del art. 63, la obligación se aplica a los sitios mantenidos por:

  • empresas con sede en Brasil;

  • empresas con representación comercial en Brasil, aunque la sede esté en el exterior;

  • organismos de gobierno.

El artículo no distingue por tamaño, sector ni facturación. Microempresa, tienda en línea y gran portal están en la misma frase.

La ley habla de sitios "mantenidos por" empresas y organismos, y no trata del reparto de responsabilidades entre quien contrata y quien desarrolla. Recomendación para agencias, freelancers y clientes: dejar en el contrato qué norma y qué nivel debe cumplir el sitio entregado (por ejemplo, conformidad regular con la NBR 17225) y quién se encarga de la accesibilidad del contenido publicado después de la entrega.

Qué es la ABNT NBR 17225

La ABNT (Associação Brasileira de Normas Técnicas, Asociación Brasileña de Normas Técnicas) es el foro nacional de normalización. La NBR 17225 lleva el título "Accesibilidad en contenido y aplicaciones web", con el subtítulo "Requisitos". Los datos siguientes están en la propia norma, en la edición de lanzamiento publicada por la Cámara de Diputados:

  • primera edición del 11/03/2025, con 69 páginas;

  • elaborada en el Comité Brasileño de Accesibilidad (ABNT/CB-040), por la Comisión de Estudio de Accesibilidad para la Inclusión Digital;

  • proyecto sometido a consulta nacional del 27/11/2024 al 26/12/2024.

Según el NIC.br, la coordinación técnica estuvo a cargo del Ceweb.br (Centro de Estudios sobre Tecnologías Web), el trabajo reunió a 178 especialistas durante casi dos años y el contenido completo de la norma se puso a disposición de forma gratuita.

El alcance dice que la norma establece requisitos de accesibilidad para sitios web con base en las directrices internacionales y que "la conformidad con esta norma busca atender a la legislación vigente". Una nota en el alcance nombra la referencia: las WCAG 2.2.

Cómo está organizada la norma

La sección 5 tiene 146 ítems. Cada uno está marcado como requisito o como recomendación: 96 requisitos y 50 recomendaciones, según el recuento de los ítems de la primera edición. Los ítems se agrupan en 16 temas: interacción por teclado, imágenes, encabezados, regiones, listas, tablas, enlaces y navegación, botones y controles, formularios y entrada de datos, presentación, uso de colores, contenido textual, codificación y marcado semántico, audio y video, animación y tiempo.

Cada ítem indica el criterio de conformidad de las WCAG 2.2 que pretende cumplir y el nivel de ese criterio. Hay también tres anexos informativos:

  • Anexo A, elementos problemáticos para la accesibilidad: CAPTCHA, reconocimiento facial, contenido que aparece solo con el foco o al pasar el mouse, contenido insertado por CSS, contenido de terceros, componentes personalizados, archivos, tablas usadas para maquetar y marcado fuera de la especificación;

  • Anexo B, desempeño funcional: lo que el sitio debe permitir a quien lo usa sin visión, con visión limitada, sin percepción del color, sin audición, sin habla, con fuerza o alcance limitados, con epilepsia fotosensible o con capacidad cognitiva limitada;

  • Anexo C, una lista de verificación con todos los ítems, su clasificación (requisito o recomendación), el criterio de las WCAG y las columnas Sí, No y N/A.

Conformidad regular y conformidad plena

La sección 4 de la norma define dos tipos de conformidad:

  • conformidad regular: se cumplen todos los requisitos. Según la norma, está alineada con el nivel AA de las WCAG 2.2, y un sitio con conformidad regular también es conforme con los niveles A y AA de las WCAG 2.2;

  • conformidad plena: se cumplen los requisitos y las recomendaciones. Si alguna recomendación queda sin cumplir, hace falta una justificación razonable.

Algunos ítems admiten más de una forma de cumplimiento, separadas por "o". La primera opción es la preferida y las siguientes funcionan como alternativas para excepciones.

¿La norma es obligatoria?

Por sí sola, no. El prefacio recuerda que los documentos técnicos de la ABNT "son voluntarios y no incluyen requisitos contractuales, legales o estatutarios" y que pueden citarse en reglamentos técnicos, que entonces definen los plazos de exigencia. La obligación legal viene del art. 63 de la LBI.

Lectura práctica, no jurídica: la LBI pide las directrices internacionales, y la NBR 17225 declara seguir las WCAG 2.2 para atender a la legislación. Eso la convierte en la referencia técnica brasileña más directa para planificar el trabajo y documentar lo que se hizo.

Cómo se relaciona la NBR 17225 con las WCAG 2.x

Las WCAG (Web Content Accessibility Guidelines, o Pautas de Accesibilidad para el Contenido Web) las publica el W3C, el consorcio que publica los estándares de la web. Se organizan en cuatro principios (perceptible, operable, comprensible y robusto), pautas (13 en la versión 2.2) y criterios de conformidad comprobables. Un criterio de conformidad es la regla verificable, como "texto con un contraste de al menos 4,5:1". Cada criterio tiene un nivel: A, AA o AAA.

Las versiones en uso, según el W3C:

  • WCAG 2.0, publicada el 11/12/2008;

  • WCAG 2.1, publicada el 05/06/2018;

  • WCAG 2.2, publicada el 05/10/2023 y actualizada el 12/12/2024. La versión de octubre de 2023 es idéntica a la ISO/IEC 40500:2025.

El texto de las WCAG 2.2 dice que el contenido conforme con la 2.2 también es conforme con la 2.0 y la 2.1. La 2.2 eliminó un criterio, el 4.1.1 (Procesamiento). El W3C recomienda usar la versión más reciente.

La NBR 17225 sigue los criterios de las WCAG 2.2, con ajustes de nomenclatura. La correspondencia no es de uno a uno. El criterio 1.1.1 (contenido no textual), por ejemplo, se convirtió en ítems separados para imágenes de contenido, imágenes funcionales, imágenes decorativas e imágenes complejas. Y un mismo ítem puede citar más de un criterio. Lo que cambia de las WCAG 2.1 a la 2.2 está en WCAG 2.2 nivel AA: qué cambió y cómo verificarlo.

Sobre el nivel AAA, la introducción de la norma afirma que no conviene adoptarlo como requisito para todo el contenido, porque no siempre es posible cumplirlo. Por eso los ítems de nivel AAA aparecen como recomendación.

Otras reglas que pueden aplicarse

Decreto 5.296/2004, art. 47 (administración pública)

El art. 47 del Decreto 5.296/2004 hizo obligatoria, en un plazo de doce meses desde su publicación, la accesibilidad "en los portales y sitios electrónicos de la administración pública" para personas con discapacidad visual (el decreto usa el término antiguo "portadoras de deficiência", "portadoras de discapacidad"). El § 2º pide un símbolo de accesibilidad en las páginas de entrada. El art. 48 exige la accesibilidad de los sitios "de interés público" para obtener financiamiento público. En la consulta al sitio del Planalto en octubre de 2026, el art. 47 no tenía ninguna anotación de derogación.

eMAG (gobierno federal)

El eMAG (Modelo de Acessibilidade em Governo Eletrônico, Modelo de Accesibilidad en Gobierno Electrónico) es un conjunto de recomendaciones para los sitios del gobierno. La versión actual es la 3.1, de abril de 2014, y se elaboró tomando como base las WCAG 2.0. La Portaria nº 3, del 7 de mayo de 2007, institucionalizó el eMAG en el Sistema de Administración de los Recursos de Tecnología de la Información (SISP) e hizo obligatoria su observancia en los sitios y portales del gobierno brasileño.

El portal Governo Digital ya incluye la NBR 17225 entre las referencias de accesibilidad, y en el lanzamiento de la norma el Departamento de Servicios Públicos Digitales del Ministerio de Gestión e Innovación (MGI) informó que los profesionales de la Unión responsables de los sitios oficiales recibirían formación para implementarla (MDHC). El eMAG se hizo para sitios de gobierno. Para una empresa privada, la obligación es la del art. 63 de la LBI.

Los errores más comunes y cómo comprobar cada uno

El WebAIM Million 2026 analizó de forma automática las páginas de inicio del millón de sitios más visitados del mundo en febrero de 2026. Los incumplimientos de las WCAG más frecuentes fueron:

  • texto con bajo contraste: 83,9 % de las páginas;

  • imágenes sin texto alternativo: 53,1 %;

  • campos de formulario sin etiqueta: 51 %;

  • enlaces vacíos (sin texto que diga adónde llevan): 46,3 %;

  • botones vacíos: 30,6 %;

  • idioma de la página no declarado: 13,5 %.

La muestra es mundial, no brasileña, y el propio informe advierte que no encontrar errores no significa que la página sea accesible. Una herramienta automática no detecta, por ejemplo, un menú que solo se abre con el mouse. Por eso la tabla siguiente combina esos errores con ítems que exigen prueba manual, como teclado, foco y encabezados.

ErrorÍtem de la NBR 17225Criterio de las WCAG 2.2Cómo verificarlo
Texto con bajo contraste5.11.3 Contraste para texto (mínimo)1.4.3 (AA): 4,5:1; 3:1 para texto grande (18 pt, o 14 pt en negrita)Medir el color del texto contra el del fondo con un verificador de contraste. Revisar el texto sobre imágenes, el texto de los botones y los textos en gris claro.
Imagen sin texto alternativo5.2.1, 5.2.2 y 5.2.31.1.1 (A)Inspeccionar el atributo alt. Una imagen con información describe esa información; una imagen dentro de un enlace o botón describe la función; una imagen decorativa usa alt="".
Campo de formulario sin etiqueta5.9.1 y 5.9.33.3.2 (A), 1.3.1 (A), 4.1.2 (A)Comprobar que cada campo tenga un label asociado en el código (for igual al id del campo) u otro nombre accesible. Con un lector de pantalla, el nombre del campo debe leerse al recibir el foco.
Enlace o botón vacío (solo un ícono, sin nombre)5.13.10 y 5.7.44.1.2 (A), 2.4.4 (A)Abrir el árbol de accesibilidad en las herramientas para desarrolladores del navegador y ver el nombre calculado de cada enlace y botón. El ícono de lupa, de carrito o de redes sociales sin texto es el caso típico.
Idioma de la página no declarado5.13.23.1.1 (A)Ver que la etiqueta html declare el idioma, por ejemplo lang="pt-BR" en un sitio en portugués de Brasil. Sin eso, el lector de pantalla puede leer el texto con la pronunciación de otro idioma.
Función que no se puede usar solo con el teclado5.1.132.1.1 (A)Dejar el mouse a un lado y usar Tab, Mayús+Tab, Intro, la barra espaciadora y las flechas. Probar el menú, la búsqueda, los filtros, el carrusel, el banner de cookies y el carrito.
Foco atrapado en un componente5.1.6 Trampa de foco2.1.2 (A)Entrar y salir con el teclado de modales, reproductores de video, mapas e iframes de terceros.
Foco invisible5.1.1 y 5.11.62.4.7 (AA), 1.4.11 (AA)Navegar con Tab y ver si siempre se sabe dónde está el foco. En el CSS, buscar outline: none sin un estilo de foco que lo reemplace.
Foco tapado por una cabecera fija o un banner5.1.32.4.11 (AA)Navegar con Tab con la cabecera fija, el chat y el banner de cookies visibles. El elemento con el foco no puede quedar totalmente cubierto.
Encabezados falsos o sin jerarquía5.3.1 y 5.3.51.3.1 (A)Listar los encabezados de h1 a h6 con una extensión o con las DevTools. La lista debe funcionar como índice de la página, y un texto grande en negrita con aspecto de título debe ser un encabezado de verdad.
Página sin título propio5.13.12.4.2 (A)Ver que el title de cada página sea distinto y describa su contenido.
Zoom bloqueado o texto que se rompe al 200 %5.13.5 y 5.12.71.4.4 (AA)Aplicar un zoom del 200 % en el navegador y leer la página entera. En la meta viewport, buscar user-scalable=no o maximum-scale=1, que bloquean el zoom en el móvil.
Área táctil demasiado pequeña5.8.7 Área de activación (mínima)2.5.8 (AA): 24 por 24 píxeles CSS, o un espaciado equivalenteMedir con las DevTools los íconos, las flechas del carrusel y los enlaces del pie de página que estén muy juntos.
Sin atajo para saltar bloques repetidos5.7.122.4.1 (A)Pulsar Tab al abrir la página. El primer elemento suele ser un enlace "Saltar al contenido"; la norma también acepta otro mecanismo.
Error de formulario que no dice qué está mal5.9.9 y 5.11.13.3.1 (A), 1.4.1 (A)Enviar el formulario con errores. El mensaje debe estar en texto, señalar el campo y no depender solo del color rojo.

El contraste y los formularios tienen artículos propios: Contraste de color: cómo cumplir los criterios 1.4.3 y 1.4.11 y Formularios accesibles: etiquetas, errores y teclado.

Cuándo no se aplica la ley y qué queda fuera

  • Una empresa sin sede ni representación comercial en Brasil no está en el texto del art. 63. Si otra norma la alcanza es una pregunta jurídica, fuera de este artículo.

  • El art. 63 habla de empresas y de organismos de gobierno. Un sitio personal de una persona física, sin actividad empresarial, no está mencionado.

  • El art. 63 trata de "sitios de internet". Para aplicaciones móviles, la ABNT tiene una norma propia, la NBR 17060 (Accesibilidad en aplicaciones de dispositivos móviles), citada como referencia normativa en la NBR 17225.

  • El contenido de terceros, como un video incrustado de una plataforma o una publicación de una red social, escapa al control de quien mantiene el sitio. El Anexo A de la NBR 17225 lo reconoce y recomienda elegir fuentes que sigan buenas prácticas y avisar al usuario cuando no haya una alternativa sin barreras.

  • El nivel AAA no se exige para la conformidad regular. En la norma, esos ítems son recomendaciones.

  • El símbolo de accesibilidad del § 1º es una exigencia adicional. La obligación principal sigue siendo que el sitio sea accesible.

Cómo evaluar la accesibilidad de un sitio

  1. Pasa un verificador automático por la página de inicio y por las páginas que más importan: formulario de contacto, búsqueda, carrito, checkout e inicio de sesión. Encuentra rápido el contraste, el alt ausente, el campo sin etiqueta y el idioma no declarado.

  2. Haz las comprobaciones rápidas del W3C (Easy Checks): título de la página, texto alternativo, encabezados, contraste, cambio de tamaño del texto, teclado y foco, formularios y errores. El W3C advierte que no son definitivas y que una página puede pasarlas y aun así tener barreras serias.

  3. Usa el sitio solo con el teclado, de principio a fin de una compra o de un registro.

  4. Escucha las páginas principales con un lector de pantalla, como NVDA en Windows o VoiceOver en Mac y iPhone.

  5. Completa la lista de verificación del Anexo C de la NBR 17225 (Sí, No o N/A) y guarda el resultado con la fecha. Para la conformidad plena, registra la justificación de cada recomendación no cumplida.

  6. Repite después de cada cambio relevante de tema, plugin, formulario o flujo de compra.

El W3C es directo sobre los límites de las herramientas: no determinan si un sitio es accesible, solo ayudan en la evaluación, y parte de la verificación exige juicio humano. Si la idea es resolverlo todo con un widget instalado en el sitio, lee antes ¿Un overlay de accesibilidad cumple la ley?

Cómo verificar tu sitio

La verificación gratuita de WebVyze, sin registro, analiza la página de inicio y señala riesgos de accesibilidad y de privacidad previstos en la ley. En /es/herramientas-gratis están las demás herramientas gratuitas.

En los planes de pago, WebVyze monitorea los sitios, vincula cada problema con la ley y el criterio correspondientes junto con una guía de corrección, y solo marca el problema como resuelto después de verificarlo de nuevo. Ninguna verificación automática cubre todos los criterios de las WCAG, y parte de ellos depende de revisión humana. WebVyze no certifica la conformidad con la LBI ni con la NBR 17225.

Preguntas frecuentes

¿Poner el símbolo de accesibilidad en el sitio cumple la obligación?
No. El § 1º del art. 63 de la LBI pide el símbolo en un lugar destacado, pero el caput (el texto principal del artículo) exige que el sitio sea accesible según las directrices internacionales. El símbolo informa; no elimina ninguna barrera de uso.
¿Los PDF y otros archivos descargables también tienen que ser accesibles?
La NBR 17225 trata este punto en el Anexo A, que es informativo: advierte que una página conforme puede llevar a archivos que no son accesibles y recomienda verificar cada archivo según las especificaciones de su formato.
¿Puedo usar CAPTCHA en un formulario?
La NBR 17225 incluye el CAPTCHA entre los elementos problemáticos. Pide que el CAPTCHA se identifique como tal, con la indicación del tipo de tarea, y que exista una alternativa en otra modalidad, por ejemplo un desafío de audio junto al desafío visual.
¿La ventana con intérprete de Libras en los videos es obligatoria según la NBR 17225?
En la NBR 17225, la ventana de Libras (la lengua de señas brasileña) para contenido de audio (ítem 5.14.6) es una recomendación, no un requisito. Cuenta para la conformidad plena, que exige justificar cada recomendación no cumplida, pero no para la conformidad regular. Otras leyes pueden tratar de Libras en situaciones específicas, algo que queda fuera de este texto.
¿Cada cuánto tiempo debo volver a evaluar el sitio?
El art. 63 de la LBI no fija una periodicidad. Recomendación: volver a evaluar cada vez que cambie el tema, el diseño, un plugin, un formulario o el flujo de compra, porque cualquiera de esos cambios puede crear barreras nuevas, y mantener un monitoreo continuo de lo que se puede verificar de forma automática.
Sobre el autor

Daniel Paz

Especialista en WordPress, rendimiento y SEO, fundador de WebOption

Daniel Paz es especialista en WordPress, rendimiento y SEO, fundador de WebOption y conferencista internacional. Con más de 18 años de experiencia en desarrollo web, ayuda a empresas a convertir sus sitios en plataformas rápidas, eficientes y orientadas a resultados.

Vea lo que su sitio necesita corregir.

Una verificación gratuita por ley, con la causa y la guía de corrección de cada problema.

Verificar mi sitio gratisCrear una cuenta gratis

Siga leyendo

Socios

Beneficios de socios con un solo cupón.

WPLIGHT

Enlaces de socios. Podemos recibir una comisión, sin costo adicional para ti.