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í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?


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

5


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


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)

http://www.elmundo.es/tts/rosa_portada.html�

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


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


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


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

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


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]


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]


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 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)


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).


<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


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


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


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

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

Documents

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