Accesibilidad digital en software médico: qué revisar

Historia clínica electrónica, portal del paciente, app de telesalud, sistema de citas: casi toda la atención en salud pasa hoy por una pantalla. Cuando esa pantalla solo funciona para quien ve bien, oye bien y usa el ratón con precisión, parte de los pacientes y de los profesionales queda atrás. La Ley Brasileña de Inclusión define persona con discapacidad como aquella que tiene 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 (Ley 13.146/2015). Un software mal diseñado es una de esas barreras.

NEXO es un juego diario de diagnóstico médico: un caso clínico por día, seis pistas progresivas y retroalimentación por proximidad en la CIE-10 en cinco niveles.

Esta guía resume las normas abiertas que orientan la accesibilidad digital, lo que los estudios encontraron en sitios web, historias clínicas y apps de salud y lo que hay que revisar antes de adoptar o desarrollar un sistema.

Puntos principales

• La referencia internacional es la WCAG, del W3C, organizada en cuatro principios y tres niveles de conformidad.
• En Brasil, la Ley Brasileña de Inclusión exige accesibilidad en los sitios web de empresas con sede o representación en el país y de órganos de gobierno, y el eMAG orienta los sitios web del gobierno federal.
• Estudios con sitios web, historias clínicas y apps de salud encuentran fallas repetidas: contraste bajo, enlaces y botones sin nombre, imágenes sin texto alternativo y navegación por teclado incompleta.
• Muchas fallas se encuentran con una prueba corta: teclado, lector de pantalla, ampliación y color.
• Involucrar a personas con discapacidad desde el diseño del sistema es la recomendación más constante de las revisiones.

Índice

• Qué es la accesibilidad digital en salud
• Las normas de referencia: WCAG, Ley Brasileña de Inclusión y eMAG
• Dónde fallan los softwares de salud, según los estudios
• Qué revisar en un software médico
• Accesibilidad en NEXO
• Preguntas frecuentes
• Checklist de accesibilidad para softwares médicos

Qué es la accesibilidad digital en salud

La Ley Brasileña de Inclusión define accesibilidad como la posibilidad y la condición de alcance, con seguridad y autonomía, de espacios, transportes, información y comunicación, incluidos sus sistemas y tecnologías, por persona con discapacidad o con movilidad reducida (Ley 13.146/2015). En el software, eso quiere decir que cada función puede ser percibida, operada y entendida por quien usa lector de pantalla, ampliación, teclado, comando de voz o subtítulos.

La WCAG 2.2 dice que seguir sus recomendaciones deja el contenido más accesible para personas ciegas o con baja visión, sordas o con pérdida auditiva, con movimiento limitado, con discapacidad del habla o fotosensibilidad, y en parte para personas con discapacidad de aprendizaje o limitaciones cognitivas (W3C, WCAG 2.2).

Quién depende de un software accesible

Lectura editorial: en el entorno de salud, la accesibilidad atiende al menos a tres grupos. Los pacientes, que piden citas, leen resultados y hablan con el equipo por portales y apps. Los profesionales con discapacidad, que necesitan registrar, prescribir y consultar la historia clínica con la misma seguridad que sus colegas. Y cualquier persona en una situación temporal, como un brazo inmovilizado, una pantalla pequeña en el turno o un ambiente ruidoso.

Las normas de referencia: WCAG, Ley Brasileña de Inclusión y eMAG

WCAG 2.2, del W3C

La WCAG (Web Content Accessibility Guidelines) es la recomendación del W3C para contenido web accesible; la versión 2.2 publicada lleva la fecha del 12 de diciembre de 2024 (W3C, WCAG 2.2). Las recomendaciones se organizan en cuatro principios (W3C, WCAG 2.2):

1. Perceptible: la información y los componentes de la interfaz deben presentarse de forma que el usuario consiga percibirlos.
2. Operable: los componentes y la navegación deben poder ser operados.
3. Comprensible: la información y la operación de la interfaz deben ser comprensibles.
4. Compatible: el contenido debe ser interpretado por una amplia variedad de programas, incluidas las tecnologías asistivas.

Cada criterio de éxito tiene un nivel: A (el mínimo), AA y AAA (el más alto), y el nivel AA exige cumplir todos los criterios A y AA (W3C, WCAG 2.2).

WCAG para software que funciona fuera de la web

Los historiales clínicos instalados en el computador y las apps nativas quedan fuera del alcance directo de la WCAG. Para ellos, el W3C publicó la WCAG2ICT, una nota que explica cómo aplicar los principios, las directrices y los criterios de las versiones 2.0, 2.1 y 2.2 a documentos y softwares que no son web; el texto es orientación informativa, y no norma (W3C, WCAG2ICT).

Ley Brasileña de Inclusión (Ley 13.146/2015)

El artículo 63 de la ley hace obligatoria la accesibilidad en los sitios de internet mantenidos por empresas con sede o representación comercial en el país o por órganos de gobierno, conforme a las mejores prácticas y directrices de accesibilidad adoptadas internacionalmente, y pide que los sitios exhiban un símbolo de accesibilidad destacado (Ley 13.146/2015). La definición de accesibilidad del artículo 3º incluye la información, la comunicación y sus sistemas y tecnologías (Ley 13.146/2015).

eMAG, el modelo del gobierno federal

El eMAG (Modelo de Accesibilidad en Gobierno Electrónico) está en la versión 3.1, de abril de 2014, y se presenta como una versión especializada de la WCAG orientada al gobierno brasileño (eMAG). La Ordenanza nº 3, del 7 de mayo de 2007, hizo obligatoria su observancia en los sitios y portales del gobierno brasileño (eMAG). A diferencia de la WCAG, el eMAG agrupa sus 45 recomendaciones por área (marcado, comportamiento, contenido, presentación, multimedia y formulario), y no por nivel de prioridad (eMAG).

Comparación rápida

Norma	Quién la publica	A qué se aplica
WCAG 2.2	W3C (WCAG 2.2)	Contenido web, con niveles A, AA y AAA
WCAG2ICT	W3C (WCAG2ICT)	Orientación para documentos y softwares fuera de la web
Ley 13.146/2015, art. 63	Presidencia de la República (Planalto)	Sitios de empresas con sede o representación en el país y de órganos de gobierno
eMAG 3.1	Gobierno federal (eMAG)	Sitios y portales del gobierno brasileño

Fuente de la tabla: páginas oficiales citadas en cada línea, abiertas el 11/10/2026.

Dónde fallan los softwares de salud, según los estudios

Sitios de salud

En una muestra de 139 sitios de salud entre los más visitados del mundo, el 91,3% de las páginas de inicio tenían fallas de accesibilidad detectables, y las más comunes fueron contraste bajo, enlaces vacíos, imágenes sin texto alternativo, botones vacíos y campos de formulario sin etiqueta (Mason et al., 2021).

En un estudio australiano con 185 páginas de servicios que atienden a personas después de un ACV, el 81,1% tenían al menos un error según la WCAG, y el más frecuente, en el 49,7% de las páginas, fue el enlace vacío, que el lector de pantalla es incapaz de anunciar (Giummarra et al., 2025). Solo 17 sitios publicaban una declaración de accesibilidad, y los sitios de órganos de gobierno tuvieron menos problemas que los del sector privado (Giummarra et al., 2025).

En la pandemia, una evaluación automática de 54 sitios oficiales de agendamiento de la vacuna contra la covid-19 en Estados Unidos encontró un cumplimiento por debajo de lo esperado de las versiones 2.0 y 2.1 de la WCAG (Alismail y Chipidza, 2021).

Historial clínico electrónico

Un estudio probó tres historiales clínicos electrónicos de código abierto con pruebas automáticas y manuales y con tres lectores de pantalla (JAWS, NVDA y VoiceOver). Los tres sistemas eran solo parcialmente accesibles, y los principales puntos a mejorar fueron la navegación por teclado y la compatibilidad con lector de pantalla (Moncy et al., 2023).

Apps de salud

En un piloto con tres apps de control de peso bien valoradas en las tiendas, nueve personas con discapacidad visual, de destreza o cognitiva probaron cada app; las personas con discapacidad visual dieron las notas de accesibilidad más bajas y relataron más dificultades (Radcliffe et al., 2021).

Cómo se desarrollan los servicios digitales de salud

Una revisión de alcance sobre servicios de salud digital incluyó 15 publicaciones, de las cuales 2 definían accesibilidad y 5 usaron la WCAG para evaluarla (Jonsson et al., 2023). Otra revisión, con 25 fuentes, concluyó que las necesidades varían según el tipo de discapacidad y que el diseño participativo, con personas con discapacidad desde la fase de idea, lleva a soluciones más accesibles (Henni et al., 2022).

Una revisión de alcance publicada en 2026 reunió 80 documentos y señaló el diseño accesible, el codiseño con los usuarios y las normas internacionales de accesibilidad como los factores que más favorecen una salud digital equitativa (Umucu et al., 2026).

El historial clínico también puede registrar necesidades de accesibilidad

En un ambulatorio de oftalmología, un cuestionario en la historia clínica electrónica preguntaba, al agendar, si el paciente necesitaba algún apoyo de accesibilidad; de 250.932 atenciones, el 9,4% tuvo alguna solicitud, con mayor frecuencia de movilidad (Varadaraj et al., 2022). Los autores consideran que ese registro estandarizado puede llevarse a otros servicios (Varadaraj et al., 2022).

Cómo leer estos estudios

Pregunta	Qué permiten decir los estudios anteriores
¿Las fallas son comunes?	Sí, en sitios de salud de varios países, con mayoría de páginas con al menos un error
¿Qué fallas aparecen más?	Contraste bajo, enlaces y botones sin nombre, imágenes sin texto alternativo, formularios sin etiqueta
¿Y la historia clínica?	En una prueba con tres sistemas de código abierto, la accesibilidad fue parcial
¿Qué ayuda?	Diseño participativo, normas internacionales y pruebas con lector de pantalla

Fuente de la tabla: síntesis del Editorial a partir de Mason et al., 2021, Giummarra et al., 2025, Moncy et al., 2023, Henni et al., 2022 y Umucu et al., 2026.

Qué revisar en un software médico

Los criterios siguientes vienen de la WCAG 2.2 y cubren las fallas que más aparecen en los estudios. La columna de ejemplo es lectura editorial.

Criterios esenciales

Criterio de la WCAG 2.2	Qué pide	Ejemplo en salud
1.1.1 Contenido no textual (A)	Alternativa en texto para todo contenido no textual (WCAG 2.2)	Ícono de alergia con nombre leído por el lector de pantalla
1.4.1 Uso del color (A)	El color nunca es el único medio de transmitir una información (WCAG 2.2)	Resultado crítico en rojo y también con la palabra "crítico"
1.4.3 Contraste mínimo (AA)	Contraste de al menos 4,5:1 para texto común (WCAG 2.2)	Texto gris claro sobre fondo blanco reprueba
1.4.4 Redimensionar texto (AA)	Texto ampliable hasta 200% sin pérdida de contenido o función (WCAG 2.2)	La prescripción sigue legible con zoom
2.1.1 Teclado (A)	Toda función operable por el teclado (WCAG 2.2)	Firmar y enviar la receta usando solo el teclado
2.4.11 Foco no oculto (AA)	El elemento con foco del teclado queda visible, al menos en parte (WCAG 2.2)	Barra fija de la historia clínica cubriendo el campo en edición reprueba
2.5.8 Tamaño del objetivo (AA)	Objetivos de toque o clic con al menos 24 por 24 píxeles CSS, con excepciones (WCAG 2.2)	Botones de dosis pequeños y pegados unos a otros reprueban
4.1.3 Mensajes de estado (AA)	Mensajes de estado anunciados por la tecnología asistiva sin cambiar el foco (WCAG 2.2)	"Prescripción guardada" anunciada al lector de pantalla

Fuente de la tabla: criterios de la WCAG 2.2 citados en cada línea; ejemplos del Editorial.

La WCAG también tiene un criterio de nivel AAA que pide que las animaciones disparadas por interacción puedan desactivarse, salvo cuando sean esenciales (W3C, WCAG 2.2).

Una prueba rápida antes de adoptar un sistema

Sugerencia práctica del Editorial, para quien evalúa un software antes de comprar o implantar:

1. Desconecte el mouse e intente hacer la tarea principal, como abrir un paciente, registrar una evolución y guardar, solo con el teclado.
2. Active el lector de pantalla del sistema operativo y confirme si botones, campos y alertas se anuncian con nombre.
3. Amplíe la pantalla al doble y vea si algo desaparece, se superpone o exige desplazamiento lateral.
4. Vea la pantalla en tonos de gris y confirme si alertas y estados siguen claros.
5. Pida al proveedor la declaración de accesibilidad y el informe de conformidad con la WCAG.
6. Pruebe con quienes van a usarlo, incluidos profesionales y pacientes con discapacidad.

Para quien desarrolla o compra

• Pruebe temprano y con personas. Las pruebas automáticas encuentran parte de las fallas; la combinación con pruebas manuales y lectores de pantalla fue el método del estudio con historias clínicas (Moncy et al., 2023).
• Defina qué es accesible. La revisión sobre servicios de salud digital encontró pocas publicaciones con definición clara de accesibilidad (Jonsson et al., 2023).
• Publique una declaración de accesibilidad con el nivel buscado y un canal para reportar barreras.
• Registre las necesidades del paciente en la propia historia clínica, como en el cuestionario del ambulatorio de oftalmología (Varadaraj et al., 2022).

Accesibilidad en NEXO

NEXO publica una declaración de accesibilidad en la que dice buscar el nivel AA de la WCAG 2.1 y enumera recursos del sitio: estructura semántica con jerarquía de títulos, contraste mínimo para texto común, diseño que se adapta al tamaño de la pantalla y al zoom, texto alternativo en las imágenes con significado y medios que solo se reproducen cuando la persona lo pide. La misma página trae un correo electrónico para reportar barreras de accesibilidad.

En el juego, cada hipótesis muestra el nivel de proximidad con color, ícono y el nombre del nivel escrito, y las animaciones respetan la preferencia de reducir movimiento del sistema operativo.

Cómo funciona el juego

En NEXO, cada caso llega en hasta seis pistas, una a la vez, y das tu hipótesis por el nombre del diagnóstico o por el código de la CIE-10. Con cada hipótesis incorrecta, el juego muestra la proximidad en cinco niveles, desde capítulo diferente hasta CIE exacto, y abre la siguiente pista.

El Diario trae un caso por día, igual para todos, y el Archivo reúne los casos diarios anteriores. El Multimedia trae imagen, audio y otros exámenes, y el Continentes cambia la epidemiología de fondo. El Adrenalina agrega tiempo. Cómo se libera cada modo está en la página de economía de NEXO.

Guardar, discutir y participar

El botón de Anki crea la tarjeta directo desde NEXO y abre en la app de Anki, busca las tarjetas que ya tienes y, cuando el caso tiene imagen, lleva la imagen a la tarjeta. La pestaña Grupo del ranking, que reúne colegas invitados, permite comparar en qué pista acertó cada uno. Médicos generalistas o especialistas con registro activo pueden revisar casos de su área por NEXO Curator. Si coordinas una residencia, una liga o una facultad, conoce NEXO Closer; investigadores en accesibilidad y educación médica pueden proponer estudios por NEXO Researcher, y quienes producen contenido de medicina pueden conocer NEXO Creators.

Preguntas frecuentes

¿Qué es la accesibilidad digital en softwares médicos?

Es la condición de un sistema de salud, como historia clínica, portal o app, de poder ser percibido, operado y entendido por personas con discapacidad, incluso con tecnologías asistivas. La referencia internacional es la WCAG, del W3C (W3C, WCAG 2.2).

¿La ley brasileña exige accesibilidad en sitios de salud?

El artículo 63 de la Ley Brasileña de Inclusión exige accesibilidad en los sitios de internet de empresas con sede o representación comercial en el país y de órganos de gobierno (Ley 13.146/2015). Para dudas sobre un caso específico, consulta la asesoría jurídica de tu institución.

¿Qué nivel de la WCAG debe buscar un software de salud?

El nivel AA es el más citado como meta, incluso en estudios que evalúan sitios de salud, y exige cumplir todos los criterios A y AA (W3C, WCAG 2.2).

¿La WCAG aplica para historia clínica instalada en la computadora?

La WCAG trata de contenido web. Para softwares fuera de la web, el W3C publicó la WCAG2ICT, que explica cómo aplicar los mismos criterios (W3C, WCAG2ICT).

¿Cuál es la diferencia entre eMAG y WCAG?

El eMAG es una versión especializada de la WCAG para el gobierno brasileño y agrupa las recomendaciones por área, y no por nivel (eMAG).

¿NEXO es accesible?

NEXO publica una declaración de accesibilidad con meta de nivel AA de la WCAG 2.1 y un canal para reportar barreras. Para conocer el juego, lee qué es NEXO.

Checklist de accesibilidad para softwares médicos

1. Toda imagen y todo ícono con alternativa en texto.
2. Información transmitida por color también transmitida por texto o ícono.
3. Contraste suficiente entre texto y fondo.
4. Texto que se amplía sin romper la pantalla.
5. Tareas completas por teclado, con foco siempre visible.
6. Botones lo bastante grandes y con espacio entre ellos.
7. Alertas y confirmaciones anunciadas al lector de pantalla.
8. Animaciones que pueden reducirse.
9. Declaración de accesibilidad publicada, con canal de contacto.
10. Pruebas con personas con discapacidad antes y después de cada cambio grande.

¿Quieres entrenar diagnóstico con un caso corto por día? Juega el caso del día en NEXO.

Referencias

1. Mason AM, Compton J, Bhati S. Disabilities and the Digital Divide: Assessing Web Accessibility, Readability, and Mobility of Popular Health Websites. J Health Commun. 2021. https://pubmed.ncbi.nlm.nih.gov/34657585/
2. Giummarra MJ, Brown E, Rose TA, et al. How accessible are the websites of health services for people who have had a stroke? Int J Equity Health. 2025. https://pubmed.ncbi.nlm.nih.gov/40275299/
3. Alismail S, Chipidza W. Accessibility evaluation of COVID-19 vaccine registration websites across the United States. J Am Med Inform Assoc. 2021. https://pubmed.ncbi.nlm.nih.gov/33993310/
4. Moncy MM, Pilli M, Somasundaram M, et al. Evaluation of accessibility of open-source EHRs for visually impaired users. AMIA Annu Symp Proc. 2023. https://pubmed.ncbi.nlm.nih.gov/38222344/
5. Radcliffe E, Lippincott B, Anderson R, Jones M. A Pilot Evaluation of mHealth App Accessibility for Three Top-Rated Weight Management Apps by People with Disabilities. Int J Environ Res Public Health. 2021. https://pubmed.ncbi.nlm.nih.gov/33915917/
6. Jonsson M, Johansson S, Hussain D, et al. Development and Evaluation of eHealth Services Regarding Accessibility: Scoping Literature Review. J Med Internet Res. 2023. https://pubmed.ncbi.nlm.nih.gov/37590050/
7. Henni SH, Maurud S, Fuglerud KS, Moen A. The experiences, needs and barriers of people with impairments related to usability and accessibility of digital health solutions, levels of involvement in the design process and strategies for participatory and universal design: a scoping review. BMC Public Health. 2022. https://pubmed.ncbi.nlm.nih.gov/34991540/
8. Varadaraj V, Guo X, Reed NS, et al. Identifying Accessibility Requests for Patients With Disabilities Through an Electronic Health Record-Based Questionnaire. JAMA Netw Open. 2022. https://pubmed.ncbi.nlm.nih.gov/35394512/
9. Umucu E, Lee B, Vernon A, et al. Inclusive Digital Health Strategies for Persons With Disabilities: A Scoping Review. JAMA Netw Open. 2026. https://pubmed.ncbi.nlm.nih.gov/42742940/

Páginas oficiales consultadas

1. W3C. Web Content Accessibility Guidelines (WCAG) 2.2, consultada el 11/10/2026. https://www.w3.org/TR/WCAG22/
2. W3C. Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT), consultada el 11/10/2026. https://www.w3.org/TR/wcag2ict-22/
3. Brasil. Ley n.º 13.146, del 6 de julio de 2015 (Ley Brasileña de Inclusión de la Persona con Discapacidad), consultada el 11/10/2026. https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm
4. Gobierno federal. eMAG, Modelo de Accesibilidad en Gobierno Electrónico, versión 3.1, consultada el 11/10/2026. https://emag.governoeletronico.gov.br/
5. NEXO. Accessibility Statement, consultada el 11/10/2026. https://nexo.wiki.br/accessibility