• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software
 

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

on

  • 1,236 views

 

Statistics

Views

Total Views
1,236
Views on SlideShare
1,236
Embed Views
0

Actions

Likes
0
Downloads
16
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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 ¿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?7 7
    • Motivación Observatorio  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 accesibilidadweb 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 Personas con discapacidad (número considerable) Usuarios Todos, diversidad funcional Crece (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 Obligación Legal Referencia a WCAG Hay certificaciones (AENOR) [BOE, 2007][AENOR, 2004]
    • 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 con discapacidad.  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 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 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 Métodos de Interacción del Software Ingeniería Persona (Web) Web 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] [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 lasolució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 Seguir enfoque DCU, e inclusivo => proceso  Excepciones en el estándar iterativo  Requisitos de accesibilidad en la Organización => Plan de accesibilidad, formación
    • Incluir requisitos de accesibilidadPropuesta. AWASoporte 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
    • Incluir requisitos de accesibilidadPropuesta. 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
    • 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
    • Qué requisitos de accesibilidad Interacción Estándar En la con el WCAG 1.0 y Organización usuario WCAG 2.0
    • Qué requisitos de accesibilidadOrganización Plan de Accesibilidad Calidad. Gestión de la accesibilidad
    • Qué requisitos de accesibilidadOrganizació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
    • 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 accesibilidadInteracció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 accesibilidadInteracció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. MecanismosActividades 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
    • 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 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]
    • 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. MecanismosIDENTIFICACIÓN DEL ESCENARIOCódigo de escenar io: 03Nombr e per sonaje: MANUELDescr 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 haordenado 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 trabajodesarrollado 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 deobras 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 ENEdad: Adulto, 41 años EL ESCENARIOPr ofesión / tar eas: Trabajador / Entidad Radiodifusora, OperadoraFr ecuencia de uso: Frecuente (semanal) Usuar io con discapacidad: Usuarios con ligera sordera, Usuarios con hipoacusia, UsuariosHar dwar e: Ninguna característica especial, común con discapacidad cognitiva de falta de atención, Usuarios con discapacidad cognitiva deAmbiente: 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 puntualesExper iencia: Baja, nuevo dominio producidas por entornos desfavorables): oídos ocupados, Dificultad auditiva menor como la deConocimiento de la tar ea: Medio, buena definición de requisitos entornos ruidosos con impedimento parcial, Existencia de elementos de audio de lenguaje noLimitaciones: Ligera sordera y falta de atención por distracción conocido (idioma extranjero), Contextos donde no es posible audio: bibliotecas, ProblemasRazó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 losPer 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 estarPer 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 laDiscapacidad. 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 lacontenidos 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]
    • Qué requisitos de accesibilidad Interacción. Mecanismos  Seguir enfoque de DI en el análisis y diseño: CARD SORTING Ayuda a cómo organizar los contenidosen la web. Clasificación de la arquitectura de laInformació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 accesibilidadInteracció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: principiode definición de elementos de diseño :presentación de las unidades decontenido según Arquitectura de laInformación, elección de estilo,consistencia, contraste, elementos deimagen, etc. Apoyo en toma de decisiones REUNIONES TORMENTAS DE IDEASVISUALES en base a estos prototipos[Granollers T., 2004], [Preece J., 1994]
    • Qué requisitos de accesibilidadInteracción. Mecanismos 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 accesibilidadWCAG 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
    • Qué requisitos de accesibilidadWCAG. 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
    • Qué requisitos de accesibilidadWCAG. 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ónRequisito(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)
    • Qué requisitos de accesibilidadWCAG. Ejemplo Traza (imagen): DISEÑO 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).
    • Qué requisitos de accesibilidad WCAG. Ejemplo Traza (imagen): DISEÑO  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” />
    • Qué requisitos de accesibilidadWCAG. 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
    • Qué requisitos de accesibilidadWCAG. Ejemplo Traza (imagen): EVALUACIÓNMecanismo: 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 enel 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ódigoWCAGExtender requisitos Extender primitivas del método Extensión Reglas Validación de de Transformación requisitosAWA_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 enel 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 extendidoExtender 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ódigoDiseñar maquetacon estilos Implementación Plantilla y estilosMaquetagrá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 : UsuariosGeneración de código Pruebas conCó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-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 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 deIngeniería WebEstrategia: 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)
    • 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