Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software

TUTORIAL:
Cómo incluir requisitos de accesibilidad web
en el proceso de desarrollo software

Lourdes Moreno, Paloma Martínez
Universidad Carlos III de Madrid
Grupo LABDA
{moreno, pmf}@inf.uc3m.es

9 de Septiembre de 2010

Índice

 Motivación
 Introducción
 Estándares, legislación y normativa
 Tecnología de desarrollo
 Trabajos relativos. Desde el punto de vista de la Ingeniería
 Inclusión de requisitos de accesibilidad. Propuesta
Organización
 Qué requisitos de accesibilidad: Interacción
Estándar WCAG

 Cómo incluirlos de manera integral en el método y proceso
 Aplicación en casos reales
 Conclusiones
 Líneas abiertas de investigación

Motivación
¿qué es accesibilidad?
 Una aplicación web es accesible cuando cualquier
usuario puede acceder a sus contenidos
independiente de sus características de acceso, y
contexto de uso

Motivación
¿de qué estamos hablando?
 Si la fuente es pequeña, y un usuario la quiere hacer mayor
¿qué pasa?

Motivación
 Si el usuario no tiene activado el JavaScript, o accede con
algún dispositivo que funciona sin javaScript, ¿qué pasa?

5

Motivación
 Si accedemos con una conexión lenta y no se descargan las
imágenes, o con un navegador solo texto, o con un lector de
pantalla, ¿qué pasa?

6

Motivación
 Si accedemos con otros dispositivos, ¿qué pasa?

7
7

Motivación
Observatorio
 Observatorio

Acessibility evaluation of
European governmental web sites

[Olsen M.G., 2008]
[Discapnet, 2009]

Motivación
Situación
 Se debería asegurar el acceso a la Web a cualquier
persona, independiente de sus características y de
cómo acceda desarrollando aplicaciones web
accesibles
 Observatorio: hay dificultades, los sitios web en su
mayoría no son accesibles, y si lo son, dejar de serlo
al tiempo
 La accesibilidad es incorporada al final del desarrollo
software (aplicación terminada) en evaluación

¿Qué esta pasando?

Motivación. Tratamiento de la accesibilidad
web en el proceso de desarrollo

 La accesibilidad en la organización.
 Inclusión tardía del requisito
 Poca formación

Introducción
Tipo de accesos. Brecha digital
Diseño Universal. Acceso compatible. Tecnología de apoyo
Directo (ejemplo)
 Indirecto, pero COMPATIBLE: Ayudas técnicas, Ingeniería
de rehabilitación:
• Ceguera: dispositivos Braille, lector de pantalla
• Visión reducida: magnificador
• Discapacidad motriz: teclado adaptado, sin ratón

Personas con discapacidad (número considerable)
 Usuarios Todos, diversidad funcional
Crece (tecnología, discapacidad por envejecimiento)

Introducción
Personas con discapacidad. Cifras
 Alrededor del 10% de los habitantes del planeta sufre algún
tipo de discapacidad.
 Europa: Casi 50 millones de personas.
 España: hay 3.528.221 personas con discapacidad, un 9% de la
población
 77 millones de europeos tienen 60 años o más.

Evolución de las discapacidades
en función de la edad

Introducción
Beneficios del desarrollo accesible

 Mejora la indexación y localización del sitio por buscadores
(SEO)
• Google es un usuario ciego
 Participación en la Web semántica
 Reducción del mantenimiento (consistencia)
 Escalabilidad, crecimiento: nuevas líneas de negocio
 Movilidad: móviles, PDA, TV
 El numero de clientes que te dejas es considerable

Estándares, legislación y normativa
Estándares
 Estándares de la Web. W3C
 Componentes interdependientes de WAI
 ATAG
 UAAG
 WCAG
 Web Content Accessibility Guidelines (WCAG)
WCAG 2.0
Técnicas, tecnología no del W3C
Excepciones
 The Accessible Rich Internet Applications (WAI-ARIA)

[W3C, 2010]

Estándares. WCAG
 No orientadas a incorporar desde el inicio en el proceso. Sí a
la evaluación sobre un desarrollo ya realizado
 Ejemplos:
 Texto alternativo en imágenes
 Título de la página
 Encabezados. Estructura lógica
 ....

 No sé indica qué pautas y cómo incluir en Diseño,
implementación, evaluación.

Legislación
 Convención de Derechos de las Personas con Discapacidad
 Marco Internacional
 Legislación: Sección 508 del Acta de Rehabilitación, ADA, ...
 Marco Nacional
 Legislación: LSSICE, LIONDAU, …
 Según Real Decreto 1494/2007 se establecían unos plazos (ya
vencidos) para que algunos sitios web deben ser accesibles según la
Norma UNE 139803:2004
• Desde del 2009: sitios web de las AAPP y otros organismos deberían cumplir con los
requisitos de Prioridad 2 de la UNE 139803
• Correspondencia entre Requisitos de la UNE 139803 y WCAG 1.0

Obligación Legal
 Referencia a WCAG
Hay certificaciones (AENOR)
[BOE, 2007][AENOR, 2004]

Normativa Internacional

 ISO 9241-20:2008: Accesibilidad en productos y servicios TIC
 ISO 9241-151:2008: Ergonomía de interfaces web
 ISO 9241-171:2008: Accesibilidad del software
 ISO/IEC TR 29138: Consideraciones de accesibilidad para personas con
discapacidad.
 Parte 1: Necesidades de usuario
 Parte 2: Inventario de estándares
 Parte 3: Guía para asignar necesidades de usuarios

Normativa nacional

 UNE 153010:2003 Subtitulado para sordos
 UNE 153020:2005 Audiodescripción
 UNE 139801:2003 Accesibilidad del Hardware
 UNE 139802:2003 Accesibilidad del Software =>UNE
139802:2009 Accesibilidad del Software
 UNE 139803:2004 Accesibilidad de los Contenidos Web
 UNE 139804:2007 LSE en Redes Informática

Tecnología de desarrollo
¿accesible?
 Tecnologías de la Web 1.0
WCAG 1.0 WCAG 2.0
 Tecnología cliente: (X)HTML, CSS, … WCAG 2.0 WAI-ARIA
Tecnologías Tecnologías
 Tecnología servidor: PHP, .NET, 1.0 2.0
 Tecnologías de la Web 2.0 (RIA)
 Ajax (Dojo , Bindows,..)
 Flash (SilverLight, Flex, ..)
 Tecnología de evaluación: Herramientas automáticas, métricas
Desarmonización. Falta de Compatibilidad
 Conclusiones Escasez de tecnología favorable en el desarrollo, y menos
al mantenimiento
“sólo se permite”, dependencia con el desarrollador

Trabajos relativos
Desde el punto de vista de la Ingeniería
 Basados en las WCAG: orientados a la evaluación
 Mayoría orientados a la evaluación de la accesibilidad [W3C, 2008 m],
[Abascal J. et al., 2004] , métricas de medición [Vigo M et al., 2007], …
 Propuestas de sencillos marcos de trabajo [Nykänen O., 2006],
sencillas recomendaciones [Bohman P.R. & Anderson S., 2005]
 La tecnología con poco soporte al autor [Xiong J. & Winckler M., 2008]
 Disciplinas a considerar

Ingeniería Métodos de Interacción
del Software Ingeniería Persona
(Web) Web Ordenador

Trabajos relativos
 INGENIERÍA DEL SOFTWARE
 Se observa que no hay un tratamiento de la accesibilidad en el
proceso, hay actividades en el desarrollo donde no ha sido abordado
cómo incluir la accesibilidad [Freire A. et al., 2007].
 Posibilidades de integración de la accesibilidad web:
• seleccionar un modelo de proceso software estándar, donde
incorporar las técnicas que incluyeran accesibilidad
• Enfoque flexible de integración en algún proceso de ciclo de vida
genérico siguiendo dependiendo de cada caso, procesos más
pesados o más ágiles
Métodos y procesos a seguir como alternativa para integrar
la accesibilidad web

Trabajos relativos
 MÉTODOS DE INGENIERÍA WEB:
 Parte de la usabilidad [Kappel G. et al., 2006], independiente [Rossi G. et al.,
2007]
 Uso de patrones para incluir algunos requisitos de accesibilidad en interfaces
de usuario [Jeschke S. et al., 2009]
 Recuperación y navegación de la información [Ceri S. et al., 2007]
 Web semántica: Acceso según características de accesos [Harper S. et al.,
2007] [Masuwa-Morgan K, 2008], formalización de las WCAG como [Moreno L.
et al., 2005]
 Modelos estándar de “access for all” [IMS, 2004] [DC, 2005]
 Anotación conceptos de la ontología Web Authoring for Accessibility (WAFA)
[Yesilada Y. et al., 2006] [Harper S. et al., 2007]. Aproximación Dante: a través
de ontología WAFA se integran requisitos desde el diseño en el método WSDM
[Plessers P. et al., 2005]
 Aspect-oriented design [Martin, A. et al, 2010]
Sistematización desde el diseño de los requisitos de accesibilidad

Trabajos relativos
 INTERACCIÓN PERSONA-ORDENADOR
 ISO 13407: “Human-Centred Design Processes for Interactive Systems”
-> ISO/DIS 9241-210
 Interfaces de usuario para todos [Stephanidis C, 2000] [Vanderheiden
G. C., 2009] hay que tener en cuenta consideraciones relativas a las
distintas actividades en un proceso
 Sistemas de adaptación automática [Savidis A. & Stephanidis C, 2004]
 Grandes avances en tecnología de apoyo
 Marcos de integración accesibilidad [Granollers T., 2004]
 Accesibilidad vs usabilidad [Henry S., 2007] [Petrie H., 2007]
[Pühretmair F., 2005] [Moreno, L. et al, 2009 b]
Marcos de trabajo con participación del usuario en contextos
específicos (accesibilidad)

Carencias encontradas y enfoque de la
solución
Cómo aplicar las WCAG en el proceso de desarrollo. No calidad
Desconocimiento en la Organización, no hay formación
Escasez de tecnología e incompatibilidad
No se encuentran propuestas de solución que incluyan requisitos
de accesibilidad web desde el inicio, y que lo trasladen a todo el
proceso de desarrollo
Considerar trabajos y enfoques metodológicos de la Ingeniería para
integrar de manera sistemática el requisito de accesibilidad
 La solución debe ir encaminada a dotar a los profesionales de
un soporte formal e integral que ayude y guíe en el proceso de
desarrollo para conseguir el objetivo de la accesibilidad

Incluir requisitos de accesibilidad
Principios
 A partir de las carencias detectadas:
 Según marcos normativos => WCAG 1.0 , WCAG 2.0
 No se indica en las WCAG cómo incluir requisitos en el proceso de
desarrollo = > Conceptualizar las WCAG en el proceso
 Calidad para todo el “ciclo de vida de la aplicación” incorporado
requisitos en el proceso=> Sistematización de los mecanismos de
integración (utilizar Método)
 Seguimiento de un método sistemático
puede distanciarse del usuario Seguir enfoque DCU, e
inclusivo => proceso
 Excepciones en el estándar
iterativo
 Requisitos de accesibilidad en la Organización => Plan de
accesibilidad, formación

Propuesta. AWA
Soporte metodológico AWA (Accessibility for Web Applications)
[Moreno, L., 2010]

AWA_Organización
34 82

AWA_Interacción AWA_Requisitos AWA_Mecanismos
proponen activan
AWA_WCAG

Propuesta. AWA
 Proceso genérico
 Modelo de ciclo de vida
• Espiral (iterativo)
 Actividades

 Soporte el proceso (Diagrama de actividades (UML))
 Estrategia: Incluir requisitos en diseño y conducir con un diseño guiado
por plantillas, a través de la implementación
 Sub-Actividades: Aplicación de mecanismos de accesibilidad de los
distintos componentes de AWA

Propuesta. AWA
 Qué desarrollos pueden adoptar AWA
 ¿para qué aplicaciones web destino? desarrollo con Tecnologías
1.0, con componentes de Tecnologías 2.0
• Arquitectura de capas (separación)
Código en el cliente accesible
 ¿en qué procesos? en cualquiera que se puedan acoplar las
actividades del proceso genérico
 ¿en qué Métodos? en cualquiera que permita integración con
calidad de la accesibilidad web desde el diseño, hasta el final del
proceso

Qué requisitos de accesibilidad

Interacción Estándar
En la
con el WCAG 1.0 y
Organización
usuario WCAG 2.0

Organización

 Plan de Accesibilidad

 Calidad. Gestión de la accesibilidad

Organización. Mecanismos
 Plan de Accesibilidad
 Grupo de accesibilidad
• Crear grupo de accesibilidad
• (Requisito Funcional) Incluir procesos de gestión del conocimiento
 Declaración de Política de accesibilidad
• Elaborar informe inicial en relación al marco legislativo
• Determinar Declaración de Política de Conformidad
 Selección de un método de desarrollo
• Aplicar soporte AWA
 Selección de tecnología
 Plan de Formación
• Establecer un plan de formación

Organización. Mecanismos
 Calidad. Gestión de la accesibilidad
 Identificación y articulación de procesos de gestión de la
accesibilidad
 Procesos externos
• Elaboración de Pliego de requisitos para proveedores
 Sugerencias del usuario
• (Requisito Funcional) Incluir procesos de gestión sugerencias y
quejas de los usuarios. Sistema de contacto específico

Interacción
 Excepciones del estándar. Qué opina el usuario
 Usabilidad y accesibilidad
 Marco de solución: ISO 13407 (ISO 9241-210 ), marco de trabajo
para seguir un enfoque DCU en el contexto particular de la
accesibilidad web, siguiendo estos principios:
 Involucrar a todos los usuarios, incluyendo al usuario con discapacidad
en todo el proceso (Principio 1 DCU con inclusión)
 Considerar la diversidad de contextos de uso en la Web (Principio 2
DCU con inclusión)
 Acomodan las actividades del DCU en las actividades del proceso
genérico a través de la integración técnicas de usabilidad

[Bevan N., 2009 a] [Bevan N., 2009 b]

Interacción
 Acomodan las actividades del DCU en las actividades del proceso
genérico a través de la integración técnicas de usabilidad, para así
dirigir a conseguir satisfacer requisitos de accesibilidad

Interacción. Mecanismos
Actividades proceso genérico
Técnicas de usabilidad con inclusión Mecanismos
COMUNICACIÓN CON EL
CLIENTE Perfiles de usuario
• Formulación
Escenarios Seguir enfoque de DI en la
PLANIFICACIÓN Persona captura requisitos
INGENIERÍA
• Análisis
Captura de Requisitos
Card sorting
Especificación de Requisitos
Validación de Requisitos Seguir enfoque de DI en el
Prototipo
• Diseño análisis y diseño
• Modelado Tormenta
de Ideas

CONSTRUCCION
• Implementación
• Pruebas Seguir enfoque de DI en la
Evaluación Heurística evaluación
DESPLIEGUE Cuestionarios
• Evaluación

 Seguir enfoque de DI en la captura requisitos: PERFILES DE
USUARIO
Personas sin discapacidad en contextos de uso Personas con discapacidad
desfavorables
Atr ibutos DOMINIO DE VALORES
Personas mayores, enfermedad, discapacidad temporal
Edad Visual, auditiva, física motriz, cognitiva
Infantil (0-12), Adolescente (12-18), Joven (18-35), Adulto (36-65),
Ambiente de oscuridad; ojos tapados, interfaz pequeño; Visual
Anciano (65-).
ambiente con humo, niebla, poca visibilidad; etc.
Profesión Estudiante, académico, empleado, empresario, Ninguna, Otras, etc.
Ambiente ruidoso; oídos ocupados, oídos enfermos (con Ocasional, Ninguna, etc.
Frecuencia de uso Habitual, Circunstancial, Auditiva.
tapón); ambiente de silencio, etc. Configuración Básica, adaptada, especifica, etc.….
Hardware
Situaciones especiales de poca movilidad,Compartido, Privado, Compartido, Oficina, Público, Otras, etc.
Ambiente Hogar, escayola, Física motriz
vendaje; otros impedimentos motores por fractura,….. Linux, Perfil especifico adaptado…..
Software Perfil Windows, Perfil
Extranjeros (desconocimiento del idioma); situación de Psíquica, cognitiva
Formación tecnológica Alta, Medio, Baja
estrés, pánico, aturdimiento; distracción, falta de
Conocimiento de la tarea Alta, Medio, Baja
atención, concentración, cansancio; efectos del alcohol
Discapacidad Visual, auditiva, cognitiva, motriz, etc..
Componentes, dispositivos informáticos lentos, antiguos Visual, auditiva, Otros, motriz, cognitiva”
Razón de uso Formativo, Laboral, Curiosidad, Necesidad, física etc.
Componentes, dispositivos informáticos muy modernos Formación, Investigación, Base cognitiva
Rol necesidad de Contenido CESyA, Normativa, Visual, auditiva, física motriz, de Datos,
Actualidad comunicación audiovisual

[Mayhew D.J., 1999] , [Moreno L. et al, 2006]

 Seguir enfoque de DI en la captura requisitos: ESCENARIOS
CON ENFOQUE PERSONA
 Contextualizar la interacción persona-sistema describiendo situaciones
de uso de la Web. En el diseño se tiene en mente para quién diseña y
qué espera encontrar el usuario.
 Con solo un Escenario se llega a varios Perfiles de usuario, y se diseña
según sus características:
• Personaje primario. Perfil de Usuario al que pertenezca la Persona
• Personajes Secundarios que no siendo por algunas necesidades
específicas están satisfechos con la aplicación del Personaje Primario
• Personajes de Cliente que reflejan las necesidades de quien realiza el
encargo, y no las de los usuarios finales

[Cooper A., 2003], [Lombardi V., 2004] [Mcmullin J., 2003]


IDENTIFICACIÓN DEL ESCENARIO

Código de escenar io: 03
Nombr e per sonaje: MANUEL
Descr ipción del escenar io: Manuel es un trabajador de la cadena de televisión y empresa de radiodifusión “TVAqui” Su encargado se ha enterado de que existe una web del CESyA y le ha
ordenado que se documente sobre la utilización de la base de datos y le prepare un informe de funcionamiento para formar a otras personas de la empresa para aplicar el sistema en el trabajo
desarrollado en su oficina. Al desconocimiento de la web se le añade que están haciendo una reforma en la oficina ya que están cambiando el falso suelo con el ruido que conlleva este tipo de
obras además de ser alérgico al polvo que provoca la radial y dificultaba la concentrarse en su trabajo.
CARACTERÍSTICAS (en base a atr ibutos del modelado de usuar io)
GRUPOS DE USUARIO POTENCIALES Y NO POTENCIALES CUBIERTOS EN
Edad: Adulto, 41 años EL ESCENARIO
Pr ofesión / tar eas: Trabajador / Entidad Radiodifusora, Operadora
Fr ecuencia de uso: Frecuente (semanal) Usuar io con discapacidad: Usuarios con ligera sordera, Usuarios con hipoacusia, Usuarios
Har dwar e: Ninguna característica especial, común con discapacidad cognitiva de falta de atención, Usuarios con discapacidad cognitiva de
Ambiente: Oficina, compartido dificultad de comprensión, Usuarios con discapacidad cognitiva de hiperactividad.
Softwar e: Windows, Mozilla Usuar io No Discapacitado en Contexto Desfavor able (Usuarios con limitaciones puntuales
Exper iencia: Baja, nuevo dominio producidas por entornos desfavorables): oídos ocupados, Dificultad auditiva menor como la de
Conocimiento de la tar ea: Medio, buena definición de requisitos entornos ruidosos con impedimento parcial, Existencia de elementos de audio de lenguaje no
Limitaciones: Ligera sordera y falta de atención por distracción conocido (idioma extranjero), Contextos donde no es posible audio: bibliotecas, Problemas
Razón de uso: Laboral cognitivos como situaciones de distracción, pánico o bajo influencia del alcohol.

PERSONAJ ES BENEFICIARIOS Y TIPO BARRERAS EN LA WEB Y ESTUDIO
Hay que cumplir con WCAG1.0 de WAI.
Per sonaje Pr imar io: Usuarios de la Base de Datos de la cadena de televisión “TVAqui”. En cuanto a la barrera más clara con respecto a los problemas auditivos habrá que proveer a los
Per sonajes suplementar io: Usuarios de la base de datos de otras empresas radiodifusoras, contenidos multimedia de contenidos alternativos como subtitulado sincronizado,
empresas subtituladoras, audiodescriptoras, ambas, y otras con interés. transcripciones textuales, etc. y con respecto a la falta de atención, la Web tiene que estar
Per sonajes cliente: Usuario del CESyA y otras entidades como el Real Patronato de organización de forma clara y consistente, el usuario debe saber siempre donde esta y cual es la
Discapacidad. tarea que esta realizando.
Per sonajes ser vidos: Usuarios de la audiencia de “TVAqui” que desean acceder a Este escenario y sus personajes representan uno de los objetivos principales en el diseño de la
contenidos subtitulados y/o audiodescriptos, personas con discapacidad auditiva y/o visual. Web, sus necesidades y metas son suficientemente únicas para necesitar una interfaz propia para
la aplicación de la Base de Datos CESyA. Además habrá que hacer en la Fase de Diseño un
estudio exhaustivo de usabilidad del interfaz de la aplicación con escenarios de estudio de tareas
específicas y testeo real con usuarios, entre otras técnicas para asegurar la accesibilidad y
usabilidad en el interfaz de la Base de datos de CESyA

[Carroll J., 2000], [Moreno L. et al, 2006], [Granollers T., 2004]

 Seguir enfoque de DI en el análisis y diseño: CARD SORTING
 Ayuda a cómo organizar los contenidos
en la web.
 Clasificación de la arquitectura de la
Información
 Aporta accesibilidad:
 Inclusión
 Accesibilidad invisible, detección de
aspectos cognitivos

[Carroll J., 2000], [Moreno L. et al, 2006], [Granollers T.,
2004]
[Moreno L. et al., 2006]

 Seguir enfoque de DI en el análisis y diseño: PROTOTIPO Y
TORMENTAS DE IDEAS
• PROTOTIPADO:
 Orientado a la fase de Diseño: principio
de definición de elementos de diseño :
presentación de las unidades de
contenido según Arquitectura de la
Información, elección de estilo,
consistencia, contraste, elementos de
imagen, etc.
 Apoyo en toma de decisiones
 REUNIONES TORMENTAS DE IDEAS
VISUALES en base a estos prototipos

[Granollers T., 2004], [Preece J., 1994]

 El conocimiento obtenido de estas técnicas incluirlo en el modelado
 PERFILES USUARIO, ESCENARIOS => Modelo Estructural
(Diseño)
 ESCENARIOS, CARD SORTING => Modelo estructural, Modelo
Navegación (Diseño)
 PROTOTIPO maqueta => Modelo de Presentación (Diseño)
[Moreno L. et al., 2009 a]

 PRUEBAS CON USUARIOS, EVALUACIONES HEURISTICAS =>
Evaluación de la accesibilidad desde el punto de vista del usuario y
experto (Evaluación)
[Nielsen J., 1994] [Pierotti D., 1994] [Stone I. K., 1997]

WCAG
 Conceptualizar las WCAG en el proceso => Clasificación
 Analizado la semántica: requisitos de distinto tipo y naturaleza
 Distinguir: cuándo y cómo pueden ser tratados en el proceso de
desarrollo , y con calidad, sistematizando desde diseño
 Correspondencia WCAG-AWA_Requisitos
Mecanismos

Requisitos de
accesibilidad Activan

abstracción

WCAG. Mecanismos
 Análisis:
 (Requisito Funcional) Editor
 Diseño:
 Contenido • Descripción (plantillas)
• Traza de mecanismos derivados
 Navegación • Documentación basada en estándares : MOF, OCL, UML,
• Soporte: AWA_Metamodelo, AWA_patrones, guías, técnicas…
 Presentación

 Implementación: Mecanismos con guías de implementación
 Evaluación:
 Metodología de evaluación
 Mecanismos con utilización de herramientas automáticas, métodos
manuales, recursos

WCAG. Ejemplo Traza (imagen): DISEÑO
Una página web que incluya contenido de tipo imagen, debe ofrecer a través del
Nombre Imagen.

código (X)HTML contenido alternativo a dicha imagen: texto alternativo breve
Descripción

con una descripción equivalente a la semántica que muestra la imagen y según
características una descripción más larga y detallada
1.1 (1)
1.1.1 (A)/ H45 (Using longdesc (HTML)), G94 (Providing short text alternative for
WCAG 1.0
Criterios
(Nivel)/Técnicas non-text content that serves the same purpose and presents the same information as
the non-text content)

AWA_MetamodelWCAG (Imagen)
WCAG 2.0
Representación

Requisito
(imagen) Con esta clase “Image” se representa este requisito, recogiendo el Criterio de
Conformidad 1.1.1 [Nivel A]. Según este requisito una imagen que no sea
decorativa debe ofrecer un texto alternativo breve con una descripción
equivalente a la imagen que queda recogido con el atributo sortText haciendo uso
de la técnica G94 y en ocasiones una descripción más larga y detallada recogida
en el atributo longText, siguiendo técnica H45.
Actividad partida Actividad de DISEÑO
Mecanismos que Este requisito activa los Mecanismos
activa/ACTIVIDAD
• Extender con contenido alternativo al contenido imagen (DISEÑO)
Traza del requisito • Elaborar y validar contenido alternativo al contenido imagen
(DISEÑO)
• Utilizar Patrones_codigo para contenido alternativo al contenido
imagen (IMPLEMENTACIÓN)
• Evaluar contenido imagen (EVALUACIÓN)

Elaborar y validar contenido alternativo al contenido imagen / (DISEÑO)
Consejos para elaborar y validar el contenido alternativo al contenido imagen:
Nombre/(ACTIVIDAD)

contenido alternativo breve y la descripción larga.
Descripción

Hay que elaborar un contenido alternativo breve que sea equivalente,
es decir, que describa la misma semántica que muestra la imagen.
Representación •

Para la descripción larga el contenido alternativo debe describir la
semántica lo más equivalente posible a la imagen de igual manera.
Este requisito es aplicable sólo cuando la imagen es no decorativa, en
caso contrario el contenido alternativo no sería necesario, y la imagen
•

se recomienda incluirla en los estilos de la aplicación con la técnica
CSS, o poner vacío el texto en el atributo alt.

Utilizar Patrones_codigo para contenido alternativo al contenido imagen /
(IMPLEMENTACIÓN)
Nombre/(ACTIVIDAD)

 Mecanismos Patrón de código final a través de la especificación (X)HTML resultante que la
aplicación web deberá generar. Está definido con correspondencia del elemento
Descripción

del AWA_MetamodelWCAG para representar el requisito “Imagen”.
Derivados Representación if (existImage.longText)
<img src=”Image.URI” alt=”sortText” longDesc=”Image.longText”/>
(imagen) else
<img src=”Image.URI” alt=”sortText” />

Evaluar contenido imagen / (EVALUACIÓN).
Revisión automática y manual de la accesibilidad en relación al contenido
Nombre/(ACTIVIDAD)

alternativo. Imagen.
Descripción

Utilización de recursos existentes como metodología UWEN
Representación Evaluación automática

[wabcluster, 2007] de manera que pueda ser incluida en el proceso.
•

• Métodos de evaluación (AWA_MecanismoWCAG EVA 01/01.02)

La imagen es no decorativa y los contenidos alternativos son los adecuados.
Evaluación manual

Comprobar que se sigue el DIS_C 01.01.01/M. Utilización herramientas (Anexo
B: Herramientas, sección Barras de accesibilidad).


 1.1.1 (A)

Imagen a incluir Meta elemento Imagen con
requisitos de accesibilidad
incluidos

<img src=”Image.URI” alt=”Image.sortText” longDesc=”Image.longText” />

WCAG. Ejemplo Traza (imagen): IMPLEMENTACIÓN

 Directamente Pautas WCAG y la aplicación de las
Técnicas , se trata de:
 Proporcionar presentación concreta con técnica CSS
 Asegurar un acceso por teclado
 Avisar ante cambios de contexto
 Asegurar compatibilidad con terceras tecnologías

WCAG. Ejemplo Traza (imagen): EVALUACIÓN
Mecanismo: Metodología que combine métodos automáticos y
manuales
 Aplicar un checklist de accesibilidad a las páginas web. Probando múltiples
configuraciones de distintos navegadores existentes.
 Imágenes adecuadas
 Todo el contenido del audio está disponible a través de texto equivalente
(subtitulado, trascripción).
 Cambio de tamaño de fuente, no pierde precisión en el diseño
 No es necesario el desplazamiento horizontal con diferentes resoluciones de
pantalla y/o tamaños de ventana.
 Contraste es suficiente.
 Acceso en la navegación y funcionalidad sólo con teclado.
 Los vínculos indican claramente el destino o dónde conducen.
 Acceder y examinar las páginas con un lector de pantalla y navegadores
especiales

[W3C, 2006 b]

Cómo incluirlos de manera integral en
el proceso
 Dos orientaciones:

1) Con orientación al Método

2) Con orientación al Proceso

Incluir los requisitos de accesibilidad en
el Método
Análisis Diseño de la extensión del método Implementación de la
:Analista : Diseñador/programador método extensión del método
:Programador

Patrones_códigoWCAG
Extender requisitos
Extender primitivas
del método
Extensión Reglas
Validación de de Transformación
requisitos
AWA_Metamodelo_ Extensión primitivas Compilador Modelos
WCAG

Elementos para incorporación de requisitos de accesibilidad

Elementos del Método donde se han incluido los requisitos de accesibilidad

Incluir los requisitos de accesibilidad en
el Proceso

ANÁLISIS
:Analista

Extender requisitos

Requisitos de Requisitos
accesibilidad extendidos

Incluir los requisitos de
accesibilidad en el Proceso

DISEÑO Play, Pause, Stop enable/disable caption

: Diseñador contenidos : Diseñador método : Diseñador gráfico

Método extendido
Extender requisitos Diseñar
maqueta
con estilos
Elaboración del
Diseñar
contenido adicional

Validación Verificar/Validar Validación

Contenido Contenido Modelos Maqueta gráfica
primario extendido extendidos accesible

Incluir los requisitos de accesibilidad en el
Proceso

IMPLEMENTACIÓN
: Diseñador programador : Programador
Modelos extendidos

Contenido extendido
Generación de código
Diseñar maqueta
con estilos
Implementación
Plantilla y estilos
Maqueta
gráfica accesible
Validación/Evaluación Verificar/Validar
Compilador
Plantillas (X)HTML y método extendido Código
CSS accesibles

Incluir los requisitos de accesibilidad en el
Proceso

EVALUACIÓN
: Evaluación automática : Evaluador : Usuarios

Generación de código Pruebas
con
Código páginas web usuarios
Evaluación
Monitorización, experta
pruebas
automáticas Retroalimentación
en el proceso
Alertas de
problemas de
accesibilidad

Aplicación en casos reales

 Distintas aplicación parciales cubriendo un espectro de
desarrollos actuales de aplicaciones web:
 Desarrollo integral desde el Inicio. Content Management
System (CMS) de código abierto. Tecnología php
(aplicación web CESyA)
 Adaptación sobre tecnología propia y método ágil.
Tecnología .NET (aplicación web proyecto)
 Diseño conceptual . Estrategia de integración sobre
Método de Ingeniería Web

Casos reales. CESyA

 Diseño e implementación del sitio web del Centro Español de
Subtitulado y Audiodescripción (CESyA)
 Content Management System (CMS) de código abierto
 AWA_Interacción

 AWA_WCAG

[CESyA, 2010] [TAW, 2008]

Casos reales. AVANZA I+D. TSI-020302-2008-55
Plataforma de acceso a Internet
 Desarrollo de una plataforma personalizable de acceso
público a Internet para personas con discapacidad, llevado a
cabo en una empresa de desarrollo de software
 Enfoque ágil de desarrollo, Tecnologías .NET
 AWA_Organización
ADO.NET XML

 AWA_WCAG
Agente de usuario CVV
(Navegador) Remoting
ASP.NET PMS
HTML CSS

SCRIPT SMS

Radius
S. Autenticación

[Disuipa, 2010]

Estrategia de integración sobre Método de
Ingeniería Web

Estrategia:
 Mapeo conceptual (Técnica: weaving metamodel [del Fabro M., 2006])
 Extensión de primitivas de modelado con requisitos de accesibilidad
 Transformación (compilador de modelos )
 Generación de código

Conclusiones

 La accesibilidad web debe ser un requisito en los proyectos web
 Obstáculos: tecnología, formación, WCAG en el proceso, sin calidad,
poca participación del usuario, …
 Se ha presentado un espacio de trabajo
 Soporte metodológico formal sobre proceso genérico
• Requisitos para la Organización
• Requisitos a partir de las WCAG Aplicación integral
• Requisitos para considerar al usuario

• No es del todo dirigido
 Carencias y excepciones
• Excepciones: Diversidad tecnológica

Líneas abiertas de investigación

 Tecnologías de desarrollo. Soportes metodológicos
 Tecnología de autor. Framework accesibles
 Planes de accesibilidad en una organización de desarrollo y
software
 Recuperación de información (imágenes, vídeo). Relación con
los requisitos de accesibilidad
 Extensión con requisitos de accesibilidad en métodos activos
de Ingeniería web
 Accesibilidad a través de la anotación semántica en el
desarrollo de aplicaciones web y de GUI. WAI-ARIA

Documentos útiles que se proporcionan

 Checklist o listados de puntos de revisión:
 Qué requisitos por actividades en el proceso
 Documentación con guías básicas de cómo:
 Elaborar informe inicial en relación al marco legislativo
 Determinar Declaración de Política de Conformidad
 Metodología de evaluación
 Recursos:
 Resumen Marco legal en España relativo
 Buenas prácticas en elaboración de contenidos
 Herramientas y recursos útiles para realizar evaluaciones
 Lista de referencias (presentación)

Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software

Semelhante a Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software (20)

Mais de Generación de Jóvenes Rompiendo Barreras

Mais de Generación de Jóvenes Rompiendo Barreras (20)

Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software