Guia de Accesibilidad 2brains

Guía para construir
Productos digitales
accesibles
•
•
•1 ,&
Accesibilidad web, el paso que

falta para mejorar tus productos digitales.
Contenidos
Bienvenida 3
Prólogo escrito por la comunidad de DALAT 5
Capítulo 1: 7
Accesibilidad web: La gran aliada para el negocio y la persona
usuaria.
Capítulo 2: 18
Una población clave en aumento.
Capítulo 3: 24
Más de una forma de acceder al contenido digital.
Capítulo 4: 27
Buenas prácticas para implementar la accesibilidad web.
Capítulo 5: 42
Directrices técnicas para un producto digital accesible.
Capítulo 6: 163
Accesibilidad web, mucho más que estándares técnicos
Anexo: 166
Recursos para revisar la accesibilidad web
Agradecimientos 172
Bienvenida
En mayo de 2021 desde 2Brains realizamos el primer evento para

celebrar el Día Mundial de Concientización sobre Accesibilidad (GAAD),
como una primera acción para visibilizar y generar conciencia sobre el
tema en relación a nuestro rol como creadores de productos
digitales de calidad en la industria. En este espacio, tuvimos la oportunidad
de realizar una charla a cargo de nuestra especialista en accesibilidad
Carolina Aguilera, contar con un panel de activistas internacionales y con
el apoyo del gran equipo de experiencia de 2Brains para diseñar y
comunicar cada espacio del evento “Accesibilidad web, más allá de los
estándares”.
Este año quisimos ir más allá y nos propusimos como meta crear este
eBook con el objetivo de celebrar y visibilizar la relevancia de la
accesibilidad web, y principalmente, entregar herramientas prácticas para
crear productos digitales accesibles. Creemos en la responsabilidad
compartida que tenemos todos los actores dentro de la industria de la
tecnología para generar productos enfocados a todas las personas, como
derecho universal al acceso a la información de forma equitativa.
| Guía para construir productos digitales accesibles 3

Bienvenida
Detrás de este eBook, hay muchas personas que han aportado con su
conocimiento desde distintas áreas, ya sea creando y revisando
contenido, diseñando, programando y aportando con sus visiones para
obtener una guía práctica que aporte a mejorar la accesibilidad web de
sitios y aplicaciones, desde la implementación de pequeñas mejoras
hasta grandes cambios en los flujos de trabajo, y en ello, todos y todas
tenemos la responsabilidad de tomar acción y posición.
Lo que nos ha motivado para crear esta guía es la posibilidad que

tenemos de mejorar la calidad de vida de las personas, es por eso que la
compartimos de forma gratuita con toda la comunidad.
Les damos la bienvenida a la Guía para construir productos digitales

accesibles ¡Manos a la obra!
Carolina Sepúlveda R.
Head of UX de 2Brains

Prólogo
Pocas veces somos conscientes del impacto que puede tener en el mundo
lo que hacemos y pensamos. Y cuando lo hacemos, nos parece exagerado
¿qué puede hacer una gota en el mar? Pero obviamos que lo que forma-
ba parte de esa gota ha cambiado de alguna manera la composición de
todo el mar. El mar ahora se parece a esa gota un poco más.
Es así como se construye y perpetúa la realidad. El mundo digital es parte

de la realidad, la tecnología se integra cada vez más a nuestra vida y nos
devuelve nuestro reflejo. ¿Construiremos las mismas formas de exclusión?
¿Replicaremos los mismos errores del mundo físico o estamos dispuestos
a construir uno mejor? Los cambios reales, los que se sostienen en el tiem-
po, son aquellos que nacen de la reflexión acompañada de la acción.
Cuando 2Brains nos invitó junto a otros expertos de la región a un panel

sobre Accesibilidad Digital, llegamos a conocerlos e identificar que esta-
ban decididos no solo a discutir del tema sino a tomar acciones para ha-
cer que las cosas sucedan. Como consecuencia de ese activismo nace
este libro que brinda una plataforma de recursos, una base fundamental,
un mapa que orienta a más profesionales que deseen transitar por sí mis-
mos el territorio de la inclusión digital.

Prólogo
Este libro nos invita a pensar. A pensar en la forma en que construimos

nuestros servicios y productos, a pensar en la accesibilidad como un de-
recho humano pero sobre todo, como dijo la activista costarricense Alina
Soto, en el derecho mismo a la dignidad humana.
Este libro nos invita a hacer, nos da herramientas concretas contra la ex-
clusión digital. Esta es una de las gotas que Carolina, especialista en acce-
sibilidad de 2Brains, suma a este mar de realidad.
Y como el mar, cada lector después de la lectura de este libro habrá cam-
biado.
Susana Pallero y Silvia Márquez

Comunidad de Desarrollo Accesible
Latinoamericano - DALAT

Capítulo 1
Accesibilidad web: La gran aliada

para el negocio y la persona usuaria
La gran aliada para el negocio y la
persona usuaria
'' En Barclays, la accesibilidad es algo más que una simple

discapacidad. Se trata de ayudar a todos a trabajar, reali-
zar operaciones bancarias y vivir sus vidas sin importar su
edad, situación, habilidades o circunstancias.
Paul Smyth
Director de Accesibilidad Digital de Barclays, compañía de servicios
financieros con sede en Londres y que opera a nivel mundial.
''
El World Wide Web Consortium (W3C) contempló la universalidad y la
accesibilidad como atributos esenciales para la Web desde sus inicios
(1998), sin embargo, aún existen barreras importantes de acceso para las
personas usuarias, y en particular, para quienes se encuentran en situa-
ción de discapacidad y los adultos mayores. Si se revisa el último reporte
de accesibilidad web entregado por WebAIM, The WebAIM Million, podre-
mos ver que, de un millón de páginas de inicio evaluadas por la organiza-
ción a nivel mundial, el 96.8% arrojó incumplimientos respecto del estándar
internacional en esta materia, las Pautas de Accesibilidad Web (WCAG).

La gran aliada para el negocio y la persona usuaria
Pero, ¿qué es la accesibilidad web? Es la capacidad de que un sitio web,

aplicación móvil o documento electrónico sea perceptible, operable y
comprensible para una amplia gama de personas, con un diverso rango
de audición, movimiento, visión y habilidades cognitivas.
En palabras de la empresa Microsoft: la accesibilidad está representada

en “Aquellas cualidades que hacen que una experiencia esté abierta a to-
das las personas”.
Asimismo, de acuerdo al Inclusive 101 Toolkit de Microsoft, debemos pensar

en 3 niveles o estados de discapacidad al diseñar un producto:
z Permanente: experimentado por aquellos que tienen una dis-

capacidad como visual, motora, auditiva, del habla o cogni-
tiva.
z Temporal: experimentado por aquellos que tienen una lesión

a corto plazo o están pasando por eventos especiales por un
corto tiempo, como mirar una luz brillante o pedir una cena en
un país extranjero.
z Situacional: experimentado por aquellos cuyas habilida-

des pueden cambiar drásticamente en entornos específicos,
como no poder escuchar bien en una multitud ruidosa o ma-
dres y padres que realizan tareas con una sola mano.

Permanente Temporal Situacional
Motora
Un brazo Lesión en el brazo Nuevo padre o madre
Visual
Ciego o ciega Cataratas Conductor distraído
Auditiva
Sordo o sorda Infección auditiva Bartender
Habla
No-verbal Laringitis Diferente idioma
Estados de discapacidad descritos por Microsoft en el material

“Inclusive 101 Toolkit”.

Quizás te preguntes por qué deberías incluir la accesibilidad web dentro

de tu proyecto digital. O, quieres saber qué argumentos puedes darle a tu
líder o cliente que no está convencido de incorporar lineamientos de
diseño y desarrollo accesibles.
A continuación, te contamos sobre algunos de los principales argumentos

para adoptar este atributo como filosofía para tu organización, para
mejorar el negocio y para cambiar la negativa de ciertos stakeholders
respecto a trabajar con estándares de calidad en sus productos digitales.
1. Una cuestión de derechos
La Organización de Naciones Unidas (ONU) reconoció en

la Convención sobre los Derechos de las Personas con Dis-
capacidad, el acceso a los contenidos de la Web como un
derecho de las personas con discapacidad, considerando
además la accesibilidad digital como un mandato funda-
mental.
El no cumplir con este requisito es un acto de vulneración

de derechos de este colectivo, e incluso, puede costarle a la
organización una demanda por ello. Mejor no correr el riesgo
¿verdad?.

2. La falta de accesibilidad web no es un buen

negocio
Un contenido digital no accesible excluye a millones de per-

sonas de participar en la Web e interactuar con sus conte-
nidos. Puede ser un alto precio a pagar. Las personas que no
logran acceder al contenido web por falta de accesibilidad,
y por tanto, de usabilidad, abandonarán el sitio en busca de
uno más fácil de usar, lo que implica un posible aumento en
la tasa de rebote y el daño a la marca dentro de la industria.

3. Mejorar la accesibilidad de tu sitio proporcionará

beneficios tangibles, entre ellos:
z Impulsar la innovación dentro de la empresa u organización,

ya sea mediante la generación de nuevos procesos de traba-
jo, la incorporación de nuevas tecnologías, entre otros aspec-
tos.
z Aumentar el alcance del negocio a un segmento más amplio

de la población.
z Obtener los beneficios de la optimización de motores de bús-

queda o SEO aplicando buenas prácticas alineadas con la
accesibilidad web. Según señala el Bureau of Internet Acces-
sibility (BOIA) “los sitios web que se toman en serio la accesi-
bilidad web constantemente obtienen una clasificación más
alta que su competencia en Google y YouTube”, lo que suma-
do a un diseño claro y comprensible, tanto visualmente como
en el adecuado uso de la semántica en el código, incidirá en
la reducción de las tasas de rebote, es decir, la gente no se irá
de tu sitio y no hará clic en otra página.

z En el artículo “Five Ways to Improve Your SEO with Web Acces-

sibility” el BOIA deja algunas sugerencias para mejorar este
recurso, como por ejemplo: describir el contenido no textual
del sitio web mediante el atributo HTML “alt” y la aplicación de
subtitulado en el contenido audiovisual; el uso de fuentes fá-
ciles de leer; un contenido bien organizado; la facilitación de
la navegación mediante teclado, entre otras.
z Entregar una experiencia satisfactoria a todas las personas

usuarias. La posibilidad de poder navegar por el sitio y acce-
der a su contenido, mejorará la visión que se tiene de la mar-
ca en el mercado.
z Finalmente, valor añadido. Si un producto digital satisface las

necesidades de más personas, es más atractivo; es posible
enfocar los productos a más mercados potenciales; y, si un
producto digital puede ser utilizado por más personas, el be-
neficio será mayor.

4. La clave está en la persona usuaria
Escuchar a tus usuarios y usuarias y conocer sus necesidades es

parte del éxito para lograr un sitio realmente accesible, usable y
competitivo. Esto sin duda favorecerá la permanencia de la perso-
na en la plataforma (ya sea un e-commerce, un banco, una univer-
sidad, etc.) y aumentará la probabilidad de compra, la adquisición
de un servicio, entre otros objetivos.
Un ejemplo de cómo la accesibilidad enfocada en la inclusión puede re-

sultar un éxito es la experiencia desarrollada por PlayStation: “El diseño de
The Last of Us Part 2, tiene la mayor cantidad de opciones de accesibilidad
de cualquier juego que
se haya creado. El juego
no solo fue una haza-
ña brillante de diseño
e ingeniería accesibles,
sino que se propuso de =----=--
manera activa y re- •
suelta incluir a todos los
• •••
humanos”.

Y, ¿cómo respondió Internet? Con una enorme cantidad de cobertura en

las redes sociales y en la prensa, lo que significó un notable impacto posi-
tivo de marca para PlayStation.
Por eso, es muy importante conocer casos de éxito sobre la implementa-

ción de la accesibilidad web y poder comunicarlos para fundamentar el
por qué este atributo es relevante tanto para el negocio como para la per-
sona usuaria.
Pantalla de inicio del video juego “The last of us” Parte 2.

En resumen, la accesibilidad web permite:
z La navegación mediante teclado y tecnologías asistivas sin

barreras.
z Mejorar el SEO (lo que de seguro le interesará mucho al área

de Marketing).
z Ampliar el alcance del negocio a un mayor número de perso-

nas, considerando en ello a las personas con discapacidad y
adultos mayores.
z Mejorar la marca y favorecer la competitividad.
z Mantener a la persona usuaria en tu sitio web.
z Garantizar el acceso a tu producto digital, evitando así posi-

bles demandas por parte de la comunidad.

Capítulo 2
Una población clave en aumento

De acuerdo a la Organización Mundial de la Salud (OMS): “El número de

personas con discapacidad está aumentando debido al envejecimiento
de la población y al aumento de enfermedades crónicas”, dos variables
que sin duda debes tener en consideración al momento de perfilar a los
potenciales usuarios y usuarias de tu producto digital.
La Convención Internacional sobre los Derechos de las Personas con Dis-

capacidad de 2008, define la discapacidad como: “un concepto que re-
sulta de la interacción entre las personas con deficiencias y las barreras
debidas a la actitud y al entorno que evitan la participación plena y efecti-
va en la sociedad, en igualdad de condiciones con los demás”. En esencia,
discapacidad es lo que ocurre cuando las necesidades funcionales de una
persona no son consideradas por el entorno físico, social, digital en los que
se relaciona y participa, poniéndola en una injusta situación de desventa-
ja e inequidad, que se convierte en una responsabilidad social, en la que
todos estamos involucrados.

Sin embargo, frente a un sitio web accesible, el impacto de la discapaci-

dad cambia radicalmente, porque la accesibilidad elimina las barreras
de comunicación e interacción que muchas personas encuentran en el
mundo físico.
A continuación, encontrarás algunas cifras interesantes de conocer res-

pecto a la población con discapacidad y los adultos mayores:
•
•
•
1 "

z La OMS indica en su Informe Mundial sobre la Discapacidad

2011 que a nivel mundial más de mil millones de personas
presentan alguna discapacidad, lo que corresponde al 15% de
la población (2010).

z En tanto, la Organización de las Naciones Unidas (ONU) repor-

tó que, a nivel mundial, en 2019 había 703 millones de perso-
nas de 65 años o más.

z De acuerdo al Segundo Estudio Nacional de la Discapacidad

del Servicio Nacional de la Discapacidad (Senadis), alrededor
de 3 millones de personas presentan alguna discapacidad en
Chile (2015).
z De acuerdo a las proyecciones realizadas

por el Instituto Nacional de Esta-
dísticas, la población de
adultos mayores en
Chile asciende a más •
de 2 millones 200 mil
personas de 65 años
y más (2019). Para
2035, se prevé un
importante aumento
de este grupo etario,
que se compondrá de 3
millones 993 mil 821 per-
sonas mayores.
z El W3C agrega otra arista en términos de cifras, señalando

ejemplos como los de Reino Unido y Estados Unidos, donde las
personas con discapacidad y sus familias gastan al menos
249 billones de libras cada año en el primero, mientras que
en el segundo, el gasto anual de este colectivo supera los 200
billones de dólares.
z A nivel global, indica que la estimación para el mercado de la

discapacidad se acerca a los 7 trillones de dólares.

Capítulo 3
Más de una forma de acceder al

contenido digital
Más de una forma de acceder al contenido digital
Todas las personas usuarias tienen necesidades, preferencias y diversas

formas de navegar e interactuar con un sitio web. Una persona con ce-
guera puede acceder al contenido digital utilizando una línea braille, audio
y lector de pantalla (o screen reader), así como una persona con disca-
pacidad motriz puede hacerlo mediante un emulador de teclado y mouse
adaptado, eye tracking, pulsadores, entre otros recursos. Este tipo de he-
rramientas se conocen como tecnologías asistivas.
También, utilizan estrategias adaptativas, es decir, técnicas como au-

mentar el tamaño del texto, reducir la velocidad del mouse y activar los
subtítulos. Combinan técnicas con software estándar, navegadores web
convencionales y tecnologías asistivas.

Aprende más sobre el tema:
El W3C entrega más información sobre cómo las personas con discapa-
cidad usan la Web. Para profundizar sobre este punto, revisa las siguientes
páginas:
¾ Tools and Techniques
¾ Diverse Abilities and Barriers
Revisa también:
¾ Herramientas facilitadoras de la Accesibilidad
| Guía para construir productos digitales accesibles

Capítulo 4
Buenas prácticas para implementar

la accesibilidad web
Buenas prácticas para implementar
la accesibilidad web
El diseño y desarrollo accesibles son aspectos clave para que un sitio web
o una aplicación permitan el acceso efectivo a sus contenidos. En caso de
no haber incluido desde un comienzo estándares técnicos y buenas prác-
ticas de accesibilidad web en ambas etapas, obtendrás un producto que
no entregará una experiencia de calidad a muchas personas, y que ade-
más, dificultará la percepción, comprensión, legibilidad y usabilidad del
contenido.
0
Adecuado contraste Navegabilidad mediante Tamaños de texto
decolores tecnologías asistivas legibles
~ [w ®
Encontrabilidad de Formularios uusables y Orientación para
los contenidos navegables el usuario
Permite a la persona usuaria navegar e interactuar incluyendo buenas prácticas

de accesibilidad en tu proceso de trabajo.

Buenas prácticas para implementar la accesibilidad web
A lo anterior, se suman las barreras que deberán enfrentar las personas

usuarias de tecnologías asistivas, mediante las que interactúan con el
entorno digital.
A continuación, encontrarás una serie de recomendaciones que te ayuda-

rán a implementar la accesibilidad web en los procesos de diseño de con-
tenido y desarrollo de tu producto digital.
Accesibilidad primero
z Incorpora la accesibilidad desde el principio en los proyectos

para que no sea necesario volver atrás y rehacer el trabajo.
Cuando desplazas la accesibilidad hacia la izquierda, al co-
mienzo del flujo de trabajo, ahorrarás tiempo, dinero y esfuerzo
a tu empresa o cliente. De acuerdo a la investigación “Minimi-
zing Code Defects to Improve Software Quality and Lower De-
velopment Costs”, realizada por IBM: “esperar hasta la fase de
mantenimiento para detectar fallos de accesibilidad puede
significar un impacto financiero 30 veces mayor que el costo
original de una función”.

.-
.........
••.
...
•• ♦
••
~
ux • . Scrum •
RESEARCH
:t--'
, ..
........ ••
'-.- ■•··
♦•
...• •.
:,• ♦..
ux .:
DESIGN
...
• Sprint
..
. •
••• •••
•••
- - .1..- .. 111119,
... _
•••- -
·- -·-
ux
RESEARCH
La accesibilidad debe trabajarse a lo largo de todo el proceso de trabajo y no úni-

camente en la etapa de QA.
z Entonces, la forma más rentable de garantizar la calidad de

tu producto es detectar los fallos lo antes posible, práctica
conocida como Shift Left, que incide en el ciclo de desarrollo
del producto al considerar cómo hacer que los productos di-
gitales sean accesibles antes de que se codifiquen.
z En el artículo “Better Accessibility Adoption: Four Key Reasons

to Spread the Word—and the Work” puedes conocer más be-
neficios de este proceso.

Control de calidad
z Es importante que integres buenas prácticas de accesibilidad
a través de todo el flujo de trabajo y no a partir del proceso de
desarrollo o después de la fecha de entrega.
z Complementa los puntos de QA que establezcas mediante el

testeo con usuarios en las distintas etapas del diseño UX y UI
y también durante el desarrollo.
Aprende y comparte
z Ve la accesibilidad web como una ventaja y una característi-
ca imprescindible para toda experiencia digital y tecnológica
que se genere.
z Contar con un equipo capacitado y un consultor en accesi-

bilidad, es esencial. Si dentro de alguno de los equipos existe
alguien que no es cercano a este concepto, debes otorgarle
los espacios de aprendizaje y capacitación necesarios.

z Investigar, identificar buenas prácticas de accesibilidad y

compartirlas son acciones que aumentarán el conocimiento
de los equipos. Además, saber cómo otros han implementado
técnicamente la accesibilidad en sus productos, puede gene-
rar nuevas ideas y soluciones.
Trabaja en equipo
z No des por hecho que todo el mundo será capaz de manejar-
se con un producto de la misma forma y facilidad que tú y que
otros. El contexto de uso y las capacidades físicas, sensoriales
y cognitivas de los usuarios pueden ser muy diferentes.
z Es clave trabajar de la mano con las Pautas de Accesibilidad

para el Contenido Web y las especificaciones WAI-ARIA, de-
sarrolladas en el W3C. Estas pautas describen los estánda-
res técnicos, de código, de interacción y de diseño mediante
principios, directrices, criterios de conformidad y técnicas su-
ficientes.
z Dile adiós a los silos. Contenido, diseño y desarrollo son áreas

que deben trabajar en conjunto.

z No olvides considerar dentro de tu equipo a un UX Writer. El

contenido textual es tan importante como el componente vi-
sual.
z Cada equipo debe contar desde un comienzo con un chec-

klist que indique los requisitos de accesibilidad que deben
considerarse a nivel de diseño y desarrollo. Esto también ayu-
dará al proceso de QA.
z Es recomendable que los diseñadores indiquen al equipo de

desarrollo cómo deben comportarse los componentes cons-
truidos. El sistema de diseño puede ser un buen espacio para
dejar esas indicaciones y realizar un traspaso (o hand-off)
del diseño a desarrollo más robusto.

z Si debes priorizar qué lineamientos de accesibilidad se im-

plementarán primero, ya sea por lo ajustado de los plazos de
trabajo o porque te piden aplicar las mejoras por etapas (di-
seño y desarrollo), comienza por los criterios de éxito de las
Pautas de Accesibilidad relacionados con:
Contraste y uso del color.
Descripción textual de elementos no textuales (imáge-

nes, gráficos, videos, etc.).
Organización lógica del contenido para una correcta na-

vegación.
Presentación visual del texto (tamaño y tipo de fuente,

espaciado)
Tamaño suficiente de los componentes interactivos de la

interfaz de usuario, como botones, controles de formula-
rios, enlaces, entre otros.

Movimiento que no produce reacciones físicas en la per-

sona usuaria.
Navegación por teclado y lectores de pantalla.
Adecuada implementación de encabezados (o headings).
Código semántico limpio y correctamente implementado.

El usuario al centro
z Para lograr productos y servicios accesibles e inclusivos de-
bes diseñar para distintos tipos de persona usuaria. Plantea
las historias y casos de uso pensando en las diversas formas
que usan para navegar la web y acceder al contenido digital.
z Testea en diferentes etapas del diseño y desarrollo del pro-

ducto, incluyendo en las pruebas a personas en situación de
discapacidad y adultos mayores. Ellos se enfrentan constan-
temente a barreras digitales por la falta de accesibilidad de
los sitios web y aplicaciones y sin duda tendrán mucho que
aportar.
z Es esencial observar a las personas en acción para compren-

der cómo aplicar los estándares técnicos de accesibilidad y
por qué existen.
z No olvides investigar sobre las formas en que los usuarios con

discapacidad y adultos mayores navegan la Web, qué recur-
sos o técnicas emplean para ello y cuáles son las barreras y
facilitadores implicados en el proceso.

Estándar técnico para el contenido web

Las Pautas de Accesibilidad para el Contenido Web (o WCAG por su nom-
bre en inglés), desarrolladas por el World Wide Web Consortium (W3C),
contienen lineamientos para el diseño y desarrollo de sitios y aplicacio-
nes accesibles, usables por una gran variedad de personas.
Asimismo, el W3C indica la necesidad del uso de código nativo para el de-
sarrollo de sitios o aplicaciones y el uso de las especificaciones WAI-ARIA
cuando corresponda. Este último estándar tiene especial relación con el
contenido dinámico y los controles avanzados de la interfaz de usuario y
se utiliza en aplicaciones web y en el acceso a sitios web con dispositivos
móviles.
'' La accesibilidad es esencial para los desarrolladores y las

organizaciones que desean crear sitios web y herramientas
web de alta calidad, y no excluir a las personas del uso de
sus productos y servicios
World Wide Web Consortium (W3C) ''

Estructura
La versión WCAG 2.1 se organiza en cuatro grandes principios que dan
fundamento a la accesibilidad web: Perceptible, Operable, Comprensible y
Robusto.
Perceptible: la información y los componentes de la interfaz de usuario

deben ser presentados de modo que cualquier persona pueda percibirlos
(no puede ser invisible a todos los sentidos de la persona).
Operable: la persona puede operar y navegar sin dificultad los compo-

nentes de la interfaz de usuario.
Comprensible: los usuarios deben ser capaces de entender la informa-

ción, así como el funcionamiento de la interfaz de usuario.
Robusto: capacidad del sitio web de ser transmitido e interpretado por los
diferentes agentes de usuario, otros programas y dispositivos, como las
tecnologías asistivas. El contenido debe ser accesible aunque las tecnolo-
gías evolucionen, por eso es importante auditar continuamente la accesi-
bilidad de nuestros sitios y aplicaciones para hacer las mejoras y actuali-
zaciones correspondientes.

Además, cada principio se divide en diferentes Directrices y Criterios de

éxito. Los criterios de cumplimiento cuentan con recomendaciones técni-
cas y ejemplos de errores, y se clasifican de acuerdo a su nivel de comple-
jidad: A (el más básico), AA y AAA (el más estricto). Los niveles superiores
abarcan a los inferiores, es decir, para cumplir con un nivel de conformi-
dad de AA, debes haber cumplido con todos los criterios de éxito del nivel
A y del nivel AA.
La agencia Human Level consignó como directrices clave de accesibili-

dad: las alternativas de texto; el contenido alternativo al audio o video; la
adaptabilidad; que el sitio sea distinguible; la navegación por teclado; mo-
vimiento que no provoque reacciones físicas; la navegabilidad; la legibili-
dad; dar tiempo suficiente para ejecución de acciones; la autocorrección y
ayuda en formularios; compatibilidad con diversas tecnologías; la predic-
tibilidad y la entrada de datos mediante distintos tipos de dispositivos.

Lista de referencia rápida de las directrices WCAG
Alternativas de texto Contenido alternativo al Adaptable

audio o video
Ofrezca alternativas de texto para Se debe crear contenido que pueda ser
cualquier contenido que no sea texto de Ofrezca alternativas para cualquier presentado de formas distintas sin
forma que pueda ser interpretado del información presentada perder la información o su estructura.
modo que precisen otras personas. exclusivamente a través de audio o
vídeo.
Accesible mediante el teclado Distinguible Ataques

Implemente las distintas Haga más fácil para sus usuarios No diseñe contenido que pueda
funcionalidades para que se pueda que vean u oigan el contenido, ocasionar ataques, como el uso de
acceder a ellas desde un teclado. incluyendo el separar mejor la contrastes de color en asociación
forma del fondo. con efectos de flash y parpadeo
rápido de las imágenes.
Navegabilidad Legibilidad Suficiente tiempo

Ofrezca formas de ayudar a sus usuarios Asegúrese de que el contenido de texto Deje bastante tiempo para que sus
a navegar, encontrar el contenido y es legible y fácilmente comprensible usuarios puedan leer o usar
determinar dónde están dentro de su para sus usuarios. adecuadamente el contenido.
sitio web.
Compatibilidad Entrada de datos Predictibilidad

Optimice la compatibilidad con los Haga posible que sus usuarios puedan Haga que sus páginas web aparezcan y
navegadores actuales y futuros usar distintos tipos de dispositivos de funcionen de una forma predecible por
incluyendo tecnologías de ayuda al entrada además del teclado. sus usuarios.
usuario.
Autocorrección o ayuda en la
entrada de datos
Ayude a sus usuarios a evitar y
corregir los errores que puedan
cometer al interactuar con su
página web.
Lista de referencia rápida de las directrices presentes en las WCAG elaborada por
la agencia Human Level.

Puedes conocer más de las Pautas de Accesibilidad en las siguientes pá-

ginas del W3C:
¾ W3C WAI Addresses Mobile Accessibility
En tanto, la página How to Meet WCAG 2.1 (Quick Reference), que entrega
los contenidos de las pautas de forma organizada y clara, puede ser de
utilidad para elaborar el checklist de requisitos de accesibilidad de acuer-
do a las áreas que participen en la generación de tu producto digital.
En la columna izquierda de la página encontrarás filtros donde podrás

customizar la búsqueda según rol, temas o etiquetas, versión, entre otros
aspectos.

Capítulo 5
Directrices técnicas para un

producto digital accesible
Directrices técnicas para un producto
digital accesible
En este capítulo encontrarás una selección de recomendaciones clave,

basadas en las Pautas de Accesibilidad al Contenido Web en su versión
vigente 2.1 (o WCAG por su nombre en inglés), útiles para lograr un diseño
y desarrollo accesibles en sitios web y aplicaciones.
1. Construye aplicaciones accesibles
Respecto a las aplicaciones móviles y versiones mobile de un sitio web,

no existe un estándar en particular para ellas ya que las Pautas de Accesi-
bilidad son aplicables también a dichos productos digitales.
Algunos de los estándares que puedes considerar para la construcción de

tus aplicaciones se relacionan con:
z Estructura jerárquica mediante encabezados.
z Contraste de color.
z Presentación visual del texto.

Directrices técnicas para un producto digital accesible
z Visibilidad y orden del enfoque.
z Navegación mediante tecnologías asistivas, como lectores

de pantalla, teclados externos, herramientas de zoom, entre
otras.
z Gestos y cancelación de puntero.
z Movimiento.
z Orientación.
z Texto alternativo para contenido no textual.
z Etiquetado y nombre accesible para los componentes inte-

ractivos de la interfaz de usuario.
z Uso de WAI-ARIA cuando corresponda.

Si estás pensando en diseñar o desarrollar una aplicación, puedes pro-

fundizar en los requisitos de accesibilidad disponibles en las páginas que
ofrece el W3C:
¾ Mobile Accessibility at W3C
¾ Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Gui-

delines Apply to Mobile

2. Organiza el contenido
• <h3>Zapatillas run-
ning</h3>
<img src=”images/run-
ning.png” alt=””>
<p>Zapatillas... </p>
<a href=””> Agregar al
carro</a>
Zapatillas running
Zapatillas running de alto impacto
Este ejemplo muestra un adecuado orden

Agregar al carro
semántico y de lectura.
Estructura el contenido para que los usuarios recopilen información clave

de manera rápida y en un orden lógico, considerando:
z Un título de página que describa su propósito (h1)
z Ubicar el contenido importante en la parte superior de la pá-

gina.
z Aplicar encabezados que den estructura a la página (h1 a h6).
z Un orden de lectura reflejado en el código (DOM).

Las tecnologías asistivas, como los lectores de pantalla o de control por

voz, siguen el orden de los componentes de la interfaz de usuario (UI),
anunciando encabezados, puntos de referencia y enlaces. Es por eso
que la página debe presentar un orden lógico y lineal, para que todos los
usuarios naveguen correctamente por la interfaz.
º-
Entonces, el orden de lectura de la página debe ser lógico
e intuitivo, lo que dependerá de cómo están dispuestos los
elementos en el DOM (Document Object Model). Una forma
de verificar si tu contenido está estructurado de manera
coherente es desactivar el estilo CSS
Esta recomendación se relaciona con los siguientes criterios de éxito de las

Pautas de Accesibilidad para el Contenido Web.
¾ 1.3.2 Meaningful Sequence
¾ 2.4.3 Focus Order
¾ 2.4.6 Headings and Labels
¾ Technique C27: Making the DOM order match the visual order
¾ Technique H4: Creating a logical tab order through links, form

controls, and objects
Revisa también:
¾ The Importance of Heading Levels for Assistive Technology

3. Utiliza elementos semánticos
Para dar estructura al contenido web

es importante el uso de elementos <header>
semánticos, tales como:
<nav>
<header>
Define un encabezado para un <section>
<aside>
documento o sección <article>
-
<nav>
Define un conjunto de enlaces de
navegación
<footer>
<section>
Define una sección de documento
<article>
Define un contenido autónomo e independiente
<aside>
Define un contenido aparte del cuerpo principal (barra lateral)
<footer>
Define un pie de página para un documento o sección

A lo anterior, suma las prácticas que verás a continuación.
Jerarquiza el contenido
Utiliza los encabezados (o headings) solo para otorgar estructura y jerar-

quía al contenido:
<h1> Encabezado 1 </h1>

…<h6> Encabezado 6 </h6>
El uso de headings beneficia la navegación de personas usuarias

de tecnologías asistivas.
No uses títulos para lograr que el texto sea GRANDE o en negrita. Para eso
está el estilo:
<h1 style=”font-size:60px;”>
heading 1</h1>

Utiliza el elemento párrafo
<p>Un sitio web debe ser accesible y usa-

ble.</p>
<p>Profundiza leyendo esta guía sobre el

tema.</p>
Se sugiere que el ancho de un párrafo no sobrepase los 80 caracteres.
Un párrafo siempre comienza en una nueva línea y los navegadores

agregan automáticamente un espacio en blanco (o margen) antes y
después de él.

Utiliza el elemento lista
Las listas HTML permiten agrupar un conjunto de elementos relacionados:
Desordenadas
<ul>
<li> Contacto </li>
<li> Nosotros </li>
<li> Servicios </li>
</ul>
Una lista anidada desordenada puede ser útil para implementar un menú de
navegación.
Ordenadas (para contenido que debe ir en orden correlativo)
<ol>
<li> Primero </li>
<li> Segundo </li>
<li> Tercero </li>
</ol>
º- Recuerda, los lectores de pantalla escanean un sitio web

de arriba a abajo de forma lineal, visitando los elemen-
tos HTML uno por uno. Por eso, es importante estructurar el
contenido de manera eficiente para favorecer la navega-
ción mediante tecnologías asistivas.

Ejemplo de un código HTML estructurado en orden:
<header> Sección del encabezado

</header>
<nav> Sección del menú de navegación
</nav>
<main>
<h1>Encabezado principal</h1>
<p>Primer párrafo</p>
<h2>Primer subtítulo</h2>
<p>Primera subsección</p>
<h2>Segundo subtítulo</h2>
<p>Segunda subsección</p>
</main>
<footer>Esta es la sección de pie de página
</footer >

Esta recomendación se relaciona con los siguientes criterios de éxito de las

Pautas de Accesibilidad para el Contenido Web.
¾ 1.3.1 Info and Relationships
¾ 2.4.6 Headings and Labels
¾ 2.4.10 Section Headings
¾ Technique H69: Providing heading elements at the beginning

of each section of content
¾ Technique G141: Organizing a page using headings
Revisa también:
¾ Content Structure
¾ The Importance of Heading Levels for Assistive Technology
¾ Aplicación de estilo a listas

Tiempo atrás las tablas HTML eran utilizadas para crear diseños de
página, dificultando la lectura mediante lector de pantalla.
Utiliza el elemento tabla
Principales componentes que debe contener una tabla:
z La etiqueta HTML <table> define una tabla.
z
-
Una fila de la tabla se define con la etiqueta: <tr> (table row)
z
(table heading) -
El encabezado de una tabla se define con la etiqueta: <th>
z Título descriptivo para la tabla: <caption>

-
Una celda/dato se define con la etiqueta: <td> (table data)
z
-
El atributo scope se puede añadir al elemento <th> para in-
dicar exactamente a qué celdas corresponde el encabezado.
Las tablas no están destinadas a ser utilizadas con fines de diseño. Una
práctica recomendada es utilizar hojas de estilo en cascada (CSS) para la
presentación visual.

Esta recomendación se relaciona con los siguientes criterios de éxito y téc-

nicas de las Pautas de Accesibilidad para el Contenido Web.
¾ 1.1.1 Non-text Content
¾ 1.3.1 Info and Relationships
¾ 1.4.5 Images of Text
¾ 1.4.9 Images of Text (No Exception)
¾ Technique H51: Using table markup to present tabular infor-

mation
¾ Tables Tutorial

Revisa también:
¾ Conceptos básicos de las tablas HTML
¾ Creating Accessible Tables
¾ Accessibility Techniques for Tables
¾ Layout Tables vs. Data Tables
¾ Data Tables

4. Usa especificaciones WAI ARIA
WAI-ARIA (o Accessible Rich Internet Applications Suite) es una especifi-

cación desarrollada por expertos del W3C, recomendada para mejorar
la accesibilidad de los contenidos web cuando no es posible a través del
HTML, permitiendo asociar información semántica a diversos componen-
tes web que necesitan información ampliada para que las tecnologías de
asistencia puedan transmitir la información adecuada a las personas con
discapacidad.
TABLE OF CONTENTS
WAI-ARIA Authoring Practices 1.1
1. lnlroducllon
W3C Working Group Note 14 August 2019
2. Read Me FI rst
2.1 No ARIA is betier than Bad ARIA Thls v&rslon:
2.2 Browser and Assistive Technology h11pS:/iwww.w3.org/TRl20191NOTE-wai-aria-practices-1.1-201908141
Sup?<Jrt Latest publishedversion:
2.3 Mobile and Touch Sup?<Jrt bttpS://www .'li3.&.rgaBf\',ai-ana-lllil-Ctices-1.1 /
Latest editor's draft:
3. DeslgnPatternsand Widgets
httos:/Jw3c
aithub
io/aria-cractices/
3.1 Accordion (Sections With Show/Hide
Functionality) Previous version:
3.2 Alert bttos:11wwww3
°mCTRl2QJ91NOJE·wai·arja;0ract;ces-1
1-201so2ou
3.3 Alert a•d Message Oialogs Edltors:
3.4 Breadcruml> Matt King (FacebookJ
3.5 Bunon JaEyo Jemma Ky (University of lllinois)
3.6 Carousel (Slide Show or lmage Rotalor) JamesNurthen(Adobe)
3.7 Zoe Bijl (Invitad Expert)
Checkbox
Combo Box Michael Cooper (W3C)
3.8
3.9 Oialog (Modal) Formereditors:
Oisclosure (Show/Hide) Joseph Scheuhammer (Inclusive Design Research Centre, OCAD University) (Edttor until October 2014)
3.10
Lisa Pappas (SAS) (Editor until October 2009)
3.11 Feed
Rich Schwerdtfeger (IBM Corporation) (Editor unlil October 2014)
3.12 Grids : lnleractive Tabular Data and
Layout Containers
~ o 2015-2019Yr.l~ !MIL.la!l.C.IM, W3C~ ~ and oermissive
Km. lllillB!lg). c1oournem
lig,nserulesapply.
3.13 Link
3.14 Listbox
Revisa el contenido de la especificación en la página WAI-ARIA Authoring

Practices 1.1.

ARIA define un conjunto de atributos HTML adicionales, aplicables a conte-

nido dinámico y controles de la interfaz de usuario (UI) desarrollados con
Ajax, HTML o Javascript, para proporcionar semántica adicional y mejorar
la accesibilidad donde sea necesario. Opera también con SVG.
Así, esta especificación proporciona roles, estados y propiedades que de-

finen los elementos accesibles de la UI, permitiendo una adecuada intero-
perabilidad de los contenidos y aplicaciones web. De esta forma, un autor
puede transmitir de mejor forma los comportamientos de la UI y la infor-
mación estructural a las tecnologías de asistencia, en el marcado a nivel
de documento.
Su aplicación beneficia a dos grupos de usuarios en particular:
z Personas con discapacidad visual que utilizan lectores de

pantalla para acceder al contenido web.
z Personas que no pueden operar un mouse y usan instruccio-

nes de voz para controlar sus dispositivos.

Algunas características de WAI-ARIA
z Permite que las tecnologías asistivas reconozcan el conte-

nido dinámico y controles complejos. Por ejemplo: es posible
informar a un lector de pantalla que un widget debe interpre-
tarse como un control deslizante.
z Permite identificar regiones de páginas facilitando que los

usuarios de teclado se muevan fácilmente entre ellas, en lu-
gar de tener que presionar la tecla Tab muchas veces.
z No afecta nada sobre la página web, excepto la información

expuesta por las API de accesibilidad del navegador (los lec-
tores de pantalla obtienen allí su información).
z Tampoco afecta la estructura de la página web, el DOM, etc.

Aporte a los autores web
Los autores web, es decir, quienes diseñan, desarrollan o mantienen un

sitio web, tienen las siguientes herramientas para implementar especifi-
caciones ARIA:
z Roles para describir el tipo de widget presentado, como un

menú, control deslizante, barra de progreso, entre otros.
z Roles para describir la estructura de la página web, como en-

cabezados, regiones y tablas (grids).
z Propiedades para describir el estado en el que se encuentran

los widgets personalizados, como aria-checked, aria-disa-
bled, aria-selected, aria-expanded y aria-pressed.
z Propiedades para definir regiones activas (live regions) de una

página que puede recibir actualizaciones (timeline de Twitter,
cotización de acciones).
z Favorece la navegación por teclado para los objetos y even-

tos web mencionados.

Las técnicas ARIA se aplican a widgets como:
z Botones
z Listas desplegables
z Funciones de calendario
z Menús expandibles
z Modales, pop-over, alertas
z Radio group
z Drag & drop
z Tooltips flotantes
z Controles deslizantes
z Barras de progreso, entre otros.

0 Label Name
Button
@ Label [__Vi_ou_r_n_a_m_e
____________ ]
Button
~ Label Choose one selection
Button [ Select
0 Label
Algunos widgets en los que es posible aplicar WAI-ARIA para su funcionamiento.
º- No olvides que ARIA es un complemento que sirve para

mejorar la accesibilidad de las páginas y no un sustituto
por sí solo de los controles nativos HTML.

¾ ARIA in HTML
¾ WAI-ARIA Authoring Practices 1.1
¾ Using ARIA
¾ Web developer requirements for use of ARIA in HTML
Revisa también:
¾ Introduction to WAI-ARIA
¾ WAI-ARIA basics
¾ Introduction to ARIA Live Regions
¾ WAI-ARIA. Introducción, referencias, ejemplos, herramientas

5. Permite la interacción por teclado
Para resultar accesibles, todos los elementos de interacción, como enla-

ces, botones, controles de formulario, entre otros componentes de la inter-
faz de usuario, deben ser operables mediante el teclado. Y, si es operable
por teclado, también favorece a los sistemas de control por voz.

Entonces, considera que no todas las personas usuarias utilizan mouse

para navegar.
Entre las personas que navegan mediante teclado se encuentran:
z Los usuarios con discapacidad visual, que utilizan lectores de

pantalla o teclado braille.
z Las personas con movilidad reducida, que hacen uso de

emuladores de teclado o que tienen dificultad para activar
objetivos pequeños.
z Las personas usuarias avanzadas.
z Cualquier persona sin acceso a un funcionamiento del mou-

se o touchpad.

Para navegar con el teclado se usan principalmente las siguientes teclas:
z Tab o Shift + Tab para moverse por todos los elementos que
pueden ser activados.
z Flechas de dirección para moverse dentro un elemento, como

por ejemplo un menú desplegable.
z Intro o Espacio para seleccionar

o activar un elemento.
Aprende más sobre el

Esta recomendación se relaciona con los siguientes criterios de

éxito y técnicas de las Pautas de Accesibilidad para el Contenido
Web.
¾ Guideline 2.1 – Keyboard Accessible (WCAG)
¾ 2.1.1 Keyboard
¾ 2.1.3 Keyboard (No Exception)
¾ Guideline 2.5 – Input Modalities (WCAG)
Revisa también:
¾ Keyboard Accessibility

6. Orienta mediante el indicador del foco
Para personas con baja visión, movilidad reducida y discapacidad cogni-

tiva el indicador del foco es esencial porque resulta ser una guía. Más aún
para quienes navegan el contenido vía teclado.
W3("' '-..1
Web
-------
Accessibility
Initiative WAl
I Ema!eg/os,esrlindaresymcrterialesporohacerla
Webaccesiblepara gentecon d,scapaadades.
Get lnvolved
I About W3C WAI ~
Fundamentosde accestb1l1dad y Polit,cas

Planificac16n D1seriary Desarrollar Probary Evaluar y Promover
Enser"tar' Estándares/Pautas
~ / Es@ndarestPautaS
I Contenido Web - WCAG 2
Introducción a las Pautas de Accesibilidad para el

Contenido Web (WCAG)
En cada navegador los elementos enfocados reciben un estilo predeterminado de

resaltado que puedes personalizar.

~ GOV.UK Design System Q Search Design System
Get started Patterns Community
En cada navegador los elementos enfocados reciben un estilo predeterminado

de resaltado que puedes personalizar.
El foco corresponde a un marcador visual que indica qué elemento de una

página web está recibiendo el foco (o sobre qué elemento se encuentra
posicionado el usuario dentro de la página).
º- El orden en que se mueve el enfoque también es muy im-

portante. Se desplazará de acuerdo al orden en que apa-
rece cada elemento enfocable en el código. Por tanto, si el
orden del contenido en el código cuenta con un orden lógi-
co, se favorecerá la navegación y la experiencia de la per-
sona usuaria.

La comunidad de desarrolladores de Google menciona dos

recomendaciones importantes respecto al orden del enfoque:
z Aprende sobre el comportamiento del enfoque trabajando

con elementos nativos, debido a que se insertan automáti-
camente en el orden de tabulación según su posición en el
DOM. Por ejemplo: tienes tres botones en una página, ubica-
dos uno tras otro en el DOM. Al presionar la tecla Tab (tabula-
ción) enfocará cada botón en orden.
z Ten cuidado con el cambio de la posición visual de los ele-

mentos en la pantalla mediante CSS, debido a que puede
provocar que el orden de tabulación salte, generalmente al
azar, y confundir a quienes navegan mediante teclado.

Recuerda
z Los elementos interactivos reciben foco.
z Solo se puede enfocar un elemento a la vez en una página.
z Cuando cualquier componente de la interfaz de usuario reci-

be el foco, no se inicia un cambio de contexto. Un cambio de
contexto corresponde a cambios importantes que, si se reali-
zan sin el conocimiento del usuario, pueden desorientar a los
usuarios que no pueden ver la página. Recuerda, no se debe
iniciar ninguna acción no deseada o no ejecutada por la per-
sona usuaria, entonces, ofrece una advertencia avanzada al
abrir una nueva ventana, por ejemplo.

Algunos ejemplos de cambios de contexto:
Abrir una nueva ventana o pestaña del navegador al ha-

cer clic en algún botón.
Reorganizar significativamente el contenido de una pá-

gina cuando un elemento recibe el foco.
z Diseñar estados de enfoque altamente visibles para ayudar

en la navegación y comprender dónde se encuentran (per-
ceptibles y distinguibles).
z Puedes personalizar los colores del indicador de foco para

que se adapten al diseño del sitio, cuidando que el color del
elemento contraste con el fondo por el que se desplaza, con
el color de los botones enfocados, enlaces, etc.

z El desplazamiento y el enfoque parecen ser iguales, excepto

que el enfoque incluye un contorno.
z Tanto el estilo de focus como el hover sobre un elemento pue-

den incluir una ligera sombra de texto, así la persona usuaria
no depende únicamente del color para saber que está enfo-
cado.
Algunos de los elementos que deben recibir foco:
z Enlaces
z Botones
z Campos de formulario / controles (campos de texto, check-

box, radio buttons, etc.)
z Elementos de menú. Si el menú es extenso puedes enfocar

solo los enlaces de la navegación principal y así no obligar a
quienes utilizan teclado y lector de pantalla a recorrer todos
los contenidos del menú.
z Elementos activados por el desplazamiento.
z Widgets, como por ejemplo, un selector de calendario.

Esta recomendación se relaciona con los siguientes criterios de éxito y

técnicas de las Pautas de Accesibilidad para el Contenido Web.
¾ 1.3.2 Meaningful Sequence
¾ 1.4.11 Non-text Contrast
¾ 1.4.13 Content on Hover or Focus
¾ 2.4.3 Focus Order
¾ 2.4.7 Focus Visible
¾ 3.2.1 On Focus
¾ Technique C27: Making the DOM order match the visual order

Revisa también:
¾ Video: Visual Focus Indication (inglés)
¾ Accessibility Visual Focus
¾ Introduction to Focus
¾ CSS Outline
¾ Lectores de pantalla: accesibilidad web para todos

7. Implementa enlaces para omitir navegación
Los enlaces para omitir navegación son útiles para dar a los usuarios de
lectores de pantalla y teclado la misma capacidad de navegar directa-
mente al contenido principal. Este recurso suele ubicarse en la parte su-
perior de la página, el que al activarse llevará al usuario al principio del
área de contenido principal.
a. 1 SKIP TO COHJENT ] U-S- IITTE:Rt,,'J\TIOKAL CANAOA HPA.filOL ~lt SUBSCAIBE ron $0.25/WEEK At:ODunl ....,
Vieme-.1,l 3 de mayo de 20:22 Síguenos: ~ hli1w:
■ Suscribirse a ElTimes
QAnon llega a la frontera
El oostci humanode la de5información.
Susc:rfbetepnra recibir POrcorreo el boletíngratuito de The Ne-."
YOfkTimesen esparl01. IWfoHiHI 17°C 11:1•5•
Santiago, Chile
ENSA'YO INVITADO
Perdí a mi bebé.Yluego
los antivacunas hicieron
que mi dolor se volviera
viral
Mi historia de dolor
fue tergiversada y
usada por gente
que propaga
mentiras.
LaCumbre de las Américas de Hace 23 l'1 ' Por A,-,•ANDA
MAKl.lLEC
Una página muy compleja con elementos repetidos debe contar con un enlace para
saltar al contenido principal.

Asegúrate de:
z Que el enlace sea uno de los primeros elementos que perci-

ban los lectores de pantalla.
z Que el enlace sea notoriamente visible cuando recibe el foco.
z Establecer correctamente el enfoque en el área de contenido

principal cuando se activa.


¾ 2.4.1 Bypass Blocks
¾ 2.4.10 Section Headings
¾ Technique G1: Adding a link at the top of each page that goes
directly to the main content area
¾ Technique H69: Providing heading elements at the beginning

of each section of content
Revisa también:
¾ Skip Navigation Links

8. Incorpora breadcrumbs para orientar
El rastro de migas de pan, o en inglés, breadcrumbs-trail, es un elemento

de navegación que se sitúa en la parte superior del contenido de una
página, cuya utilidad es ayudar al usuario a ubicarse dentro de la
arquitectura de la información de un sitio web.
Este mecanismo se compone por enlaces con los que el usuario puede
retroceder en su navegación o desplazarse a categorías más o menos
genéricas dentro de la jerarquía de contenidos.
Inicio > Blog > Accesibilidad > Implementa un sitio web accesible
Aporta a la experiencia positiva del usuario y a asegurar que las personas

puedan encontrar fácilmente un camino óptimo de navegación, sin con-
fusión y sin perderse.

Para implementar este recurso, considera:
z No usar textos largos en las breadcrumbs, ya que debe pri-

mar la usabilidad.
z Las breadcrumbs permiten marcar los escalones de jerarquía

hacia la URL en la que el usuario se encuentra, estableciendo
niveles de navegación (enlace de primer nivel, de segundo
nivel, tercero, etc.)
z Las breadcrumbs que no incluyan toda la ruta o niveles de

navegación, también son válidas. Es posible saltar del enlace
de segundo nivel al de cuarto nivel en una página.
Inicio> Blog > Implementa un sitio web accesible

z Puede existir más de una ruta o breadbrumb para indicar la

ubicación de una página en la jerarquía de la web.
Blog > Accesibilidad > Implementa un sitio web accesible
z Implementación simple mediante HTML + CSS:
<div id=”breadcrumbs”>
<a href=”/index.html”> Página de inicio </a>
<a href=”/nivel1.html”>Nivel 1</a>
<a href=”/nivel1-3.html”>Subcategoría del
nivel 1</a>
</div>


¾ 2.4.5 Multiple Ways
¾ 2.4.8 Location
¾ G65 Technique: Providing a breadcrumb trail
¾ Breadcrumb Example
Revisa también:
¾ Video: ¿Qué es un BREADCRUMB TRAIL o rastro de migas de

pan?
¾ Breadcrumb trail o migas de pan: las ventajas de la ruta de

navegación

9. Aplica buenas prácticas en los formularios
Incorpora elementos semánticos de forma adecuada, tales como:
-
<form> Etiqueta que abre un formulario.
<textarea> Para introducir un texto libre.
<input> Puede usarse para distintas cosas. Se especifica con el

atributo type.
<fieldset> Para asociar data relacionada.
<label> Etiqueta que indica lo que debes colocar en <input>.
<legend> Texto que explica el <fieldset>.
<button> Botón clicable.
<select> Para listas desplegables.

Recuerda los siguientes requisitos que favorecen la

interacción
z Asocia los controles a etiquetas <label>.
z Un correcto etiquetado de los componentes ayuda a los lec-

tores de pantalla a narrar el contexto de los elementos pre-
sentes en la interfaz de usuario.
z No ocultes visualmente elementos <label>. Las etiquetas

nunca deben desaparecer por completo cuando el foco está
en una entrada.
z Usa el atributo placeholder solo si es necesario. Debes siem-

pre orientar y apoyar al usuario en su experiencia y no ocultar
o permitir que desaparezca información clave, por eso, ese
tipo de información, enfocada para que la persona complete
correctamente el formulario, no debe ir como placeholder.
z Entrega instrucciones claras sobre cómo llenar el formulario.
z No utilices tooltips para entregar indicaciones, instrucciones u

otra información relevante para que la persona usuaria inte-
ractúe con el formulario.

z Si el formulario es muy extenso divídelo en secciones e indica

en qué paso del formulario se encuentra la persona.
z Agrupa con <fieldset> los campos relacionados por tema

(Ejemplo: Datos Personales = Nombre, Apellido, RUT, etc.)
z Si un formulario tiene una combinación de campos obliga-

torios y opcionales, agrega el atributo aria-required=”-
z
-
true” a cada entrada que requiere ser completada.
Si los datos obligatorios son pocos, puedes a continuación

de la etiqueta textual del campo, añadir entre paréntesis la
palabra “Obligatorio” y no utilices asterisco para señalar ese
tipo de indicaciones.
z Indica los errores con un mensaje en formato de texto y seña-

la cómo solucionarlos.
z No uses únicamente el color para indicar errores u otra info-

mación relevante, acompaña con iconos y asegúrate de que
los elementos del formulario cumplan con los requisitos de
contraste de color.


¾ Guideline 3.3 Input Assistance (WCAG)
¾ Web Accessibility Tutorials: Labeling Controls
¾ Web Accessibility Tutorials: Validating Input
¾ Web Accessibility Tutorials: Labeling Controls
Revisa también:
¾ Formularios accesibles según las WCAG 2.0
¾ ::placeholder
¾ Placeholders in Form Fields Are Harmful
¾ Basic form hints
¾ Web forms: Working with user data

10. Retroalimenta las interacciones de la persona
usuaria
Es importante entregar información a la persona indicando de manera
clara el resultado de las acciones realizadas al interactuar con tu produc-
to digital.
z Comunica los resultados de las interacciones, permitiendo a

las personas comprender sus acciones y lo que pueden hacer
a continuación.
z Proporciona instrucciones claras, mensajes de error, valida-

ción, notificaciones y diálogos de confirmación a las acciones
con consecuencias significativas.
z Cuando ocurra un error:
Ayuda a las personas a encontrar dónde está el problema.
Proporciona explicaciones específicas y comprensibles.
Sugiere correcciones.
z Considera mensajes de estado como “El formulario se ha en-

viado correctamente” o “El contenido se está actualizando”,
para que el usuario sepa qué sucede en pantalla. Puedes uti-
lizar especificaciones WAI ARIA como aria-live y roles.


¾ Guideline 3.3 Input Assistance (WCAG)
¾ 4.1.3 Status Messages

11. Proporciona texto alternativo a elementos no

textuales
Describe las imágenes informativas y funcionales mediante el atributo
HTML alt (alternativa textual). Aplica también para botones, gráficos, info-
grafías y otros elementos visuales más complejos.
El utilizar este atributo permitirá, por ejemplo, a quienes utilizan lectores de

pantalla conocer el contenido o propósito del elemento visual mediante
texto (los lectores de pantalla interpretan el contenido textual). En cambio,
si no agregas el atributo alt o te saltas las comillas dentro de ese atributo,
las tecnologías asistivas leerán el nombre del archivo, o, comunicarán
a la persona que solo hay una imagen, lo que puede confundirla debido
a que sabe que hay un elemento allí en tu página pero no puede saber si
contiene información clave.

-- -
El atributo alt se asocia a las etiquetas HTML <img> y <area> y opcional-
mente, a <input> y <object>. En relación a la etiqueta <img>, sus
atributos obligatorios son:
--
src: Especifica la ruta a la imagen
alt: Especifica un texto alternativo para el elemento no textual.
Ejemplo:
<img src=”img_girl.
jpg” alt=”Girl with
a jacket”>

Es importante que consideres lo siguiente:
z La alternativa textual (alt) debe describir el contenido, infor-

mación o propósito que muestra el elemento visual.
z El atributo alt describe, no debe utilizarse para complementar

la imagen.
z La descripción textual debe ser breve y clara.
z Existen recomendaciones que indican que la descripción no

debiese pasar de los 100 caracteres, en tanto otras señalan
que el límite debe ser 80 caracteres. La idea es que el texto
sea conciso y refleje fielmente lo que grafica el elemento vi-
sual.
z No comiences la descripción textual con la frase “Imagen de”

o “Fotografía de”, es información redundante.
z No utilices el atributo title con un contenido igual al del atri-

buto alt. Este recurso es útil si quieres agregar información
complementaria. No es leído por tecnologías asistivas.

º-
Para imágenes decorativas utiliza texto alternativo vacío o
nulo (alt=””). También se pueden incluir en el CSS (propie-
dad background-image).
Además, el uso de alternativas textuales es útil para:
z Una imagen que no se carga o cuando la persona ha blo-

queado imágenes. El navegador presentará el texto alterna-
tivo visualmente en pantalla en lugar de la imagen.
z Los motores de búsqueda utilizan texto alternativo y lo tienen

en cuenta en su evaluación del propósito y el contenido de la
página. Se relaciona con el SEO.


¾ Web Accessibility Tutorials - Images Concepts
¾ Images Tutorial
¾ Functional Images
¾ HTML Attributes
Revisa también:
¾ Alternative Text
¾ Guía para incluir textos alternativos adecuados y accesibles
¾ Living Standard - 4.8.4 Images

12. Considera enlaces autodescriptivos

Los enlaces autodescriptivos aportan a la correcta implementación del
código semántico de tu producto digital, y, son una herramienta esencial
dentro del código al permitir redirigir a la persona dentro del sitio web o
a un sitio web externo. Por eso, debes mantener los estilos que los dife-
rencian del resto de los componentes y evitar que se comporten de forma
inesperada.
El texto del enlace
-
Lo que escribes dentro de las etiquetas HTML <a> (o Anchor) crea un enla-
ce a otras páginas de internet, archivos o ubicaciones dentro de la misma
página, direcciones de correo, o cualquier otra URL.

-
De esta forma, es importante que las etiquetas <a> expliquen claramente
a dónde se enviará a la persona usuaria. Considera lo siguiente:
z El texto del enlace debe tener sentido por sí solo. Evita utilizar
textos ambiguos como “Haga clic aquí” o “Leer más”, ya que
no estarás facilitando la lectura que realice un lector de pan-
talla a una persona con ceguera, no comprenderá el conteni-
do ni el propósito del enlace.
<p>
Si quieres saber más sobre la vacante
<a href=”vacante-abierta.html”
aria-label=”Requisitos para el cargo
de asesor en tecnología”>
Ver requisitos
</a>.
</p>

z Si el texto no es autodescriptivo o se necesita una descrip-

ción más detallada, usa el atributo WAI-ARIA aria-label para
agregar fácilmente un nombre propio al elemento. Por ejem-
plo:
z Asigna un orden lógico a los enlaces. Las personas que no

pueden usar un mouse para desplazarse por el sitio pueden
navegar a través de los enlaces usando la tecla de tabulación
(Tab).
z Asegúrate que los enlaces sean reconocibles. Puedes distin-

guirlos del cuerpo del texto utilizando algo más que el color,
por ejemplo, subrayado.


¾ 1.4.1 Use of Color
¾ 1.4.3 Contrast (Minimum)
¾ 2.4.4 Link Purpose (In Context)
¾ 2.4.7 Focus Visible
¾ 2.4.9 Link Purpose (Link Only)
¾ 3.2.4 Consistent Identification
Revisa también:
¾ Accessibility Techniques for Links
¾ Links
¾ Links and Hypertext

13. Describe los iconos cuando corresponda

Los íconos son geniales porque son universales, pero ¡no todos pueden
verlos! Entonces, otórgales una etiqueta textual para que cualquier perso-
na pueda comprender su propósito, particularmente a quienes acceden al
contenido digital mediante lectores de pantalla.
•••
Un icon button es un botón que activa una acción en la página y que contiene un
icono sin texto visible que lo acompañe.

En el caso de que el icono corresponda a una imagen funcional donde se

utiliza como botón (icon button), el texto alternativo del ícono debe des-
cribir la funcionalidad del botón en lugar de la imagen visual. Por ejemplo,
utilizar un icono de impresora para representar la función “Imprimir esta
página”.
De esta forma, los botones de ícono deben contar con un nombre accesi-
ble, de lo contrario, los lectores de pantalla no podrán entregar informa-
ción adicional que entregue contexto a la persona sobre el elemento y solo
percibirá la función “botón”, “imagen”, “menú”, etc.

Puedes darles un nombre accesible explícito mediante el atributo WAI-

ARIA aria-label, que anula cualquier contenido de texto dentro del botón, lo
que le permite describir claramente la acción a cualquiera que use tecno-
logía asistiva.
º- Si el ícono es interactivo, debe recibir el indicador de foco.

Además, su color debe contrastar con el color del fondo
sobre el que se ubica.


¾ Images Tutorial
¾ Functional Images
¾ 1.4.5 Images of Text
¾ 2.5.3 Label in Name
¾ 4.1.2 Name, Role, Value

14. Agrega un nombre accesible a los elementos

de la UI
El nombre accesible es el nombre que se otorga a un elemento de la inter-
faz de usuario (UI), en tanto cada API de accesibilidad de plataforma (sis-
tema operativo u otras) proporciona la propiedad del nombre accesible.
El valor del nombre accesible puede derivarse de una propiedad visible,
como por ejemplo el texto visible en un botón, o invisible, como lo sería el
texto alternativo que describe un icono a nivel de código (atributo “alt”).
Dicho de otra manera, la mayoría de los controles van acompañados de

una etiqueta de texto visible, los que además cuentan con un nombre
programático o nombre accesible. Entonces, si las palabras y los carac-
teres de la etiqueta visible de un control coinciden o están incluidos en el
nombre accesible, las personas podrán tener una experiencia mucho más
satisfactoria, por ejemplo:

z Quienes interactúan con el sitio web mediante entrada de voz

pueden navegar pronunciando las etiquetas de texto visibles
de los componentes que aparecen en la pantalla, como me-
nús, enlaces y botones.
z Las personas con discapacidad visual que usan texto a voz

(como lectores de pantalla), también tendrán una mejor ex-
periencia si el texto que escuchan coincide con el texto vi-
sualizado en la pantalla al mover el foco a ese elemento.
Así, la información del nombre accesible es utilizada por las tecnologías

asistivas para identificar un elemento de la UI y la definición e implemen-
tación del nombre accesible son responsabilidad del desarrollador quien
debe trabajar junto con el UX Writer para asignar las etiquetas de los com-
ponentes y nombre.


¾ Accessible Name and Description Computation 1.1
¾ 2.5.3 Label in Name
¾ Understanding Success Criterion 2.5.3: Label in Name
Revisa también:
¾ What is an accessible name?

15. Árbol de accesibilidad del navegador

El árbol de accesibilidad es con lo que la mayoría de las tecnologías asis-
tivas interactúan. Por eso, asegúrate de expresar la semántica de tu pági-
na correctamente.
Esta estructura se relaciona con el nombre accesible de un elemento

HTML el que es expuesto en el árbol de accesibilidad del navegador. En-
tonces, es necesario que los elementos importantes de la página tengan
los estados, propiedades y roles correctos, especificando nombres y des-
cripciones accesibles.
~ UI visual
o o
Usuario
Tecnología
asistiva
JS Árbol accesible
Fuente: <shortdiv />

Creación del Árbol de Objetos de Accesibilidad:
El navegador toma el árbol del DOM (Document Object Model) y lo modifi-

ca para generar un documento útil para acceder e interactuar con el con-
tenido mediante tecnologías asistivas. A este árbol modificado se le cono-
ce como árbol de accesibilidad. El árbol de accesibilidad y el árbol DOM
son estructuras paralelas.
De esta forma, el navegador puede permitirle a las tecnologías asistivas

acceder a esa información para crear una experiencia personalizada.
Para ver el árbol puedes utilizar la consola de desarrollo.
• a]•
[i Elements Recorcler l.
DevTools - developer.chrome.com/docs/devtools/
CSS Overview l. Console Sources Network » J:il12 o

RootWebArea "Chrome DevTools - Chrome @"'tyles Computed Layout Accessibility »
"'Developers' focusable: true focused: true
,.. banne r "' " Accessibility Trae Jt
► link 'Skip to content' focusable: true r.il .l. Enable full-page accessibility trae
► search "Chrome Developers•
The accessibility trae moved to the top right comer of the DOM trae.
,.. main •• focusab le: true ~ yourfeedback.
► navigation "breadcrumbs"
,.. heading 'Chrome DevTools' " ARIA Attributes
StaticText 'Chrome DevTools" aria-label:breadcrumbs
► paragraph "'
" Computad Properties
► list ••
• Name: "breadcrumbs"
• contentinfo '" aria-label ledby: Not specified
StaticText 'Follow us' aria-label: "breadcrumbs"
► link 'YouTube"focusable:true title: Not specified
► link 'Twitter"focusable:true Role: navigation
StaticText ·contribute" " Source Order Viewer
► list ••
O Show source order
StaticText "Related content'
► list ••
StaticText 'Connect"
► list ••
Fuente: Chrome Developers

¾ The Browser Accessibility Tree
¾ The Accessibility Tree
¾ Full accessibility tree in Chrome DevTools

16. Genera contenido textual legible y comprensible

Para trabajar el contenido textual de tu sitio web, considera las siguientes
recomendaciones:
Presentación visual
z Considera 16px (1em) como el tamaño mínimo de fuente. Uti-

lizar una medida menor puede perjudicar la legibilidad del
texto y la experiencia a personas con baja visión o que utilizan
gafas.
z Elige fuentes que estén disponibles y sean conocidas y fami-

liares para la mayoría de las personas.
z Aplica un tamaño de fuente receptivo en unidades relativas

CSS em o rem, relacionadas al tamaño de letra del elemento
principal o al tamaño de la ventana gráfica. Estas se diferen-
cian principalmente en:

z La unidad em tiene como referencia de medida el font-size

del elemento actual.
z La unidad rem tiene como referencia de medida el font-size

del elemento root, la etiqueta <html>
-
A+ A-

z Sin embargo, ambas permiten a quien lo requiera, cambiar el

tamaño de fuente en el navegador y ajustarla a sus necesida-
des, así como también obtener un diseño escalable y flexible.
z Evita las cursivas para no dificultar la lectura del texto, espe-

cialmente para las personas con dislexia.
z Evita usar palabras en mayúsculas debido a que existen lec-

tores de pantalla que interpretarán, por ejemplo, una palabra
corta en mayúsculas como si fuera un acrónimo, deletreando
de la siguiente forma: “MIS FAVORITOS “ como “eme i ese favo-
ritos”. Esto solo dificultará la lectura.
z Usa el estilo negrita con moderación.
z No uses subrayado en el texto a menos que sea un enlace, así

evitarás la confusión en algunos usuarios.

z Alinea los textos hacia la izquierda para favorecer la legibili-

dad y comprensión del contenido.
z Otorga estas medidas para altura para línea y espaciados:
Altura de línea: al menos 1,5 veces el tamaño de la fuente.
Espacio entre párrafos: al menos 2 veces el tamaño de

la fuente.
Espacio entre letras (tracking): al menos 0,12 veces el ta-

maño de la fuente.
Espaciado entre palabras: al menos 0,16 veces el tama-

ño de fuente.

Selecciona una fuente simple y legible
El uso de fuentes accesibles facilitan la comprensión y legibilidad del con-

tenido, pensando además en que los usuarios obtengan la información de
forma rápida y clara. Esto beneficia particularmente a personas con baja
visión, dislexia, dificultades de aprendizaje y a quienes presentan migraña.
Algunas recomendaciones:
z Prefiere utilizar para tus textos fuentes sans serif, son más sim-
ples y no tienen trazos decorativos. En tanto, las fuentes Serif
tienen rasgos ornamentados al final de cada letra que pue-
den afectar la legibilidad.
z Evita las fuentes manuscritas y de estilo script.
z Elige una fuente que sea sencilla y familiar para tus usuarios.
z Limita la cantidad de fuentes y variaciones de fuentes en tu

producto.
z Evita usar fuentes con formas de letras muy idénticas para di-
ferentes caracteres, porque pueden confundir al usuario. Esto
puede suceder, por ejemplo, con los caracteres “e”, “c” y “o”.

z Cuida utilizar una fuente cuyos caracteres no se reflejen entre

sí, se genera un efecto de duplicación.
z Elige una fuente que tenga un espacio adecuado entre las le-
tras por defecto. Las fuentes estrechas y condensadas pue-
den ser problemáticas. Por ejemplo, “r” y “n” uno al lado del
otro pueden verse como una “m” si el espacio no es suficiente.
º-
Para asegurarte que las fuentes que utilizas en tu sitio o
aplicación son adecuadas para tus usuarios, pruébalas con
una variedad de usuarios. No olvides incluir a personas con
discapacidad y adultos mayores.

Escribe de forma clara y sencilla
Hacer que el contenido web sea accesible no siempre significa centrarse

exclusivamente en el trabajo técnico. Para personas con discapacidades
cognitiva, visual, auditiva o movilidad reducida, por ejemplo, que el len-
guaje sea fácil de leer y comprender es de gran relevancia, al igual como
lo puede ser para una persona adulta mayor.
Preocúpate de redactar contenido claro y conciso y utilizar un lenguaje y

un formato sencillos. Para ello, considera lo siguiente:
z Escribir oraciones y párrafos cortos y claros. Ayuda a los lec-

tores a mantenerse enfocados.
z Evitar el uso de palabras y frases innecesariamente comple-

jas: palabras inusuales y abreviaturas.
z Considerar el uso de imágenes, ilustraciones, video, audio y

símbolos para ayudar a aclarar el significado.

Palabras inusuales:
Considera que el contenido que contiene lenguaje técnico o figurativo,

terminología de jerga o modismos, acrónimos no expandidos o que pare-
ce tener mucho texto, puede dificultar la lectura y comprensión de la infor-
mación.
La recomendación principal es utilizar dicho tipo de recursos solo si es

necesario. En caso que debas incluir palabras inusuales, muy técnicas o
usadas exclusivamente por un grupo de personas en particular, conside-
ra explicar el significado a los usuarios mediante alguna de las siguientes
opciones:
z Mostrar el significado en el texto. Por ejemplo: “Me gusta co-

mer esturión. Un esturión es un pez”.
z Mostrar el significado entre paréntesis. Por ejemplo: “Me gusta

el esturión (un tipo de pez)”.

z Vincular la palabra a una definición en una página de glosa-

rio en el sitio web;
z Vincular la palabra a una nota al pie de definición en la mis-

ma página.
Abreviaturas:
El uso de abreviaturas (como Dr por Doctor) puede causar confusión y di-

ficultar la comprensión de tu sitio web o aplicación. Personas usuarias con
discapacidad cognitiva o con baja visión, memoria limitada o que utilizan
la lupa de pantalla pueden tener dificultades con las palabras y frases
abreviadas.
Evita entonces su uso donde puedas y explícalas cuando necesites usar-

las. Estas también incluyen acrónimos, como por ejemplo OTAN e iniciales
como FBI.

Algunos lineamientos para cumplir con éxito este requisito de las WCAG:
z Evita el uso de abreviaturas, siglas e iniciales.
z Si necesitas usar una abreviatura, existen las siguientes alter-

nativas para explicar el significado a los usuarios:
Mostrar el significado en el texto. Por ejemplo: Federal

Bureau of Investigation (FBI).
Enlazar a una definición en una página de glosario en el

sitio web, o, a una nota al pie de definición en la misma
página;


Ejemplo: -
Usar la etiqueta HTML “abbr” (la más recomendable).
Comenzaremos el proyecto <abrr title=“Labo-

ratorio de Accesibilidad Digital”>LAD</abrr>
con el objetivo de aumentar nuestra expe-

riencia.
De esta forma, tecnologías assitivas como lectores de pan-

talla leerán la versión completa de la abreviatura, es decir,
“Laboratorio de Accesibilidad Digital” y no “LAD”.


¾ 1.4.8 Visual Presentation
¾ 1.4.12 Text spacing
¾ 3.1.3 Unusual Words
¾ 3.1.4 Abbreviations
¾ Keep content clear and concise
¾ Stories of Web Users
Revisa también:
¾ Writing Clearly and Simply
¾ Typefaces and Fonts
¾ Valores y unidades CSS

17. Diseña con colores que contrasten

Asegúrate de lograr un adecuado contraste entre el color del fondo y el
contenido del primer plano, el que debe ser lo suficientemente alto como
para garantizar la legibilidad. Este lineamiento beneficia no solo a las per-
sonas con baja visión, con discapacidad auditiva o cognitiva, sino que
también favorece a quienes usan pantallas atenuadas, ya que un mayor
contraste ayuda a distinguir con mayor facilidad el contenido en pantalla.
Existe software gratuito y páginas web donde puedes elaborar tu paleta de

colores y comprobar si alcanzan el nivel mínimo de contraste.

Contenidos como el texto, los componentes de la UI (como enlaces, íco-

nos, botones) y cualquier otra información en la página deben cumplir
con los requisitos mínimos de relación de contraste. Excepto los elementos
inactivos, logotipos y elementos decorativos.
Al diseñar interfaces legibles para diferentes capacidades de visión, las di-

rectrices de las WCAG recomiendan las siguientes relaciones de contraste.
Relación de contraste texto y fondo del texto
z Al menos 4.5:1: para texto menor a 24px sin negritas, y, menor

de 19px en negritas.
z Al menos 3:1: para texto igual o mayor a 24px sin negritas, e,

igual o mayor a 19px en negritas.
Cuida también el uso de texto sobre imágenes porque puede perderse y

dificultar su visibilización.

Relación de contraste para elementos interactivos

de la UI
z Al menos 3: 1: para la presentación visual necesaria para iden-

tificar los componentes y estados de la UI.
z También cuenta para objetos gráficos, como los iconos.
z Excepto componentes inactivos.


¾ Directriz 1.4 - Distinguishable (WCAG)
¾ 1.4.3 Contrast (Minimum)

[ Name ] [ Name ]
-----)
[ !!! l ¡--!!! --¡
[ Name 9 ] [ Name 9 ] El uso de íconos para reforzar
[ !!! ºl -.,-l
> ¡-~-.
mensajes es una práctica muy
útil para comprender mejor la
información.
18. Distingue la información no solo con color

Esto beneficia a diversas personas, como por ejemplo, a aquellas que
presentan dificultad para distinguir colores, quienes pueden no compren-
der el contenido.
Entonces, puedes destacar, por ejemplo, un enlace, permitiendo el cambio

de su color cuando recibe el foco, y a su vez, lo subrayas. O, puedes ubicar
un icono de advertencia junto a un campo de formulario donde falta infor-
mación.
º- Utiliza texto, color, formas, subrayado, iconos y texturas

para comunicar información, indicar una acción o provocar
una respuesta.


¾ 1.4.1 Use of Color
Revisa también:
¾ Guía de accesibilidad web y color (II). Recomendaciones de

las WCAG 2.1 para color y contraste
¾ From A Colourblind Designer To The World: Please Stop Using

Red And Green Together

19. Tamaño del área activa

Considera un área activa mínima para los controles interactivos (click o
touch), como botones, enlaces, inputs, menús, etc.
Debes tener en cuenta a quienes presentan movilidad reducida, a los que

tienen temblores en sus extremidades, los que tienen dedos grandes, los
que no pueden apuntarle al objetivo porque van caminando, etc.

Dimensiones recomendadas:
z Para web, el área clicable debe ser de 44x44px CSS o supe-

rior, para facilitar el acceso al target.
z Para objetivos táctiles en aplicaciones, la medida mínima re-

comendada es de 48x48dp o 9mm.
:-:
-· ·-
:-
Click Me·➔,
..- - ~
.Click Me ➔-.,
,l'm an option - ---·----·- --
(< l'm an option •.
.. --- -- -------
o o
Clickable area


¾ 2.5.5 Target Size
¾ Understanding Success Criterion 2.5.5: Target Size
Revisa también:
¾ Enhancing The Clickable Area Size
¾ Objetivos táctiles accesibles
¾ Target Size and 2.5.5

20. Diseño escalable

La UI de tu producto debe ajustarse correctamente si las personas eligen
opciones de fuente más grandes, utilizan zoom u otra tecnología asistiva.
La UI que no escala correctamente puede provocar que los contenidos se

vuelvan inaccesibles.
--1
1

Utiliza un diseño responsive
Para adaptar la pantalla a diferentes estados de zoom y tamaños de ven-

tana gráfica, como en dispositivos móviles y tabletas.
Permite que la persona usuaria pueda ampliar el tamaño del contenido

textual sin tecnologías asistivas (excepto imágenes de texto o los subtítu-
los de un video), a un 200% y 400% sin que haya pérdida de información o
funcionalidad y sin que se genere scroll bidimensional.
Esta acción puede lograrse mediante el zoom del navegador o comandos

de teclado como Ctrl y + (en Windows) y Cmnd y + (en Mac).

Reflow
Este requisito de accesibilidad señala que el contenido puede presentarse

sin pérdida de información o funcionalidad y sin scroll bidimensional, ex-
cepto para partes del contenido que requieran desplazamiento bidimen-
sional para su uso o significado, como mapas, diagramas, videos, presen-
taciones, tablas de datos, entre otros.
Considera lo siguiente:
z Contenido con desplazamiento vertical con un ancho equi-

valente a 320 px CSS.
z Contenido con desplazamiento horizontal con una altura

equivalente a 256 px CSS.


¾ 1.4.4 Resize text
¾ 1.4.10 Reflow
¾ Understanding Success Criterion 1.4.10: Reflow
Revisa también:
¾ Reflow
¾ Mobile accessibility considerations primarily related to Prin-

ciple 1: Perceivable

21. Movimiento con responsabilidad

Diseña considerando a quienes no pueden experimentar el movimiento
o necesitan evitarlo. Entre las reacciones físicas que el movimiento ejecu-
tado de forma muy rápida puede causar: mareos, náuseas, falta de equili-
brio y dolores de cabeza.
Asimismo, las personas sensibles a estímulos visuales intensos, como

rebotes o destellos, pueden presentar reacciones como convulsiones, epi-
lepsia y fotosensibilidad.

º- Los movimientos presentes en la interfaz de usuario pueden

corresponder a animaciones, micro o macro interacciones,
contenido audiovisual, entre otros.
Por eso:
z Evita los contenidos que parpadeen más de tres veces en un

período de un segundo.

♦ netlify
Thanks a Mlllion!
1he roedto 1 mi Iondevs
Fhe_.ego. Nellfylu1c:hedend changedh- ......... buld lorhweb,and
wveoowonbollded!IQ9dlln 1 maon-1.ookupyourNelify llCCCIWIIIOINm
_,)Qljoinod.and-outh_lO ____ ofhbig
falbnsand mllalarmllonglhe-. -.-,our runberand mllellanelO

wlthlhe~
• Nellfy.-?M-b;WIO
Nall/111 join .. onlhejalmly.
Flndout your placeIn our tlmellne
C·#MiiiifüN
Revisa el mecanismo de desactivación utilizado por el sitio web de Netlify.
z Ofrece controles o configuraciones para reducir o desactivar

el diseño de movimientos no esenciales, mediante la imple-
mentación de recursos como un toggle switch on/off o un bo-
tón de pausa. Por ejemplo:
z Permite la consulta de medios “prefers reduced motion”: @

media prefers-reduced-motion.
La opción permite verificar si la persona ha establecido

preferencias para reducir movimiento mediante la con-
figuración del sistema operativo y agentes de usuario
(respetada por todos los navegadores modernos).

Olíicial home of
Revisa el mecanismo para reducir movimiento utilizado en

la página de Animal Crossing.
Obtendrás entonces dos opciones en tu código, una para

quienes prefieren un movimiento reducido y otra para
aquellos que no.
z Evita el uso de parallax, puede causar mareos o distracción

en las personas y así afectar la experiencia con tu producto.
Cada sistema operativo ofrece la opción de reducir movi-

miento mediante las herramientas de accesibilidad.


¾ 2.3.1 Three Flashes or Below Threshold
¾ 2.3.2 Three Flashes
¾ 2.3.3 Animation from Interactions
¾ 1.4.3 Contraste mínimo
¾ 1.4.11 Contraste sin texto
Revisa también:
¾ Animation, Motion, and Timed Content

22. Diseña carruseles solo si es necesario

Otro recurso de movimiento muy utilizado en los sitios web es el carrusel
o slider. También, resulta ser un mecanismo muy cotizado principalmente
por el área de Marketing para destacar información relevante, de tipo co-
mercial, financiero, ofertas, entre otros contenidos.
Sin embargo, no es un elemento considerado como accesible o usable,

debido a que puede afectar la operatividad de tecnologías asistivas, como
lectores de pantalla y a quienes utilizan teclado porque el foco suele en-
tramparse al intentar avanzar en las diapositivas del slider. Otra barrera
que enfrentan las personas usuarias de lectores de pantalla, es que no
se etiquetan correctamente los controles interactivos, como botones de
pausa, avanzar, retroceder, etc., por tanto, el software no puede “leer” el
elemento no etiquetado.

º- Considera que las personas que navegan mediante tecla-

do se ven obligadas a recorrer el carrusel en su totalidad,
lo que aumenta su carga cognitiva. Por eso, debes pensar
muy bien si incluyes este mecanismo en tu producto, si
será un aporte, y, argumentar claramente al cliente el ries-
go de incorporarlo.
Slide 2
Slide 2
o • o
• • •

Slide 2
Slide 2
o • o
• • •
Si no tienes otra opción de mostrar el contenido, considera las siguientes
recomendaciones:
z Si es más de una slide, agrega al carrusel controles para pau-

sar o detener el movimiento, porque nada debe moverse o
activarse si la persona no lo quiere.
z Proporciona un texto de enlace descriptivo al control que

permita saber su funcionalidad, como por ejemplo: “Pausar
carrusel”.
z Agrega puntos de navegación debajo del carrusel. El nú-

mero de puntos representa el número de slides disponibles,
mientras que el estado activo en el punto indica qué slide se
encuentra enfocada. A medida que se activa el punto, debe
cambiar de color. Este debe contar con un nivel adecuado de
contraste respecto al fondo.

z Las flechas “Anterior” y “Siguiente” deben activarse solo

cuando hay slides por delante (Siguiente) y cuando las slides
se acabaron (Anterior).
z El color de los controles debe contrastar con el fondo sobre el

cual se ubican.
z El indicador del foco debe ser visible alrededor de la slide y

controles. El color del indicador también debe contrastar.
z Considera que si la persona presiona “Enter” en su teclado,

mientras el slide tiene el foco, será llevado al enlace del mis-
mo. Si presiona la tecla de tabulación (Tab), el foco se move-
rá al siguiente slide.
z Una vez que se han tabulado todos los slide, el foco debe mo-
verse al siguiente elemento de la página web.
z Programa correctamente el código para que el teclado no

quede atrapado en el carrusel. La persona usuaria debe po-
der pasarlo, si así lo desea.

z Cuando una persona con discapacidad visual navega por la

página y se posiciona en el carrusel, deberá pasar al slide 1 del
elemento. El enlace del slide 1 debería envolver todo el texto
del panel en que se encuentra. Así, el lector de pantalla leerá
todo el texto, por ejemplo:
“Título del slide 1” y la descripción de la diapositiva que debes

agregar para que el lector de pantalla sepa de qué se trata
este contenido.
z Evita que la persona usuaria de lector de pantalla escuche

solo la etiqueta del enlace vinculado a la slide, debido a que
no entrega suficiente contexto y la persona debe saber qué
contenido viene al activar el enlace.
z Utiliza código nativo y complementa con las especificaciones

WAI-ARIA para programar el carrusel.


¾ 2.3.1 Three Flashes or Below Threshold
¾ 2.3.2 Three Flashes
¾ 2.3.3 Animation from Interactions
¾ WAI-ARIA Slide
¾ 1.4.3 Contraste mínimo
¾ 1.4.11 Contraste sin texto
Revisa también:
¾ If you must use a carousel, make it accessible

1
c::::=i
c::::=i
--
23. Permite la orientación vertical y la horizontal

Este requisito apunta a no restringir la visualización y funcionamiento del
contenido a una única orientación de pantalla, como vertical u horizontal,
a menos que sea esencial que la pantalla se oriente de una forma especí-
fica.
Este lineamiento técnico beneficia a:
z Personas con discapacidad física o movilidad reducida que

pueden utilizar sus dispositivos montados en una orienta-
ción fija, como por ejemplo, llevarlos en el brazo de una silla
de ruedas eléctrica.
z Personas con baja visión, quienes podrán ver el contenido en

la orientación que más les convenga. Por ejemplo, para au-
mentar el tamaño del texto viendo el contenido en formato
horizontal.
z Personas que deben rotar el dispositivo por tener las manos

ocupadas.

Entonces, asegura que el contenido se muestre en la orientación preferida

por la persona, considerando lo siguiente:
z Los sitios web y aplicaciones no deben configurar y restringir

automáticamente la pantalla a una orientación de visualiza-
ción particular y esperar que las personas respondan girando
su dispositivo para que coincida. Esto puede generar proble-
mas de usabilidad.
z La persona puede bloquear la pantalla de un dispositivo mó-

vil en una orientación específica, a través de un interruptor o
una configuración del sistema (o ambos).
z Si la persona decide bloquear todo su dispositivo a una orien-

tación, todas las aplicaciones deberían adoptar esa confi-
guración y mostrar el contenido en la orientación elegida.


¾ 1.3.4 Orientation
¾ Understanding Success Criterion 1.3.4: Orientation
Revisa también:
¾ Managing screen orientation

24. Indica el idioma de la página

Para definir el idioma principal de cada página usa el atributo <lang> en la
etiqueta HTML: <html lang=”es”>.
Este atributo es heredado por todos los demás elementos y establece un

idioma predeterminado para el texto en el elemento head del documento.
<!DOCTYPE html>
<html lang=”en”>
<head>...

-
También, utiliza el atributo <lang> en elementos específicos cuando el
idioma difiere del resto de la página. De esta forma, el lector de pantalla
entenderá que debe cambiar a otro idioma. Por ejemplo:
<html lang=”es”>
<body>
<h1>Bienvenido</h1>
<p lang=”fr”>Ce paragraphe est en espag-
nol.</p>
</body>
</html>
º- Recuerda, los lectores de pantalla pueden “hablar” varios

idiomas, siempre que se identifique el idioma del contenido.


¾ 3.1.1 Language of Page
¾ 3.1.2 Language of Parts
Revisa también:
¾ Declarar idioma en HTML
¾ Document and Content Language

25. Permite personalizar los límites de tiempo
Elimina los límites de tiempo, o al menos, da la opción a la persona usuaria

de extenderlos. Por eso, considera a quienes pueden necesitar más tiem-
po para navegar y realizar ciertas acciones, como por ejemplo:
z Las personas con discapacidad física y movilidad reduci-

da pueden necesitar más tiempo para reaccionar, escribir y
completar actividades.
Advertencia:
Para proteger sus datos, las sesiones de
los usuarios caducan después de 15
minutos de inactividad.
Puede perder su progreso en este

formulario si hace una pausa en el trabajo
por más tiempo que este período.
( Regresar ] Continuar
Una buena práctica es avisar mediante un mensaje cuánto dura la sesión de usuario.

z Las personas con baja visión necesitan más tiempo para ubi-
car contenidos en la pantalla y para leer.
z Las personas ciegas que usan lectores de pantalla, pueden

necesitar más tiempo para comprender los diseños de pan-
talla, encontrar información y operar los controles.
z Las personas que presentan discapacidad cognitiva o tras-

tornos del lenguaje necesitan más tiempo para leer y com-
prender.
z Adultos mayores.


¾ 2.2.1 Timing Adjustable
¾ 2.2.3 No Timing
¾ 2.2.4 Interruptions
¾ 2.2.5 Re-authenticating
¾ 2.2.6 Timeouts

26. Evita el uso de overlays de accesibilidad

Si un sitio es accesible, no necesitará implementar un overlay de accesibi-
lidad. Este elemento se superpone delante de una página web y al activar-
lo, generalmente cubre parte de su contenido.
Los widgets de superposición pueden afectar a las tecnologías asistivas,

o bien, sus controles pueden no ser accesibles mediante estas.
MIAMI HEAT STORE 1 "/' ltf/ Locations I Aa:ount Ll O
YOUTM HE:ADWE:AR NOVE:LTIES PLAYERS BRANCS SALE
__--
NMgatJon Adji,,stmen1
.f}
--_,
¿ ... +1-2->
J.
-- ©
CQIQrAdju,a;l"""nt
c:Ji)
T,pt~,~tr
"""'""""""'
11
Cuslom Color
<) ~N11atto'•eckln
c:l·:-1-1• .....-.,,. C011.~•rwi•
• (.!)RflMt colon
-- .......,T
......
'
·Ó.-
•,•
1
J •• . 1
Conoce el overlay implementado en el home de la tienda online del equipo de

básquetbol Miami Heat.

¾ Video: Accessibility Overlays: What You See You Already Have
¾ Overlay Fact Sheet
¾ Overlay Fact Sheet: Conclusion

27. Robustez del sitio web

El cumplimiento del principio sobre la Robustez del sitio web presente en
las WCAG, tiene como objetivo asegurar que el sitio sea interpretado por
agentes de usuario, tecnologías asistivas y otro tipo de dispositivos, en su
versión actual y futuras.

,.,.,,
r---------
Para cumplir este principio de accesibilidad, considera:
z Es un rol directamente relacionado con el desarrollador.
z Es importante respetar el código para que el sitio sea compa-

tible con el mayor número de dispositivos y software.
z El código del sitio web debe ser tan limpio como sea posible.
z Se deben respetar estándares y especificaciones (HTML, XHT-

ML, XML, etc.)
z 3 criterios de éxito para cumplir con este Principio.

A continuación, encontrarás cuáles son los 3 criterios de éxito que plantea

este Principio:
Procesamiento y código limpio
Corresponde al criterio de éxito 4.1.1 del principio “Robustez”. Indica que en

los contenidos implementados mediante el uso de lenguajes de marcas,
debes asegurar, entre otros aspectos:
z Elementos con etiquetas de apertura y cierre completas.
z Elementos anidados de acuerdo a sus especificaciones.
z Elementos sin atributos duplicados.
z Identificadores únicos (id).

■

Nombre, función y valor
Corresponde al criterio de éxito 4.1.2 del principio “Robustez” e indica que

debes considerar para componentes de la UI, como elementos de formu-
lario, enlaces y componentes generados por scripts, lo siguiente:
z Nombre y función de los componentes pueden ser determi-

nados mediante programación.
z Los estados, las propiedades y los valores que puede estable-

cer el usuario, se pueden establecer mediante programación.
z La notificación de cambios en los elementos está disponible

para ser consultada por los agentes de usuario, incluidas las
tecnologías asistivas.

Mensajes de estado
Corresponde al criterio de éxito 4.1.3 del principio “Robustez” e indica que:
z En el contenido implementado con lenguajes de marcado, los

mensajes de estado pueden ser determinados por software
mediante su rol o propiedades y así ser presentados al usua-
rios de tecnologías asistivas sin recibir el foco.
z Los mensajes de estado: informan al usuario sobre el resulta-

do de una acción relacionada con:
- El estado de espera de una aplicación.

- El progreso de un proceso.
- La existencia de errores.

X
¡Gracias!
(0
Tu mensaje ha sido enviado correctamente
-;;;;;;
Algunos ejemplos:
z La persona usuaria pulsa el botón “Agregar al carrito de

compra” y a continuación se muestra el mensaje “Carrito: 1
producto”.
z La persona ingresa un email en formato equivocado en un

campo de formulario y a continuación aparece el mensaje de
error “El formato de email es incorrecto”.
z La persona presiona el botón “Enviar” y envía un formulario,

entonces, el lector de pantalla anuncia “Formulario enviado”.


¾ 4.1.1 Parsing
¾ 4.1.2 Name, Role, Value
¾ 4.1.3 Status Messages
Revisa también:
¾ WCAG 2.1 Principles Explained: Robustness
¾ Robust

Capítulo 6
Accesibilidad web, mucho más que

estándares técnicos
Accesibilidad web, mucho más que
estándares técnicos
Comprender la accesibilidad digital como un derecho humano y no como

una simple característica que un producto debe cumplir, permitirá tratar-
la como una prioridad principal y no como algo para empujar a la fuerza
dentro de la cartera de pedidos de un equipo. Por ello, no se debe pasar
por alto incluir la implementación de este atributo dentro de los tiempos
y recursos considerados para un proyecto.
Entonces, para que una organización y cada uno de sus equipos adopten
la accesibilidad como atributo imprescindible, es necesario elaborar una
estrategia o plan de accesibilidad. Esta herramienta permitirá incluir la
accesibilidad web en los diversos proyectos y sus etapas, así como tam-
bién a actores importantes, como stakeholders, product owners, líderes,
entre otros. En este esfuerzo debe incluirse a las áreas de Marketing y Co-
municaciones, que también están llamadas a generar contenidos accesi-
bles y comprensibles por la gran mayoría de personas usuarias.
El contar con especialistas en la materia y equipos constantemente ca-

pacitados permitirá, además de desarrollar productos digitales más usa-
bles y accesibles, aplicar empatía en cada una de las etapas de elabora-
ción de un sitio web o aplicación. Así, se estarán ofreciendo las mejores
experiencias posibles, independiente de las capacidades y la situación de
quienes acceden al contenido digital.

Accesibilidad web, mucho más que estándares técnicos
Pero, no basta con conocer de memoria los estándares técnicos de la

accesibilidad web si no se comprende, por ejemplo, el por qué es tan re-
levante su implementación y la participación de personas usuarias con
discapacidad y adultos mayores en las etapas de research y testeos de
accesibilidad.
Se requiere aprendizaje continuo y el deseo de hacer la diferencia al dise-

ñar y desarrollar productos digitales que incluso pueden mejorar la cali-
dad de vida de las personas usuarias.
Finalmente, se debe tener en claro que cuando los sitios web, las aplica-
ciones o las tecnologías están mal diseñadas o desarrolladas, pueden
crear barreras que excluyen a las personas del uso de la Web. Por eso,
este material es la herramienta perfecta para adentrarse en el camino de
la accesibilidad digital, aprender sobre buenas prácticas y aplicar este co-
nocimiento en cualquier proyecto que se inicie.
º-
“Ser inclusivo comienza cambiando nuestra percepción.
Ahora es el momento de poner en práctica esta mentali-
dad. Es hora de crear nuevas formas de hacer. ¡Empece-
mos!”
Microsoft Inclusive Design.

Anexo:
Recursos para revisar la accesibilidad web
Anexo: Recursos para revisar la accesibilidad web
A continuación, encontrarás algunas de las herramientas más utilizadas

para trabajar y auditar la accesibilidad del contenido y del sitio web.
Auditores de contraste
¾ Colour Contrast Analyser (aplicación para Windows y Mac)
¾ Stark (plug-in para Figma, Adobe XD, Sketch y Chrome)
¾ WebAIM Contrast Checker (página web)
Simuladores de discapacidad
¾ Stark (plug-in para Figma, Adobe XD, Sketch, Chrome)
¾ Funkify (extensión para Chrome)
¾ Web Disability Simulator (aplicación para Chrome)

Auditores automáticos de accesibilidad

¾ Web Developer (extensión para Chrome, Firefox y Opera)
¾ Chrome Developer Tools (viene integrado en Chrome)
¾ aXe - Deque Systems (extensión para Chrome y Firefox)
¾ ARC Toolkit (extensión para Chrome)
¾ Lighthouse (se ejecuta desde la consola de desarrollo)
¾ Siteimprove (extensión para Chrome, Firefox, Opera y Microsoft)
¾ WAVE (sitio web y extensión para Chrome y Firefox)
¾ Validator W3C (valida documentos HTML, XHTML, SMIL, Ma-

thML, SVG)
¾ Test de Accesibilidad (aplicación que opera en SO Android)

Evaluación de la navegación
¾ Keyboard Accessibility
¾ Screen reader NVDA y teclado (lector de pantalla que opera

en SO Windows)
¾ Screen reader JAWS o Job Access With Speech (lector de

pantalla, opera en SO Windows)
¾ Screen reader TalkBack (lector de pantalla que opera con SO

Android)
¾ Screen reader VoiceOver (lector de pantalla Mac OS X - iOS)

Extensiones para comprobar la correcta imple-

mentación de ARIA
¾ Web Developer Toolbar (Chrome, Firefox y Opera)
¾ Chrome Developer Tools (viene integrado en Chrome)
¾ ARC Toolkit (extensión para Chrome)
¾ Visual ARIA (extensión para Chrome)
¾ aXe (Chrome)
¾ Validator W3C (valida documentos HTML, XHTML, SVG, entre

otros)

Agradecimientos
Agradecimientos
Detrás de este inspirador trabajo existe un gran equipo sin el cual no ha-
bría sido posible llegar a destino.
Muchas gracias por su talento, por haber creído en este proyecto y cola-
borar en la creación del primer eBook sobre Accesibilidad Web de 2Brains.
Carolina Aguilera Carolina Sepúlveda

Consultora en accesibilidad Head of UX
web
Sebastián Bascuñán Vega Jacinto Obispo Márquez

UI Lead Chief of Technology Consulting
Camila Acevedo Setz Emilisbeth Carrasco Almao
UI Designer UX Writer & Research
Carlos Peñailillo Zúñiga Jocelyne Muñoz

UI Designer UI Designer
Cristián Peña Toledo Jefferson Varela Freitez

UX Writer Frontend Modyo specialist

Guía para construir
Productos digitales accesibles
Este contenido está bajo la licencia Creative Commons Recono-

cimiento-No comercial-Sin obras derivadas 4.0 Internacional.

Guia de Accesibilidad 2brains

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia de Accesibilidad 2brains

Cargado por

Copyright:

Formatos disponibles

Guía para construir

Accesibilidad web, el paso que

Prólogo escrito por la comunidad de DALAT 5

En mayo de 2021 desde 2Brains realizamos el primer evento para

| Guía para construir productos digitales accesibles 3

Lo que nos ha motivado para crear esta guía es la posibilidad que

Les damos la bienvenida a la Guía para construir productos digitales

| Guía para construir productos digitales accesibles 4

Es así como se construye y perpetúa la realidad. El mundo digital es parte

Cuando 2Brains nos invitó junto a otros expertos de la región a un panel

| Guía para construir productos digitales accesibles 5

Este libro nos invita a pensar. A pensar en la forma en que construimos

Susana Pallero y Silvia Márquez

| Guía para construir productos digitales accesibles 6

Accesibilidad web: La gran aliada

'' En Barclays, la accesibilidad es algo más que una simple

| Guía para construir productos digitales accesibles 8

Pero, ¿qué es la accesibilidad web? Es la capacidad de que un sitio web,

En palabras de la empresa Microsoft: la accesibilidad está representada

Asimismo, de acuerdo al Inclusive 101 Toolkit de Microsoft, debemos pensar

z Permanente: experimentado por aquellos que tienen una dis-

z Temporal: experimentado por aquellos que tienen una lesión

z Situacional: experimentado por aquellos cuyas habilida-

| Guía para construir productos digitales accesibles 9

Un brazo Lesión en el brazo Nuevo padre o madre

Ciego o ciega Cataratas Conductor distraído

Sordo o sorda Infección auditiva Bartender

No-verbal Laringitis Diferente idioma

Estados de discapacidad descritos por Microsoft en el material

| Guía para construir productos digitales accesibles 10

Quizás te preguntes por qué deberías incluir la accesibilidad web dentro

A continuación, te contamos sobre algunos de los principales argumentos

1. Una cuestión de derechos

La Organización de Naciones Unidas (ONU) reconoció en

El no cumplir con este requisito es un acto de vulneración

| Guía para construir productos digitales accesibles 11

2. La falta de accesibilidad web no es un buen

Un contenido digital no accesible excluye a millones de per-

| Guía para construir productos digitales accesibles 12

3. Mejorar la accesibilidad de tu sitio proporcionará

z Impulsar la innovación dentro de la empresa u organización,

z Aumentar el alcance del negocio a un segmento más amplio

z Obtener los beneficios de la optimización de motores de bús-

| Guía para construir productos digitales accesibles 13

z En el artículo “Five Ways to Improve Your SEO with Web Acces-

z Entregar una experiencia satisfactoria a todas las personas

z Finalmente, valor añadido. Si un producto digital satisface las

| Guía para construir productos digitales accesibles 14

4. La clave está en la persona usuaria

Escuchar a tus usuarios y usuarias y conocer sus necesidades es

Un ejemplo de cómo la accesibilidad enfocada en la inclusión puede re-

| Guía para construir productos digitales accesibles 15

Y, ¿cómo respondió Internet? Con una enorme cantidad de cobertura en

Por eso, es muy importante conocer casos de éxito sobre la implementa-

Pantalla de inicio del video juego “The last of us” Parte 2.

| Guía para construir productos digitales accesibles 16

En resumen, la accesibilidad web permite:

z La navegación mediante teclado y tecnologías asistivas sin

z Mejorar el SEO (lo que de seguro le interesará mucho al área

z Ampliar el alcance del negocio a un mayor número de perso-

z Mejorar la marca y favorecer la competitividad.

z Mantener a la persona usuaria en tu sitio web.

z Garantizar el acceso a tu producto digital, evitando así posi-

Contraste y uso del color.

Descripción textual de elementos no textuales (imáge-

Organización lógica del contenido para una correcta na-

Presentación visual del texto (tamaño y tipo de fuente,

Tamaño suficiente de los componentes interactivos de la

Movimiento que no produce reacciones físicas en la per-

Navegación por teclado y lectores de pantalla.

Adecuada implementación de encabezados (o headings).

Código semántico limpio y correctamente implementado.