羠ea de Tecnolog韆s de la Informaci髇 y las Comunicaciones Aplicadas
羠ea de Tecnolog韆s de la Informaci髇 y las Comunicaciones Aplicadas Universidad de Murcia
羠ea de Tecnolog韆s de la Informaci髇 y las Comunicaciones Aplicadas
ATICA
25.09.2017
 
 
Aspecto y Funcionalidades de las aplicaciones WEB (NORMAWEB) Imprimir E-mail
El objeto de este documento es proponer normas, para homogeneizar el aspecto y las funcionalidades de las aplicaciones Web de ATICA, haciendo incapié en las recomendaciones de desarrollo web del W3C (HTML, CSS, etc), especialmente las pautas de accesibilidad web del W3C (WCAG 2.0, adecuación AA). Para ello los desarrolladores de ATICA disponen de una sección sobre Normas y Recomedaciones de Accesibilidad, Usabilidad y Experiencia de Usuario en la Wiki del Programador, que incluye por ejemplo, un Manual de Accesibilidad Web basado en la norma UNE-139803-2012, que publica el Observatorio de Accesibilidad, a través del Portal de Administración Electrónica del Gobierno de España.

NORMALIZACIÓN DE APLICACIONES WEB DE ATICA.

Juan Luis Serradilla Amarilla

Programador
ATICA
MNCS

ATICA. Campus de Espinardo. 30100 Murcia

Versión 1.0

 

18/10/2004

Historial de revisiones
Revisión 1.0 18/10/2004 juanlu

Documento inicial.

Revisión 1.1 22/10/2004 juanlu

Primera versión.

Revisión 1.2 08/11/2004 juanlu

Incluye explicación del prototipo.

Revisión 1.3 17/02/2005 juanlu

Se decide suprimir el logo de ATICA de los encabezados, ya que en la
leyenda del pie ya consta que la aplicación en cuestión ha sido
desarrollada por ATICA.

Cambios en el prototipo, reflejando el cambio de la norma.

Cambios en el prototipo incluyendo nueva hoja de estilo mucho más
completa.

Revisión 1.4 22/06/2005 juanlu

Incluyo lista de aplicaciones en fase de adaptación a Normaweb, otra
con las ya adaptadas y una más con las que están pendientes de iniciar
el proceso.

Revisión 1.5 21/02/2006 juanlu

Incluyo el texto relativo a la "ventana de mantenimiento" de los sistemas
que se produce por la noche, de modo que sea incluido en la página de
entrada de cualquier aplicación.

Revisión 1.6 15/05/2006 juanlu

Todas las páginas de los desarrollos web deben intentar seguir los
estándares HTML, CSS y XHMTL del W3C. Aquellas que los cumplan
incluirán los sellos respectivos del W3C.

Revisión 1.7 28/06/2006 juanlu

Incorporación de las pautas de accesibilidad (AA) del W3C.

Revisión 1.8 18/04/2007 juanlu

Incorporo Proyecto FORJA (FOrmacion de un Repositorio Javascript para Atica).

Revisión 1.9 01/07/2008 juanlu

Normativa para el Desarrollo de Aplicaciones Web Seguras (OWASP).

Revisión 1.10 04/06/2009 juanlu

Desarrollo de aplicaciones JEE con FUNDEWEB.

Revisión 1.11 08/09/2009 juanlu

Pantalla Unificada de Acceso (PUA).

Revisión 1.12 10/10/2011 juanlu
Manual de Accesibilidad Web de la Administración General del Estado
Revisión 1.13 05/04/2013 juanlu
Guía de Comunicación Digital para la Administración General del Estado
Revisión 1.14 28/04/2014 juanlu
Manual del Observatorio de Accesibilidad Web del Gobierno de España (Febreo 2014)
Revisión 1.15 23/05/2016 juanlu
Manual del Observatorio de Accesibilidad Web del Gobierno de España, basado en la UNE-139803-2012 (Diciembre 2014)

Resumen

Normalizar el estilo y funcionalidades de las aplicaciones web de ATICA


1. Introducción y Normativa Aplicable.

El objeto de este documento es proponer normas, para homogeneizar el aspecto y las funcionalidades de las aplicaciones Web de ATICA.

ÁTICA procura en todos sus desarrollos adoptar fielmente estándares internacionalmente reconocidos. Siguiendo esta premisa, todos nuestros desarrollos web intentarán adaptarse a los estándares HTML, CSS, XHTML y WAI del W3C, para ello desde el 2013 los desarrolladores disponen del Manual del Observatorio de Accesbilidad Web del Gobierno de España, que se pueden descargar de la Sección de Accesibilidad Web de la Wiki del Programador

Desde Abril del 2007, hemos impulsado un proyecto (FORJA), para la FOrmación de un Repositorio Javascript para Atica. que pretende proporcionar un repositorio de funciones javascript de uso común, además de la documentación y la formación necesaria tanto para su construcción, como para su posterior mantenimiento.

En Julio del 2008, MNCS publica la Normativa para el Desarrollo de Aplicaciones Web Seguras (OWASP), que deben cumplir todas las aplicaciones web desarrolladas en ATICA.

Las nuevas aplicaciones web JEE de ATICA deben de hacerse según FUNDEWEB, desde Junio del 2009 (fecha de la versión 1.0). FUNDEWEB es un servicio de MNCS que proporciona, entre otras cosas, un IDE y un framework (basado en Seam) de desarrollo JEE que incorpora estándares actuales (JSF, JPA, EJB3, etc).

Desde el 8-9-2009, TODAS las aplicaciones web de ATICA deben modificar la pantalla de acceso, según las indicaciones del Prototipo de Pantalla Unificada de Acceso (PUA).

Resumiendo, las normativa aplicable a TODAS las aplicaciones web de ATICA es la siguiente:

2. Estándares HTML, CSS y X-HTML del W3C.

Todas las páginas de nuestras aplicaciones web deben seguir los estándares HTML, CSS, XHTML y WAI del W3C. Para ello los desarrolladores deben validarlas (leyendo el Manual del Observatorio de Accesibilidad Web del Gobierno de España y usando los validadores del W3C, así como las herramientas que se proponen en el Anexo B), y en todas aquellas que superen los test de validación debe aparecer el o los sellos correspondientes del W3C. Estos sellos, en lugar de contar con un enlace que envíe a la página del validador correspondiente, deben llevar a una página estática en la sede de ÁTICA especialmente preparada por MNCS.

El hecho de que la página principal o de entrada a uno de nuestros desarrollos ostente los sellos de validación y calidad no significa, salvo que así se explicite, que la totalidad de las páginas de dicho desarrollo cumpla estos estándares.

3. Recomendaciones de accesibilidad del W3C.

En el desarrollo de nuevas aplicaciones web, en ATICA, se deben seguir las recomendaciones de accesibilidad del W3C ("http://www.discapnet.es/web_accesible/wcag10/full-checklist.html") de prioridad 1 y 2 (AA). Estas recomendaciones sólo podrán ser soslayadas, en el caso en que los requisitos de funcionalidad de la aplicación impidan su cumplimiento (en cuyo caso se estudiará la viabilidad de una versión accesible).

Los Jefes de Proyecto, para cualquier nueva aplicación web, deben tener en cuenta un requisito NO funcional OBLIGATORIO más, que será la accesibilidad (AA), de modo que se facilitará a los desarrolladores todo lo necesario para conseguirla; y se deberá de hacer el control de calidad correspondiente, haciendo uso del Manual del Observatorio de Accesibilidad Web del Gobierno de España.

Este documento incluye un apéndice "Pautas de Accesibilidad (AA) y herramientas", además de un prototipo que sigue las recomendaciones de accesibilidad (AA) del W3C.

4. Estilo.

En primer lugar y lo más importante, debemos seguir las pautas de accesibilidad web del W3C (adecuación AA). Además, en cuanto al estilo de las aplicaciones web, debemos tener en cuenta:

  • Hojas de estilo. Todos los atributos relativos al aspecto se llevarán a la hoja de estilo, de modo que no se deje ninguno en el código HTML de la página. Además, se pueden proporcionar varias hojas de estilo, para cada uno de los dispositivos en los que se prevea que se visualizará la página (pantalla, impresora, etc). Se deben seguir las recomendaciones del W3C sobre hojas de estilo, y validarlas.

  • Fondo y tono. Serán preferiblemente los de la web de ATICA. Se facilitarán al desarrollador, al menos, tres paletas de colores. Los colores elegidos deben seguir las recomendaciones de contraste de color del W3C. Se validará que tal punto se cumple.

  • Imágenes. Evitar en la medida de lo posible la sustitución de texto por imágenes. A la hora de usar imágenes con degradados, asegurar la adecuada legibilidad del texto de la imagen. Todas deben llevar su texto alternativo, por si el navegador no las puede mostrar.

  • Utilizar el atributo title para los “tooltips” en imágenes o enlaces. El atributo alt sin embargo es un texto sustitutivo por si la imagen no saliera, que tiene que estar presente siempre.

  • Logos. Podemos partir de tres versiones de cada logo (pequeña, mediana y grande); y otras 3 en versión "degradado". En el encabezado de las páginas se incluirán logos en versión degradada y en su tamaño más pequeño: en general, en el centro el de la UM, a la derecha el de la aplicación y a la izquierda el de ATICA (según se mira a la pantalla). Si procede incluir otros logos, como el de la CARM o la UPCT, se pondrá en el centro el de mayor rango, por ejemplo, en el caso de que haya que incluir los tres (CARM, UM y UPCT), se pondrá en el centro el de la CARM y, según se mira a la pantalla, a la izquierda el de la UM y a la derecha el de la UPCT. También se puede optar por eleminar el logo de ATICA del encabezado, en cuyo caso el la UM (y los que lleve alrededor) irán a la izquierda de la pantalla (degradados).

  • Resolución. Todas las aplicaciones serán optimizadas para su visualización en 1024x768 (y por tanto se verán bien también con resoluciones mayores).

  • Fuente y tamaño de letra. Usar hojas de estilo. Recomendamos usar sólo dos estilos: serif y sans serif, por ejemplo, Times New Roman y Arial. El tamaño recomendado en puntos puede ser 10 o superior, en función de la fuente. Indicar tamaños de fuente relativos (em).

  • Encabezado y pie. En el pie poner: "(c) Universidad de Murcia - ATICA". La leyenda "ATICA" será, a su vez, un enlace a la página principal de ATICA.

  • Identificación de campos. Evitar la maquetación con tablas para los formularios. Deben utilizarse los elementos fieldset para la agrupación de campos relacionados, y label para relacionar un control con su etiqueta. El control debe ir dentro de la etiqueta label. Hay disponible una clase para señalizar los campos obligatorios (ver prototipo). Hay que diferenciar visualmente los campos de "solo lectura" y los "obligatorios". Los de sólo lectura aparecerán tal cual, como una etiqueta más. Los "obligatorios" deben llevar un asterisco rojo a la izquierda de la etiqueta. Se incluirá una leyenda que informe sobre el significado del "asterisco rojo", al inicio del formulario, justo antes de la primera linea de campos.

  • Botones. Todas las aplicaciones deben usar los mismos botones. Las imágenes deben ser significativas e intuitivas, por ejemplo, "interrogación" para ayuda, "impresora" para imprimir, "casa" para inicio, "buzón" para sugerencias, etc.

  • Marcar los menús con listas desordenadas. Siempre que hay más de una opción, hay que usarlas o no se pasará AA.

  • Evitar, a ser posible, decir que una aplicación está optimizada para un navegador concreto. En caso de que sea necesario, indicar una lista de navegadores en los que ha sido probada. Si la página es accesible, funcionará en la gran mayoría.

5. Funcionalidades.

No olvidemos que en primer lugar y lo más importante, será seguir las pautas de accesibilidad web del W3C (adecuación AA), aplicando las técnicas que propone el propio W3C. Sólo podremos saltarnos alguna de las citadas pautas, si para conseguir una determinada funcionalidad, que sea requisito imprescindible de la aplicación, no fuese posible cumplirla. En cuanto a las funcionalidades de las aplicaciones web de ATICA, tendremos presente:

  • Ayudas. Todas las aplicaciones deben llevar ayuda. Usaremos una ventana sin maximizar. El tamaño lo fijaremos en función del tamaño que establezcamos para las imágenes de captura de pantalla que vayamos a incluir, de modo que se vean sin necesidad de maximizar la ventana; y teniendo en cuenta los menús que pueda llevar. La ventana se debe poder maximizar. En principio, para generar la ayuda, usaremos XML (DocBook).

  • Alertas y acciones. Procuraremos usar javascript no intrusivo (ver FORJA). Con Javascript sólo tenemos tres ventanas de alerta: "aceptar", "aceptar + cancelar" y "campo + aceptar + cancelar". Por tanto los textos de las ventanas de alerta deben ajustarse a las respuestas que se pueden dar con las ventanas anteriores. En todo caso deben ser afirmaciones.

  • Tabulador. Habilitar su uso, teniéndolo presente en la ordenación de los campos de los formularios.

  • Menús. Los montaremos con un frame superior que permita visualizar dos niveles de menús. En la pantalla inicial de la aplicación (la siguiente a la conexión) aparecerá el menú de primer nivel (en el frame superior), y llenando la ventana, un mapa de la aplicación, con un máximo de 3 niveles. En las pantallas siguientes aparecerá el menú principal siempre visible, más el menú contextual elegido.

  • Conexión y autenticación, las aplicaciones web Intranet usarán (de momento) la autenticación Radius. Usar la misma ventana de conexión para todas las aplicaciones, cambiando el logo de la aplicación. Incluir información como el teléfono de Soporte a Usuarios (Dumbo 4222), enlace al Acrobat Reader, Navegadores soportados (ver punto siguiente), manual de usuario y logotipo de compatibilidad W3C.

  • Navegadores. Se incluirá un letrero en las aplicaciones que diga "Optimizado para navegadores que sigan los estándares del W3C (HTML4.01/CSS/WAI), como Internet Explorer, NetScape y Mozilla/Firefox". Este letrero, que aparecerá en la página de conexión (ver punto anterior), también puede aparecer en una página aparte de "Recomendaciones de navegación", con enlace en la pantalla de conexión. En el mismo punto se incluirá el letrero "SOFTLA: Trabajamos por el Software Libre".

    Se deben probar las aplicaciones en todos los navegadores que, además, indique la MNCS. Para asegurar la compatibilidad con el máximo número de navegadores, las páginas HTML deben seguir las recomendaciones W3C.

  • Listados. Se generarán en PDF. Debe aparecer el enlace al Acrobat Reader en la pantalla de conexión (ver "Conexión y autenticación", más arriba).

  • Scroll. Hay que evitarlo siempre que sea posible; sobre todo el scroll horizontal.

6. Prototipo de aplicación web.

Desde el 8-9-2009, TODAS las aplicaciones web de ATICA deben modificar la pantalla de acceso, según las indicaciones del Prototipo de Pantalla Unificada de Acceso.

El prototipo está disponible en https://www.um.es/atica/documentos/prototipos/normaweb/ y fué desarrollado por Inmaculada Bermejo Salar, siguiendo las pautas de accesibilidad del W3C (adecuación AA). Se trata de un prototipo de aplicación llamada MNCS, que consta de:

  • Control de acceso (en cuatro versiones diferentes).

  • Recomendaciones y requisitos de navegación.

  • Menú principal y mapa web.

  • Opción de menú principal.

  • Opción de menú de segundo nivel.

  • Formulario.

El prototipo está optimizado para su visualización en 800x600, tal como recomienda esta norma.

6.1. Esquema del código HTML utilizado en el prototipo.

Uno de los principales problemas del prototipo estribaba en que, debido al uso de tablas para maquetar, tanto los formularios como los menús y disposición de la página, el código HTML se hacía bastante complejo, más difícil de comprender y mantener, y de adaptar para las diferentes aplicaciones a las que tenía que servir. Por eso la primera medida a tomar ha sido la organización y maquetación del prototipo de la forma más sencilla posible. Se han eliminado todos los elementos posibles y se ha organizado la página con los siguientes:

  • div#contenedor: contiene al resto del código, se utiliza para restringir el ancho de la página de forma sencilla.

  • div#cabecera: contiene un h1 con la imagen del escudo de la Universidad y el texto alternativo institucional "Universidad de Murcia", y un h2 con el nombre de la aplicación o la imagen de su logotipo.

  • div#menu: en este caso utilizamos un elemento div para agrupar los diferentes niveles de menú. Para cada uno se utilizará una lista, teniendo por ahora dos tipos:

    • ul.uno: clase para los menús de primer nivel

    • ul.dos: clase para los menús de segundo nivel

    Además, disponemos de la clase li.activo para indicar la opción de menú en la que nos encontramos en ese momento.

  • div#contenido: en esta capa pondremos el contenido propio de la página en cuestión. Dentro de ella se podrán utilizar todos los elementos HTML, crear nuevos menús, encabezados y así debemos hacerlo. Además se han añadido estilos para los formularios, párrafos y listas que se aplicarán automáticamente al elegir la hoja de estilo del prototipo. Hay algunas clases especiales para casos que se producen frecuentemente:

    • div.info: mensajes informativos o para aclarar el funcionamiento de una página, como por ejemplo, indicación de que los campos requeridos de un formulario están marcados de determinada manera, o alguna otra aclaración.

    • div.avisoatica: avisos sobre las aplicaciones (como por ejemplo, el mensaje de mantenimiento).

    • div.exito: para cuando una acción se ha llevado a cabo con éxito.

    • div.error: para cuando una acción ha producido un error.

    • .obligatorio: para marcar los campos obligatorios de un formulario. Se aplica al elemento label del elemento que corresponda. También se dispone del elemento em para marcar el elemento distintivo de los campos obligatorios (en este caso, el asterisco).

    • .bloque: esta clase se ha creado por comodidad, sirve para poder aislar un elemento cuando sea necesario, sustituyendo al elemento br que está en desuso.

    • div.uno, div.dos, div.tres, div.cuatro: se han dispuesto estas clases para evitar maquetar el contenido con tablas (menos accesibles y menos flexibles). Se puede utilizar cuando se quiere disponer el contenido por columnas (cada clase hace referencia al número de columnas por línea) aunque no siempre es necesario. Pueden verse ejemplos claros de su uso en los formularios de entrada construidos para el prototipo.

  • div#pie: la información del pie de página se ha organizado en dos secciones:

    • ul#ayuda: iconos de ayuda para la navegación, se trata como un menú y tiene su propio formato.

    • div#meta: información sobre la propia página. Copyright e información de validación

      • ul#validacion: iconos de validación para las páginas que lo cumplan, con los enlaces a donde corresponde según la documentación Normaweb.

6.2. Separación de contenido y la presentación.

De cara a la adecuación a los nuevos estándares, así como para tener mayor flexibilidad y facilitar la validación de accesibilidad, no debe usarse ningún elemento que proporcione formato en el código HTML.

Hay que distinguir entre formato y contenido, especialmente cuando se trata de imágenes, y proporcionar la descripción adecuada cuando se trate de información valiosa.

Para lograr separar el contenido y la presentación se utilizan las hojas de estilo, donde podemos especificar cualquier propiedad relativa al aspecto de un elemento.

Así mismo, se procurará reservar algunos formatos como la negrita y la cursiva para el propósito que tienen, es decir, enfatizar, al menos en la medida de lo posible, no abusar de ellos.

Es importante recordar que, en los controles de formularios, el atributo size puede considerarse contenido, ya que debe ser indicativo del tamaño aproximado que pueden tener los datos que se deban escribir, y en este sentido ayuda al usuario a hacerse una idea (por ejemplo, en controles para fechas). Así podemos especificar el tamaño del control sin tener que recurrir a propiedades CSS.

6.3. Separación de contenido y comportamiento.

Especialmente problemático para la accesibilidad es el aspecto del comportamiento en el cliente (navegador) de las aplicaciones, controlado mediante javascript (procuraremos usar javascript no intrusivo; ver FORJA).

Además de para mejorar la accesibilidad, es muy conveniente separar la capa de comportamiento de la de contenido de la misma forma que hicimos con la presentación.

Para ello, podemos ver el ejemplo de la validación de campos obligatorios en los formularios de entrada y sugerencias del prototipo. No hay ninguna línea ni llamada a función javascript en el propio formulario, sino que está relacionada en el fichero javascript que contiene las propias funciones (ver ejemplo de formulario en FORJA).

6.4. Semántica.

En este sentido:

  • Uso de encabezados, párrafos y listas para el contenido. Es importante utilizar los niveles de los encabezados (h1, h2, h3) para marcar los niveles de profundidad del contenido asociado a ellos en el documento, en lugar de para dar formato.

  • Evitar la maquetación con tablas.

  • Uso de los elementos de agrupación para formularios:

    • Fieldset: agrupación de campos relacionados entre sí. El elemento legend servirá para etiquetar el fieldset como si fuera su título correspondiente.

    • Label: imprescindible para lograr que el formulario sea accesible, porque relaciona el texto escrito con el control del formulario y será leído junto con él al saltar por los diferentes campos del formulario con las teclas.

6.5. Cambios gráficos.

Se pueden observar diversos cambios gráficos que responden principalmente a requerimientos de accesibilidad y usabilidad.

  • El más notable de ellos es el cambio en los colores utilizados. Se ha tomado esta determinación con el fin de conseguir el contraste de color adecuado entre color de fondo y primer plano, según las fórmulas publicadas por el W3C.

  • También se han creado algunos bloques, como la delimitación de los formularios aplicando un color de fondo y borde, para centrar la atención del usuario en la zona en concreto en la que tiene que interactuar.

  • Se han suprimido todas las imágenes que sustituían texto. Esto debe procurarse en la medida de lo posible, ya que así dejamos al usuario que controle el tamaño del texto, así como el contraste de color, y nos aseguramos que el texto será leído (previniendo, por ejemplo, olvidos en etiquetas alt para imágenes) y que economizamos al máximo en la descarga de la página.

  • El color de los enlaces ha pasado a ser azul. En este cambio no sólo contamos con el contraste (anteriormente insuficiente) sino también juega un papel el estándar en el que se ha convertido el color azul para los enlaces (color predeterminado). Aun así, esto no es determinante, mientras el color tenga el contraste adecuado. También se ha considerado que los enlaces visitados tengan un color diferente.

  • Además del color, los enlaces han pasado a estar subrayados y a tener un tamaño de letra normal, reservando la negrita para los casos en los que queramos hacer énfasis, poder distinguirlo visualmente de un enlace normal.

  • Leve disminución del tamaño de la fuente. Se conserva un tamaño razonable pero que permita optimizar el espacio disponible a 800x600. El tamaño se especifica con em, unidad escalable que permite al usuario modificarlo en cualquier navegador.

6.6. Accesibilidad.

Consejos para conseguir que una página sea accesible:

  • Uso adecuado de HTML:

    • Validar el código según los estándares de W3C.

    • Especificar siempre el tipo del documento, el idioma y la codificación del documento.

    • Asegurar que todos los elementos se usan para proporcionar estructura al documento (h1...h6, p, ul, ol, em, strong, img...). Evitar elementos como b, font, i... Ejemplo: usar em en lugar de i para enfatizar un texto. Usar blockquote o q junto con el elemento cite para citas textuales.

    • Asegurar que todos los atributos se usan para proporcionar estructura (title, alt, src, size, lang...). Evitar atributos como background, width, padding, cellspacing... todos pueden especificarse después con CSS.

    • Usar los elementos estructurales para la función que les corresponde:

      • Títulos para aportar una jerarquía al documento

      • Tablas para listar datos tabulares (2 columnas o más, en otro caso, usar listas). A las tablas de datos hay que darles la estructura adecuada, con los elementos y atributos que las hacen accesibles:

        • summary: resumen del contenido de la tabla. Ayuda para saltar contenido que no interese al usuario

        • caption: título de la tabla

        • thead, tbody: identifican diferentes secciones de la tabla, la cabecera y el cuerpo

        • th: celda de encabezado en la cabecera de la tabla

        • td: celda de datos del cuerpo de la tabla

          Ejemplo de tabla accesible:

          <table summary="Porcentaje de uso de navegadores en el sitio web de la Universidad de Murcia">
           <caption>Navegadores más usados</caption>
           <thead>
            <tr>
             <th scope="col">País</th>
             <th scope="col">Internet Explorer</th>
             <th scope="col">Mozilla Firefox </th>
             <th scope="col">Opera</th>
             <th scope="col">Otros</th>
            </tr>
           </thead>
           <tbody>
            <tr>
             <td>España</td>
             <td>60%</td>
             <td>25%</td>
             <td>10%</td>
             <td>5%</td>
            </tr>
           </tbody>
          </table>

      • Listas para listar elementos y para dar estructura a los menús

      • Aportar elementos y atributos que ayudan a la accesibilidad:

        • Elementos: abbr, acronym, caption, thead, th, label, fieldset...

        • Atributos: title, summary, accesskey, tabindex, alt.

  • Separación de la presentación en hojas de estilo aparte:

    • En el documento no debe existir ningún elemento ni atributo que proporcione información de decoración.

    • Asegurarnos siempre de que el contraste de color entre fondo y primer plano es suficiente.

    • Evitar basarnos sólo en el color para distinguir elementos (ej. enlaces del resto del texto) o estados (rollovers). Hay que utilizar algún elemento distintivo más, por ejemplo el subrayado, la negrita o un tamaño de texto mayor.

    • Utilizar unidades adecuadas para el tamaño del texto: em, porcentajes (con un tamaño base de em)

    • Es importante distinguir entre imágenes decorativas e imágenes que proporcionan información. Las primeras siempre deberán ir en la hoja de estilo, y las segundas siempre deberán tener su alternativa textual adecuada.

    • Proporcionar varias hojas de estilo para distinguir los diferentes medios, si se prevee que la aplicación puede requerirlo: screen, print, handheld, projector, all.

    • Para usar efectos rollover en los menús, se usa CSS, nunca javascript.

  • Identificar cambios en el lenguaje: la página tiene definido un idioma en su cabecera. Si a lo largo del texto se produce un cambio en este idioma, debe notificarse:

    <p>Y entonces el extranjero le dijo:<q lang=&rdquo;en&rdquo;>How are you?</q></p>
  • Proporcionar contenido alternativo para todos los elementos no textuales:

    • Imágenes: atributo alt suficientemente descriptivo. No usar por ejemplo, la descripción “Logotipo” o “Gráfico” y similares. Usar longdesc si alt no es suficiente.

    • Scripts, javascript: las páginas deben ser funcionales sin javascript. Usar el elemento noscript de forma eficiente y no como mera información, cuando sea posible. Realizar siempre las validaciones tanto a nivel de cliente como en servidor. Es muy importante reducir el uso de javascript para lo estrictamente necesario. Evitar a toda costa su uso cuando hay elementos HTML disponibles para realizar la misma interacción (por ejemplo un enlace). Usar javascript no intrusivo (ver FORJA).

    • Objetos embebidos (flash, java...): se debe usar el elemento object en lugar de embed. El contenido alternativo se pondrá dentro del objeto de la siguiente manera:

      <object title="Universidad de Murcia" type="application/x-shockwave-flash" data="http://www.um.es/imagenes/home/cabeceraum2.swf" width="730" height="82">
        <param name="movie" value="http://www.um.es/imagenes/home/cabeceraum2.swf" />
        <param name="quality" value="high" />
        <h1>Universidad de Murcia</h1>
        <h2>Formación, prestigio, investigación, tradición</h2>
      </object>

    • Marcos: evitar su uso en la medida de lo posible. Si es inevitable, utilizar su atributo title para indicar lo que contienen y facilitar la navegación entre ellos. Para proporcionar la alternativa se usará el elemento noframes, proporcionando desde ahí acceso a una versión sin marcos, o bien a cada una de las páginas que se accede a través del conjunto de marcos.

6.7. Usabilidad.

Algunas cuestiones relativas a la usabilidad:

  • Legibilidad:

    • Tipo y tamaño de letra: para pantalla, sans-serif de un tamaño equivalente a unos 10 puntos, unos 0.9em (cambiará según la familia de fuente escogida)

    • Bloques de texto: no crear líneas demasiado largas (entre 60 y 80 caracteres) y no crear párrafos demasiado grandes. En pantalla se leen más cómodamente los textos cortos.

    • Evitar el uso de controles de formulario para mostrar texto no editable, producen una sensación engañosa y son incómodos.

  • Organización de la página: considerando que los usuarios leen de arriba a abajo y de izquierda a derecha, los estándares de facto más extendidos para la maquetación en entorno web son los siguientes:

    • Logotipo/identificación de la entidad: esquina superior izquierda. Con enlace de vuelta a la página principal.

    • Menús de navegación/opciones: horizontal o vertical en la esquina superior izquierda bajo el logotipo. Se puede duplicar de forma discreta en el pie de página.

    • Buscador y menús de ayuda: zona superior derecha.

  • Proporcionar ayudas para la ubicación y navegación:

    • Rastro de migas

    • Mapa del web

    • Enlaces con texto suficientemente descriptivo. Si es necesario, usar el atributo title para describir lo que pasará al pulsar el enlace.

    • Enlaces fácilmente distinguibles del texto que los rodea. Intentar seguir el estándar de facto de color azul y subrayado, o al menos uno de los dos.

    • Proporcionar atajos de teclado:

      • En formularios, es útil indicar el orden del tabulador para cada campo (tabindex).

      • En menús se puede optar por teclas de acceso directo accesskey pero hay que tener cuidado con no sustituir a las propias del sistema operativo (alt+tecla). Se recomienda usar números.

  • Al manipular el comportamiento del navegador a través de la página:

    • Evitar sustituir el botón atrás por un enlace con javascript: para ello está el botón. Si se quiere poner un enlace, usar un elemento HTML normal que lleve a la página que corresponda (por ejemplo, en un rastro de migas).

    • Evitar modificar el aspecto del navegador eliminando los menús y botones, o deshabilitando el botón derecho del ratón.

    • Evitar refrescar automáticamente la página sin intervención del usuario en la medida de lo posible (realizar los cambios con una interacción con el servidor).

    • Si se usa Ajax, facilitar la percepción del cambio que se produce utilizando elementos gráficos.

    • Evitar el uso del atributo target de los enlaces, y la creación de ventanas pop-ups en la medida de lo posible. Dejar al usuario la capacidad de decidir dónde quiere abrir el enlace.

  • Proporcionar suficiente información al usuario:

    • Advertir de los requisitos necesarios (ej. marcos, javascript) para utilizar una aplicación al usuario antes de pedir que se identifique para entrar en ella.

    • Poner especial atención en los mensajes de respuesta del sistema. En el prototipo hemos proporcionado tres tipos de mensaje (éxito, error e información) que pueden ayudar para distinguir los mensajes de respuesta.

    • A la hora de poner ficheros disponibles para que el usuario descargue, avisar el tipo de fichero que es y su tamaño.

    • En formularios:

      • Advertir de cómo se señalizan los campos obligatorios antes de comenzar.

      • Señalizar que un campo es obligatorio antes de mostrar su etiqueta, e incluirlo en el elemento label para poder ser leído al navegar el formulario por teclado.

 

7. Pantallas que integran el prototipo.

Básicamente, las pantallas que forman parte del prototipo son:

  • Control de acceso (en cuatro versiones diferentes).

  • Recomendaciones y requisitos de navegación.

  • Menú principal y mapa web.

  • Opción de menú principal.

  • Opción de menú de segundo nivel.

  • Formulario.

7.1. Control de acceso.

Desde el 8-9-2009, TODAS las aplicaciones web de ATICA deben modificar la pantalla de acceso, según las indicaciones del Prototipo de Pantalla Unificada de Acceso.

Es la pantalla de conexión a la aplicación (incluyendo la posibilidad de autenticación RADIUS, o con tarjeta inteligente, o con DNI): (http://www.um.es/atica/documentos/prototipos/normaweb/entrada4.php).

Figura 1. Control de Acceso

Pantalla de Control de Acceso

El prototipo propone otras dos pantallas de acceso (para aquellas aplicaciones cuyo control de acceso sea más sencillo), una donde sólo se pide usuario y contraseña (http://www.um.es/atica/documentos/prototipos/normaweb/entrada1.php) y otra donde se habilita el acceso sin tarjeta inteligente o con ella (http://www.um.es/atica/documentos/prototipos/normaweb/entrada2.php).

En el encabezado, aparece el escudo de la UM (degradado) a la izquierda de la pantalla, y a la derecha el de la aplicación MNCS. El logo de la UM aparece degradado, para que no resalte sobre el de la aplicación. Está montado con dos imágenes, para que se pueda adaptar (a lo ancho) a la resolución elejida por el usuario..

En el pie figura la leyenda "(C) Universidad de Murcia - ATICA"; además de los enlaces que permiten comprobar la compatibilidad W3C de la página, tanto del HTML como de la hoja de estilo y de la accesibilidad (AA). Este pie, tal cual, será el que aparezca en todas las pantallas de la aplicación.

Junto al pie tenemos el enlace a las "Recomendaciones y requisitos de navegación", además de algunos iconos como "Inicio" (casita) o "Buzón de sugerencias" (sobre).

Sobre el enlace "Recomendaciones de navegación" hay un espacio reservado para avisos, que incluye el dibujo degradado del logo de ÁTICA (a la izquierda). En este espacio es obligatorio incluir un mensaje que informe sobre la "ventana de mantenimiento" nocturna que tienen los sistemas, tal y como se observa en la imagen de más arriba.

Los campos a rellenar serán "Usuario" y "Contraseña"; o si procede, el "PIN"; o, en su caso, el DNI y el pin de la propia aplicación. En el caso de tratarse de autenticación RADIUS, se podrá indicar (si procede) el servidor de conexión (personal de la UM o el de alumnos).

El botón que inicia la conexión es "ACEPTAR". Se hacen las comprobaciones necesarias para que se rellenen todos los campos que son necesarios.

Se incluye la posibilidad de incluir un pequeño menú a la izquierda donde se incluyan opciones como: información sobre la aplicación, problemas con ella o preguntas frecuentes, etc.

La conexión a la aplicación nos lleva al "Menú principal y mapa web".

7.2. Recomendaciones y requisitos de navegación.

En esta página se informa de los navegadores compatibles con la aplicación (cualquiera que siga los estándares HTML, CSS y WAI del W3C). También se proporciona el visualizador de documentos PDF. Además, se incluirá un enlace al "Manual de usuario" de la aplicación, y se informará sobre cómo obtener soporte técnico (http://www.um.es/atica/documentos/prototipos/normaweb/recomendaciones.php).

Figura 2. Recomendaciones de navegación

Pantalla de Recomendaciones de Navegaci贸n

El encabezado y el pie son los mismos que los de la página de control de acceso.

7.3. Menú principal y mapa web.

Esta es la primera pantalla de la aplicación, propiamente dicha. En ella aparecen el menú principal, y el mapa de la aplicación (http://www.um.es/atica/documentos/prototipos/normaweb/mapa.php).

Figura 3. Menú principal y mapa web

Pantalla con Men煤 Principal y Mapa Web

El encabezado sigue siendo igual al de la página de control de acceso.

El menú principal incluye las opciones "Inicio" y "Salir", para volver a esta pantalla o a la de control de acceso, respectivamente. Las opciones del menú incluyen textos explicativos (title), que se muestran al situar el ratón sobre las mismas.

Justo debajo de la barra de menú, aparece el título de la pantalla en cuestión.

En el cuerpo de la pantalla principal se muestra el mapa de la aplicación.

Justo encima del pie aparecen algunos iconos nuevos, como el de buscar (lupa) y el de imprimir (impresora), que pueden servir de ejemplo para su posterior uso.

El pie es el mismo usado anteriormente (ver pantalla de control de acceso).

7.4. Opción de menú principal.

Se trata de la pantalla resultante al elegir una de las opciones del menú principal, en este caso la opción "CALIDAD" (http://www.um.es/atica/documentos/prototipos/normaweb/calidad.php).

Figura 4. Opción de menú principal

Pantalla con opci贸n de men煤 principal seleccionada

Esta pantalla es igual que la anterior (Menú principal y mapa web), pero justo debajo de la barra del menú principal, aparece la barra de menú de segundo nivel correspondiente a la opción del menú principal elegida. Además, en la barra del menú principal, la opción elegida aparece resaltada en negrita y con borde (para que no sea sólo el cambio de color lo que la identifica).

En el cuerpo de la página aparece el contenido correspondiente a la opción del menú principal elegida, si es que procede.

El título de la pantalla ahora aparece debajo de la barra del menú secundario.

7.5. Opción de menú de segundo nivel.

Es la pantalla resultante de elegir una opción del menú secundario; en el ejemplo, "CONTROL VERSIONES" (http://www.um.es/atica/documentos/prototipos/normaweb/controlversiones.php).

Figura 5. Opción de menú de segundo nivel

Pantalla con opci贸n de men煤 de sgundo nivel selccionada

Como se puede observar, la pantalla resultante es exactamente igual que la anterior (Opción de menú principal), excepto que en la barra del menú secundario aparece resaltada la opción elegida (de forma similar al menú principal).

En el cuerpo aparece el contenido correspondiente a la opción de segundo nivel elegida, que podría ser un formulario pero en este caso no lo es (ver el siguiente apartado para ver el ejemplo de formulario).

7.6. Formulario.

En esta página tenemos un ejemplo de formulario, resultante de elegir una opción del menú secundario, concretamente "SUGERENCIAS" (http://www.um.es/atica/documentos/prototipos/normaweb/sugerencias.php).

Figura 6. Formulario

Pantalla con Formulario

La página es igual que la anterior, pero en el cuerpo aparece un formulario, en este caso resultado de elegir la opción "SUGERENCIAS", del menú de segundo nivel.

Centrándonos en el formulario, se observa que no hay scroll horizontal. Haremos todo lo posible por evitar también el scroll vertical. Sí evitaremos a tod a costa el scroll horizontal.

Los campos obligatorios llevan un asterisco rojo a la izquierda de la etiqueta (de forma que, por ejemplo, un lector de pantalla los leerá siempre antes que el texto de la etiqueta). Además el asterisco está marcado con énfasis. Hay una leyenda encima del pie, justo antes de la línea de iconos, que explica el significado del asterisco rojo.

Nos podemos desplazar por los campos haciendo uso del tabulador, de forma que el movimiento entre campos se produce de izquierda a derecha, y de arriba a abajo.

Todos los campos para la introducción de datos llevan su etiqueta (label); y se ha utilizado fieldset para hacer las agrupaciones.

Los botones asociados a acciones sobre el formulario aparecen debajo de la última línea de campos, a la izquierda de la pantalla (según se mira a ella). En este caso sólo podemos "ENVIAR" o "BORRAR" los datos del formulario.

Tanto esta pantalla, como todas las anteriores donde aparece el menú principal, incluyen las opciones "INICIO" (para volver a la pantalla principal) y "SALIR" (para salir de la aplicación y volver al control de acceso).

A. Estado de implantación.

A continuación se pueden consultar tres tablas con el estado de implantación de Normaweb: aplicaciones adaptadas, en proceso de adaptación, y pendientes de iniciar el proceso.

Tabla A.1. Aplicaciones adaptadas

APLICACIÓN URL
Justoi http://justoi.um.es/
Minerva Web https://pau.um.es/minerva/servlet/um.minerva.ControlInicio
PAU http://www.um.es/pau/
ERASMUS http://erasmus.um.es
ALBA https://harmonia.cpd.um.es:8033/inicio/entrada.jsp
PAIPUC http://paipuc.um.es
Automatrícula http://suma.um.es (se accede desde SUMA)
Ceuri http://ceuri.um.es
Memorias de Investigación http://memoriasinves.um.es
ORMUZ http://ormuz.um.es
PAU http://www.um.es/pau
Preinscripción https://preinscripcion.um.es
Reciclática https://dumbo.um.es/servlet/ dumbo21.reciclatica.servlet.Control?accion=GLMuestra
Factel https://telefonia.um.es
Webmail https://webmail.atica.um.es

Tabla A.2. Aplicaciones pendientes de iniciar el proceso de adaptación

APLICACIÓN URL
Papys http://www.um.es/atica/papys
Kron http://kron.um.es
Pagina https://pagina.um.es/WWW/index.htm
CURIE http://www.um.es/curie
Casiopea http://casiopea.um.es
Bolsa http://bolsa.um.es
Arcon https://habidis.cpd.um.es:8001/servlet/ um.curie.ControlCurie?opcion=menuopcion& menucodigo=55&url=%2Foferta_convenios.jsp
Estación Metereológica http://www.um.es/estacion
GENTE http://gentecodigos.um.es/pls/wwwgente/consultar.tablas
Grupos de Investigación http://www.um.es/investigacion/grupos
Guindaweb http://guindaweb.um.es
LUCI https://cadmo.cpd.um.es:8011
Matilde https://cadmo.cpd.um.es:8008/matilde
PAPYS https://cadmo.cpd.um.es:8002/papys/index.jsp
Prácticas en Empresas http://practicas.um.es
Publicaciones https://habidis.cpd.um.es:8021
Reserva Docente de ALAS https://carnesweb.um.es/pls/alainter/ alas_web.solicita_dni_acceso
Televoto http://www.um.es/investigacion/televoto

Tabla A.3. Aplicaciones en proceso de adaptación

APLICACIÓN URL
SUMA http://suma.um.es
DUMBO https://harmonia.cpd.um.es:7795/dumbo (nuevo DUMBO7 en desarrollo)
Minerva https://pau.um.es/minerva/servlet/um.minerva.ControlInicio

B. Pautas de Accesibilidad (AA) y herramientas.

La Iniciativa de Accesibilidad en la Web (WAI) del W3C se puede encontrar en "http://www.w3.org/WAI". A través de esta iniciativa, el W3C establece unas pautas de accesibilidad al contenido web, que se pueden consultar en "http://www.w3.org/TR/WAI-WEBCONTENT".

Existe una excelente traducción al castellano de las pautas de accesibilidad del W3C, en la dirección "http://www.discapnet.es/web_accesible/wcag10/WAI-WEBCONTENT-19990505_es.html". Además, en la misma web se pueden encontrar una interesante serie de documentos para el diseño accesible de contenidos en la Web ("http://www.discapnet.es/web_accesible/"). Entre los documentos citados están los siguientes (que son traducciones al castellano de los originales y oficiales del W3C):

Toda esta información puede ser realmente útil al desarrollador (y al Jefe de Proyecto) para la creación de nuevas aplicaciones web, que sigan las citadas pautas de accesibilidad.

Además, a continuación, suministramos las direcciones de algunas de las herramientas más utilizadas, en el desarrollo de aplicaciones web accesibles:

 

C. Otros enlaces sobre accesibilidad web.

Además de los ya vistos en el apéndice anterior sobre pautas de accesibilidad y herramientas, pueden resultar interesantes los siguientes enlaces:

趌tima modificaci髇 ( 23.05.2016 )
 
羠ea de Tecnolog韆s de la Informaci髇 y las Comunicaciones Aplicadas
Volver al incio del documento Volver al inicio del documento
羠ea de Tecnolog韆s de la Informaci髇 y las Comunicaciones Aplicadas