Usable y accesible

Web Usability Guidelines–Directrices de usabilidad web

2012-03-22T10:43:00.012+01:00

Artículo anterior: Qué teclas de acceso rápido (accesskey) utilizar

Última actualización: 26/03/2012

En el artículo Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística definí qué es un estándar y la diferencia entre estándares oficiales (o “de jure” o formales) y estándares “de facto” (o no formales)

En dicho artículo traté los estándares oficiales, repasando las diferentes normas ISO existentes, donde destaca la norma ISO 9241-151 que presenta una checklist de validación.

Asimismo repasé diferentes propuestas basadas en estas normas ISO que incluían formas prácticas de aplicarlas en una evaluación heurística, en especial WUEP (Web Usability Evaluation Process)

Por ello incluí la descarga de una excel con las subcaracterísticas (y descripción), atributos (y su descripción) y métricas, a modo de herramienta de ayuda, para la elaboración de una evaluación de usabilidad de una web de acuerdo a la ISO 25000 (SQUARE), según el modelo propuesto por WUEP (Web Usability Evaluation Process)

En este artículo repaso, fuera ya de los que son los estándares formales, diferentes propuestas de directrices de usabilidad web, - algunas de las cuáles se pueden considerar estándares “de facto”-, con listas de verificación (checklist) asociadas, que permitan la evaluación heurística de los sitios en base a dichas directrices.

No está de más recordar que las directrices de usabilidad no pueden considerarse nunca reglas fijas ni pueden ser aplicadas por igual en todos los sitios web, siempre habrá que tener en cuenta y reflexionar sobre el tipo de sitio, su audiencia, sus objetivos o su contexto.

He seleccionado las que me parecen más relevantes, incluyendo al final un listado con otros enlaces de interés. Os animo a que dejéis en los comentarios aquellas que no he incluido pero os parecen relevantes.

Índice

HHS Guidelines
247 directrices de usabilidad de Userfocus
Nielsen Norman Group Guidelines
Swedish National Guidelines for Public Sector Websites
SIRIUS
Australia Government Usability Checklist
Guía para el Desarrollo de Sitios Web del Gobierno de Chile
Usability Guidelines del MIT
Directrices de usabilidad para sitios web del Estado colombiano
Otros enlaces de interés

HHS Guidelines

Las "HHS Guidelines" son las directrices de diseño web y usabilidad del Gobierno de EEEUU. Fueron desarrolladas por el U.S. Department of Health and Human Services (HHS) en 2004, de ahí que se las conozca como las HHS Guidelines.

Están disponibles en formato PDF en el documento Research-Based Web Design and Usability Guidelines (PDF 20.64 MB)

Fueron realizadas y revisadas por diseñadores y expertos de usabilidad basándose en la investigación de diferentes campos (citan en concreto: cognitive psychology, computer science, human factors, technical communication y usability)

En la actualidad cuenta con 209 directrices (en la primera edición eran 187) que, tras un estudio de cardsorting, se agruparon en 18 temas:

Proceso de diseño y evaluación (11 directrices)
Optimizando la experiencia de usuario (16 directrices)
Accesibilidad (13 directrices)
Hardware y software (5 directrices)
La página de inicio (9 directrices)
Esquema de la página (layout) (13 directrices)
Navegación (12 directrices)
Desplazamiento (scrolling) y paginado (5 directrices)
Encabezados, títulos y etiquetas (8 directrices)
Enlaces (14 directrices)
Apariencia del texto (11 directrices)
Listas (9 directrices)
Controles y Widgets (25 directrices)
Gráficos, imágenes y multimedia (16 directrices)
Escribiendo contenido web (11 directrices)
Organización del contenido (9 directrices)
Búsqueda (9 directrices)
Test de usabilidad (13 directrices)

Se puede consultar de forma individual cada uno de estos capítulos en la página Guidelines de la web usability.gov Esta web del Gobierno de EEUU recoge la metodología que se debe aplicar en la construcción de un sitio web bajo una metodología de Diseño Centrado en el Usuario, dentro de la cuál cumplir con estas directrices sólo es un paso más. Traté en profundidad esta web y su metodología propuesta en el artículo La usabilidad como metodología para el desarrollo de una aplicación

Dentro de cada capítulo las directrices están ordenadas de más a menos importantes. La estructura de cada directriz es la siguiente:

Como se aprecia consta de:

Numeración y título de la directriz ("1:1 Provide Useful Content")
Guideline, título extendido de la directriz;
Comments, descripción de la directriz indicando en qué consiste y por qué hay que cumplirla;
Sources, referencias sobre esta directriz;
Ejemplos, solo disponibles en algunas directrices.
Relativa Importance, importancia de la directriz que están clasificadas de 1 a 5 (5 las más importantes, 1 las menos importantes) La clasificación fue llevada a cabo por una encuesta a numerosos expertos en usabilidad.
Strength of Evidence, indica la "medida de confianza" clasificada de 1 a 5 (5 las que mayor nivel de confianza ofrecen y 1 las que menos) La medida de confianza está basada en la calificación dada por numerosos expertos en usabilidad (y en la que, según se indica, hubo alto grado de coincidencia) que buscaron evidencias de esa directriz en investigaciones, estudios, resultados de experimentos, etc.

La medida de confianza se define de la siguiente manera:

5 – Strong Research Support
- Cumulative and compelling, supporting research-based evidence
- At least one formal, rigorous study with contextual validity
- No known conflicting research-based findings
- Expert opinion agrees with the research
4 – Moderate Research Support
- Cumulative research-based evidence
- There may or may not be conflicting research-based findings
- Expert opinion
- Tends to agree with the research, and
- A consensus seems to be building
3 – Weak Research Support
- Limited research-based evidence
- Conflicting research-based findings may exist
- There is mixed agreement of expert opinions
2 – Strong Expert Opinion Support
- No research-based evidence
- Experts tend to agree, although there may not be a consensus
- Multiple supporting expert opinions in textbooks, style guides, etc.
- Generally accepted as a ’best practice’ or reflects ’state of practice’
1 – Weak Expert Opinion Support
- No research-based evidence
- Limited or conflicting expert opinion

En el apéndice de la guía encontramos lo que puede servirnos de checklist (PDF 20.64 MB), que es el listado de todas las directrices agrupadas por su importancia.

Se puede consultar una comparativa entre la ISO 9241-151 y las HHS Guidelines en BEVAN, N. , SPINHOF, L. (2007): "Are guidelines and standards for web usability comprehensive?" (PDF)

247 directrices de usabilidad web de Userfocus

Userfocus propone 247 directrices de usabilidad que distribuye en 9 heurísticos:

Usabilidad de la página de inicio (20 directrices)
Orientado a tareas (44 directrices)
Navegación y Arquitectura de Información (29 directrices)
Formularios y entrada de datos (23 directrices)
Confianza y credibilidad (13 directrices)
Escritura y calidad de los contenidos (23 directrices)
Esquema de la página (layout) y diseño visual (38 directrices)
Usabilidad en la búsqueda (20 directrices)
Ayuda, feedback y tolerancia a errores (37 directrices)

Una gran ventaja es que ofrece gratuitamente una excel de trabajo con las 247 directrices (traducida al español) que facilita la valoración y la inclusión de comentarios.

Nielsen Norman Group Guidelines

Posiblemente los 10 heurísticos de Jakob Nielsen sean los más conocidos:

Visibilidad del estado del sistema.
Utilizar el lenguaje de los usuarios.
Control y libertad para el usuario.
Consistencia y estándares.
Prevención de errores.
Minimizar la carga de la memoria del usuario.
Flexibilidad y eficiencia de uso.
Los diálogos estéticos y diseño minimalista.
Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores.
Ayuda y documentación.

Según el propio Jakob Nielsen dispone de 2397 directrices de usabilidad repartidas en múltiples informes que lista en "Publications" de nngroup.com

Swedish National Guidelines for Public Sector Websites

La guía del Gobierno de Suecia Swedish National Guidelines for Public Sector Websites es especialmente completa. Las directrices están agrupadas por capítulos, dentro de los cuales se listan los heurísticos y las directrices asociadas.

Aunque no incluye checklists asociadas, las directrices están muy bien explicadas y tienen asociadas un nivel de prioridad (1, 2 y 3, siendo las de nivel 1 las más críticas)

En el capítulo "3. Website standards" se incluyen 58 directrices agrupadas en:

Estructura y navegación (9 directrices)
Color, contraste y tipografía (3 directrices)
Diseño (22 directrices)
Tablas de datos (5 directrices)
Formularios (11 directrices)
Aplicaciones web (3 directrices)
Manejo de errores (3 directrices)
Eventos del sistema (2 directrices)

En el capítulo Contenidos y servicios se incluyen 29 directrices agrupadas en:

Acerca de la autoridad (5 directrices)
Información básica (8 directrices)
Otros lenguajes (3 directrices)
Búsqueda (4 directrices)
Distribución de servicios y contenidos del sitio web (4 directrices)
Participación y transparencia (5 directrices)

En el capítulo Actualización del sitio web (o mantener el sitio al día) se incluyen 43 directrices agrupadas en:

Administración (1 directrices)
Seguimiento del uso y el contenido (6 directrices)
Información de "emergencia" en el sitio (6 directrices)
Escribir para la web (9 directrices)
Formato de la web (marcado HTML) (9 directrices)
Imágenes y gráficos (4 directrices)
Enlaces y documentos (8 directrices)

Hay otros capítulos como "Servicio mejor y más eficiente", "Proceso de desarrollo", "Contenido para dispositivos móviles", "Herramientas de publicación" o "Productos de apoyo para usar el sitio web".

Sirius

La propuesta de Mª del Carmen Suarez en su tesis Sirius: Sistema de Evaluación de la Usabilidad Web Orientado al Usuario y basado en la Determinación de Tareas Críticas (PDF, 3.39 MB) son 83 directrices dividas en:

Aspectos generales (10 directrices)
Identidad e información (7 directrices)
Estructura y navegación (14 directrices)
Rotulado (6 directrices)
Layout de la página (10 directrices)
Entendibilidad y facilidad en la interacción (7 directrices)
Control y retroalimentación (10 directrices)
Elementos multimedia (6 directrices)
Búsqueda (8 directrices)
Ayuda (5 directrices)

Hablé de su sistema en profundidad en Sirius. Nuevo sistema para la evaluación de la usabilidad web. Su método presenta numerosas ventajas, por ejemplo que la relevancia de los errores tienen en cuenta el tipo de sitio evaluado.

Permite elaborar una herramienta de evaluación que dé soporte al sistema planteado y facilite la validación empírica de la propuesta de evaluación. Proporcioné esta herramienta en formato excel: Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3 (XLSX)

Australia Government Usability Checklist

La Australia Government Usability Checklist es la más sencilla de todas las vistas hasta ahora. Está incluida dentro del conjunto de publicaciones "User Profiling and Testing Tollkit" del Gobierno de Australia.

Son 43 directrices clasificadas en 6 temas:

Arquitectura y navegación
Layout y diseño
Contenidos
Formularios
Plataforma e implementación
Accesibilidad (prioridad 1)

Guía para el Desarrollo de Sitios Web del Gobierno de Chile

Al igual que la del Gobierno de Australia, presenta una checklist de usabilidad bastante reducida.

Son 30 directrices divididas en los siguientes heurísticos:

Identidad corporativa
Utilidad del sitio web
Navegación
Visibilidad del estado del sistema
Consistencia y cumplimiento de estándares
Atención a errores
Estética y diseño
Ayuda a errores
Retroalimentacion (feedback)

Usability Guidelines del MIT (Massachusetts Institute of Technology)

En la web IST (Information Services & Technology) del MIT (Massachusetts Institute of Technology) encontramos el apartado "Usability at MIT" con numerosos recursos de interés.

Uno de estos recursos son las "Usability Guidelines", 62 directrices agrupadas en:

Navegación (5 directrices)
Funcionalidad (4 directrices)
Control del usuario (5 directrices)
Lenguaje y contenido (7 directrices)
Ayuda en línea y guías de usuario (2 directrices)
Feedback (7 directrices)
Accesibilidad (14 directrices)
Consistencia (2 directrices)
Prevención y correción de errores (8 directrices)
Claridad arquitectual y visual (8 directrices)

Directrices de usabilidad para sitios web del Estado colombiano

En 2010 M. Carvajal y J. Saab (2010) publicaban un documento muy interesante: “Documento de análisis de prácticas y recomendaciones mundiales en Usabilidad (PDF)” para el Ministerio de Tecnologías de la Información y las Comunicaciones de la República de Colombia. En él se repasan diferentes propuestas de diferentes países para concluir cuál sería la mejor forma de redactar unas recomendaciones de usabilidad para el Gobierno de Colombia.

Actualmente encontramos una versión 1.0.4 candidata a oficial (del 26 de agosto de 2010) en Directrices de usabilidad para sitios web del Estado colombiano (PDF, 4.1 MB).

Las directrices están organizadas así:

1. Arquitectura de información
- 1.1 Objetivos del portal web
- 1.2 Personajes y escenarios
- 1.3 Necesidades de los usuarios
- 1.4 Evaluación constante
- 1.5 Evaluación de la Arquitectura de Información
- 1.6 Navegación global consistente
- 1.7 Navegación de contexto
- 1.8 Ruta de migas
- 1.9 URL limpios
- 1.10 Ubicación del usuario
- 1.11 Tagline
- 1.12 Enlaces bien formulados
- 1.13 Memoria a corto plazo
2. Diseño de Interfaz de Usuario
- 2.1 Ubicación del logotipo
- 2.2 Diseño ordenado y limpio
- 2.3 Interfaces en movimiento
- 2.4 Contenido que parece publicidad
- 2.5 Contraste en brillo y color
- 2.6 Información transmitida a través de color
- 2.7 Justificación del texto
- 2.8 Ancho del cuerpo de texto
- 2.9 Fuentes tipográficas comunes
- 2.10 Texto subrayado
- 2.11 Uso adecuado del espacio en blanco
- 2.12 Desplazamiento horizontal
- 2.13 Vínculo a la página de inicio
- 2.14 Tareas clave en la página de inicio
- 2.15 Contenidos de ejemplo en la página de inicio
- 2.16 Hojas de estilo para diferentes formatos
- 2.17 Independencia de navegador
- 2.18 Vínculos visitados
- 2.19 Calidad del código
3. Diseño de Interacción
- 3.1 Campos obligatorios
- 3.2 Asociación de etiquetas y campos
- 3.3 Validación dinámica de datos
- 3.4 Error de página no encontrada
- 3.5 Ventanas emergentes
- 3.6 Botón atrás
- 3.7 Tiempo de carga de las páginas
- 3.8 Ejemplos en los campos de formulario
- 3.9 Páginas de confirmación

4. Búsqueda
- 4.1 Motor de búsqueda y ubicación
- 4.2 Búsquedas con términos familiares y errores de digitación
- 4.3 Sugerencias de búsqueda
- 4.4 Ubicación en los 10 primeros resultados

5. Pruebas de usabilidad
- 5.1 Evaluación heurística
- 5.2 Test de Usuario
- 5.3 Diseño y evaluación iterativos

6. Contenido
- 6.1 Contenido útil
- 6.2 Pirámide invertida
- 6.3 Títulos y encabezados
- 6.4 Listas
- 6.5 Escaneado de contenido
- 6.6 Vínculos rotos
- 6.7 Contenido encontrable

Otro documento recomendable de M. Carvajal es La Guía Web 1.0 de Proexport (PDF) donde se aplican las directrices.

Otros enlaces de interés

En Index of Government Guidelines for Web Sites de Peter Krantz se puede encontrar las guías web de los diferentes gobiernos en el mundo. Algunas de interés que no he nombrado son:

Las Kwaliteitsmodel Webrichtlijnen (The Web Guidelines quality model) son las las directrices del Gobierno de Holanda. Están centradas en la accesibilidad y el uso adecuado del estándar HTML
Las Elmer 2: User interface guidelines for governmental forms on the Internet (PDF), es una guía del Gobierno de Noruega con una checklist muy interesante pero está centrada exclusivamente en los formularios web.
Tasmanian Government Web Usability Guidelines 2009 recoge diversos documentos pero no tienen directrices asociadas como hemos podido ver en otros casos.

El artículo "Official Usability, User Experience & User Interface Guidelines From Companies" de usabilitygeek.com, repasa las diferentes guías de directrices de compañías concretas (Adobe, Apple, IBM, Microsoft, etc.) aunque la que más me gusta es la de SUN, pero la de 1995: Sun Guide to Web Style

¿Añadirías alguna más?

Artículos anteriores

Qué teclas de acceso rápido (accesskey) utilizar

2012-03-21T13:53:00.005+01:00

Artículo anterior:
Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

El punto de verificación 9.5 de las WCAG 1.0 de nivel AAA indica Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario. [Prioridad 3] Por ejemplo, en HTML, especifique los atajos a través del atributo "accesskey"

En las WCAG 2.0 deja de ser un criterio de conformidad y pasa a ser una técnica adicional del criterio 2.4.1 de nivel A Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web".

Aunque no es obligatorio, yo sí que recomiendo incluir atajos de teclado. La duda que surge entonces es ¿qué accesskey incluir de forma que no entren en conflicto con las teclas de atajo de los menús del navegador? ¿hay algún estándar?

UK Government accesskeys standard

El Gobierno del Reino Unido estableció en 2002 las siguientes teclas de acceso rápido para sus portales web:

S - Skip navigation
1 - Home page
2 - What’s new
3 - Site map
4 - Search
5 - Frequently Asked Questions (FAQ)
6 - Help
7 - Complaints procedure
8 - Terms and conditions
9 - Feedback form
0 - Access key details

Consultar en: Uk Guidelines for government websites (PDF) (capítulo 2 "Content of websites". Apartado 2.4 "Building in universal accessibility + checklist". Subapartado 2.4.4 "UK Government accesskeys standard".

Estas accesskey se siguen utilizando como se observa por ejemplo en la web Directgov (UK government's digital service for people in England and Wales)

Swedish Government accesskeys standard

En Suecia, en las Swedish National Guidelines for Public Sector Websites (2008) (PDF), que establecen las normas a seguir por los portales de la Administración Pública, se definen también las teclas de acceso rápido que se han de utilizar.

Según se indica, están basadas en las del Reino Unido (The choices of access keys are inspired by the UK Government access keys):

S - Skip navigation, go directly to text content
0 - “About the website”, accessibility information. Provided details on access keys
1 - “Home” page
2 - News. Collection of news
3 - Content outline. A site map, or perhaps A-Z
4 - Search. Should be connected to the search field that searches the entire website
5 - Frequently Asked Questions (FAQ)
6 - Help. For example, about a specific service.
7 - Contact us. Page with contact details to important functions within the government agency.
8 - Legal information. Page that describe the website’s privacy policy and how legal information such as cookies are handled.

Según se especifica, en la página "About the website" se deben indicar las teclas utilizadas y explicar su uso en diferentes navegadores y sistemas operativos.

Ninguna de estas teclas colisiona con los atajos de menú de los navegadores. La "S" no genera conflicto en los navegadores en castellano, aunque indican que en la versión sueca de IE6 sí colisiona con un menú.

Mi recomendación es que no reinventemos la rueda y usemos las accesskey propuestas por los gobiernos de Reino Unido y Suecia. Tienen la ventaja de no colisionar con el navegador y que son lo más cercano a un estándar "de facto" que existe, de modo que, si se generalizan, el usuario no deberá reaprenderlas de una web a otra.

Así que os animo a aplicar y difundir este estándar de accesskey.

Un ejemplo de uso y adaptación de estas accesskey lo implementamos en la web de la Clínica Universidad de Navarra.

Otros enlaces de interés

Artículos anteriores

Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

2012-03-15T15:01:00.167+01:00

Novedad 19/3/2012

Descarga de excel para ayudar en una evaluación de usabilidad según WUEP (Web Usability Evaluation Process), proceso explicado en el artículo y que se basa en la ISO 25000 (SQUARE).

Ver WUEP (Web Usability Evaluation Process)

26/03/2012: ampliado el contenido sobre la ISO 9241-151

Índice

Qué es un estándar
Tipos de estándares
Estándares formales de usabilidad
Aplicación práctica de los estándares formales en la evaluación heurística de una web
Qué es un estándar
“Estándar” es definido por la ISO (Organización Internacional de Estandarización) como:
documento establecido por consenso y aprobado por una institución reconocida, que prevé, para uso común y repetido, reglas, directrices y características para actividades o sus resultados, encaminada a la consecución del grado óptimo de definición en un contexto dado. Nota: las normas deben basarse en los resultados consolidados de la ciencia, la tecnología y la experiencia, y tener por finalidad promover beneficios óptimos.
[ISO/IEC Guide 2:2004, definición 3.2]
Tipos de estándares
Existen tres tipos de estándares:
- los oficiales o “de jure”. Los estándares oficiales son aquellos que han sido aprobados y sancionados por un organismo oficial de estandarización.
  Como organismos oficiales de estandarización podemos destacar:
  - En España, el organismo nacional de normalización es AENOR (Asociación Española de Normalización y Certificación) que elabora normas técnicas españolas (UNE)
  - A nivel europeo está el Comité Europeo de Normalización (CEN)
  - A nivel internacional la Organización Internacional de Estandarización (ISO) compuesta por representantes de los organismos de normalización (ON's) nacionales, que produce normas internacionales industriales y comerciales. Dichas normas se conocen como normas ISO
  Los estándares oficiales son a veces de obligado cumplimiento. De hecho en España no se puede hacer referencia en la legislación a estándares que no provengan de un organismo oficial de estandarización. Por ejemplo en España es obligatorio por ley que determinados tipos de sitios web cumplan con la Norma UNE 139803 que asegure su accesibilidad.
- los “de facto”. Son aquellos que son promulgados por comités guiados por una entidad, organismo o compañía, se usan por voluntad propia o conveniencia y tienen una amplia aceptación, aunque no hayan sido sancionados por un organismo de estandarización.
  El caso más claro es el W3C (World Wide Web Consortium) que crea estándares ampliamente aceptados y que a veces pasan a ser reconocidos como estándares oficiales (por ejemplo la Norma UNE 139803 se basa en las WCAG del W3C; y hay muchos países que en su legislación establecen que los sitios web cumplan con las WCAG)
- Estándares propietarios de una corporación o entidad.
En el caso de la accesibilidad web son muy conocidos los estándares existentes, posiblemente porque son de obligado cumplimiento en muchos países.
Sin embargo los estándares de usabilidad no son tan conocidos. En el siguiente apartado se explica de manera sencilla y comprensible cuáles son los estándares oficiales de usabilidad. En el último apartado se abordará cómo se pueden aplicar en la práctica dichos estándares para realizar evaluaciones heurísticas de usabilidad.
Estándares formales de usabilidad
Orientados al proceso: ISO 9241 e ISO 13407

ISO 9241 Ergonomics of Human System Interaction
Está compuesta por 17 partes. La 1 y 2 es una introducción y guías para el empleo del estándar. De la 3 a la 9 tratan los requisitos y guías relacionadas con el hardware que impactan en el funcionamiento del software. De la 10 a la 11 se centran en los aspectos del software.
En realidad la norma se llamaba Ergonomic requirements for office work with visual display terminals (VDTs) pero en 2006 se le simplificó el nombre; y además se renumeraron sus partes para poder cubrir más temas como la interacción táctil (ISO 9241-920:2009) , la interacción con formularios (ISO 9241-143:2012) o interfaces web (ISO 9241-151:2008)
La ISO 9241-11:1998 “Guidance on usability”, define la usabilidad como:
La medida con la que un producto se puede usar por usuarios determinados para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso concreto.
Por tanto, los tres factores, los tres atributos de calidad son:
- Efectividad: exactitud e integridad con la que los usuarios alcanzan los objetivos especificados, y por tanto implica la facilidad de aprendizaje, la ausencia de errores del sistema o la facilidad del mismo para ser recordado. Las métricas definidas son:
  - Número de tareas importantes realizadas
  - Porcentaje de funciones relevantes utilizadas
  - Porcentaje de tareas completadas con éxito al primer intento
  - Número de referencias a la documentación
  - Número de llamadas para soporte
  - Número de accesos a la ayuda
  - Número de funciones aprendidas
  - Porcentaje de usuarios capaces de aprender sus características
  - Porcentaje de errores corregidos o reportados por el sistema
  - Número de errores de los usuarios tolerados
  - Porcentaje de palabras leídas correctamente a una distancia de visualización normal
- Eficiencia: recursos empleados (esfuerzo, tiempo, etc.) en relación con la exactitud e integridad con la que los usuarios alcanzan los objetivos especificados. Las métricas definidas son:
  - Eficiencia relativa en comparación con un usuario experto
  - Tiempo empleado en el primer intento
  - Eficiencia relativa en el primer intento
  - Tiempo empleado en reaprender funciones
  - Número de errores persistentes
  - Tiempo productivo
  - Tiempo para aprender características
  - Tiempo para reaprender características
  - Eficiencia relativa durante el aprendizaje
  - Tiempo empleado en la corrección de errores
- Satisfacción: un factor subjetivo que implica una actitud positiva en el uso del producto. Las métricas definidas son:
  - Calificación (por parte del usuario) de su satisfacción con las características importantes
  - Tasa de uso voluntario del producto
  - Frecuencia de reutilización del producto
  - Calificación (por parte del usuario) de la facilidad de aprendizaje
  - Calificación (por parte del usuario) del tratamiento de errores
La ISO 9241‐11 recomienda un enfoque basado en procesos para evaluar la usabilidad, a través del Diseño Centrado en el Usuario (DCU). Por ello la ISO 9241 debe aplicarse en conjunto con la ISO 13407.

La ISO 9241-151:2008 “Guidance on World Wide Web user interfaces” referencia a la 9241-11 para la evaluación de criterios y a la ISO 13407 como guía de Diseño Centrado en el Usuario, puesto que señala que el diseño de interfaces web debe seguir un proceso de DCU.
Se pueden consultar comparativas de la 9241-151 con HHS Guidelines [USABILITY.GOB] en [BEVAN, 2005] y actualizado en [BEVAN, 2007]
Dentro de la ISO 9241-151 podemos destacar las siguientes directrices (viene cada una explicada y con ejemplos, y se puede encontrar una checklist para la evaluación al final del documento de la ISO):
- 6. High-level design decisions and design strategy (11 directrices evaluables)
- 7. Content design
  - 7.1 Conceptual content model (5 directrices evaluables)
  - 7.2 Content objects and functionality (19 directrices evaluables, 5 de las cuales referentes al 7.2.8 Privacy and business policies; y 7 al punto 7.2.9 Indivudualisation and user adaptation)
- 8. Navigation and search
  - 8.1 General
  - 8.2 General guidance on navigation (5 directrices evaluables)
  - 8.3 Navigation structure (11 directrices evaluables, varias de ellas relativas a Splash screens)
  - 8.4 Navigation components (16 directrices evaluables)
  - 8.5 Search (22 directrices evaluables)
- 9. Content presentation
  - 9.1 General
  - 9.2 Observing principles of human perception (1 directrices evaluables)
  - 9.3 Page design issues functions (17 directrices evaluables)
  - 9.4 Link design (15 directrices evaluables)
  - 9.5 Interaction objects (3 directrices evaluables)
  - 9.6 Text design (6 directrices evaluables)
- 10. General design aspects
  - 10.1 Designing for cultural diversity and multilingual use (5 directrices evaluables)
  - 10.2 Providing help (1 directrices evaluable)
  - 10.3 Making Web user interfaces error-tolerant(2 directrices evaluables)
  - 10.4 URL names (1 directrices evaluable)
  - 10.5 Acceptable download times (1 directrices evaluable)
  - 10.6 Using generally accepted technologies and standards(1 directrices evaluable)
  - 10.7 Supporting common technologies(1 directrices evaluable)
  - 10.8 Making Web user interfaces robust(1 directrices evaluable)
  - 10.9 Designing for input device independence(1 directrices evaluable)
  - 10.10 Making the user interface of embedded objects usable and accessible
ISO 13407:1999. Human centred design processes for interactive systems
La ISO 13407:1999 ha sido revisada por la ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems.
La ISO 13407 proporciona una guía para alcanzar la calidad en el uso mediante la incorporación de actividades de naturaleza iterativa involucradas en el Diseño Centrado en el Usuario (DCU).
El Diseño Centrado en el Usuario (DCU) lo describe como una actividad multidisciplinar, que incluye factores humanos y conocimientos y técnicas de ergonomía con el objetico de mejorar la efectividad y eficiencia, las condiciones de trabajo y contrarrestar los posibles efectos adversos de su uso.
Describe los cuatro principios del Diseño Centrado en el Usuario:
- Involucrar activamente a los usuarios
- Asignación adecuada de funciones al sistema y el usuario
- Soluciones de diseño iterativas
- Diseño multidisciplinar
Y las cuatro actividades del Diseño Centrado en el Usuario:
- Entender y especificar el contexto de uso
- Especificar los requisitos del usuario y de la organización
- Producir más de una solución de diseño candidata
- Contrastar los diseños con los requisitos
Figura 1. Imagen tomada de [MONTERO, 2008, pág.6]
Como he dicho, la ISO 13407 ha sido revisada por la ISO 9241-210:2010 Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems que describe seis principios clave que caracterizan al Diseño Centrado en el Usuario [TRAVIS, 2011]:
- El diseño está basado en una comprensión explícita de usuarios, tareas y entornos.
- Los usuarios están involucrados durante el diseño y el desarrollo.
- El diseño está dirigido y refinado por evaluaciones centradas en usuarios.
- El proceso es iterativo.
- El diseño está dirigido a toda la experiencia del usuario.
- El equipo de diseño incluye habilidades y perspectivas multidisciplinares
Orientados al producto: ISO 9126 e ISO 14598
ISO 9126 Software engineering — Product quality
Es un estándar para evaluar la calidad del software. Esta dividida en cuatro partes:
- ISO/IEC 9126‐1: 2001 : presenta el modelo de calidad que clasifica la calidad del software en un conjunto estructurado de características: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
  Define la usabilidad como la capacidad que tiene un producto software para ser entendido, aprendido, operable, atractivo para el usuario y conforme a estándares/guías, cuando es utilizado bajo unas condiciones específicas.
  Por ello la usabilidad se divide en las siguientes subcaracterísticas:
  - Fácil de aprender: capacidad para ser aprendido en su manejo
  - Fácil de entender: capacidad del producto de ser entendido por nuevos usuarios en términos de su propósito y cómo puede ser usado en tareas específicas.
  - Fácil de operar: capacidad del producto de ser operado y controlado en cualquier momento.
  - Atractivo: capacidad del producto de ser atractivo para sus usuarios.
  - Conformidad: capacidad del producto para adherirse a estándares, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.
  Figura 2. Modelo de calidad ISO/IEC 9126-1
- ISO/IEC 9126‐2:2003 : describe las métricas externas que se pueden utilizar para evaluar el comportamiento del software cuando es operado por el usuario.
- ISO/IEC 9126‐3:2003 : describe las métricas internas que se pueden utilizar para describir propiedades estáticas de la interfaz, que puede ser evaluadas por la inspección sin poner en funcionamiento el software.
- ISO/IEC 9126‐4:2004 : describe las métricas de calidad que se pueden utilizar para evaluar el efecto del producto software cuando son operados por el usuario en determinados contextos de uso. Las métricas definidas son:
  - Efectividad (el método de aplicación definido para las tres es el test con usuarios)
    - Efectividad de las tareas: ¿qué proporción de objetivos de las tareas son logrados correctamente?
    - Tareas completadas, ¿qué proporción de tareas son completadas?
    - Frecuencia de los errores
  - Productividad (el método de aplicación definido para todas es el test con usuarios)
    - Tiempo de las tareas, ¿cuánto tiempo lleva completar una tarea?
    - Efectividad de las tareas, ¿cuán eficientes son los usuarios?
    - Productividad económica, ¿cómo de rentable es el usuario?
    - Porcentaje de producción, ¿qué proporción de tiempo dedica el usuario a acciones productivas?
    - Eficiencia relativa de los usuarios, ¿cómo de eficiente es el usuario comparado con un experto?
  - Seguridad (el método de aplicación definido para todos es el uso de estadísticas)
    - Salud y seguridad del usuario, ¿cuál es la frecuencia de problemas de salud entre usuarios del producto?
    - Seguridad de las personas afectadas por el uso del sistema, ¿cuál es la frecuencia de peligro para las personas afectadas por el uso del sistema?
    - Daños ergonómicos, ¿cuál es la frecuencia de daños ergonómicos?
    - Daños del software, ¿cuál es la frecuencia de la corrupción del software?
  - Satisfacción
    - Escala de satisfacción, ¿cómo de satisfecho está el usuario?
    - Cuestionario de satisfacción, ¿cómo de satisfecho esta el usuario con características específicas del software?
    - Uso discrecional, ¿qué proporción de potenciales usuarios eligen el uso del sistema? El método de aplicación definido es la observación del uso.
Puesto que la ISO 9126 se limita a la especificación de un modelo de calidad general, esta se debe aplicar en conjunto con la ISO 14598.
ISO 14598 Information technology — Software product evaluation
La ISO 14598 es un estándar que proporciona un marco de trabajo para evaluar la calidad de todo tipo de producto software e indica los requisitos para los métodos de medición y el proceso de evaluación. Consta de seis partes:
- ISO/IEC 14598‐1: 1999 : provee una visión general de las otras cinco partes y explica la relación entre la evaluación del producto software y el modelo de calidad definido en la ISO/IEC 9126
  Figura 3. Imagen de [Férnandez-Martinez, 2009]
- ISO/IEC 14598‐2: 2000 : contiene requisitos y guías para las funciones de soporte tales como la planificación y gestión de la evaluación del producto del software.
- ISO/IEC 14598‐3: 2000 : provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo en paralelo con el desarrollo por parte del desarrollador.
- ISO/IEC 14598‐4:1999 : provee los requisitos y guías para que la evaluación del producto software sea llevada a cabo en función a los compradores que planean adquirir o reutilizar un producto de software existente o predesarrollado.
- ISO/IEC 14598‐5: 1998 : provee los requisitos y guías para la evaluación del producto software cuando la evaluación es llevada a cabo por evaluadores independientes.
- ISO/IEC 14598‐6:2001 : provee las guías para la documentación del módulo de evaluación.
Ventajas y desventajas de la definición de usabilidad como proceso y como producto
[Férnandez-Martinez, 2009] explica las ventajas y desventajas de la definición de la usabilidad como proceso o como producto vistas en el conjunto de normas anteriores:
Ventajas de la definición usabilidad como proceso:
- Se identifican aspectos de usabilidad y componentes del contexto de uso que deben tenerse en cuenta en las fases de especificación de requisitos, diseño y evaluación de usabilidad.
- El rendimiento y la satisfacción del usuario proporcionan medidas directas de usabilidad en un contexto específico.
- Las medidas obtenidas proporcionan una base para comparar la usabilidad de varios diseños en un mismo contexto.
Desventajas de la definición usabilidad como proceso:
- La usabilidad está estrictamente tratada desde una perspectiva de proceso, no centrada en el producto.
- No tiene en cuenta la característica de “facilidad de aprendizaje”, siendo esta recomendada por otros estándares y expertos en usabilidad.
- No tiene en cuenta aspectos de seguridad, considerados importantes por expertos del dominio.
Las ventajas de la definición de usabilidad como producto:
- Existe un marco claramente definido y acordado en el modelo, que aclara la
- Definición de usabilidad, y propone métricas para proporcionar evidencia objetiva de los logros.
- Se puede utilizar como una referencia para los acuerdos contractuales entre un comprador y un proveedor de software, pudiendo ser utilizados además, para eliminar una serie de malentendidos entre el comprador y el proveedor.
- Se propone un proceso de evaluación que puede ser adaptado a compradores, desarrolladores y evaluadores externos.
Desventajas de la definición de usabilidad como producto:
- El conjunto de métricas se proporciona para sub‐características que a su vez engloban conceptos difícilmente medibles si no se descomponen en atributos
- Existe superposición de conceptos, al definir usabilidad como una característica de calidad interna‐externa, y llamar calidad en uso a otras características también vinculadas a la usabilidad.
- El tener por separado dos normas que se aplican conjuntamente produce inconsistencias en los ciclos de vida de ambas dificultando su uso.
ISO 25000 (SQUARE): unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598
La ISO 25000:2005 se conoce como SQUARE (Software Quality Requirement Evaluation) y básicamente se trata de una unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598.
Su objetivo principal es guiar el desarrollo de los productos de software con la especificación y evaluación de requisitos de calidad.
Figura 4. Imagen de [ISO25000.com]
La norma está formada por las siguientes divisiones [ISO25000.com, b]:
- División de gestión de calidad (ISO/IEC 2500n): los estándares que forman esta división definen todos los modelos comunes, términos y referencias a los que se alude en las demás divisiones de SQuaRE.
- División del modelo de calidad (ISO/IEC 25001n): el estándar que conforma esta división presenta un modelo de calidad detallado, incluyendo características para la calidad interna, externa y en uso.
- División de mediciones de calidad (ISO/IEC 25002n): los estándares pertenecientes a esta división incluyen un modelo de referencia de calidad del producto software, definiciones matemáticas de las métricas de calidad y una guía práctica para su aplicación. Presenta aplicaciones de métricas para la calidad de software interna, externa y en uso.
- División de requisitos de calidad (ISO/IEC 25003n): los estándares que forman parte de esta división ayudan a especificar los requisitos de calidad. Estos requisitos pueden ser usados en el proceso de especificación de requisitos de calidad para un producto software que va a ser desarrollado ó como entrada para un proceso de evaluación.
- División de evaluación de la calidad (ISO/IEC 25004n): estos estándares proporcionan requisitos, recomendaciones y guías para la evaluación de un producto software, tanto si la llevan a cabo evaluadores, como clientes o desarrolladores.
En el modelo de calidad hay tres vistas del modelo según el contexto: modelo de calidad de software, modelo de calidad de datos y modelo de calidad en uso, que puede tener distintas vistas según la parte beneficiaria que consideremos (usuario final, organización y soporte técnico)
Considerando la vista del usuario final tendríamos una definición de usabilidad más cercana a la planteada en la ISO 9241‐11.
Figura 5. Imagen [Férnandez-Martinez, 2009]
En el modelo de calidad de software la usabilidad se mantiene como una característica más del producto, pero que se llama operabilidad, y tiene alguna diferencia respecto a la ISO 9126, siendo sus subcaracterísticas:
- Fácil de aprender: capacidad para ser aprendido en su manejo
- Fácil de entender: capacidad del producto de ser entendida por nuevos usuarios en términos de su propósito y cómo puede ser usado en tareas específicas.
- Fácil de usar: capacidad del producto de ser operado y controlado en cualquier momento.
- Atractivo: capacidad del producto de ser atractivo para sus usuarios.
- Conformidad: capacidad del producto para adherirse a estándares, convenciones, guías de estilo o regulaciones relacionadas con la usabilidad.
- Facilidad de ayuda: hace referencia al grado con el que el producto ofrece ayuda a los usuarios cuando la necesitan, algo que en la ISO 9126 se consideraba implícita en la facilidad de aprender.
- Accesibilidad técnica: hace referencia a cómo el producto software puede ser usado por personas con discapacidad.
Tanto [Férnandez-Martinez, 2009, pp. 48 y ss] como [RUIZ MORILLA, 2009] comparan y enumeran las ventajas y desventajas de la ISO 25000 frente a sus predecesoras ISO/IEC 9126 y ISO/IEC 14598.
Aplicación práctica de los estándares formales en la evaluación heurística de la web
Hemos visto que la ISO 9126 es un estándar oficial de usabilidad orientado al producto que ha sido revisado en la ISO 25000.
Por otra parte, hemos visto que en estas normas se definen una serie de características y subcaracterísticas de la usabilidad.
¿Cómo podemos aplicarlo de forma práctica en la evaluación heurística de una web?
Una buena respuesta es mediante WUEP (Web Usability Evaluation Process), la tesina de Adrián Fernández Martínez [FERNANDEZ-MARTINEZ, 2009]
WUEP (Web Usability Evaluation Process)
La WUEP define un proceso genérico de usabilidad para metodologías de desarrollo Web basadas en modelos. Presenta una guía detallada para realizar evaluaciones de usabilidad integrando todos los atributos de usabilidad posibles desde la perspectiva del concepto de usabilidad que ofrece la ISO 25000 (SQUARE)
El modelo de usabilidad web tiene en cuenta la división en subcaracterísticas y el modelo de calidad propuesto por SQuaRE. Como están subcaracterísticas son muy genéricas y están a un alto nivel de abstracción, descompone dichas subcaracterísticas en atributos cercanos al dominio Web, intentando que las definiciones de las atributos se solapen lo mínimo posible entre ellas, con el objetivo de obtener un modelo de usabilidad lo más amplio posible centrado en el ámbito de las aplicaciones Web.
En esa extensión del modelo hacia productos Web se tienen en cuenta los criterios ergonómicos de [BASTIEN y SCAPIN, 1993], las pautas de usabilidad del Gobierno de EEUU [USABILITY.GOB] (conocidas como las HHS Guidelines), y otras métricas generalmente aceptadas con el objetivo de proveer un conjunto de métricas genéricas que puedan ser operacionalizadas en distintos niveles de abstracción y en distintos métodos de desarrollo Web.
Cada métrica tiene asociada un único atributo, pudiendo pertenecer este a cualquier vista del modelo, con el objetivo de descubrir problemas de usabilidad en base a los valores obtenidos de la métrica, pudiendo además cuantificar cómo dicho atributo afecta al nivel de usabilidad de la aplicación Web.
En este modelo hay dos tipos de evaluaciones uno sería el equivalente a una evaluación heurística, que a su vez puede ser de tres tipos: PIM o independiente de la plataforma, PSM o específico de una plataforma y CM o informe de usabilidad de la aplicación final; el segundo tipo de evaluación sería el de la evaluación de calidad en uso con test de usuarios.
Por otra parte, señalar que WUEP extiende y adapta el método de evaluación de calidad de la ISO 25004n para su integración en evaluaciones de usabilidad:
Otras propuestas
Mplu+a
En el año 2004, Toni Granollers i Saltiveri [GRANOLLERS, 2004], profesor de la Universidad de Lleida, presentaba su tesis doctoral: "MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona-Ordenador y la Accesibilidad en el contexto de equipos de desarrollo multidisplinares", una metodología que emplea los estándares ISO/IEC 9126 e ISO/IEC 9241, así como las guías de accesibilidad propuestas por el World Wide Web Consortium (W3C). La trate con detenimiento en [CARRERAS, 2008]
WebQEM
[OLSINA y ROSSI, 2002] especifican características y atributos basados en la norma ISO/IEC 9126-1, aplicando métricas para cuantificar los atributos.
WQM (Web Quality Model)
[CALERO et al.] establece características de calidad basadas en la ISO/IEC 9126-1 y los procesos del ciclo de vida de un sitio Web basándose en la ISO/IEC 12207. Incorpora un total de 326 métricas Web que han sido validadas teórica y/o empíricamente, indicando cuáles de ellas se prestan mejor a automatizar su cálculo. Ver la clasificación de sus métricas
QUIM (Quality in Use Integrated Measurement)
[Seffah et al.] se basa en la ISO 9241-11 y establece 10 subcaracterísticas que se descomponen en 26 atributos o criterios medibles. En el tercer nivel encontramos 127 métricas de usabilidad asociadas a los atributos. Posee una herramienta de gestión llamada QUIM Editor [STRIKE, 2003]
Referencias
AENOR (Asociación Española de Normalización y Certificación)
BASTIEN, J. M.; SCAPIN, D. L. (1993): “Ergonomic Criteria for the Evaluation of Human-Computer Interfaces”, version 2.1
BEVAN, N. (2005): "Guidelines and Standards for Web Usability"
- (2006): “International Standards for HCI” , mayo 2006
- BEVAN, N. , SPINHOF, L. (2007): “Are guidelines and standards for web usability comprehensive?”
- Nivel Began Published Papers: http://www.nigelbevan.com/cart.htm
CALERO, C.; RUIZ, J.; PIATTINI, M. (2005): “Classifying Web metrics using the Web Quality Model”. Emerald Group Publishing Limited. ISSN: 1468‐4527. Vol.29, nº 3, pp. 227‐248,
CARRERAS MONTOTO, O. (2008), “Metodología DCU MPlu+a”, marzo 2008
Comité Europeo de Normalización (CEN)
FERNANDEZ MARTINEZ, A. (2009): “WUEP: Un Proceso de Evaluación de Usabilidad Web Integrado en el Desarrollo de Software Dirigido por Modelos”
GRANOLLERS, T. (2004): “MPIu+a. Una metodología que integra la Ingeniería del Software, la Interacción Persona‐Ordenador y la Accesibiiad en el contexto de equipos de desarrollo multidisciplinares”. Tesis Doctoral, Departament de Llenguatges i Sistemas Informàtics. Universitat de Lleida
ISO25000.com: “Calidad del Producto Software y la norma ISO/IEC 25000”,
- [ISO25000.com, b]: “La Norma ISO/IEC 25000:2005”,
MONTERO SIMARRO, F. (2008): “Tema 2. El diseño centrado en el usuario”
OLSINA, L.; ROSSI, G. (2002): “Measuring Web Application Quality with WebQEM”. IEEE Multimedia, Vol. 9, nº 4, pp. 20‐29.
Organización Internacional de Estandarización (ISO)
RUIZ MORILLA, J.J. (2009): “ISO 9126 vs. SQuaRE”
SCALONE, F. (2006): “Estudio comparativo de los modelos y estándares de calidad del software”, junio de 2006
TRAVIS, D. (2011): “ISO 13407 is dead. Long live ISO 9241-210!”, Userfocus, 6/6/2011
SEFFAH, A.; Donyaee, M.; Kline, R.B.; Padda, H.K. (2006): Usability measurement and metrics: A consolidated model . Software Quality Journal 14(2), pp. 159-178.
STRIKE, J. (2003): “QUIM Editor: a Tool for Quality in Use Measurement”
USABILITY.GOB: “Research-Based Web Design & Usability Guidelines”
USABILITYNET (2006): “International standards for HCI and usability”
Normas ISO referenciadas:

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements

2011-01-21T22:00:00.002+01:00

Descripción: Tabla en formato excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos: navegadores que los soportan, anotaciones de accesibilidad, etc. (ver descripción detallada de la tabla)

Versión: [20.01.2011] versión 1.0 en castellano

Autor: Olga Carreras

Descarga: Cheat Sheet HTML 4.01, HTML 5, XHTML Elements (Excel, 189 KB)

Descripción detallada de la tabla

La tabla consta de 14 columnas. Los encabezados de las columnas se han bloqueados para que estén siempre disponibles aunque se escrole la tabla verticalmente.

Columna A: Elemento

Incluye todas los elementos (X)HTML (incluidos los de HTML 5) en orden alfabético con enlace a su descripción en la especificación correspondiente. También se incluyen elementos que no están en ninguna especificación del W3C como marquee, spacer, etc. en cuyo caso enlazan con una web de referencia. Es en estos enlaces donde se puede consultar información sobre los atributos de cada elemento.

No se han incluido los elementos que sólo están presentes en XHTML 2. Como excepción se incluye el elemento h de XHTML 2 para documentar los encabezados en esta especificación. Se pueden consultar todas las etiquetas de XHTML 2 en: XHTMl 2.0. List of elements del W3C.

Está primera columna está bloqueada para tener siempre presente el elemento aunque se escrole la tabla horizontalmente.

Columna B: Descripción

Breve descripción del elemento.

Columna C: Desaprobado/No estándar/Obsoleto

En esta columna se indica si los elementos son:

Desaprobado (deprecated): son elementos que están en la especificación HTML 4.01 o XHTML pero que el W3C los ha marcado como "deprecated", desaprobando su uso. No están permitidos en documentos STRICT. Se indica el elemento alternativo que debe usarse.

No estándar: son elementos no estándar, que fueron implementados por algunos navegadores (y que aún las soportan en muchos casos) pero que no pertenecen a ninguna especificación (X)HTML. En cada caso se indica el navegador que las implementó y las alternativas a su uso.

Obsoleto: son elementos de especificaciones anteriores (se indica de cual).

HTML 5: elementos que sólo pertenecen a HTML 5.

En cualquier otro caso la celda correspondiente aparece vacía.

Columna D: Web Browser Support

He documentado el soporte de cada elemento (incluidos los de HTML 5) en las diferentes versiones de navegadores.

Referencias sobre soporte en navegadores:

HTML 4.01 / XHTML 1.0 Reference, about.com

HTML reference, sitepoint.com

HTML, XHTML, and WML support in Opera Presto 2.2, soporte en Opera 10

Web specifications support in Opera Presto 2.7, soporte en Opera 11

When can I use..., compatibility tables for support of HTML5, CSS3, SVG and more in desktop and mobile browsers

HTML5 Tutorial, w3school.

Comparison of layout engines (Non-standard HTML), wikipedia

En algunos casos se indica el test concreto que se ha realizado para validar un elemento concreto.

Columna E-L: Especificación

Las columnas son:

HTML 4.01

XHTML 1.0 Strict

XHTML 1.0 Transitional

XHTML 1.0 Frameset

XHTML 1.1

XHTML 1.1 Basic

HTML 5

XHTML 2

Cuando la celda correspondiente está verde con el texto "SI" indica que el elemento pertenece a esa especificación.

Cuando la celda correspondiente está roja con el texto "NO" indica que el elemento no pertenece a esa especificación.

Algunas celdas pueden aparecer naranjas con una advertencia dentro. Por ejemplo, en el caso de que el elemento pertenezca a HTML 4.01 pero esté desaprobado y no pueda usarse con HTML 4.01 Strict, la celda correspondiente a la columna E (HTML 4.01) estará coloreada en naraja con la advertencia en su interior.

Columna M: Notas de accesibilidad

En este apartado se incluyen notas relevantes como el soporte en lectores de pantalla, ejemplos cuando se trata de elementos poco habituales, mención a puntos de verificación de las WCAG relacionadas con el elemento en cuestión, etc.

Columna N: ¿Semántico?

En esta columna se indica si es una elemento semántico o si por el contrario es un elemento de presentación. En algunos casos, como se indica, puede depender del uso que se haga de ella.

Referencias:

Semantic (X)HTML, microformats.org

Presentational (X)HTML, microformats.org

Otros enlaces de interés:

Keryx (X)HTML Elements Best Practice Sheet

Podeis dejar en los comentarios cualquier propuesta o anotación para incluir en versiones posteriores.

HTML 5

2008-01-23T09:18:00.069+01:00

Última actualización: 15 de febrero de 2012

El 22 de enero de 2008 el W3C publicó al fin el primer borrador del HTML 5 . Actualmente el último borrador es del 13 de enero de 2011.

Antecedentes

En 1997 se publicaba la especificación HTML 4.0, actualizándose en 1999 con HTML 4.0.1, la última especificación oficial del HTML.

El W3C presentó la especificación XHTML 1.0 en el año 2000 como "una versión más estricta y limpia de HTML, que nace precisamente con el objeto de reemplazar a HTML ante su limitación de uso..." ("Guía Breve de XHTML " del W3C). Desde entonces la actividad de estandarización de HTML se detuvo y el W3C se centró en el desarrollo del estándar XHTML.

La última especificación de XHTML es el XHTML 1.1 de 2001. Se comenzó entonces a trabajar en la versión XHTML 2.0.

Por este motivo, en el año 2004, las empresas Apple, Mozilla y Opera (es decir Firefox, Opera, Safari, Camino, Seamonkey) mostraron su preocupación por la falta de interés del W3C en HTML y decidieron organizarse en una nueva asociación llamada WHATWG (Web Hypertext Application Technology Working Group).

La actividad del WHATWG se centró en el futuro estándar HTML 5, el objetivo era una actualización del HTML, compatible con HTML 4 y compatible con Web Apps 1.0 y Web Forms 2.0.

A finales de 2006 nos sorprende el artículo de Tim Berners-Lee (creador del "hipertexto" y director del W3C) "Reinventing HTML" [Ver resumen del artículo de Tim en Blog Posible: "W3C desarrollará de forma paralela HTML: HTML 4.x, XHTML 2…"] . Básicamente es una crítica al éxito del XHTML e incluso a la forma de trabajar del W3C: dice que la evolución de HTML a XHTML no ha funcionado, que los desarrolladores no se han pasado a esta especificación en parte porque los navegadores no han acompañado y aboga por una evolución del HTML.

Anuncia que se pretende trabajar en dos grupos distintos, por un lado un grupo de trabajo para la evolución del HTML y por otro un grupo de trabajo para la evolución del XHTML a la versión 2. Cada uno de estos grupos de trabajo tendrán su estructura independiente (responsables y personal de contacto), pero trabarán juntos en HTML y XHTML.

A los pocos días aparece el artículo "Have your say about the future of HTML" publicado conjuntamente por The Web Standards Project, Lachy’s Log, Molly.com y 456 Berea Street (puedes leerlo traducido en Blog posible) a favor del WHATWG. Piden opinión y ayuda a la comunidad en el proceso de desarrollo de la nueva versión de HTML que ya denominan HTML 5.

El 10 de enero de 2007 nos sorprende la noticia de que Chris Wilson, jefe del proyecto IE7 de Microsoft, va a ser el responsable del grupo de trabajo de la evolución del HTML, algo que es muy criticado por ser una persona tan relacionada con un navegador concreto, uno en especial que no se ha caracterizado precisamente por respetar los estándares, aunque esto también supone un acercamiento de IE7 a los estándares. El grupo de trabajo dice que va a colaborar con el WHATWG.

Debido a la fuerza de las empresas que forman el grupo WHATWG y a la publicación de sus borradores de HTML 5.0, en marzo de 2007 el W3C decidió retomar oficialmente la actividad estandarizadora de HTML.

El 22 de enero de 2008 el W3C y el WHATWG publican el nuevo borrador pudiéndose leer en el del WHATWG:

"This specification is also being produced by the W3C HTML WG. The two specifications are identical from the table of contents onwards.
This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications." [En "HTML 5" del WHATWG]

En 2009 el W3C anuncia que disolverá el grupo de trabajo del XHTML 2 para centrarse en el documento del HTML 5. El documento XHTML 2.0 se actualizó el 16 de diciembre de 2010, en él se indica que el grupo se ha disuelto antes de terminarlo, pero que quizás pueda retormarlo otro grupo en el futuro.

Aplicaciones para desarrollo con HTML 5

Adobe Muse

Recursos HTML 5

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements
HTML 5. A vocabulary and associated APIs for HTML and XHTML, W3C
HTML W3C, referencias, artículos y más.
Grupo de Trabajo de HTML del W3C
HTML 5 differences from HTML 4, del W3C.
[Relacionado: "Las principales diferencias entre HTML5 y HTML4", de anieto2k.]
"A Preview of HTML 5" by Lachlan Hunt
HTML 5 tutorial de w3schools.com
HTML MDC Doc Center de Mozilla
Dive Into HTML5, libro online de Mark Pilgrim
HTML Glossary
"15 Excellent Step by Step HTML5 Website Coding Tutorials", WebdesignerAid.
"Tutorial sobre HTML5 y CSS3", Daniel Martinez.
Developing with HTML5
HTML Cheat Sheets
HTML 5 en Delicious
HTML5 presentation
Blogs especializados en HTML 5:
- HTML 5 Doctor
- HTMLcinco

Plantillas HTML 5

"Easy HTML5 Template", Louis Lazaris
HTML5 Boilerplate, plantilla compleja.
HTML 5 Reset, plantilla más sencilla que la anterior.
Tutoriales sobre creación de plantillas web en HTML5

HTML 5 y accesibilidad

Ver el artículo HTML 5 y accesibilidad donde recopila recursos de interés.

Soporte de HTML 5

En noviembre de 2010 el W3C dió a conocer las pruebas oficiales que dan cuenta del soporte para HTML 5 en los siguientes navegadores:

IE 9 Platform Preview 6
Chrome 9.0.571.0
Firefox 4 Beta 6
Safari 5.0.2

IE 9 gana con ventaja. Los test se pueden pasar individualmente por cualquier navegador.

En Cheat Sheet HTML 4.01, HTML 5, XHTML Elements se recoge una tabla con todos los elementos HTML 5 y su soporte en diferentes navegadores.

Otros recursos:

En "When can I use" de caniuse.com, se puede consultar una comparativa muy exhaustiva en cuanto a versiones de navegadores y aspectos de HTML 5, que además está muy actualizada.
Soporte en Opera 11
HTML 5 Test, el test de soporte de HTML 5 se realiza sobre el navegador con el que se abre el test.
Test de soporte de los nuevos tipos de input y sus atributos

Para consultar los formatos de vídeo soportados por cada navegador: HTML 5 video

Validador automático de sintaxis HTML 5

El validador del W3C, admite validación de sintaxis HTML 5.

Validator.nu3 también permite permite validar:

HTML5
HTML5+ARIA
HTML5 + ARIA, SVG 1.1 plus MathML 2.0

Desarrollos en HTML 5

"LeanBack Player HTML5. Video Player with Subtitle-Support", fantástico ejemplo explicado paso a paso de un reproductor de vídeo en HTML 5 con subtítulos.
Reproductor de vídeo HTML5 de YouTube
Reproductor de vídeo HTML5 de Vimeo
HTML 5 demos
Coding A HTML 5 Layout From Scratch, Enrique Ramirez explica paso a paso la creación de una página en HTML 5
"35 interesantes ejemplos de sitios web diseñados con HTML5" en cssblog.es
W3C HTML Demos Wiki

Logotipos e iconos

La web del logotipo de HTML 5 permite descargar diversas versiones del logo de HTML 5, que además está disponible bajo licencia “Creative Commons 3.0 Reconocimiento”, así que puede ser adaptado por los diseñadores para cubrir sus necesidades.

El W3C anima a los desarrolladores a usar HTML5 y a comentar su experiencia al Grupo de Trabajo de HTML del W3C como parte del proceso de estandarización.

La página principal del logo incluye un creador de insignias en función de las tecnologías que estés usando, una galería de sitios que usan el logo, enlaces para comprar una camiseta de HTML5, instrucciones para obtener adhesivos gratuitos, preguntas frecuentes sobre el logo, y más.

Los iconos hacen referencia a: Connectivity/Realtime, CSS3/Styling, Device Access, Graphics, 3D & Effects, Multimedia, Performance & Integration, Semantics, and Offline & Storage

Noticias

[09/07/2009] Se espera que el Grupo de Trabajo de XHTML 2 cese su trabajo a finales de 2009, INTECEO. [...] el W3C espera acelerar el progreso del HTML 5 y clarificar la posición del W3C sobre el futuro del HTML. Nota Olga 2011: el documento XHTML 2.0 se actualizó el 16 de diciembre de 2010, en él se indica que el grupo se ha disuelto antes de terminarlo, pero que quizás pueda retormarlo otro grupo en el futuro.
[09/06/2009] "Safari 4 ya está aquí" de Programar a ciegas. Safari 4 implementa HTML 5 y WAI-ARIA.
[28-05-09]"La etiqueta <video> disponible en Google Chrome 3.0", de Kabytes.
[29-05-09]"Google apuesta por el HTML5 y lo hace a lo grande" de anieto2k. Presentación de una página de demo en Youtube en la que usamos HTML5 y los controles multimedia para mostrar los videos (sólo en Chrome, Safar4i, Webkit, Firefox 3.5) [...] Google Wave hace uso de las propiedades de HTML5, sacándole el máximo partido al estandar para innovar una vez más.
[03/02/2009]"HTML5 llega al iPhone" de anieto2Kel iphone será el primer dispositivo móvil que dispondrá de algunas de las maravillas del HTML5 en su navegador web

Artículos de interés

Franganillo, Jorge. “Html5: el nuevo estándar básico del Web”. Anuario ThinkEPI, 2011, v. 5
"A Simple Trip Meter using the Geolocation API", Michael Mahemoff [24.05.2010]
"HTML5 alternativas para Flash", caChi [02.03.2010]
"28 HTML5 Features, Tips, and Techniques you Must Know", Jeffrey Way [01.08.2010]
"When to Use the HTML5`section´ Element", Louis Lazaris [12.01.2011]
El elemento audio del HTML5, anieto2k [14.07.2009]
El elemento video del HTML5, anieto2k [30.06.2009]
Solventar problemas con los estilos
- CSS Reset para HTML5, anieto2k [27.07.2009]
- Disfruta de HTML5 en Internet Explorer y Firefox 2, anieto2k [30.06.2009]
"HTML5: qué cambios trae la nueva versión del lenguaje estándar de la web" de Federico Erostarbe
Guía básica de HTML 5 para diseñadores web, Sebastián Thüer [01/10/2009]
Lo que está pasando con la futura versión de HTML de Blog posible, de enero de 2007
Iniciativa por el HTML 5: que alquien me lo explique de Tripix.net, de noviembre de 2006
Breve historia de HTML de librosweb.es
"El próximo estándar Web" de PC Actual

Plantilla base XHTML

2007-08-26T10:50:00.007+02:00

Artículo relacionado: Cheat Sheet HTML 4.01, HTML 5, XHTML Elements, tabla en formato excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos: navegadores que los soportan, anotaciones de accesibilidad, etc.

El objetivo de este artículo era tan simple como crear una correcta plantilla XHTML base, lo más completa posible para que en función del desarrollo se pudiera eliminar aquello que fuera prescindible.

Pronto comprendí que para justificar la inclusión de cada línea sería necesaria una explicación, y al final me he liado a escribir y me ha salido de nuevo un artículo demasiado amplio. De modo que si te interesa tan sólo la plantilla puedes ir directamente al final del artículo. Serán bienvenidas todas las aportaciones acerca de qué añadirías o quitarías, pero entonces te agradecería que leyeras el artículo completo y argumentarás tu posición.

Si te interesa seguir la construcción de la plantilla aquí tienes el índice del artículo:

DOCTYPE
HTML
HEAD
Metas
CSS
Navegación semántica
JS
BODY
- Estructura de contenidos
- Microformatos
Fin de documento
Plantilla XHTML base

Declaración de tipo de documento DOCTYPE

     
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"       
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Lo primero que debe contener nuestra página es la declaración del tipo de documento (Document Type Definition (DTD), también conocida como Doctype para abreviar) no sólo para cumplir con los estándares sino para garantizar la correcta renderización de nuestra página.

Mediante esta declaración indicamos la versión de (X)HTML que usa la página y la DTD con la cual se realiza la validación, de forma que los navegadores puedan saber qué sintaxis y gramática se usa, y los validadores puedan comprobar su validez.

Los navegadores entran en modo de visualización Quirks Mode cuando una página no tiene definido un Doctype o pese a tenerlo no cumple el estándar referente a ese Doctype (por ello es tan importante validar la sintaxis de nuestras páginas con el validador del W3C). Las consecuencias de que el navegador entre en Quirks Mode son que:

procesa las páginas de forma más lenta
renderiza las páginas de forma completamente diferente a lo que teníamos previsto (ver consecuencias en ¿Qué pasa en el modo chapuzas (Quirks Mode)?

Con Firefox, por ejemplo, puedes consultar el modo de visualización de la página desde el menú "Herramientas/Información de la página".

La declaración de tipo de documento que he puesto es la de XHTML 1.0 Strict. Existen muchos otros que puedes consultar en el W3C.

El HTML se ha jubilado hace tiempo (bueno, habrá que ver como evoluciona el tema del HTML5), hoy en día yo creo que la elección debe ser entre los distintos tipos de XHTML, concretamente ente XHTML 1.0 Strict o XHTML 1.1, que nos aseguran una página bien estructurada, con una clara separación entre el contenido y la presentación.

Pero para no llevarnos desagradables sorpresas después, hay que tener en cuenta varias cosas antes de tomar una decisión:

Con XHTML 1.0 Strict y XHTML 1.1 no puedes utilizar el parámetro "target", y evidentemente tampoco vas a usar un window.open, así que si quieres abrir una ventana nueva hay que echar mano de soluciones ingeniosas como la de Kevin Yank. Lo cierto es que lo ideal es no abrir nunca nuevas ventanas, puesto que muchos user-agent no las permiten (dispositivos móviles, TDT, etc.)
Una página XHTML 1.1 NO puede ser servida como "text/html" (permitido en XHMTL 1.0 Strict siempre que se cumpla con las Directrices de Compatibilidad con HTML) lo cual no podrá ser interpretado por muchos navegadores (ver lista en el W3C)
Una página XHTML 1.1 debe incluir antes del DOCTYPE la línea: <?xml version="1.0" encoding="ISO-8859-1"?> (el encoding dependerá del idioma de la página, claro) lo cual provoca que Explorer 6 entre siempre en modo Quirks Mode (ver artículo "HTML Doctype" de webdiseny.es y el artículo "Duda con XHTML 1.1" de Anieto2K )
En XHTML 1.0 Strict y XHTML 1.1 no se admiten los elementos "applet", ni "frame" o "iframe", ni permite escribir código con javascript mediante "document.write"

En resumen, es muy importante la elección del DOCTYPE, y esta no se puede hacer a la ligera, sino que es necesario conocer las especificaciones de los distintos tipos de documento. Si tu desarrollo es incompatible (normalmente por las exigencias del que paga) con cualquiera de las prohibiciones/restricciones que hay en XHTML 1.0 Strict o XHTML 1.1, tus páginas deberán ser XHTML 1.0 Transitional o XHTML 1.0 Frameset.

Enlaces de interés:

XHTML 1.0
XHTML 1.1
Traducciones SIDAR sobre XHTML
HTML 4.01 / XHTML 1.0 Reference
"Recommended DTDs to use in your Web document" del W3C
"Preguntas frecuentes sobre HTML y XHTML" del W3C
"HTML Doctype" de webdiseny.es
"Pasando de HTML a XHTML" de mononeurona.org
"XHTML" de Patricio Galdames

HTML

     
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">

A continuación se incluye la etiqueta HTML indicando el idioma utilizado en la página. Como nuestra página es XHTML 1.0 debemos indicar el idioma tanto con "xml:lang" como con "lang", así como el espacio nominal a través del atributo "xmlns", siendo este: "http://www.w3.org/1999/xhtml"
(ver especificación de XHMTL 1.0)

HEAD

     
<head profile="http://miservidor.org/xmdp/htmlprofile.html http://dublincore.org/documents/dcq-html/ http://geotags.com/geo/">       


<title>Titulo de la pagina</title>       

<link rel="shortcut icon" href="favicon.ico" type="image/x-icon" />       

<base href="http://miservidororg.com/" />

Comenzamos la cabecera de la página con <head>, que como se ve tiene definidos varios profile (documentos que contienen un perfil de metadata), separados por espacios. Es necesario utilizar un profile siempre que usemos metas que no estén definidos en la especificación XHTML. En este caso incluimos dos formalmente definidos como son el de Dublin Core y el de Geotags.

Del mismo modo, si en las etiquetas <link> o <a> usamos valores para “rel" y “rev" diferentes de los definidos en la especificación XHTML, también habremos de utilizar un profile propio en el cual sean definidos. En nuestro caso he creado mi propio profile (miprofile.html) con XMDP.

Estos profile deben estar ordenados de mayor a menor importancia, teniendo en cuenta que si un mismo elemento es definido en varios de esos profile tendrá prioridad el del primer profile en el que se defina. Si estás un poco perdido puedes leer esta breve introducción al tema.

Esta es la teoría, en la práctica, como se puede leer en el W3C , los user-agent, hoy en día, sólo admiten el primero de la lista. Incluimos los tres en espera de que sean capaces de reconocer varios profile, y más delante, delante de los metas, incluiré un link con el schema . Que yo sepa, el profile y el schema no son excluyente o sustitutivos, me corregís si me equivoco, así que se pueden incluir ambos en la plantilla.

A continuación añadimos el título de la página con <title> que debe identificar de la forma más clara y breve posible el contenido del documento que lo contiene (y por tanto no debe ser el mismo para todas las páginas del portal). El contenido del <title> será lo que se muestre en la ventana de título del navegador, el nombre del enlace al guardar la página en Favoritos, al descargarla o al hacer un acceso directo, será el título de nuestra página en los buscadores, etc.

En “Como optimizar los títulos en sus páginas web" encontrarás todas las reglas que debe seguir el <title> de tus páginas. Deberías tener en cuenta que los buscadores dan gran importancia al contenido del title (más que a las keywords) para indexar tu web y que Google interpreta que se hace spam si aparece más de una vez una palabra determinada en el título.

[..] el título debe ser una frase bien redactada y llamativa, y a su vez con una alta densidad de palabras clave, que describa con precisión los contenidos de la página. Una práctica muy común es poner como etiqueta de título el nombre de la empresa o página web. En primer lugar, esta práctica explica bien poco al visitante de lo que se trata la página y, en segundo lugar, no muestra al robot del buscador el tema principal […]
[En "La optimización de etiquetas y meta-tags HTML"]

Podemos indicar opcionalmente el favicon (icono asociado a la web), pero antes de usarlo deberías estar al corriente de los problemas de seguridad asociados a él: 'Favicon': la 'cara' de las direcciones url o favicon.net

Verás que hay un espacio en blanco antes del “/>" de la etiqueta link, espacio que he incluido en todas la etiquetas simples de la plantilla, puesto que así lo indican las Directrices de Compatibilidad con HTML del XHTML.

Por último, he incluido la etiqueta <base> para indicar la ruta base de referencia para enlaces relativos, esto es muy útil en sitios dinámicos y para que los enlaces sigan funcionando fuera de contexto (por ejemplo si se han guardado tu página en local)

METAS

Metas http-equiv

     
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />       


<meta http-equiv="content-language" content="es" />

Existen dos tipos de metas, los meta http-equiv, que tienen control sobre los exploradores, y son utilizados para refinar la información y dar instrucciones al explorador que las está leyendo (aunque hay que advertir que muchos navegadores las ignoran) y los meta name, que contienen información referida al documento (meta información) que no se presenta en la pantalla del navegador.

Las metaetiquetas [en referencia a los meta "http-equiv"] generan información extra a las cabeceras HTTP, de manera que cuando se hace una petición al servidor de una página en concreto, este genera una respuesta HTTP que incluye como información las metaetiquetas que nosotros hayamos insertado en nuestra página [...]
Debemos tener en cuenta que la inserción de las metaetiquetas no produce ningún cambio en el resultado de nuestra página a "nivel visible", es decir, que no alterará en nada el diseño de nuestra página, ya que su efecto sólo influye en las cabeceras HTTP, y por tanto sólo son utilizadas y vistas a nivel de servidor, motores de búsqueda, navegadores web, etc.

[En "Metaetiquetas"]

Hay diferentes metas http-equiv: para la caché, la expiración, el refresco (que se ha de evitar a toda costa) o las cookies de las páginas.

Yo he añadido a la plantilla los dos que me parecen fundamentales:

content-type: lo colocamos en primer lugar, indica el tipo de documento y su codificación de caracteres (XHMTL 1.0 Strict permite que la página sea servida como text/html siempre que se cumpla con las Directrices de Compatibilidad con HTML)
content-lenguage: el idioma del documento

Hay otros para especificar el tipo de script o de hojas de estilo utilizadas:

     
<meta http-equiv="content-style-type" content="text/css" />       


<meta http-equiv="content-script-type" content="text/javascript" />

Hay otros metas propietarios, sólo para determinados navegadores, no estandarizados por el W3C, por ejemplo imagetoolbar, que permite no mostrar en Explorer la barra de herramientas asociada a las imágenes. Yo no soy partidaria de incluirlo por las mismas razones por las cuales no deshabilitaría el menú del botón derecho del navegador, pero la experiencia me dice que el que paga a menudo no atiende a razones.

Otro meta interesante es window-target que especifica el nombre de la ventana en la cual se debe visualizar la página web. Es muy útil para evitar que nuestra página sea vista en el marco de otra página web ajena a la nuestra, puesto que con el parámetro _top elimina todos los marcos existentes en el explorador.

     
<meta http-equiv="window-target" content="_top" />

Si la página incluye contenido para adultos habría que añadir PICS-Label (existe un generador automático: PICS Rating Generator).

Metas name

     
<meta name="description" content="incluir descripcion" />       

<!--// Incluir descripción //-->

Las metaetiquetas tienen una utilidad fundamental, principalmente en la promoción e indexación de la página Web en motores de búsqueda, directorios, etc.
También tienen otros usos, pero el principal es el ofrecer información sobre el documento a estos buscadores y directorios (y más concretamente a los programas que estos usan, llamados robots, que utilizan para indexar páginas Web en sus bases de datos)

[En "Metaetiquetas"]

Hay un meta que no puede faltar, es “description", que será la descripción que muestre Google habitualmente en su resultado, y que debería ser atrayente para animar a los usuarios a hacer clic sobre el título.

La descripción debe ser de 20-35 palabras, siendo buena idea ajustar el texto para que quepa en dos líneas. Debe ser única para cada pagina pues a un buscador le parecerá extraño que distintas páginas tengan la misma descripción, por lo que las marcará como poco relevantes y, en consecuencia, o no las posicionará bien o, peor todavía, no las mostrará entre sus resultados.

La etiqueta de Description bien redactada debe ser corta, precisa y con una alta densidad de palabras clave. Deberíamos evitar la tentación de utilizar la misma frase para las etiquetas de título, palabras clave y descripción.

[En "La optimización de etiquetas y meta-tags HTML"]

Existen robots que no hacen uso de las metaetiquetas para indexar las páginas web, así que algunos recomiendan incluir una descripción de la página que pueda ser útil para estos robots en el head, como si se tratase de un comentario.

     
<meta name="keywords" content="palabra1, palabra2" />

keywords ha perdido mucha importancia porque los principales buscadores ya no la utilizan para buscar las palabras clave de un sitio, puesto que ahora buscan las palabras clave en el title y en el body. Muchos optan por eliminarlas, pero aunque sólo sea por Inktomi, uno de los cinco principales buscadores, puede merecer la pena incluirlas.

Se recomienda que no sean muchas palabras, escribirlas en minúsculas, sin acentos, ni caracteres no internacionales, separadas por coma y un espacio o sólo por espacios formando frases, y personalizarlas para cada página del sitio. No deben ponerse palabras repetidas pues los buscadores lo consideran spam.

En cualquier caso debe evitarse todo uso ilegal de los metas porque los buscadores son capaces de detectarlos y eliminar la web de sus índices.

Si incluimos las palabras clave o la descripción en un idioma diferente habrá que añadir el parámetro del lenguaje mediante "lang" y "xml:lang".

A partir de este punto se pueden incluir muchos metas más, algunos muy extendidos como "autor", "copyright" y "robots" (este último sólo cuando queremos cambiar los valores por defecto, sino no es necesario. En cualquier caso sería más apropiado hacerlo con un fichero “robots.txt" que permite mucha más versatilidad)

¿Pero por qué incluir más metas?

Esos metadatos, son uno de los pilares de la web semántica, cuyo objetivo principal es lograr una "web inteligente" en la que los agentes de usuarios (como los buscadores, y otros mucho más avanzados) son capaces de intercambiar información de forma automática, con una mínima intervención humana.

[En Webposible]

Los metas que incluyas ya depende de ti y de tu web. Deberías añadir, eso sí, sólo los necesarios, no añadir metas porque sí, puesto que algunos de los buscadores premian a las páginas por tener más contenidos comparado con la cantidad de código y hasta se dice que Google penaliza a las páginas con un exceso de etiquetas. De todas maneras, como veremos, siempre se pueden incluir en ficheros RDF.

Puedes ver referencias completas de metas en estas direcciones:

Como curiosidad, este meta que se ve en ciertas páginas: <meta name="MSSmartTagsPreventParsing" content="true">, no tiene sentido incluirlo, puesto que Microsoft nunca llego a implementar "smart tags" en Explorer.

Metas Dublin Core

Dublin Core es un estándar de metadatos que define un conjunto de propiedades recomendadas para descripciones bibliográficas electrónicas, y su objetivo es promover la interoperabilidad entre modelos descriptivos dispares.

[En conclase.com]

Dentro de la gran variedad de estándares que utilizan las diferentes comunidades en Internet, el Dublin Core ha resultado el más citado, aceptado y usado, desarrollándose a un ritmo acelerado; muchos son los aportes que se han hecho al formato en los últimos años, lo que ha posibilitado que pueda ser utilizado en una amplia y creciente variedad de proyectos pertenecientes a las más diversas comunidades dentro de Internet.

El formato Dublin Core tiene dos niveles de codificación: simple y calificado. El DC simple emplea solamente los 15 elementos originales que forman parte del formato (Creador, Title, Subject, Description, Publisher, Type, Format, Coverage, Contributor, Date, Relation, Source, Language, Identifier y Rights); el calificado, además de los 15 elementos del DC simple, incluye: nuevos elementos DC, términos de refinamiento y esquemas de codificación de los elementos.

[En "Dublin Core (DC) en XHTML" de Isabel Daudinot]

Una vez que hemos incluido su profile en el head como ya vimos, podríamos por ejemplo añadir los siguientes metas (precedidos de su schema, tema sobre el que puedes ampliar información en En "Dublin Core (DC) en XHTML"):

     
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />       

<meta name="DC.title" content="ejemplo" />       

<meta name="DC.creator" content="ejemplo" />       

<meta name="DC.subject" content="ejemplo" />       

<meta name="DC.description" content="ejemplo" />       

<meta name="DC.language" scheme="ISO639-1" content="es" />       

<meta name="DC.rights" content="(c) 2007 propiedad del copyright" />

Muchas páginas que utilizan metas Dublin Core incluyen este label en sus páginas:

Otros enlaces de interés:

"Expressing Dublin Core in HTML/XHTML meta and link elements" en Dublin Core Metadata Iniciative
Generador de metas de Dublin Core en Webposible
"Encoding Dublin Core Metadata in HTML" de J. Kunze
es.dublincore.org
Guía de uso en es.dublincore.org
Dublin Core en la Wikipedia
Dublin Core en Webposible

Metas Geotags

Permiten incluir metainformación geográfica. Una vez que hemos incluido su profile en el head, como ya vimos, podríamos por ejemplo añadir los siguientes metas (precedidos de su schema)

     
<link rel="schema.geo" href="http://geotags.com/geo" />       

<meta name="geo.position" content="36.1254;-5.4429" />       

<meta name="geo.region" content="ES-AN" />       

<meta name="geo.placename" content="Algeciras" />

Existe un generador automático de etiquetas: Geo Tag Generador. GeoURL Header Generator las genera a partir de una dirección, pero sólo está disponible para EEUU. Earth Google y Google Maps también son de utilidad porque te dan la localización exacta de un lugar.

Enlaces de interés:

"Cómo indicar con exactitud un lugar geográfico en metadatos" de Gonzalo M.B.
"Metadatos geográficos" en Web Semántica Hoy
"Pon tus fotos en el mapa" de Ramso Net Blog
"Geotagging Flickr photos with Google Earth"

Metadatos en RDF

     
<link rel="meta" href="miservidor/dublincore.xml" type="application/rdf+xml" title="Dublin Core Metadata" />

Otra manera de incluir metadatos es mediante un fichero RDF (Resource Description Framework), un framework para metadatos en la Web desarrollado por el W3C.

El fichero contendrá información optimizada para los agentes semánticos (buscadores semánticos u otras aplicaciones) y su potencial es inmenso: interoperabilidad entre aplicaciones, procesamiento automatizado de recursos, etc.

Como siempre, todo tiene sus ventajas y sus inconvenientes y su uso depende de las características de nuestro desarrollo. Imprescindible el artículo de Web Semántica Hoy "Etiquetas meta, ficheros RDF, microformatos: 3 sabores de la Web Semántica"

Existen herramientas automáticas para crear RDF como vimos para Dublin Core o RDF-Gen, el generador de ficheros RDF para describir imágenes; y por supuesto se pueden escribir a mano en un simple bloc de notas. Puedes ver un ejemplo en "Cómo indicar con exactitud un lugar geográfico en metadatos" de Gonzalo M.B.

Otros enlaces de interés:

DOAC, RDF metadata para información curricular
FOAF, para la descripción de relaciones personales. Existe un generador automático: Foaf-a-matic. Existen muchas aplicaciones relacionadas: FOAF People Map, foafnaut!, FoaF Explorer o FOAF Web View que explotan estos datos.

CSS

     
<link href="estilosGeneral.css" type="text/css" rel="stylesheet" media="all" />       


<link href="estilosPantalla.css" type="text/css" rel="stylesheet" media="screen,projection" />       


<link href="estilosPrint.css" type="text/css" rel="stylesheet" media="print,tty" />       


<link href="estilosTelevision.css" type="text/css" rel="stylesheet" media="tv" />       


<link href="estilosSintetizador.css" type="text/css" rel="stylesheet" media="aural" />       


<link href="estilosMovil.css" type="text/css" rel="stylesheet" media="handheld" />       



<!--[if IE]>       

<link href="estilosIE.css" rel="stylesheet" type="text/css" media="screen" />       

<![endif]-->

Nuestros estilos deberían estar siempre recogidos en CSS. Podemos y debemos especificar diferentes CSS según el dispositivo de salida.

La CSS de pantalla debería tener explícito el media="screen" porque, si no se especifica, el resto de las CSS heredarán sus atributos y esto complica mucho el mantenimiento de las mismas. Es mejor tener una CSS media="all" con los elementos comunes y una específica para redefinir la visualización de los elementos que consideremos necesarios para los distintos dispositivos de salida.

Es imprescindible siempre una CSS para impresión media="print" que nos permita controlar la impresión de las páginas. También recomiendo leer mi artículo “Tu web en la televisión" para crear una CSS especifica para televisión (media="tv"). Hoy en día también es imprescindible una CSS para dispositivos móviles (media="handheld"). Si tienes posibilidad de revisar tu web con otros dispositivos de salida: un proyector, en dispositivos táctiles braille, etc. también deberías comprobar la necesidad de una CSS específica.

Para los sintetizadores de voz puedes crear una "CSS auditiva" mediante el media="aural", en la cual puedes indicar una pausa, el volumen o incluso el sexo de la voz que lee determinado texto.

Son pocos los navegadores (Opera 9, FireVox, Emacspeak) que admiten estas CSS y no todos interpretan la totalidad de sus propiedades. Puedes ampliar información en: “Aural CSS: Support for CSS 2 Aural Style Sheets / CSS 3 Speech Module". También puedes consultar “Aural style sheets" del W3C.

Nuestras CSS deberían ser multinavegador, pero a veces Explorer nos pone las cosas difíciles, sólo cuando nos sea imposible que se visualice correctamente en Explorer algún elemento, deberemos recurrir a una CSS correctiva, que sólo redefina las etiquetas que nos dan problemas, lo cual hará el mantenimiento del portal mucho más sencillo. Esta CSS correctiva la podemos llamar mediante los condicionales de Explorer, como se ve en el código, condicionales que pasan la validación XHTML 1.0 Strict.

Ya he comentado porque hay un espacio en blanco antes de cerrar la etiqueta link.

Navegación semántica

     
<link rel="home" href="default.htm" title="Pagina inicial. " />       


<link rel="index" href="mapa_web.htm" title="Mapa web. " />       


<link rel="contents" href="#menu" title="Tabla de contenidos. " />       


<link rel="search" href="buscador.asp" title="Buscador. " />       


<link rel="glossary" href="glosario.htm" title="Glosario. " />       


<link rel="help" href="ayuda.htm" title="Ayuda. " />       


<link rel="first" href="articulo1.htm" title="Primer articulo. " />       


<link rel="previous" href="articulo3.htm" title="Articulo anterior. " />       


<link rel="next" href="articulo5.htm" title="Articulo siguiente. " />       


<link rel="last" href="articulo10.htm" title="Ultimo articulo. " />       


<link rel="up" href="#inicio" title="Arriba. " />       


<link rel="copyright" href="#copyright" title="Copyright. " />       


<link rel="author" href="mailto:carreras.olga@gmail.com" title="Contactar. " />

Si no sabes qué es la navegación semántica deberías comenzar leyendo

"Navegación Semántica o Meta Navegación" de Emmanuelle Gutiérrez y Restrepo.

No todos los navegadores incluyen por defecto la barra de navegación semántica, la tienen Seamonkey, Opera, Lynx o iCab, pero existen extensiones para otros, por ejemplo la Link Toolbar de Firefox o la <link> Navigation Bar para Explorer.

La forma de mostrar los vínculos varía de uno a otro, de tal manera que en algunos, como en Opera, sólo se muestran los definidos por el navegador pero no los definidos por la página:

Como ves, en Opera, los 13 enlaces aparecen activos porque se han definido todos ellos con el código anterior. Para que sean reconocidos, el parámetro “rel" debe ser exactamente el que he indicado (si pusieras otro, o lo pusieras en español, deberías definirlo en un profile para que fuera reconocido). El href puede ser a otra página, a una zona de la página actual o a un email.

Por ejemplo, en Explorer, vemos las mismas 13 opciones pero en forma de iconos y en distinto orden. Explorer presenta además un desplegable para los rel="alternate" y otro para los definidos por el autor (lo vemos más adelante):

En Lynx, por ejemplo,

se insertan estos enlaces al comienzo de la página. Aquí se ve claramente por qué conviene poner “." más un espacio en blanco al final del title: para que los enlaces sean legibles en los navegadores modo-texto (de otro modo, los enlaces hubieran estado todos juntos y seguidos). Por otro lado, el punto forzará una pausa en su lectura.

Además de esos 13 enlaces estándar, existen los alternate, que permiten ofrecer acceso a una presentación alternativa del documento.

     
<link rel="alternate" href="/en" hreflang="en" title="English version. " xml:lang="en" lang="en" />       


<link rel="alternate" href="/fr" hreflang="fr" title="Français version. " xml:lang="fr" lang="fr" />       


<link rel="alternate" href="/es" hreflang="es" title="Versión en Español. " xml:lang="es" lang="es" />

En estos enlaces estamos indicando versiones de la web en otros idiomas, también podemos indicar otro tipo de versiones:

     
<link rel="alternate" type="application/rss+xml" title="Titulares RSS Feed. " href="titulares.rss" />       


<link rel="alternate" type="application/atom+xml" title="Titulares Atom. " href="titulares.atom" />

En este caso dos versiones: RSS y ATOM para la distribución (o sindicación, con su nueva acepción tomada del “syndication" en inglés) del contenido de nuestra web. Si siglas y palabras como RSS, RDF, Atom, feed te suenan a chino o no terminas de aclararte con ellas, sólo necesitas leer el fabuloso artículo de microsiervos “¿Qué es RSS –y XML, RDF, Atom,...?". También puedes consultar la “Guía fácil del RSS".

Se podrían incluir en este tipo de link rel="alternate" otras versiones alternativas como versión zoom, versión alto contraste, etc.

En Explorer, por ejemplo, todos los rel="alternate" se muestran en un desplegable:

La W3C especifica otros valores de "rel", aparte de los vistos: chapter, section, subsection, appendix, bookmark

Por último, podemos ofrecer otros links definidos por el autor y no descritos en la especificación, en cuyo caso se debe usar un profile definido en el head, como ya he indicado.

Sería conveniente añadir estos dos links: rel=“accesibility" y rel=“personalizar" para los enlaces de accesibilidad, como se propone en "Navegación Semántica o Meta Navegación" de Emmanuelle Gutiérrez y Restrepo.

     

<link rel="accesibility" href="accesibilidad.rdf" type="application/rdf+xml" title="Accesibilidad. " />       


<link rel="personalizar" href="personalizar.htm" title="Opciones de personalización para la navegación por el sitio web. " />

El primero de ellos, “accesibility", enlazaría con el informe de evaluación de la accesibilidad de la página en formato RDF, que puede generarse fácilmente utilizando HERA u otra herramienta de revisión que permita la generación de informes utilizando el vocabulario EARL. Esto permite comprobar hasta que punto se han revisado las páginas, quién lo ha hecho y qué nivel de accesibilidad declara.

Este informe no está dirigido al usuario, aunque existan herramientas para que los informes generados en formato RDF se presenten de forma legible para los humanos en formato XHTML. Por ello tendríamos el link “personalizar" que enlazaría con la página habitual de accesibilidad, en donde se explicarían cuestiones básicas sobre las opciones de configuración y adaptación (por tanto de personalización) del sistema operativo y agente de usuario: teclas de acceso rápido, ampliación de fuente, etc.

Otros enlaces podrían ser propios de la aplicación, por ejemplo:

     
<link rel="archive" href="" title="Mayo 2007. " />       


<link rel="archive" href="" title="Junio 2007. " />

Estos enlaces personales, en Lynx, por ejemplo, no se visualizan, en Explorer sin embargo aparecen en un desplegable:

JS

     
<script type="text/javascript" src="js/utils.js"></script>

En XHMLT 1.0 Strict no se permite el parámetro “language" en la etiqueta script, por eso no lo incluyo.

Todo el código javascript debería estar en ficheros JS, aunque es cierto que la especificación permite incluir código en la página así:

   
<script>     
<![CDATA[     
... contenido no procesado del script ...     
]]>     
</script>

Nuestra página debe tener claramente separado el contenido, la presentación y el comportamiento, por ello el javascript utilizado debe ser no intrusito, invisible, de tal manera que no afecte su desactivación al funcionamiento de la página, y por supuesto tener cuidado con el tipo de eventos que se manejan (el evento "onclick" será inservible, por ejemplo, a un usuario que no disponga de ratón).

BODY

     
</head>       

<body>

Cerramos la cabecera del documento y comenzamos el cuerpo de la página. El body no debe llevar ningún parámetro de estilo (topmargin, etc.) ni tampoco debería incluir llamadas a eventos javascript (por ejemplo onLoad, perdón onload, en XHTML los atributos van en minúsculas) pues como digo todo el javascript debe ser no intrusito.

BODY: Estructura de contenidos

     
<div id="pagina"><a id="inicio" name="inicio">Inicio de la pagina</a>       


<div id="irContenido"><a rel="contents" href="#content" accesskey="S">[S] Ir al contenido</a></div>       


<div id="irNavegacion"><a rel="index" href="#menu">Ir al menú de navegación</a></div>

Al comienzo de las páginas deberíamos incluir un enlace que permita saltar directamente al contenido y otro que permita saltar directamente al menú, de manera que aquellos usuarios que, por ejemplo, utilicen un lector de pantalla, no tengan que escuchar en cada página toda la cabecera, todo el menú, etc., o que los usuarios que por ejemplo usen un navegador tipo texto como Lynx, no deban tabular por todas las opciones previas hasta llegar a un enlace en el contenido (lo mismo se aplica a otros dispositivos como MSN TV o dispositivos móviles en los que no se usa ratón)

Todo lo que hay que saber acerca de este tema está resumido en Enlaces de "saltar navegación" de jlvelazqueznet, y a él te remito.

En resumen, lo habitual es esconder estos enlaces mediante display:none, visibility:hidden, text-indent negativo o con una imagen invisible, anulando además el indentado del enlace. Usaremos por tanto las CSS de los dispositivos que nos convenga para mostrarlo o no.

Jlvelazquez reivindica, y estoy con él, que no deberíamos ocultarlos sino ofrecerlos como una herramienta más.

En cualquier caso, si se desea ocultar, hay que tener en cuenta que en función de la forma seleccionada se leerá/mostrará o no. En su artículo incluye una tabla aclaratoria que puede ser completada con esta otra.

Como vemos, es mejor evitar el display:none y el visibility:hidden.

Por otro lado, el acceso de teclado (acceskey) que le ha asignado al enlace de saltar al contenido es la "S". Si te preguntas qué es un acceso de teclado o por qué la "S", lo mejor es que leas “Atajos de teclado en documentos Web" de Accesibilidad Web y Alan.

Tal y como indica, los atajos propuestos por el gobierno del Reino Unido son:

S - Saltar navegación
1 - Página de inicio
2 - Novedades
3 - Mapa del sitio
4 - Búsqueda
5 - Preguntas frecuentes (FAQ)
6 - Ayuda
7 - Reclamaciones
8 - Términos y condiciones
9 - Contactar
0 - Definición de teclas rápidas

En Suecia, en las Swedish National Guidelines for Public Sector Websites, las teclas de acceso rápido que se indican para los portales de la Administración Pública son, según ellos mismos indican, basadas en las del Reino Unido:

S - Skip navigation, go directly to text content
0 - “About the website”, accessibility information. Provided details on access keys
1 - “Home” page
2 - News. Collection of news
3 - Content outline. A site map, or perhaps A-Z
4 - Search. Should be connected to the search field that searches the entire website
5 - Frequently Asked Questions (FAQ)
6 - Help. For example, about a specific service.
7 - Contact us. Page with contact details to important functions within the government agency.
8 - Legal information. Page that describe the website’s privacy policy and how legal information such as cookies are handled.

Ya he comentado en el apartado de navegación semántica el atributo "rel", es interesante el artículo sobre rev y rel "Hypertext links in HTML" de Murray Maloney y Liam Quin

     
<div id="cabeceraDiv">       
[…]       
</div>       


<div id="migasDiv">       
[…]       
</div>       


<div id="contenidoDiv"><a id="content" name="content">Inicio del contenido</a>       
[…]       
</div>       


<div id="menuDiv"><a id="menu" name="menu">Menu</a>       
<ul>       
   <li><a href="" accesskey="" rel="" rev=""></a>       
      <ul>       
        <li><a href="" accesskey="" rel="" rev=""></a></li>       
      </ul>       
  </li>       
</ul>       
</div>       


<div id="pieDiv"><a id="copyright" name="copyright">Copyright</a>       
[…]       
</div>       

</div>

Supongo que lo primero que llama la atención es que el código del menú esté al final de la página, por supuesto esto no tiene nada que ver con la situación visual del mismo que se define en la CSS. Prefiero colocarlo al final, porque ya tenemos al comienzo la navegación semántica y los dos enlaces de saltar al contenido y al menú, así que coloquemos lo primero el contenido, que es lo realmente importante de nuestra página.

Otro dato importante es que la estructura de nuestra página siempre ha de estar armada mediante DIV y nunca mediante tablas... no creo que hoy en día haya nadie capaz de rebatir esto.

También es importante que el menú esté estructurado mediante listas anidadas (si has leído el artículo completo ya no es necesario que explique los atributos "rel" y "rev").

El punto 9.5 de las pautas WCAG recomienda incluir atajos de teclado para los enlaces importantes. La Administración Pública del Reino Unido tiene definido un estándar de teclas rápidas en la guía para desarrolladores (Web handbook), como defiende Accesibilidad Web y Alan en "Atajos de teclado en documentos Web ". apliquemos las mismas:

S - Saltar navegación
1 - Página de inicio
2 - Novedades
3 - Mapa del sitio
4 - Búsqueda
5 - Preguntas frecuentes (FAQ)
6 - Ayuda
7 - Reclamaciones
8 - Términos y condiciones
9 - Contactar
0 - Definición de teclas rápidas

Por último, y en referencia a las anclas, indicar que el atributo id para marcar anclas se puede utilizar en cualquier etiqueta, sin embargo puede que algunos navegadores no lo reconozcan como un ancla, por eso se suele "anclar" sobre elementos a; se incluye el name también porque algunos viejos navegadores es posible que no reconozcan el atributo id.

No he dejado las anclas vacías, sino que he incluido dentro un texto; posteriormente se puede mover el ancla o sustituir este texto según el contenido y la estructura final de la página.

Puedes ampliar información en el W3C.

Otros enlaces de interés:

"Ocho pasos para servir buen XHTML" de Torres Burriel
Dive Into Accessibility.30 days to a more accessible web site
"Tags HTML no recomendados y sus alternativas" de Anieto2k

BODY: Microformatos

Ya hemos visto cómo añadir información semántica a la página mediante metas, mediante ficheros RDF, etc. Otra manera son los microformatos, una forma de representar información semántica cuyo objetivo principal es ser útil a las personas y no a las máquinas. Esta información aparece entre las etiquetas <body> y </body> de un documento HTML.

Los microformatos se salen ya del objetivo del artículo, si necesitas ampliar información te recomiendo:

el brillante artículo de Web semántica hoy “Etiquetas meta, ficheros RDF, microformatos: 3 sabores de la Web Semántica"
"Dublin Core Metadata Gen: Generador de metadatos Dublin Core" de Webposible
"hCard" de microformats.org

Fin del documento

     
</body>       

</html>

Plantilla XHTML base

Por supuesto habrá que adaptarla al desarrollo concreto, modificando lo que sea necesario (por ejemplo el title, la descripción de la página, etc.) y eliminado lo que no lo sea (por ejemplo, aquellos metas que no consideremos necesarios). Para ello te será de utilidad la información recopilada en el artículo.

La plantilla se distribuye bajo un contrato ColorIURIS. Deberás aceptar el contrato antes de descargarla:

Descargar Plantilla XHTML base

Usable y accesible

Web Usability Guidelines–Directrices de usabilidad web

Índice

HHS Guidelines

247 directrices de usabilidad web de Userfocus

Nielsen Norman Group Guidelines

Swedish National Guidelines for Public Sector Websites

Sirius

Australia Government Usability Checklist

Guía para el Desarrollo de Sitios Web del Gobierno de Chile

Usability Guidelines del MIT (Massachusetts Institute of Technology)

Directrices de usabilidad para sitios web del Estado colombiano

Otros enlaces de interés

Qué teclas de acceso rápido (accesskey) utilizar

UK Government accesskeys standard

Swedish Government accesskeys standard

Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

Índice

Qué es un estándar

Tipos de estándares

Estándares formales de usabilidad

Orientados al proceso: ISO 9241 e ISO 13407

ISO 9241 Ergonomics of Human System Interaction

ISO 13407:1999. Human centred design processes for interactive systems

Orientados al producto: ISO 9126 e ISO 14598

ISO 9126 Software engineering — Product quality

ISO 14598 Information technology — Software product evaluation

Ventajas y desventajas de la definición de usabilidad como proceso y como producto

ISO 25000 (SQUARE): unificación y revisión de los estándares ISO/IEC 9126 e ISO/IEC 14598

Aplicación práctica de los estándares formales en la evaluación heurística de la web

WUEP (Web Usability Evaluation Process)

Otras propuestas

Mplu+a

WebQEM

WQM (Web Quality Model)

QUIM (Quality in Use Integrated Measurement)

Referencias

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements

Descripción detallada de la tabla

Columna A: Elemento

Columna B: Descripción

Columna C: Desaprobado/No estándar/Obsoleto

Columna D: Web Browser Support

Columna E-L: Especificación

Columna M: Notas de accesibilidad

Columna N: ¿Semántico?

Otros enlaces de interés:

HTML 5

Antecedentes

Aplicaciones para desarrollo con HTML 5

Recursos HTML 5

Plantillas HTML 5

HTML 5 y accesibilidad

Soporte de HTML 5

Validador automático de sintaxis HTML 5

Desarrollos en HTML 5

Logotipos e iconos

Noticias

Artículos de interés

Plantilla base XHTML

Declaración de tipo de documento DOCTYPE

HTML

HEAD

METAS

Metas http-equiv

Metas name

Metas Dublin Core

Metas Geotags

Metadatos en RDF

CSS

Navegación semántica

JS

BODY

BODY: Estructura de contenidos

BODY: Microformatos

Fin del documento

Plantilla XHTML base