Los textos de qweos.net

Cocktail Cadius Canarias (C3) de Mayo 2009

2009-05-05T09:45:33Z

Nueva web para Cadius Canarias

Como mencionábamos hace (demasiado) tiempo, la primera versión de la web para Cadius en Canarias está en línea. Todavía tiene algunos errores conocidos y pendientes de corrección, así que paciencia, ya saben que estos proyectos van a otro ritmo

Existían varios motivos para crear una web para la Comunidad Cadius en Canarias:

Descentralizar la labor de publicación. Ahora cualquiera de nuestros miembros habituales puede publicar, de hecho, varios ya tienen su cuenta y libertad total para escribir lo que deseen. Esperamos que ayude a que se involucren y se sientan más partícipes de Cadius.
Unificar la información. Ya no será necesario consultar los blogs personales que, hasta este momento, publicaban los eventos Cadius en Canarias. Desde un único lugar se podrá estar al día de todo lo relacionado con Cadius Canarias y las temáticas afines.
Anunciar eventos de interés. Hemos integrado un completo calendario de eventos relacionados con los temas habituales de Cadius: usabilidad, diseño de interacción, accesibilidad… está integrado en Google Calendar por lo que cualquiera puede aportar sus eventos.
Compartir conocimientos. Nuestra intención es que la información sea útil para todos. Cadius Canarias utiliza WordPress y, desde que acabemos de corregir algunos defectos, compartiremos nuestro desarrollo con cualquier ciudad Cadius que lo quiera usar, modificar y mejorar.

Cambios en los anuncios de los Cócteles Cadius Canarias

Como comentábamos antes, partir de este mes, los eventos relacionados con la Comunidad Cadius en Canarias se publicarán en Cadius Canarias. Desde qweos.net simplemente se hará una reseña a la convocatoria que corresponda.

Por el momento ya está anunciado el Cocktail Cadius de Mayo en Las Palmas de Gran Canaria.

Cocktail Cadius Canarias – abril 2009

2009-04-16T13:34:28Z

Actualización: debido a diversos imprevistos, la mayoría de nosotros no podremos asistir esta noche, así que hemos decidido suspender el Cóctel de abril 2009. Lamentamos la falta de tiempo en el aviso. Nos vemos el próximo mes.

Cocktail Cadius Canarias (edición en Las Palmas de Gran Canaria)

Este mes lo retrasamos al jueves, 16 de abril de 2009, sobre las 20:30 horas, en la Tasca La Barbería (Mendizábal, 14. 35001- Vegueta, Las Palmas de Gran Canaria).

¿Cómo llegar? Míralo en este mapa (PNG – 38Kb.) o a través de Google Maps.

Cocktail Cadius Canarias (edición en Santa Cruz de Tenerife)

Suponemos que nuestros compañeros de Cadius en Tenerife lo anunciarán en breve.

¿Más información?

¿Qué son los Cocktails Cadius? Te lo explicamos.
¿Quieres participar? Tan sencillo como comentarlo en esta entrada.

Por favor, rogamos que confirmen su asistencia.

World Usability Day (WUD) 2009 – Designing for a Sustainable World

2009-03-24T15:51:36Z

Con el lema de "Diseño para un Mundo Sostenible" se celebrará el próximo Día Mundial de la Usabilidad el jueves, 12 de noviembre de 2009. Este evento se celebra desde hace 5 años y es organizado por la Usability Professionals’ Association (UPA) con carácter internacional.

Desde Cadius Canarias participamos activamente en las ediciones 2005 y 2006 hasta que en 2007 se convirtió en un negocio. Este año parece que han recapacitado y el registro de eventos será gratuito para todos. El formulario de inscripción estará disponible a partir del 1 de abril de 2009 en la web oficial del evento.

Cualquier persona u organización relacionada con el diseño centrado en el usuario, la sostenibilidad y áreas afines están invitadas a participar. Vayan proponiendo ideas.

Cocktail Cadius Canarias – marzo 2009

2009-03-02T09:46:06Z

Cocktail Cadius Canarias (edición en Las Palmas de Gran Canaria)

Tendrá lugar el jueves, 5 de marzo de 2009, sobre las 20:30 horas, en la Tasca La Barbería (Mendizábal, 14. 35001- Vegueta, Las Palmas de Gran Canaria).

¿Cómo llegar? Míralo en este mapa (PNG – 38Kb.) o a través de Google Maps.

Cocktail Cadius Canarias (edición en Santa Cruz de Tenerife)

Nuestros compañeros de Cadius en Tenerife lo celebrarán también el jueves, 5 de marzo, sobre las 20 horas.

¿Más información?

¿Qué son los Cocktails Cadius? Te lo explicamos.
¿Quieres participar? Tan sencillo como comentarlo en esta entrada.

Por favor, rogamos que confirmen su asistencia.

Cocktail Cadius Canarias – febrero 2009

2009-01-31T14:47:11Z

Cocktail Cadius Canarias (edición en Las Palmas de Gran Canaria)

Tendrá lugar el jueves, 5 de febrero de 2009, sobre las 20:30 horas, en la Tasca La Barbería (Mendizábal, 14. 35001- Vegueta, Las Palmas de Gran Canaria).

¿Cómo llegar? Míralo en este mapa (PNG – 38Kb.) o a través de Google Maps.

Cocktail Cadius Canarias (edición en Santa Cruz de Tenerife)

Suponemos que nuestros compañeros de Cadius en Tenerife lo anunciarán en breve.

¿Más información?

¿Qué son los Cocktails Cadius? Te lo explicamos.
¿Quieres participar? Tan sencillo como comentarlo en esta entrada.

Por favor, rogamos que confirmen su asistencia.

Guías Prácticas para Profesionales Web: Puntos de verificación de las Pautas de Accesibilidad al Contenido Web (WCAG) 2.0

2009-03-26T14:48:15Z

Hacía aproximadamente un año y medio que no se publicaba nada nuevo en las Guías Prácticas para Profesionales Web. Ya iba siendo hora y, esta vez, nos toca ponernos al día y hablar de los checklists (puntos de verificación) de las WCAG 2.0.

Notas importantes:

El siguiente contenido no son las Web Content Accessibility Guidelines (WCAG) 2.0. Es una simple lista que presenta los principios y técnicas de las WCAG 2.0 en un formato más amigable y comprensible. El lenguaje utilizado ha sido modificado y simplificado de manera significativa respecto a la especificación oficial para permitir comprobar y verificar las páginas web de una forma más sencilla. Si bien esta lista puede resultar muy útil para comprobar la accesibilidad y conformidad con respecto a las WCAG 2.0, utilice la documentación oficial para verificar la conformidad real.
Este documento, en constante mejora y revisión, es una traducción libre, modificada y autorizada del publicado en inglés bajo el título WCAG 2.0 Checklist, propiedad de WebAIM (Web Accessibility in Mind).
Las referencias se han enlazado con su correspondencia en la especificación original (en inglés), aunque existe una traducción, no oficial, realizada por Saúl González Fernández: Pautas de Accesibilidad de Contenido Web 2.0.
Comparativas y correspondencias con otras Pautas:
- Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order. Listing by Checkpoint (en inglés)
- Actualización del 3 de marzo de 2009; comparativa entre los puntos de comprobación de las Pautas de Accesibilidad de Contenido Web 1.0 y las Pautas 2.0, agrupados por prioridades. Traducción española de Saúl González Fernández.
- Actualización del 16 de marzo de 2009; correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0, por Olga Carreras.
- Actualización del 26 de marzo de 2009; Migrating from WCAG 1.0 to WCAG 2.0, por Roger Hudson.
Se permite la reproducción de este artículo citando a los autores y enlazando a sus correspondientes versiones originales (en ambos casos, tanto de la versión original como de la traducida).
Si encuentra algún fallo (algo bastante posible), estaría muy agradecido de que me lo comunicara. Espero que les sea de utilidad.

Principios de fundamentales de accesibilidad (resumen)

Las WCAG 2.0, recomendación oficial desde el 11 de diciembre de 2008, como comentábamos hace mucho tiempo atrás, se organizan en 4 principios fundamentales para la accesibilidad del contenido:

Perceptible
Operable
Comprensible
Robusto

En total conforman 12 pautas o directrices (guidelines); los dos primeros principios tienen cuatro pautas asociadas, el tercero tiene tres y el último una pauta. Estas pautas proporcionan los objetivos básicos para hacer el contenido accesible, y sirven para comprender los criterios de éxito e implementarlos (Olga Carreras). Se han definido 60 criterios de éxito o puntos de comprobación que definen el nivel de accesibilidad (A, AA o AAA).

Perceptible

El contenido web debe estar disponible (ser perceptible) para los sentidos – vista, audición, y/o tacto.

Pauta 1.1. Alternativas textuales. Ofrezca alternativas en forma de texto para todo el contenido no textual.

Criterios de éxito	Nivel	Recomendaciones
1.1.1 Contenido no textual	A	Todas las imágenes, botones de imagen de los formularios y las zonas activas de los mapas de imagen, tendrán un texto alternativo adecuado. Las imágenes que no transmitan contenidos, sean decorativas o con el contenido ya presente como texto se ofrecerán con el texto alternativo vacío (`alt=""`) o aplicadas como fondos de imagen CSS. Todas las imágenes enlazadas contarán con un texto descriptivo alternativo. El contenido equivalente alternativo para las imágenes complejas se ofrecerá en una página (enlazada o referenciada mediante `longdesc`) aparte. Los botones de los formularios tendrán nombres (`value`) descriptivos. Los elementos de los formularios tendrán etiquetas textuales (`label`) asociadas o, si éstas no pueden utilizarse, un título (`title`) descriptivo. Los elementos multimedia incrustados (embedded) se identificarán mediante textos accesibles. Los marcos (frames) tendrán un título apropiado.

Pauta 1.2. Contenido dependiente del tiempo: ofrezca alternativas para los contenidos que dependan del tiempo.

Nota: si el audio o vídeo ha sido designado como una alternativa al contenido web (por ejemplo, una versión sonora o en lengua de signos de la página web), entonces, el contenido web por sí mismo funciona como la alternativa.

Criterios de éxito	Nivel	Recomendaciones
1.2.1 Sólo audio y sólo vídeo pregrabado	A	Se ofrecerá una transcripción descriptiva (incluyendo todas las pistas e indicadores visuales y auditivos) para el audio grabado (no en directo) basado en web (podcast de audio, archivos MP3, etc.) Se ofrecerá una descripción auditiva o textual para los vídeos grabados (no en directo) sin audio basados en web (por ejemplo, vídeos que no incluyen pistas de audio)
1.2.2 Subtítulos (Pregrabados)	A	Se ofrecerán subtítulos para los vídeos grabados (no en directo) basados en web (vídeos de YouTube, etc.)
1.2.3 Audio descripciones o Contenidos "media" alternativos (Pregrabados)	A	Se ofrecerá una transcripción O audio descripción de los vídeos basados en web grabados (no en directo)
1.2.4 Subtitulado (En directo)	AA	Se ofrecerán subtítulos sincronizados con el audio para todo el contenido multimedia ofrecido en directo (emisiones sólo audio, web cast, videoconferencias, animaciones Flash, etc.)
1.2.5 Audio descripción (Pregrabado)	AA	Se ofrecerán audio descripciones para todo el contenido de vídeo. Nota: sólo será necesario si el vídeo transmite contenido visual que no está disponible por defecto en la pista de audio.
1.2.6 Lengua de signos (Pregrabada)	AAA	Se ofrecerá un vídeo en lengua de signos para todo el contenido "media" que contenga audio.
1.2.7 Audio descripción extendida (Pregrabada)	AAA	Cuando una pista de audio descripción no se pueda añadir al vídeo debido a la sincronización del audio (por ejemplo, no existen pausas en el audio), se proporcionarán una versión alternativa del vídeo con pausas que permitan las descripciones de audio.
1.2.8 Alternativas "media" (Pregrabado)	AAA	Se ofrecerá una transcripción descriptiva para todos los medios pregrabados que contengan una pista de vídeo.
1.2.9 Sólo audio (En directo)	AAA	Se ofrecerá una transcripción descriptiva (por ejemplo, el guión de una presentación en vivo de audio) para todos los contenidos en directo que contengan audio.

Pauta 1.3. Adaptable: crea contenido que pueda presentarse de diferentes maneras (por ejemplo, un diseño simplificado) sin perder la información o estructura.

Criterios de éxito	Nivel	Recomendaciones
1.3.1 Información y sus relaciones	A	El marcado semántico se usará para designar los encabezados (`<h1>`), listas (`<ul>`, `<ol>`, and `<dl>`), texto especial o enfatizado (`<strong>`, `<code>`, `<abbr>`, `<blockquote>`, por ejemplo), etc. El marcado semántico deberá usarse apropiadamente. Las tablas se usarán para marcar los datos tabulados. Las celdas de datos (`<td>`) se asociarán con sus encabezados (`<th>`) donde sea necesario. Los títulos de las tablas (`caption`) y sus resúmenes (`summary`) se usarán de forma apropiada. Las etiquetas (`label`) textuales se asociarán con sus campos (`input`) correspondientes en los formularios. Los elementos de los formularios que estén relacionados se agruparán mediante `fieldset/legend`.
1.3.2 Secuencia con significado	A	El orden de navegación y lectura (determinado por el orden en el código fuente) será lógico e intuitivo.
1.3.3 Características sensoriales	A	Las instrucciones no dependerán de la forma, tamaño o ubicación visual (por ejemplo, "Haga clic en el icono cuadrado para continuar" o "Las instrucciones están en la columna de la derecha"). Las instrucciones no dependerán del sonido (por ejemplo, "Un sonido beep le indica que puede continuar").

Pauta 1.4. Distinguible: facilite a los usuarios el ver y escuchar el contenido, incluyendo la separación entre el primer plano y el fondo.

Criterios de éxito	Nivel	Recomendaciones
1.4.1 Uso del color	A	No use el color como el único método para transmitir el contenido o distinguir elementos visuales. Los enlaces deben distinguirse de los elementos y texto que les rodean. Si utiliza el color para diferenciar los enlaces, use una forma adicional para distinguirlos. (por ejemplo, se subrayan cuando reciben el foco).
1.4.2 Control del audio	A	Se debe ofrecer un mecanismo para poder parar, pausar, silenciar o ajustar el volumen de cualquier sonido que se reproduzca automáticamente en la página más de tres segundos.
1.4.3 Contraste (mínimo)	AA	El texto o las imágenes de texto deben tener una relación de contraste de al menos 4.5:1, excepto en los siguientes casos: En los textos grandes (de más de 18 puntos o 14 puntos en negrita) y las imágenes de texto grandes la relación de contraste debe ser de al menos 3:1. En los textos, o las imágenes de texto, que forman parte de un componente de la interfaz de usuario inactivo, que son meramente decorativos, que no son visibles o que forman parte de una imagen cuyo significado es visual, no tienen un requisito mínimo de contraste. Los textos que forman parte de un logotipo o de una marca comercial no tiene un requisito mínimo de contraste. Nota del traductor: puede usar algunas herramientas para comprobar el contraste, por ejemplo, Color Contrast Checker o Luminosity Colour Contrast Ratio Analyser.
1.4.4 Tamaño del texto	AA	La página deberá ser legible y funcional cuando se doble el tamaño del texto. La interpretación del diseñador web Roger Johansson a este punto es que hasta que la amplia mayoría de los usuarios utilicen navegadores que soporten zoom (y el soporte del zoom de los navegadores mejore), deberíamos comprobar que el texto de nuestras páginas puede ser ampliado hasta un 200%.
1.4.5 Imágenes de texto	AA	Si la misma representación visual puede realizarse usando sólo texto, no deben usarse imágenes para representar ese texto.
1.4.6 Contraste (aumentado)	AAA	El texto o las imágenes de texto deben tener una relación de contraste de al menos 7:1. Los textos grandes (de más de 18 puntos o 14 puntos en negrita) deben tener una relación de contraste de al menos 4.5:1. Nota del traductor: utilice las herramientas de comprobación del contraste existentes para verificar esos valores, por ejemplo, Color Contrast Checker.
1.4.7 Bajo o sin sonido de fondo	AAA	Compruebe que no hay o existe un ruido de fondo muy bajo que permita distinguir fácilmente las conversaciones.
1.4.8 Presentación visual	AAA	Para bloques de texto de más de una frase de longitud: No habrá más de 80 caracteres de ancho No estarán justificados a ambos lados (alineados los márgenes izquierdo y derecho) Tendrán un interlineado (de al menos la mitad de la altura del texto) y espacio entre párrafos (1.5 veces la medida del interlineado) adecuado. Tendrán especificados un color de primer plano y fondo. Estos se pueden aplicar a elementos específicos de la página o en su totalidad utilizando CSS (y, por tanto, heredados por el resto de elementos). No aparecerá desplazamiento horizontal cuando se doble el tamaño del texto.
1.4.9 Imágenes de texto (sin excepción)	AAA	Sólo se usarán imágenes de texto para decorar cuando no transmitan información o cuando la información no pueda presentarse de ninguna otra manera (por ejemplo, cuando el texto forme parte del logotipo de una empresa).

Operable

Los formularios, controles, navegación y otros elementos de la interfaz deben permitir la interacción.

Pauta 2.1. Accesibilidad mediante el teclado: permita que toda la funcionalidad esté disponible usando el teclado

Criterios de éxito	Nivel	Recomendaciones
2.1.1 Teclado	A	Todas funciones de las páginas deberán estar disponibles utilizando el teclado, excepto aquellas que de forma conocida no pueden realizarse con el teclado (por ejemplo, un dibujo a mano alzada). Los atajos de teclado y `accesskeys` (que normalmente deberían evitarse) no deben entrar en conflicto con las presentes en el navegador y/o lector de pantalla.
2.1.2 Teclado no bloqueado	A	El foco del teclado no deberá estar bloqueado o fijado en un elemento concreto de la página. El usuario deberá poder moverse por todos los elementos navegables de la página utilizando únicamente el teclado.
2.1.3 Teclado (Sin excepción)	AAA	Toda la funcionalidad de las páginas deberán estar disponibles utilizando el teclado.

Pauta 2.2 Suficiente tiempo: ofrezca a los usuarios el tiempo suficiente para que puedan leer y utilizar el contenido

Criterios de éxito	Nivel	Recomendaciones
2.2.1 Tiempo ajustable	A	Si una página o aplicación tiene un límite de tiempo para realizar una tarea deberá ofrecer la opción de apagar, ajustar o aumentar ese límite de tiempo. No es un requisito para eventos en tiempo real (por ejemplo, una subasta) donde el límite de tiempo es absolutamente necesario, o si el plazo de tiempo es de más de 20 horas.
2.2.2 Pausar, parar, ocultar	A	Todo movimiento automático, parpadeo o desplazamiento de más de tres segundos deberá poderse pausar, parar u ocultar por el usuario. El movimiento, parpadeo, o desplazamiento podrá usarse para llamar la atención del usuario o destacar un contenido si dura menos de tres segundos. El contenido actualizado automáticamente (por ejemplo, una página recargada o redireccionada automáticamente, un ticker de noticias, la actualización de un campo mediante AJAX, un aviso, etc.) deberá poder ser pausado, parado u ocultado por el usuario o el usuario deberá poder controlar manualmente los tiempos de actualización.
2.2.3 Sin tiempo	AAA	El contenido y funcionalidad no tendrá limitaciones de tiempo.
2.2.4 Interrupciones	AAA	Las interrupciones (alertas, actualizaciones de las páginas, etc.) deberán poder ser pospuestas o canceladas por el usuario.
2.2.5 Re-autentificación	AAA	Si la autentificación en una sesión termina (expira), el usuario podrá re-autentificarse y continuar con su actividad sin perder ningún dato de la página actual.

Pauta 2.3. Convulsiones: no diseñe los contenidos de tal forma que puedan provocar ataques o convulsiones

Criterios de éxito	Nivel	Recomendaciones
2.3.1 Tres destellos (flashes) o debajo del umbral	A	No deberá crear contenidos que destellen más de tres veces por segundo a menos que el parpadeo sea lo suficientemente pequeño, los destellos sean de bajo contraste y no contengan demasiado rojo. (Véase el apartado sobre el destello en general y el umbral de destello del rojo, en inglés)
2.3.2 Tres destellos	AAA	No deberá crear contenidos que destellen más de tres veces por segundo.

Pauta 2.4 Navegable: ofrezca métodos que ayuden al usuario a navegar, encontrar el contenido y determinar dónde se encuentra

Criterios de éxito	Nivel	Recomendaciones
2.4.1 Accesos directos	A	Se ofrecerá un enlace para saltar la navegación y otros elementos que se repitan en todas las páginas. Si una página cuenta con una estructura adecuada de encabezados, puede considerarse una técnica suficiente en lugar de un enlace del tipo "Ir al contenido principal". Tenga en cuenta que la navegación por encabezados todavía no está soportada en todos los navegadores. Si una página utiliza un conjunto de marcos (frameset) y los marcos (frame) están apropiadamente titulados, puede considerarse una técnica suficiente para acceder directamente a cada marco individual.
2.4.2 Título de la página	A	La página web deberá tener un título descriptivo e informativo de la misma.
2.4.3 Orden del foco	A	El orden de la navegación por los enlaces, elementos de los formularios, etc. deberá ser lógico e intuitivo.
2.4.4 Propósito de los enlaces (en su contexto)	A	Siempre que no sean ambiguos para los usuarios en general, los enlaces (o botones de imagen en un formulario, o zonas activas en un mapa de imagen) serán lo suficientemente descriptivos como para identificar su propósito (objetivo) directamente desde el texto enlazado o, en su caso, desde el enlace en su contexto (por ejemplo, en los párrafos que lo rodean, elementos de una lista, celdas o encabezados en una tabla, etc.). Los enlaces (o botones de imagen en un formulario) con el mismo destino deberían tener las mismas descripciones (ser consistentes, según criterio de éxito 3.2.4), pero los enlaces con diferentes propósitos y destinos deberían tener diferentes descripciones.
2.4.5 Múltiples vías	AA	Se deben ofrecer múltiples formas para encontrar otras páginas web en el sitio – al menos dos de las siguientes: una lista de páginas relacionadas, tabla de contenidos, mapa web, búsqueda en el sitio, o un listado de todas las páginas web.
2.4.6 Encabezados y etiquetas	AA	Los encabezados (`<h>`) de las páginas y las etiquetas (`<label>`) para los controles interactivos de los formularios deberán ser informativos. Evite el duplicar los encabezados (por ejemplo, "Más detalles") y las etiquetas de texto (por ejemplo, "primer nombre") a menos que la estructura ofrezca una diferenciación adecuada entre ellas.
2.4.7 Visibilidad del foco	AA	Compruebe que es visualmente evidente el elemento que tiene el foco actual del teclado (por ejemplo, si se mueve con el tabulador por la página, puede ver dónde se encuentra).
2.4.8 Ubicación	AAA	Si la página web forma parte de una secuencia de páginas o está dentro de un sitio con una estructura compleja, deberá indicar la ubicación de la página actual, por ejemplo, a través de las migas de pan (breadcrumbs) o especificando el paso actual en la secuencia (por ejemplo, "Paso 2 de 5 – dirección de envío").
2.4.9 Propósito de los enlaces (enlaces sin contexto)	AAA	Siempre que no sean ambiguos para los usuarios en general, los enlaces (o botones de imagen en un formulario, o zonas activas en un mapa de imagen) serán lo suficientemente descriptivos como para identificar su propósito (objetivo) directamente desde el texto enlazado. No deberán existir enlaces (o botones de imagen en un formulario) con el mismo texto que vinculen a lugares diferentes (por ejemplo, "Lea más").
2.4.10 Encabezados de sección	AAA	Además de proporcionar un documento con la estructura global del sitio, cada una de las secciones de contenido deberán ser designadas mediante encabezados (títulos), donde sea oportuno.

Comprensible

El contenido y la interfaz deben poder entenderse fácilmente y ser semánticamente ricos.

Pauta 3.1 Legibilidad: cree contenidos legibles y fáciles de entender

Criterios de éxito	Nivel	Recomendaciones
3.1.1 Idioma de la página	A	El idioma principal de la página deberá estar identificado utilizando el atributo `lang` de HTML (por ejemplo, `<HTML lang="es">`).
3.1.2 Idioma de las partes	AA	Si algunas secciones tienen contenidos en un idioma diferente al principal, éste deberá estar identificado utilizando el atributo `lang` (por ejemplo, `<blockquote lang="en">`) cuando sea apropiado. Existen algunas excepciones: nombres propios, términos técnicos, palabras o frases en un lenguaje indeterminado o inventado, locuciones propias de la lengua (vernaculares) que se entienden dentro del contexto (por ejemplo, locuciones latinas en español).
3.1.3 Palabras inusuales	AAA	Las palabras que puedan ser ambiguas, desconocidas o usadas de una forma muy específica, deberán definirse través de un texto adyacente, una lista de definiciones, un glosario, o de cualquier otro método.
3.1.4 Abreviaturas	AAA	La explicación para las abreviaturas se realizará, usando el elemento `<abbr>` o enlazando a un glosario de términos, la primera vez que se utilicen en el contenido. Nota: WCAG 2.0 no hace excepciones con las abreviaciones conocidas en un determinado ámbito (por ejemplo, la abreviatura HTML utilizada en un sitio de desarrollo web deberá también ser explicado).
3.1.5 Nivel de lectura	AAA	Una alternativa para hacer los contenidos más comprensibles es suponer que aquellos que sean más avanzados puedan ser razonablemente leídos por una persona con aproximadamente 9 años de educación primaria.
3.1.6 Pronunciación	AAA	Si la pronunciación de una palabra es vital para comprenderla, su pronunciación se mostrará seguida de dicha palabra o mediante un enlace a un glosario.

Pauta 3.2. Predecible: cree páginas web que se muestren y funcionen de forma previsible

Criterios de éxito	Nivel	Recomendaciones
3.2.1 Foco	A	Cuando un elemento reciba el foco no se deberá iniciar un cambio en la página que confunda o desoriente al usuario.
3.2.2 Cambios imprevistos	A	Deberá advertir al usuario con antelación de los cambios, imprevistos o automáticos, en la configuración de cualquier elemento de la interfaz que causen una modificación en la página.
3.2.3 navegación consistente	AA	Los enlaces de navegación que se repiten en las páginas web no deberían modificar su orden al navegar por el sitio.
3.2.4 Identificación consistente	AA	Los elementos que tienen la misma funcionalidad a través de múltiples páginas web deberán identificarse de manera consistente. Por ejemplo, un campo de búsqueda en la parte superior de la página deberá etiquetarse siempre de la misma forma.
3.2.5 Solicitud de cambio	AAA	Los cambios sustanciales de las páginas, la aparición de ventanas emergentes (pop-ups), los cambios no controlados del foco del teclado, o cualquier otro cambio que podría confundir o desorientar al usuario deberán ser iniciados por éste. Alternativamente, siempre se le deberá ofrecer al usuario una opción para desactivar dichos cambios.

Pauta 3.3. Asistencia en la introducción de datos: ayude a los usuarios a evitar y corregir los errores

Criterios de éxito	Nivel	Recomendaciones
3.3.1 Identificación de errores	A	Ofrezca información al usuario sobre los campos obligatorios de un formulario, o aquellos que necesitan un formato, valor o longitud específica, utilizando el elemento `<label>` (si éste no está disponible ponga la información en el atributo de título `title` del elemento). Si se usa la validación de datos de los formularios (del lado del cliente o del servidor), ofrezca la información sobre los errores y avisos de forma eficiente, intuitiva y accesible. Los errores deben estar claramente identificados, ofrecer un acceso rápido al elemento problemático, permitir que el usuario pueda fácilmente solucionar el error y reenviar los datos del formulario.
3.3.2 Etiquetas o instrucciones	A	Se deberán proporcionar las suficientes etiquetas, avisos e instrucciones necesarios para los elementos interactivos. Use para ello instrucciones, ejemplos, posicionane adecuadamente las etiquetas (`label`) y agrupe e identifique los campos con `fieldsets/legends`
3.3.3 Sugerencias de error	AA	Si se detecta un error al introducir un dato (mediante la validación en el lado del cliente o en el del servidor), deberá proporcionar sugerencias para solucionar el problema de forma oportuna y accesible.
3.3.4 Prevención de errores (Legales, financieros, de datos)	AA	Si el usuario puede modificar o eliminar datos de carácter legal, financiero o de prueba, estas acciones deberán ser reversibles, verificadas o comprobadas.
3.3.5 Ayuda	AAA	Si el usuario puede enviar, cambiar o eliminar información, la información deberá poder volver a estar disponible, y/o las acciones realizadas ser verificadas o confirmadas.
3.3.6 Prevención de errores (todos)	AAA	Si el usuario puede enviar información, el envío deberá poder ser reversible, verificado o confirmado.

Robusto

El contenido debe ser lo suficientemente consistente y fiable como para permitir su uso con una amplia variedad de agentes de usuario, ayudas técnicas… y preparado para las tecnologías venideras.

Pauta 4.1. Compatible: mejore la compatibilidad con los agentes de usuario actuales y futuros, incluidas las ayudas técnicas.

Criterios de éxito	Nivel	Recomendaciones
4.1.1 Análisis	A	Se deberán evitar los errores de sintaxis de HTML/XHTML. El código puede comprobarse, analizarse y validarse a través de http://validator.w3.org/
4.1.2 Nombre, función, valor	A	Deberá utilizar el marcado de tal forma que se facilite la accesibilidad. Esto incluye el seguir las especificaciones oficiales de HTML/XHTML, utilizando la gramática formal de forma apropiada.

Más sobre Jonás, la serie de animación

2009-01-26T14:22:01Z

Hace unos meses les hablaba de Jonás, una serie de animación de gran calidad y 100% hecha en Canarias.

Ahora pueden conocer a sus creadores y su trabajo en el próximo mixtura Lab: Jonás. La animación "desde dentro". Será el viernes, 30 de enero de 2009 a las 18:00h., en la mediateca de Gran Canaria Espacio Digital (abre Google Maps).

Mientras, pueden disfrutar de los cortos publicados:

Cocktail Cadius Canarias – enero 2009

2009-01-07T11:13:50Z

Cocktail Cadius Canarias (edición Las Palmas G.C.)

Después de tantas fiestas, será el jueves, 15 de enero de 2009, como siempre, sobre las 20:30 horas en la Tasca La Barbería (Mendizábal, 14. 35001- Vegueta, Las Palmas de Gran Canaria).

¿Cómo llegar? Míralo en este mapa (PNG – 38Kb.) o a través de Google Maps.

Cocktail Cadius Canarias (edición Santa Cruz de Tenerife)

Nuestros compañeros de Cadius en Tenerife celebrarán su reunión el jueves, 8 de enero de 2009.

¿Más información?

¿Qué son los Cocktails Cadius? Te lo explicamos.
¿Quieres participar? Tan sencillo como comentarlo en esta entrada.

Por favor, rogamos que confirmen su asistencia.

Crónica del Cocktail Cadius en Las Palmas de Gran Canaria – Diciembre 2008

2008-12-18T13:25:57Z

Lo cierto es que no pensé que el último Cocktail Cadius de 2008 en Las Palmas de Gran Canaria fuera a ser tan ameno y concurrido. Normalmente no solemos hacer crónicas de los cócteles, pero esta vez, por el interés y variedad de las temáticas tratadas les ofreceré un pequeño resumen y, de paso, conocerán a los asistentes.

Ruymán Ferrera, nos habló sobre el Máster en Interacción Persona – Ordenador que está realizando en la Universidad de Lleida; por el momento le está pareciendo interesante, quizá algo más teórico de lo que pensaba, pero está mereciendo la pena el sacrificio puesto que sigue trabajando en Gran Canaria mientras asiste a las clases presenciales en Lleida (donde ha podido contactar con el grupo local Cadius).

Cristina Olmos, retomó las reuniones tras varios meses sin poder asistir. Nos contó sus peripecias para poder aplicar algunos criterios de usabilidad y accesibilidad en la ULPGC, una institución compleja y altamente burocratizada. También nos ofreció un resumen de lo más destacado de las ponencias y talleres de Fundamentos Web 2008, comentando, entre otras cosas, la magistral puesta en escena de Jesse James Garrett pero que se quedaba en lo global (como suele pasar en este tipo de conferencias). Especial mención tuvo para la ponencia sobre la accesibilidad en las aplicaciones web enriquecidas (WAI-ARIA), de la que obtuvo ejemplos concretos sobre buenas y malas prácticas con estas tecnologías. También pudo constatar que la mayoría de los asistentes siguen siendo "programadores", a pesar de que los conocimientos tratados afectan a un número de profesionales web mucho más amplio.

No puede escuchar demasiado las conversaciones de Mingo Cabrera, otro habitual de nuestras reuniones, puesto que estaba en la otra punta de la mesa, pero nos hizo toda una tesis sobre el origen Western del nombre de Jesse James Garrett, además, coincidimos, al hablar del sistema de reservas de Spanair, que tal y como están las cosas en la compañía aérea, deberían añadir un botón de "Voy a tener suerte" junto al de "Reservar".

David Horat, nuestro miembro más viajero, como en otras ocasiones, llegó acompañado de la siempre discreta Dácil Sánchez. David llevaba varios meses fuera de la isla y es que no ha parado, desde su estancia en la frontera franco-suiza en el Openlab del CERN, que además coincidió con la puesta a punto del Gran Colisionador de Hadrones (LHC), a su periplo norteamericano en el Google Summer of Code Mentor; imagínense las experiencias que nos pudo contar.

La sorpresa de la noche fue la aparición de Carlos Marrero, que nos visitó desde el grupo Cadius en Tenerife (este mes, además, ha disfrutado de dos cócteles). Carlos vino cargado de propuestas e ideas, quizás la más relevante fuera la de unas Jornadas centradas en usabilidad, accesibilidad y diseño web con estándares (de las que ya existe, en fase embrionaria, una página, un grupo en Google y hasta un canal twitter). Las jornadas estarían organizadas desde Canarias para romper el mito de que aquí nunca se hace nada interesante en nuestro sector y hay que salir fuera para buscarlo. También compartió con nosotros Designing the Obvious, un libro que él estaba empezando a leer y del que he encontrado una pequeña reseña.

Por mi parte, comenté que, espero que a principios del próximo año ya podamos utilizar cadiuscanarias.org como plataforma de comunicación para las ciudades Cadius en Canarias. La plataforma está montada en WordPress y el diseño estará disponible para cualquier ciudad Cadius que quiera usarlo y adaptarlo.

Conjuntamente con Cristina también repasamos las Jornadas de Accesibilidad Web para Entidades Locales organizadas por el Cabildo de Gran Canaria. Desde mi punto de vista, aún no hay concienciación política y sigue faltando una visión más "humana" de la accesibilidad, de hecho, la mayoría de los desarrolladores presentes se centraban en preguntar sobre las normas y pautas existentes y sus posibles interpretaciones. Para ellos sólo comento que desde que se realizan pruebas con usuarios discapacitados y se comprende cómo acceden a la web, todas esas dudas desaparecen al instante.

Sin duda, una gran velada para cerrar los Cocktails Cadius Canarias de 2008 y afrontar nuevos retos para 2009. Espero verlos pronto.

Felices Fiestas.

Actualización del 18 de diciembre de 2008: entre tantas cosas, me había olvidado. David Horat señaló que Gran Canaria iba a ser la sede del Gran Canaria Desktop Summit 2009. Gracias a Víctor por recordármelo.

Cocktail Cadius Canarias – diciembre 2008

2008-12-01T15:00:55Z

Cocktail Cadius Canarias (edición Las Palmas G.C.)

Será el jueves, 11 de diciembre de 2008, como siempre, sobre las 20:30 horas en la Tasca La Barbería (Mendizábal, 14. 35001- Vegueta, Las Palmas de Gran Canaria).

¿Cómo llegar? Míralo en este mapa (PNG – 38Kb.) o a través de Google Maps.

Cocktail Cadius Canarias (edición Santa Cruz de Tenerife)

Actualización: como comenta Julio, después de ocho meses de "descanso", se vuelve a convocar un Cóctel Cadius en Tenerife para el jueves, 4 de diciembre de 2008. Sin duda una magnífica noticia.

¿Más información?

¿Qué son los Cocktails Cadius? Te lo explicamos.
¿Quieres participar? Tan sencillo como comentarlo en esta entrada.

Por favor, rogamos que confirmen su asistencia.