cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software
Post on 19-Jan-2015
994 Views
Preview:
DESCRIPTION
TRANSCRIPT
TUTORIAL:Cómo incluir requisitos de accesibilidad web
en el proceso de desarrollo software
Lourdes Moreno, Paloma MartínezUniversidad 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
Qué requisitos de accesibilidad:
Cómo incluirlos de manera integral en el método y proceso Aplicación en casos reales Conclusiones Líneas abiertas de investigación
OrganizaciónInteracciónEstándar WCAG
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¿de qué estamos hablando?
Si el usuario no tiene activado el JavaScript, o accede con algún dispositivo que funciona sin javaScript, ¿qué pasa?
5
Motivación¿de qué estamos hablando?
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¿de qué estamos hablando?
Si accedemos con otros dispositivos, ¿qué pasa?
77
MotivaciónObservatorio
Observatorio
Acessibility evaluation of European governmental web sites
[Olsen M.G., 2008][Discapnet, 2009]
MotivaciónSituació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ónTipo 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
UsuariosPersonas con discapacidad (número considerable)Todos, diversidad funcionalCrece (tecnología, discapacidad por envejecimiento)
IntroducciónPersonas 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ónBeneficios 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 normativaEstá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, legislación y normativaEstá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.
Estándares, legislación y normativaLegislació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
Referencia a WCAGObligación Legal
[BOE, 2007][AENOR, 2004]Hay certificaciones (AENOR)
Estándares, legislación y normativaNormativa 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 condiscapacidad.
Parte 1: Necesidades de usuario
Parte 2: Inventario de estándares
Parte 3: Guía para asignar necesidades de usuarios
Estándares, legislación y normativaNormativa 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
Tecnología cliente: (X)HTML, CSS, …
Tecnología servidor: PHP, .NET,
Tecnologías de la Web 2.0 (RIA)
Ajax (Dojo , Bindows,..)
Flash (SilverLight, Flex, ..)
Tecnología de evaluación: Herramientas automáticas, métricas
Conclusiones
Tecnologías 1.0
Tecnologías 2.0
WCAG 2.0WAI-ARIA
WCAG 1.0WCAG 2.0
Desarmonización. Falta de CompatibilidadEscasez de tecnología favorable en el desarrollo, y menos
al mantenimiento“sólo se permite”, dependencia con el desarrollador
Trabajos relativosDesde 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 del Software
(Web)
Métodos de Ingeniería
Web
Interacción Persona
Ordenador
Trabajos relativosDesde el punto de vista de la Ingeniería
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 relativosDesde el punto de vista de la Ingeniería 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 relativosDesde el punto de vista de la Ingeniería
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] [VanderheidenG. 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 accesibilidadPrincipios
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
Excepciones en el estándar
Requisitos de accesibilidad en la Organización => Plan de accesibilidad, formación
Seguir enfoque DCU, einclusivo => proceso iterativo
Incluir requisitos de accesibilidadPropuesta. AWA
Soporte metodológico AWA (Accessibility for Web Applications)
AWA_Organización
AWA_Interacción
AWA_WCAG
AWA_Requisitos AWA_Mecanismos
proponen activan
34 82
[Moreno, L., 2010]
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
Incluir requisitos de accesibilidadPropuesta. 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
Incluir requisitos de accesibilidadPropuesta. AWA
Qué requisitos de accesibilidad
En la Organización
Interaccióncon el
usuario
Estándar WCAG 1.0 y WCAG 2.0
Qué requisitos de accesibilidad Organización
Plan de Accesibilidad
Calidad. Gestión de la accesibilidad
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
Qué requisitos de accesibilidadOrganizació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
Qué requisitos de accesibilidadOrganización. Mecanismos
Qué requisitos de accesibilidad 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]
Qué requisitos de accesibilidad 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
Qué requisitos de accesibilidad Interacción. Mecanismos
Seguir enfoque de DI en la captura requisitos
Seguir enfoque de DI en el análisis y diseño
Seguir enfoque de DI en la evaluación
COMUNICACIÓN CON EL CLIENTE• Formulación
PLANIFICACIÓN
INGENIERÍA• AnálisisCaptura de RequisitosEspecificación de RequisitosValidación de Requisitos• Diseño• Modelado
CONSTRUCCION• Implementación• Pruebas
DESPLIEGUE• Evaluación
Actividades proceso genérico
Perfiles de usuario
Escenarios
Persona
Prototipo
Tormenta de Ideas
Evaluación Heurística
Cuestionarios
Card sorting
Técnicas de usabilidad con inclusión Mecanismos
Qué requisitos de accesibilidad Interacción. Mecanismos
Seguir enfoque de DI en la captura requisitos: PERFILES DE USUARIO
Personas sin discapacidad en contextos de uso desfavorables
Personas con discapacidad
Personas mayores, enfermedad, discapacidad temporal Visual, auditiva, física motriz, cognitiva Ambiente de oscuridad; ojos tapados, interfaz pequeño; ambiente con humo, niebla, poca visibilidad; etc.
Visual
Ambiente ruidoso; oídos ocupados, oídos enfermos (con tapón); ambiente de silencio, etc.
Auditiva.
Situaciones especiales de poca movilidad, escayola, vendaje; otros impedimentos motores por fractura,…..
Física motriz
Extranjeros (desconocimiento del idioma); situación de estrés, pánico, aturdimiento; distracción, falta de atención, concentración, cansancio; efectos del alcohol
Psíquica, cognitiva
Componentes, dispositivos informáticos lentos, antiguos Visual, auditiva, física motriz, cognitiva” Componentes, dispositivos informáticos muy modernos Visual, auditiva, física motriz, cognitiva
Atr ibutos DOMINIO DE VALORES Edad Infantil (0-12), Adolescente (12-18), Joven (18-35), Adulto (36-65),
Anciano (65-). Profesión Estudiante, académico, empleado, empresario, Ninguna, Otras, etc. Frecuencia de uso Habitual, Circunstancial, Ocasional, Ninguna, etc. Hardware Configuración Básica, adaptada, especifica, etc.…. Ambiente Hogar, Compartido, Privado, Compartido, Oficina, Público, Otras, etc. Software Perfil Windows, Perfil Linux, Perfil especifico adaptado….. Formación tecnológica Alta, Medio, Baja Conocimiento de la tarea Alta, Medio, Baja Discapacidad Visual, auditiva, cognitiva, motriz, etc.. Razón de uso Formativo, Laboral, Curiosidad, Necesidad, Otros, etc. Rol necesidad de Contenido CESyA, Normativa, Formación, Investigación, Base de Datos,
Actualidad comunicación audiovisual
[Mayhew D.J., 1999] , [Moreno L. et al, 2006]
Qué requisitos de accesibilidadInteracción. Mecanismos
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]
Qué requisitos de accesibilidad Interacción. Mecanismos
IDENTIFICACIÓN DEL ESCENARIO
Código de escenar io: 03 Nombre personaje: 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)
Edad: Adulto, 41 años Profesión / tareas: Trabajador / Entidad Radiodifusora, Operadora Frecuencia de uso: Frecuente (semanal) Hardware: Ninguna característica especial, común Ambiente: Oficina, compartido Software: Windows, Mozilla Exper iencia: Baja, nuevo dominio Conocimiento de la tarea: Medio, buena definición de requisitos Limitaciones: Ligera sordera y falta de atención por distracción Razón de uso: Laboral
GRUPOS DE USUARIO POTENCIALES Y NO POTENCIALES CUBIERTOS EN
EL ESCENARIO Usuar io con discapacidad: Usuarios con ligera sordera, Usuarios con hipoacusia, Usuarios
con discapacidad cognitiva de falta de atención, Usuarios con discapacidad cognitiva de dificultad de comprensión, Usuarios con discapacidad cognitiva de hiperactividad.
Usuar io No Discapacitado en Contexto Desfavorable (Usuarios con limitaciones puntuales producidas por entornos desfavorables): oídos ocupados, Dificultad auditiva menor como la de entornos ruidosos con impedimento parcial, Existencia de elementos de audio de lenguaje no conocido (idioma extranjero), Contextos donde no es posible audio: bibliotecas, Problemas cognitivos como situaciones de distracción, pánico o bajo influencia del alcohol.
PERSONAJES BENEFICIARIOS Y TIPO Personaje Pr imar io: Usuarios de la Base de Datos de la cadena de televisión “TVAqui”. Personajes suplementar io: Usuarios de la base de datos de otras empresas radiodifusoras, empresas subtituladoras, audiodescriptoras, ambas, y otras con interés. Personajes cliente: Usuario del CESyA y otras entidades como el Real Patronato de Discapacidad. Personajes servidos: Usuarios de la audiencia de “TVAqui” que desean acceder a contenidos subtitulados y/o audiodescriptos, personas con discapacidad auditiva y/o visual.
BARRERAS EN LA WEB Y ESTUDIO Hay que cumplir con WCAG1.0 de WAI. En cuanto a la barrera más clara con respecto a los problemas auditivos habrá que proveer a los contenidos multimedia de contenidos alternativos como subtitulado sincronizado, transcripciones textuales, etc. y con respecto a la falta de atención, la Web tiene que estar organización de forma clara y consistente, el usuario debe saber siempre donde esta y cual es la tarea que esta realizando. Este escenario y sus personajes representan uno de los objetivos principales en el diseño de la 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]
Qué requisitos de accesibilidadInteracción. Mecanismos
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]
Qué requisitos de accesibilidad Interacción. Mecanismos
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]
Qué requisitos de accesibilidad Interacción. Mecanismos
Qué requisitos de accesibilidad 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
Requisitos de accesibilidad
Mecanismos
abstracción
Activan
Análisis:
(Requisito Funcional) Editor
Diseño:
Contenido
Navegación
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
Qué requisitos de accesibilidad WCAG. Mecanismos
• Descripción (plantillas)• Traza de mecanismos derivados• Documentación basada en estándares : MOF, OCL, UML, • Soporte: AWA_Metamodelo, AWA_patrones, guías, técnicas…
Qué requisitos de accesibilidad WCAG. Ejemplo Traza (imagen): DISEÑO
Nombre Imagen.
Descripción Una página web que incluya contenido de tipo imagen, debe ofrecer a través del código (X)HTML contenido alternativo a dicha imagen: texto alternativo breve 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
WCAG 1.0 1.1 (1)
Criterios (Nivel)/Técnicas
WCAG 2.0
1.1.1 (A)/ H45 (Using longdesc (HTML)), G94 (Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content)
Representación AWA_MetamodelWCAG (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 activa/ACTIVIDAD
Traza del requisito
Este requisito activa los Mecanismos • Extender con contenido alternativo al contenido imagen (DISEÑO) • 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)
Requisito(imagen)
Mecanismos
Derivados(imagen)
Qué requisitos de accesibilidad WCAG. Ejemplo Traza (imagen): DISEÑO
Nombre/(ACTIVIDAD) Elaborar y validar contenido alternativo al contenido imagen / (DISEÑO)
Descripción Consejos para elaborar y validar el contenido alternativo al contenido imagen: contenido alternativo breve y la descripción larga.
Representación • Hay que elaborar un contenido alternativo breve que sea equivalente, es decir, que describa la misma semántica que muestra la imagen. 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.
Nombre/(ACTIVIDAD) Utilizar Patrones_codigo para contenido alternativo al contenido imagen /
(IMPLEMENTACIÓN)
Descripción 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 del AWA_MetamodelWCAG para representar el requisito “Imagen”.
Representación if (existImage.longText) <img src=”Image.URI” alt=”sortText” longDesc=”Image.longText”/> else <img src=”Image.URI” alt=”sortText” />
Nombre/(ACTIVIDAD) Evaluar contenido imagen / (EVALUACIÓN).
Descripción Revisión automática y manual de la accesibilidad en relación al contenido alternativo. Imagen.
Representación Evaluación automática
• Utilización de recursos existentes como metodología UWEN [wabcluster, 2007] de manera que pueda ser incluida en el proceso.
• Métodos de evaluación (AWA_MecanismoWCAG EVA 01/01.02) Evaluación manual
La imagen es no decorativa y los contenidos alternativos son los adecuados. Comprobar que se sigue el DIS_C 01.01.01/M. Utilización herramientas (Anexo B: Herramientas, sección Barras de accesibilidad).
Qué requisitos de accesibilidad WCAG. Ejemplo Traza (imagen): DISEÑO
<img src=”Image.URI” alt=”Image.sortText” longDesc=”Image.longText” />
Imagen a incluir Meta elemento Imagen con requisitos de accesibilidad incluidos
1.1.1 (A)
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
Qué requisitos de accesibilidad WCAG. Ejemplo Traza (imagen): IMPLEMENTACIÓ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
Qué requisitos de accesibilidad WCAG. Ejemplo Traza (imagen): EVALUACIÓN
[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:Analista
AWA_Metamodelo_WCAG
Extender requisitos del método
Diseño de la extensión del método: Diseñador/programador método
Extensión primitivas
Extender primitivas
Validación de requisitos
Implementación de la extensión del método
:Programador
Compilador Modelos
Extensión Reglasde Transformación
Patrones_códigoWCAG
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
Requisitos de accesibilidad
Requisitos extendidos
Extender requisitos
DISEÑO: Diseñador contenidos : Diseñador método : Diseñador gráfico
Contenido primario
Contenido extendido
Elaboración del contenido adicional
Validación
Diseñar
Verificar/Validar
Modelos extendidos
Método extendidoDiseñar
maqueta con estilos
Validación
Maqueta gráfica accesible
Extender requisitos
Incluir los requisitos de accesibilidad en el Proceso
Play, Pause, Stop enable/disable caption
IMPLEMENTACIÓN: Diseñador programador : Programador
Plantillas (X)HTML y CSS accesibles
ImplementaciónPlantilla y estilos
Validación/Evaluación
Generación de código
Código
Verificar/Validar
Compilador método extendido
Modelos extendidos
Contenido extendido
Diseñar maquetacon estilos
Maquetagráfica accesible
Incluir los requisitos de accesibilidad en el Proceso
EVALUACIÓN: Evaluación automática : Evaluador : Usuarios
Alertas de problemas de accesibilidad
Monitorización, pruebas
automáticas
Evaluación experta
Pruebas con
usuarios
Retroalimentación en el proceso
Generación de código
Código páginas web
Incluir los requisitos de accesibilidad en el Proceso
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-55Plataforma 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
AWA_WCAG
SCRIPT
ASP.NET
ADO.NET
Remoting
RadiusS. Autenticación
SMS
CVV
PMS
XML
Agente de usuario(Navegador)
HTML CSS
[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
• Requisitos para considerar al usuario
Carencias y excepciones
Aplicación integral
• No es del todo dirigido• 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)
TUTORIAL:Cómo incluir requisitos de accesibilidad web
en el proceso de desarrollo software
Lourdes Moreno, Paloma MartínezUniversidad Carlos III de Madrid
Grupo LABDA{moreno, pmf}@inf.uc3m.es
9 de Septiembre de 2010
top related