Archivo de la etiqueta: estándares

Problemas de accesibilidad asociados al color.

Fuente:

http://www.juanhidalgoreina.com/2011/03/problemas-de-accesibilidad-asociados-al-color/

Problemas de Accesibilidad asociados al color.

Publicado
14 de marzo, 2011.
Autor
Juan Hidalgo Reina

Primero indicar que es necesario no basarse en el color, tal y como se indica en las WCAG.

En el punto de verificación 2.1 de las WCAG 1.0 se indica ” Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores”.

Pongamos un ejemplo, que ocurre cuando por alguna razón diseñamos una tabla con barras de diferentes tonalidades de rojos, y ponemos unatablita indicando que significa cada tono de rojo. Vale, preciosa tabla, pero y si esa persona tiene por ejemplo Protanopia?. Los usuarios que tiene esta “disfunción visual“, tienen una carencia de sensibilidad al color rojo.

Genial hemos conseguido que los usuarios con esa discapacidad no puedan acceder, ni comprobar la información, solo por que hemos decidido poner ese color.

Puedo decir sin animo de equivocarme que la mayoría de los sitios que certifican Accesibilidad (no digamos los que no certifican), tienen carencias graves en los valores de brillo y contraste de los tonos empleados. Algunas veces por un leve descuido, otro por que el diseñador tiene mayor peso que la necesidad implícita de Accesibilidad, y otras por que no se ha tenido en cuenta. Existen otras situaciones pero prefiero obviarlas por los términos que se suelen emplear.

Información transmitida por el color.

Por ejemplo observemos este ejemplo, en el observamos un error de lo mas común. Indicamos y planteamos una funcionalidad basada en el color. El campo obligatorio está en color rojo.

Uso incorrecto de transmisión de información por el colorUso incorrecto de transmisión de información por el color.

Esto es un grave problema para muchos usuarios, pues en cierta medida anteponemos criterios estéticos y comportamientos visuales corporativos a toda costa, sin valorar ni constatar el perjuicio que estamos ocasionando.

Como se resuelve este tipo de problemas?

Pues simplemente debemos poner por ejemplo, “Los campos obligatoriosestán marcados en rojo y con asterisco”, tal y como aparece en el ejemplo siguiente. La información se sigue transmitiendo por el color, pero tambiénpor el marcado. Independientemente del dispositivo o de la discapacidad visual, el asterisco está perfectamente marcado.

Caso de uso de transmisión de información por el color y marcado.Caso de uso de transmisión de información por el color y marcado.

Brillo y color

El Punto de Verificación 2.2 de las WCAG 1.0 nos indica que lascombinaciones de color de fondo y de primer plano deben ofrecer suficiente contraste para ser visualizadas por personas con discapacidad visual, o tener el suficiente contraste para pantallas en blanco y negro.

Para ello el W3C nos sugiere la utilización de un algoritmo que nos determinará un valor de contraste suficiente.

Por ejemplo debemos tener mucho cuidado con las combinacionesempleadas en el site. Los diseñadores tenemos una facilidad innata por poner tonos imposibles (muchos de mis profesores, dirían que en determinadas situaciones atentan contra la teoría del color), y sobre todo por poner una degradaciones de color, que queden bellísimas pero que a simple vista puedan pasar inadvertidas por muchos usuarios que no tengan ningún tipo de discapacidad visual, por lo que imaginemos lo que puede ocurrir con los que si la tengan.

A continuación os pongo una captura de mi pagina de FACEBOOK, en la que se puede observar como ese tono NO cumple las necesidades requeridas para validar en Brillo y Color.

Problemas de color en FacebookProblemas en el todopoderoso Facebook.

En la captura de imagen anterior, podéis observar una de mis herramientas de cabecera, un magnifico plugin para Firefox(ColorChecker). Os animo a que lo instaléis, y que por ejemplo probéishaciendo click en la casilla de verificación “Selector de texto“,

Revisad por encima las siguiente webs, y comprobad que tipo de problemas de accesibilidad tienen los cuerpos de texto.

http://www.bde.es/webbde/es/

http://www.iberia.es

http://mailchimp.com/

Ahora bien, a pesar de que el W3C en las WCAG 1.0 recomienda la utilización del algoritmo anteriormente citado, el cual se basa en la diferencia de brillo y color, os recomiendo lo que a mi me han recomendado desde que salieron las WCAG 2.0.

Hay que utilizar el nuevo algoritmo de Luminosidad. Por que? pues por que las WCAG 2.0 conllevan una serie de revisiones y mejoras, el nuevo algoritmo ya es una mejora evidente.

Diferencias entre algoritmos

WCAG 1.0 (Algoritmo de Brillo y Color)

  • La diferencia de brillo debe tener un rango igual o superior a 125 como mínimo.
  • La diferencia de color debe tener un valor mínimo de 500.

OJO hay muchos sitios en los que los validadores o chequeadores de color, comentan algunas variaciones realizadas por HP creo recordar.

WCAG 2.0 (Algoritmo de Luminosidad)

  • En función de la tamaño y estilo del texto e incluso de nivel de conformidad, se establecen como ratio mínimo de luminosidad, 3:1, 4.5:1 o 7:1.

Brillo y color en imágenes, logotipos, etc.

Cuando por ejemplo las imágenes lleven texto, esa información debe aparecer si o si en el ALT.

En las WCAG 2.0 los logotipos están exentos de cualquier tipo de restricción por contraste. Anteriormente en las WCAG 1.0 no es que se obligase a cumplir la restricción y ahora en las WCAG 2.0 no, simplemente que antes no se tenían en cuenta algunas particularidades como la implantación, o la experiencia documentada que genera el tiempo transcurrido entre las ambas WCAG .

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA.

Fuente:

http://olgacarreras.blogspot.com/2011/02/accesibilidad-integrada-en-todas-las.html

Domingo 27 de febrero de 2011.

Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA.

Como consultor de usabilidad y accesibilidad es fundamental, cuando formas parte del grupo de trabajo que va a desarrollar una aplicación Web, conocer el marco metodológico del Diseño Inclusivo para incluir los requisitos de accesibilidad y usabilidad a lo largo de todo el proceso de desarrollo. Ello permitirá crear aplicaciones usables y accesibles cuya calidad perdure en el tiempo.

El objetivo de este artículo es difundir el marco metodológico AWA para el desarrollo de aplicaciones web accesibles, pues es un excelente ejemplo de metodología de Diseño Inclusivo que ayuda a comprender las bases en las que se debe asentar un desarrollo que tenga la accesibilidad y la usabilidad presentes en todas las fases del proceso.

Para ampliar información o contactar con su autora recomiendo acceder directamente a su web:AWA (Accessibility for Web Applications) También recomiendo su presentación Tutorial: Cómo incluir requisitos de accesibilidad web en el proceso de desarrollo software (PDF)

Índice del artículo

  1. Introducción: marco metodológico AWA
  2. Pre-requisitos para la aplicación de AWA
  3. Fases y actividades
  4. Estructura del soporte metodológico AWA
  5. Checklist de seguimiento del cumplimiento de requisitos y mecanismos
  6. Casos reales: portal corporativo con Drupal.

Introducción: marco metodológico AWA.

AWA (Accessibility for Web Applications) es el marco metodológico para el desarrollo de aplicaciones web accesibles elaborado por Lourdes Moreno es su tesis doctoral: “AWA, Marco metodológico específico en el dominio de la accesibilidad para el desarrollo de aplicaciones Web”, 2010 [PDF, 8.5 MB].

El objetivo del trabajo es ofrecer un soporte metodológico para incorporar los requisitos de accesibilidad en todo el proceso de desarrollo de una aplicación web, aportando sistematización y un enfoque DCU que situé al usuario como protagonista. El marco de trabajo es el Diseño Inclusivo que involucra a los usuarios con necesidades especiales y a expertos en este tipo de necesidades y discapacidades. El estándar de referencia a lo largo del trabajo son las WCAG (1.0 y 2.0) y el cumplimiento de las mismas en las páginas web finales de la aplicación Web.

Uno de los errores habituales es afrontar la revisión de la accesibilidad cuando el desarrollo está muy avanzado, siendo más costoso y complicado aplicar los requisitos necesarios. Por otra parte, cuando la accesibilidad no se ha sistematizado en el desarrollo es mucho más difícil mantenerla durante el ciclo de vida de la aplicación Web.

Los objetivos finales son pues:

  1. conseguir que las páginas web finales generadas por la aplicación sean accesibles según las WCAG y usables desde el punto de vista del usuario,
  2. garantizar la calidad, es decir, que esta accesibilidad sea estable en todo el ciclo de vida de la aplicación web.

Es una propuesta flexible para que pueda ser aplicada a cualquier proceso de desarrollo de software que cumpla con los pre-requisitos mínimos.

Pre-requisitos para la aplicación de AWA.

La aplicación de esta metodología tiene como pre-requisito que la aplicación siga una arquitectura de modelo de más de dos capas (MVC) donde la lógica de negocio esté separada de la presentación, pues la separación de la presentación, la estructura y el contenido es un requisito imprescindible del diseño accesible. Además asegurará que las funcionalidades implementadas sólo en cliente (como AJAX) no dejen de funcionar.

Por otro la lado, la tecnología cliente deberá estar basada en estándares del W3C (XHTML, CSS, etc.) y tecnología servidor que no deje código en el lado del cliente (a excepción de AJAX que podrá ser utilizado junto con soluciones WAI-ARIA).

Fases y actividades.

Presupone un proceso de desarrollo con un enfoque iterativo y un ciclo de vida incremental, cuyas fases y actividades son:

Espiral en la que se señalan las fases y actividades que se enumeran a continuación:

Comunicación con el cliente:

  1. Análisis de negocio: identificación de metas y objetivos de la aplicación.
  2. Actividad de formulación: captura de requisitos que involucre a todos los participantes.

Planificación:

  1. Estimación de costes.
  2. Evaluación de riesgos.
  3. Planificación del desarrollo para definir tareas y plazos de cada incremento (plan de iteración)

Ingeniería:

  1. Análisis:
    1. Definición de requisitos técnicos, identificación de elementos de contenido y análisis del diseño gráfico.
    2. Requisitos de interacción: relación de los elementos de contenido y su funcionalidad asociada.
    3. Análisis de navegación: mecanismos de navegación que se van a proporcionar.
  2. Diseño:
    1. Diseño del contenido y diseño gráfico.
    2. Diseño de la estructura y el comportamiento de la aplicación en sí, incluyendo arquitectura, navegación e interfaz.
  3. Modelado: creación de modelos antes de la construcción.

Construcción:

  1. Implementación: de los modelos procedentes de la fase de ingeniería para construir la aplicación Web. Integración con software intermedio.
  2. Pruebas: para asegurar la calidad:
    1. Verificación: comprobación de que la aplicación es correcta desde la perspectiva del diseñador en relación al contenido, arquitectura, presentación, interfaz y navegación
    2. Validación: comprobación de que la aplicación hace y tiene la apariencia que el cliente esperaba.

Despliegue:

  1. Evaluación e interacciones de cambios.

Estructura del soporte metodológico AWA.

Estructura de soporte metodológico AWA: AWA_ Organización, AWA_Interacción y AWA_WCAG proponen AWA_Requisitos que activan AWA_Mecanismos

Componentes.

AWA_Organización.
Mecanismos para integrar planes y políticas de accesibilidad en la organización y equipo de desarrollo.

Se articula en torno a la elaboración de un Plan de accesibilidad (creación del grupo de accesibilidad, determinar la política de accesibilidad con el nivel de conformidad deseado, mecanismos para compartir el conocimiento sobre accesibilidad y plan de formación, seleccionar tecnologías accesibles, etc.) y laGestión de la accesibilidad (procesos a nivel interno pero también externo como la elaboración de requisitos para proveedores externos o la gestión de sugerencias de los usuarios)

Consultar mapa conceptual de AWA_Organización

AWA_Interacción.
Mecanismos para integrar un enfoque de DCU con inclusión, teniendo como instrumento base el estándar  ISO 13470:1999 (PDF, p.121) que se introduce en las páginas 121 y siguientes.

Se articula en torno a dos principios fundamentales:

  1. Involucrar a todos los usuarios, incluyendo al usuario con discapacidad en todo el proceso
  2. Considerar las características del usuario con discapacidad y la diversidad de contextos de uso en la Web.

Engloba técnicas de usabilidad con inclusión como: perfiles de usuario,personasescenariosprototipotormenta de ideascardsortingevaluación heurísticacuestionarios, entrevistas y encuestas, que se detallan en las páginas 129 y siguientes.

Consultar mapa conceptual de AWA_Interacción

En este capítulo 5 me parece muy interesante la tabla de correspondencia entre los criterios heurísticos de usabilidad y los criterios de conformidad de las WCAG 2.0 (PDF) (tabla que se explica en las páginas 155 y siguientes). Recurso muy útil para saber qué aspectos de la accesibilidad se están teniendo en cuenta cuando la usabilidad se incluye en un proyecto.

AWA_WCAG.
Abstracción de las WCAG (1.0 y 2.0) de manera que su tratamiento pueda ser incluido desde el inicio del proceso de desarrollo de una aplicación Web.

Puesto que no todos los requisitos pueden ser incorporados desde el diseño se distingue estos (AWA_WCAG Diseño) de los que son a nivel de implementación (AWA_WCAG Implementación: presentación con CSS, acceso por teclado, cambio de contexto o compatibilidad con terceras tecnologías) y de los que han sido definidos para ser incorporados en la actividad de evaluación (AWA_WCAG Evaluación)

Consultar los mapas conceptuales de AWA_WCAG para las actividades de diseño, implementación y evaluación

Requisitos.

AWA_Requisitos.
Como resultado se definen unos requisitos de accesibilidad que tienen tres objetivos principalmente:

  1. seguir las WCAG 1.0 y 2.0,
  2. seguir un enfoque DCU con Inclusión
  3. tener en cuenta la gestión de la accesibilidad considerando los requisitos de accesibilidad desde la organización como punto de partida.

En la notación de los requisitos se incluye el componente, por ejemplo:AWA_RequisitoOrganización PLAN 01.02: Declaración de Política de accesibilidad

Los AWA_RequisitosWCAG que hay que incorporar en la actividad de diseño se describen en las páginas 150 y siguientes, incluyendo por cada uno una tabla de correspondencia con las WCAG 1.0 y las WCAG 2.0. También se pueden consultar estas tablas accediendo en la web a cada una de las pautas WCAG 1.0 y WCAG 2.0

Consultar una tabla simplificada de correspondencias entre las WCAG 1.0, las WCAG 2.0, los AWA_Requisitos y los grupos de usuarios beneficiados.

Los AWA_Requisitos activan mecanismos de accesibilidad denominados AWA_Mecanismos.

Mecanismos.

AWA_Mecanismos.
Articulan la incorporación de los AWA_Requisitos desde el inicio del proceso. En la notación de los requisitos se incluye el componente, por ejemploAWA_MecanismoOrganización PLAN 01.02/02: Determinar Declaración de Política de Conformidad.

Checklist de seguimiento del cumplimiento de requisitos y mecanismos

Consultar checklist de seguimiento del cumplimiento de requisitos y mecanismos (PDF).

Casos reales.

En el capítulo 7 se explican casos reales de aplicación, uno de ellos el de la web del Centro Español de subtitulado y Audiodescripción (CESyA) gestionada con Drupal.

Se explica el enfoque de Diseño Inclusivo en la captura de requisitos combinando las técnicas de perfiles de usuario, personas y escenarios.

Se detalla la utilización de la técnica Card Sorting (manual abierta, automática con WebSort y manual cerrada) para adecuar la arquitectura de la Información al modelo mental de los usuarios.

La elaboración de un prototipo de bajo coste y reuniones Visual Brainstorming antes de abordar el diseño gráfico, así como la elaboración posterior de un prototipo software funcional, evaluándolo por expertos (evaluación heurística) y mediante pruebas de usuarios con y sin discapacidad (consultar cuestionarios a los participantes en el test de usuarios y a los testers (PDF)).

Aplicando todo lo anterior se crearon las plantillas de Drupal y se validó su accesibilidad.

Me parecen fundamentales todos los mecanismos que se llevaron a cabo en Drupal para asegurar que la inclusión de contenido a través del gestor diera lugar a contenido accesible y por tanto páginas que cumplen los niveles de conformidad AA.

Para ello se incluyó un editor de contenido con criterios de accesibilidad que transformara los datos introducidos en código válido. Por ejemplo, al incluir una noticia se pide el título (que se incluirá como encabezado), el idioma (aplicará en el código la identificación del idioma si no se corresponde con el idioma de la página), etc.

Me gustaría destacar las características y restricciones que debe tener el editor de contenido de un CMS para que el contenido resultante sea accesible:

  1. Edit text: permite escribir texto plano e incluye una opción guiada donde no se puede incluir tags (X)HTML
  2. Specify language: puedes seleccionar el idioma mediante una select.
  3. Add header: permite incluir un encabezado de un nivel específico, pero si existe un nivel de encabezado ya definido que englobe el actual documento, el nivel relativo se ajustará a ese nivel global, siendo relativo a éste. Se puede especificar también su idioma.
  4. Add image: siendo obligatorio la URI y el texto alternativo, y opcionalmente el longdesc
  5. Add multimedia: permite incluir vídeo siendo obligatoria la URL, el recurso de subtitulado y audiodescripción, y su lenguaje.
  6. Add link: siendo obligatorio la URI y pudiendo incluir un title y el lenguaje de la página de destino.
  7. Add abbreviation: que permita incluir un contenido con texto abreviado, pudiendo especificar su idioma.
  8. Add acronym: permite incluir un acrónimo, pudiendo especificar su idioma.
  9. Add list: añade una lista de diversos tipos.
  10. Add table: permite incluir una tabla, indicando filas, columnas, encabezados, resumen, etc..
  11. Add form: añade un formulario, permitiendo incluir los elementos típicos de formularios HTML mediante “Add element”. “Specify action” permite indicar la acción que realizará el formulario al ser enviado.
  12. Finish editing: finaliza la edición del contenido, comprobando que éste cumple con las especificaciones definidas y lo inserta en el sistema de persistencia, quedando a la espera de una revisión de accesibilidad (AWA_RequisitoWCAG EVA 01) para su publicación definitiva.

Esta revisión manual del contenido incluido en el editor para que pueda publicarse tiene en cuenta los puntos de las tabla de la página 241.

La belleza del marcado semántico (en inglés).

Fuentes:

http://ablognotlimited.com/articles/the-beauty-of-semantic-markup-introduction

http://ablognotlimited.com/index.php/articles/the-beauty-of-semantic-markup-part-1-quotes-citations

http://ablognotlimited.com/index.php/articles/the-beauty-of-semantic-markup-part-2-strong-b-em-i

http://ablognotlimited.com/index.php/articles/the-beauty-of-semantic-markup-part-3-headings

The Beauty of Semantic Markup, Introduction

JUL152010

Ever since I started writing Microformats Made Simple, I’ve been distracted … from this blog, from my career goals, from my personal life. And even though the book is long since finished, I’m still distracted.

It is getting better, though. I’m gaining a bit more focus each day.

I quit my job to pursue freelance work in hopes of reconnecting with what I love about my career: making great web sites.

I’m letting go of some of my responsibilities with the user group I co-manage,Webuquerque, so that I can better experience the reason I co-founded it: the community.

I started writing for other publications to encourage my passion for sharing knowledge and information to audiences beyond my meager reach.

And I even decided to break an almost seven-year stretch of happily living alone to *fingers-crossed* happily living in sin with my boyfriend.

A New Blog Series!

The next thing I’m returning focus to is this blog. And there aren’t words to describe how right and grounding this feels.

A Blog Not Limited is my baby. My first online presence where I can do and say anything I want in my own voice, however wrong, inappropriate or profane it may be.

It was the vehicle that inspired me to start writing about microformats and, by extension, gave me the opportunity to write a book.

It is the place where I started to get comfortable “putting myself out there” … where I could shamelessly self promote, while simultaneously sharing information.

And in return for all this, I’ve been a bad parent. I haven’t done a single bit of development I planned to do after it’s first anniversary. I even forgot the anniversary this year.

As for content, I haven’t written too much beyond the shameless self promotion, which sorta takes away the “shameless” part because I like to have a balance (not to mention, I’m beyond sick of promoting me and the book).

I can overlook my neglect of the design and development needed here (for now), but I can’t overlook neglect of content. Which brings me to the reason for this post: I’m starting a new blog series focusing on semantic markup.

Why Semantic Markup?

The most obvious answer is I dig it. I mean I really love it.

Semantic markup is more exciting, challenging and satisfying for me than all the cool shit you can do with CSS 3 transitions or HTML<canvas> or any of the latest–and–greatest emerging web trends.

There is a purity to semantic markup that appeals to me. It is simply deciding what markup elements best describe the content. If you have content for a primary heading on a page, you simply use <h1>. If you have a series of paragraphs, <p> is there for you. Want to provide a sequential list of instructions, <ol> won’t let you down.

But those are the most simplistic scenarios. I also believe writing truly semantic markup is much like putting pieces of a puzzle together.

It’s beyond only using <table>s for tabular data. It is beyond not using<blockquote>s to simply indent text.

You have to be able to see the big picture.

That means a solid understanding of the content itself, even how the content may change over time. For example, if I’m working with contact information I want to know what, specifically, is included. Name, job title, birthday, web site? Will additional content be added in the future? All of these little details affect the final markup.

An understanding of the design and CSS needed to translate that design is essential. Is there a “sticky footer”? What, if any, image replacement techniques will be used? What about font embedding? Again, these design and CSS details will absolutely require certain markup considerations.

You even need an appreciation for your fellow designers and developers who may, someday, have to work with your markup. I’ve too often inherited sites from designers who believed 10 nested <div>s were necessary to contain a single blog post. Or from developers who felt id="static23" was a descriptive and useful naming convention.

It’s About Craftsmanship

HTML is, by comparison, one of the easiest web languages to learn and start using right away. And nothing is going to stop you from using dozens of <table>s for layout, or structuring navigation with <a>s and <br />s, or any of the thousands of examples of shoddy markup that exist on the web today.

Anyone can write crap markup. It takes a craftsman to write that “big picture” markup I described.

It takes knowledge to understand the semantics of HTML elements and properly apply them to content. It takes commitment to spend the extra time needed to follow semantic naming conventions for ids and classes. It takes experience to know that sometimes you do need a few extra <div>s to support a design or invalidrole attributes to support accessibility.

POSH Foundation

After I wrote Meaningful Markup: POSH and Beyond, I realized I had much more to share beyond the basics covered in that article. And so, I decided to start this Beauty of Semantic Markup series.

The focus will be Plain Old Semantic Markup (POSH, for you acronym-loving geeks) examples for real-world content. Not a bunch of theory about what benefits semantic markup offers. No admonitions that you must write semantic markup to support web standards and accessibility. You can see Meaningful Markup if you want that.

Instead, I want to focus on foundation because that’s where craftsmanship begins.

I’ll take different types of content and mark them up, using POSH and semantic naming conventions. Some posts will focus on a specific element, such as <table>, and show best practices for structure and attributes. Some posts will focus on specific content, such as quotes and citations, and cover which elements are most semantically appropriate to use.

Of course, I’ll introduce microformats when the content examples dictate. I’ll also get into CSS when it seems relevant. And you better believe I’ll address accessibility. As for HTML5, I would never neglect it, but I do want to focus on more “foundational” elements first.

Who Is This Series For?

First and foremost, this series is for me. As I explained, refocusing on this blog and writing for myself is something I need and want to do. Plus, I learn so much when I spend the time researching and writing about a topic.

But also, with abundance of news and posts focusing on emerging trends in this industry, I feel compelled to re-engage in the discussion about fundamentals.

Far too often, I hear from developers who know they aren’t producing the best markup, but due to a range of circumstances — limited resources at their jobs, employers who think “web people” can do everything, lack of experience and knowledge — they feel hamstrung. And far too often, I’ve inherited work from other developers who didn’t appreciate good markup, which led to me spending unnecessary time fixing their work (and that means more time and money for employers and clients).

If you are one of those developers/designers, then this series is for you. It’s not going to be brain science. It probably won’t be anything that hasn’t already been written about before. But I do hope it will provide simple, easy–to–understand examples that you can (and will) use to take your markup to a higher level. Hell, I even plan to use the markup examples as my own personal reference to save time when I’m developing.

If you are a markup master already, this series may not be for you. Then again, it might. I’ve been writing HTML for over 10 years and I regularly discover new ways of approaching my markup. Perhaps this series may offer a golden nugget of goodness for even the most experienced front-end developers.

I also hope this series inspires discussion. I’m not perfect and I don’t know everything there is to know about markup. I hope as I present my suggestions for markup, others will chime in with their own ideas and conventions. And then we all learn something new. Yay!

The Plan

I don’t have a formal editorial calendar for this series, but I plan to tackle a range of semantic markup topics, including (and not limited to):

  • Accessible <table>s for tabular data
  • Semantic naming conventions for <id>s and <class>es
  • List elements (<ul><ol> and <dl>)
  • Images with captions
  • Accessible <form>s
  • Document structure with the new HTML5 semantic elements
  • A survey of sites that are “doing it right” and those that aren’t
  • Headings (<h1><h6>)
  • <acronym> and <abbr>

I also plan to explore different semantic markup approaches for different types of content, such as blog posts, site maps, image galleries and more. It might also be nice to take a look at one of those sites that is “doing it wrong” and show what I would do instead.

This series may span several months, a year or even more. As long as I feel interested and engaged in the topic, I plan to write about it. I hope to publish a new article every week, but it could be every 10 days … if I’m really busy, it could be longer.

I suggest you subscribe to A Blog Not Limited to get updates via RSS or follow me on Twitter, where I’ll posts links to new articles.

In the meantime, I already have part one, covering quotes and citations, ready for your inspection. Enjoy!

The Beauty of Semantic Markup, Part 1: Quotes & Citations

JUL152010

As I mentioned in my introduction, this series is going to take a close look at the fundamentals of semantic markup. In this first installment, I’m focusing on quotes and citations.

Before we get started, if you’d like to know more about semantic markup — what it is, why you should develop your sites with it — check out my article, Meaningful Markup: POSH and Beyond.

Now, let’s get to it!

Content First

My approach to writing markup always starts with the content, because knowing the nuances of content definitely affects the final markup. Let’s consider quotes:

  • Will the quote include a citation to the source? Is the source online?
  • Will the source citation require a link users can select?
  • Is the quote to appear on its own or within a body of text?
  • Does the quote contain block-level elements (such as several paragraphs or a list)?

Once you know the answer to these questions, you can get started on the markup.

Semantic Elements

Before you begin marking up those quotes, you should know which elements are at your disposal for this type of content.

<blockquote>

The <blockquote> is a block-level element intended for (comparatively) large quotations that contains other block-level elements. A <blockquote> could be a single paragraph, a series of paragraphs, a paragraph and a list, paragraphs and headings … you get the picture.

In real-world context, a <blockquote> may contain an excerpt from a book or resource. It can also be a relatively lengthy testimonal, as you might see on some companies’ web sites. And, of course, <blockquote> could also be an actual quote; something a person said in conversation, in a speech, in a presentation.

Since I’m in the mood for a bit of ego stroking, let’s apply <blockquote> to myLinkedIn recommendation from my former boss:

  1. <blockquote>
  2. <p>Emily is hands-down the best XHTML/CSS designer I've known. She consistently cranks out the most semantic, valid XHTML/CSS web designs in amazingly short order. Most importantly, she keeps the user experience and semantics in mind... setting the bar for code quality that has not yet been met even by companies netting $400-800k for web design projects.</p>
  3. <p>I always compare XHTML mark up and CSS code quality from other companies to Emily's and every time I'm disappointed. If I want the best, lightest, most semantic XHTML designs, I go to Emily. Other companies and individuals might come up with XHTML that validates, but only Emily's is as efficient and as semantic as possible.</p>
  4. </blockquote>
THE cite ATTRIBUTE

If your <blockquote> content is from an online source, you can indicate that source via the cite attribute with a valid URL. The above recommendation example is, indeed, online:

  1. <blockquote cite="http://www.linkedin.com/in/emilyplewis">
  2. <p>Emily is hands-down the best XHTML/CSS designer I've known. She consistently cranks out the most semantic, valid XHTML/CSS web designs in amazingly short order. Most importantly, she keeps the user experience and semantics in mind... setting the bar for code quality that has not yet been met even by companies netting $400-800k for web design projects.</p>
  3. <p>I always compare XHTML mark up and CSS code quality from other companies to Emily's and every time I'm disappointed. If I want the best, lightest, most semantic XHTML designs, I go to Emily. Other companies and individuals might come up with XHTML that validates, but only Emily's is as efficient and as semantic as possible.</p>
  4. </blockquote>
RENDERING & INTERPRETATION

In terms of how browsers render <blockquote>s, they are typically displayed with a left indent. It is this visual presentation that led to much abuse of <blockquote>. Some less–than–savvy developers use(d) it to give content an indent. And that’s a big ole no-no.

Screen readers, meanwhile, will often announce the beginning and end of a<blockquote> to give users context of the content.

<q>

The <q> is an inline element used for, you guessed it, quotes that appear inline within other text (like a sentence) and do not require any block-level elements, such as paragraph breaks.

In the real-world, <q> is most often appropriate for comparatively shorter quotes, such as a simple phrase or statement within a paragraph or sentence:

  1. <p>When I was younger, my mom used to do my hair before school. And in her morning rush, I often got forehead burns from the curling iron as she did my bangs. Her response? <q>Beauty is pain.</q> And thus began my indoctrination into society's pursuit of beauty.</p>
THE cite ATTRIBUTE

Just like <blockquote>, you can also use the cite attribute with <q> to indicate the source, if it’s online, of the quote:

  1. <p>Wikipedia defines citations as <qcite="http://en.wikipedia.org/wiki/Citations">a reference to a published or unpublished source</q>.</p>
RENDERING & INTERPRETATION

Browsers are supposed to render <q> elements with quotation marks before and after the content. As such, the W3C advises authors against including quotation marks in the content itself.

Furthermore, if you nest <q>s, browsers are supposed to render both the inner and outer quotes with the proper punctuation. In American English, for example, this would mean the inner quote would be delimited with single quotation marks, while the outer quote would begin and end with double quotation marks.

However, browsers makers often go their own ways, which is what Internet Explorer did and, as such, all versions of IE prior to IE8 do not add those delimiting quotation marks. The other major browsers, however, do insert quotation marks.

It is worth mentioning, that quotation marks vary according to language. As such, best practices recommend specifying the lang attribute for <q> to ensure the proper punctuation is applied:

  1. <p>Wikipedia defines citations as <q lang="en-us"cite="http://en.wikipedia.org/wiki/Citations">a reference to a published or unpublished source</q>.</p>

As far as screen readers go, they don’t seem to treat content within <q>s any differently than other content. They don’t announce the beginning or end of the quote, as with <blockquote>.

<cite>

While I’ve mentioned the cite attribute, there is also a <cite> element. It is aninline element used for references to a source. In other words, a citation.

And, as a sidenote, I’m not embarrassed to admit that for years, I was incorrectly using this element for inline quote content. I didn’t even realize there was a <q>element, much less that <cite> is intended for references to other work, not the actual reference itself.

In real-world practice, <cite> can be used in conjunction with a quote, to indicate the source of the quote … a person, book, whatever. This is particularly useful if the source is not online and, therefore, you can’t use the cite attribute with<blockquote> or <q>:

  1. <blockquote>
  2. <p>Mr. L. Prosser was, as they say, only human. In other words he was a carbon-based bipedal life form descended from an ape. More specifically he was forty, fat and shabby and worked for the local council.</p>
  3. <p><cite>The Hitchhiker's Guide to the Galaxy</cite></p>
  4. </blockquote>

Update

Thanks to a comment from Chris Pederick, I’ve already learned something new from this series (yay!).

It seems the HTML5 working draft says using <cite> when referencing a person is a no-no. Instead, we can use <b> or <span>What. The. Fuck!?

Yeah, that just seems stupid to me. And a step away from semantics. But, oh well, lots of stuff in specifications are stupid to me. And who knows, the final HTML5 spec is a ways off, so it could change.

Want to try to help make it change? Contribute to the WHATWG wiki pagedocumenting uses of <cite> in reference to people.

I now return you to regularly scheduled programming …

Note that if you use <cite> within <blockquote>, you must first contain it with another block-level element, because <cite> is inline and <blockquote> can only contain block-level elements:

  1. <blockquote>
  2. <p><cite>The Hitchhiker's Guide to the Galaxy</cite></p>
  3. </blockquote>

And even if you are referencing an online source, you can still use <cite> along with the cite attribute:

  1. <blockquote cite="http://en.wikipedia.org/wiki/Citations">
  2. <p>A prime purpose of a citation is intellectual honesty; to attribute to other authors the ideas they have previously expressed, rather than give the appearance to the work's readers that the work's authors are the original wellsprings of those ideas.</p>
  3. <p><cite>Wikipedia</cite></p>
  4. </blockquote>

When I am dealing with an online source, as in the above example, I often drop in a link as a containing element for <cite>:

  1. <blockquote cite="http://en.wikipedia.org/wiki/Citations">
  2. <p>A prime purpose of a citation is intellectual honesty; to attribute to other authors the ideas they have previously expressed, rather than give the appearance to the work's readers that the work's authors are the original wellsprings of those ideas.</p>
  3. <p><a href="http://en.wikipedia.org/wiki/Citations"><cite>Wikipedia</cite></a></p>
  4. </blockquote>

You don’t, however, have to make the <a> href value the same URL as that ofcite.

Consider the earlier LinkedIn recommendation example. The recommendation exists on my profile page, so that makes sense as the URL for the cite attribute. But if I wanted to include my former boss’s name as the <cite> reference, I would typically provide a link to his personal site:

  1. <blockquote cite="http://www.linkedin.com/in/emilyplewis">
  2. <p>Emily is hands-down the best XHTML/CSS designer I've known. She consistently cranks out the most semantic, valid XHTML/CSS web designs in amazingly short order. Most importantly, she keeps the user experience and semantics in mind... setting the bar for code quality that has not yet been met even by companies netting $400-800k for web design projects.</p>
  3. <p>I always compare XHTML mark up and CSS code quality from other companies to Emily's and every time I'm disappointed. If I want the best, lightest, most semantic XHTML designs, I go to Emily. Other companies and individuals might come up with XHTML that validates, but only Emily's is as efficient and as semantic as possible.</p>
  4. <p><a href="http://www.ianpitts.com/"><cite>Ian Pitts</cite></a></p>
  5. </blockquote>

And just for purposes of demonstration, since all of the above examples use<blockquote><cite> can absolutely be used to reference the source of <q>content:

  1. <p><cite>Wikipedia</cite> defines citations as <q cite="http://en.wikipedia.org/wiki/Citations">a reference to a published or unpublished source</q>.</p>

<cite> can also be used as a direct reference to a source without any quote content, such as in my previous paragraph where I mentioned the W3C and provided a link to the W3C’s specification:

  1. <p>Browsers are supposed to render q elements with quotation marks before and after the content. As such, the <cite>W3C</cite> advises authors <a href="http://www.w3.org/TR/html401/struct/text.html#h-9.2.2">against including quotation marks in the content</a> itself.</p>
RENDERING & INTERPRETATION

The default browser rendering of <cite> is often in italics. As for screen readers, they don’t treat content contained by <cite> in any special way.

Enter Microformats

Whenever I see content that includes a name (person, place or organization), I immediately think of the hCard microformat for marking up contact information. Since my LinkedIn recommendation example includes the name and web site of a person, it is a good fit for hCard:

  1. <blockquote cite="http://www.linkedin.com/in/emilyplewis">
  2. <p>Emily is hands-down the best XHTML/CSS designer I've known. She consistently cranks out the most semantic, valid XHTML/CSS web designs in amazingly short order. Most importantly, she keeps the user experience and semantics in mind... setting the bar for code quality that has not yet been met even by companies netting $400-800k for web design projects.</p>
  3. <p>I always compare XHTML mark up and CSS code quality from other companies to Emily's and every time I'm disappointed. If I want the best, lightest, most semantic XHTML designs, I go to Emily. Other companies and individuals might come up with XHTML that validates, but only Emily's is as efficient and as semantic as possible.</p>
  4. <p class="vcard"><a href="http://www.ianpitts.com/" class="url"><cite class="fn">Ian Pitts</cite></a></p>
  5. </blockquote>

Don’t know what hCard is? No problem, check out part 3 of my Getting Semantic With Microformats series.

Real-World Applications

Now that you know the fundamental structure and semantic uses of these elements, where might you use them? I’ve already mentioned testimonials and in-text quotes, but how about:

  • <blockquote> for blog comments
  • <blockquote> for excerpts of reviews
  • <blockquote> or even <q> for status updates on social networks
  • <q> for colloquialisms
  • <cite> any time you mention a resource

And I’m sure there are many more. It is really about considering your content and deciding what is semantically appropriate for it.

Debbie Downer Wants to Know Why

I’m not going to get too much into the specifics of why you should be using these elements for your quotation and referenced content. Again, I refer you toMeaningful Markup for that.

But I’m not clueless about those folks out there who poo-poo these approaches (I did work for a huge corporate monster for five years). Maybe it is the .NET developer on your team who only knows how to (horrifically) use <div>s. Maybe it is the department VP who thinks since her nephew can make web sites, it is simple, straightforward and markup doesn’t matter.

For those folks, I offer the following:

  • Semantic markup supports today’s web standards. And aside from beingstandards that all web professionals should aim for, they do have ROI.
  • Semantic markup provides the foundation for accessible sites.
  • Semantic markup can provide design patterns to help streamline team development. If everyone knows that <blockquote> with <cite> is to be used instead of a series of <div>s, <span>s, <br />s and the like, less time is needed to not only develop markup, but also to style that markup.
  • Semantic markup can contribute to SEO to help improve your content’sfindability.

For Your Consideration

It just wouldn’t be the web we all know and love if there weren’t debates and issues. <q> and <cite> aren’t immune.

No Love for <q>

Some designers, fed up with IE’s lack of delimiting quotation marks for <q>, drop the element entirely from their markup. Some turn to JavaScript or CSS to add the quotation marks.

As for me, I don’t sweat it too much. Depending on the client and project, I may serve conditional CSS to IE (versions prior to 8) so that the <q> content appears in italics. That’s about as far as I go. I encourage you to decide for yourself, but first maybe a bit more information to help your decision-making:

<cite> Is Better?

Also, there are some folks who feel that <cite> can be used similarly to <q> for inline quotes or citations. And since <q> has inconsistent browser rendering, <cite>is the better way to go.

True, the W3C spec states <cite> contains a citation or a reference to other sources, and I can understand that some people think a citation can be an actual quote or excerpt.

But I disagree here. My understanding of citation aligns with Wikipedia‘s definition ofa reference to a published or unpublished source. So, semantically, I see <q> as being specific to inline quotes, referenced content, etc., while <cite> is the source of the referenced content.

Stop Picking Sides and Just Develop

Ultimately, though, I try to avoid getting too wedded to any single approach toanything. The web is constantly evolving and, as such, I try to be the kind of professional that evolves with it.

Plus, I don’t know everything and I’m okay with that. I like to see what other people are doing, think about what makes the most semantic (and usable andaccessible) sense for me and my sites, and then just do it. When I encounter a new idea, I consider it and, if necessary, make changes to my approach. Which is one of the primary reasons I started this series.

So, let me know what you think about my approaches to <blockquote><q> and<cite>. If you have other ideas, please share them.

Coming Next

I’m still deciding on the topic for part 2. Right now, it is a toss-up between images with captions and accessible <table>s. You’ll just have to stay tuned to find out!

See what I did there? A cliffhanger! How exciting!

The Beauty of Semantic Markup, Part 2: <strong><b><em><i>

AUG062010

So, I had planned to focus the second installment of this series on markup for images with captions. The topic was a request from my friend Ian and his birthday was coming up. However, his birthday has passed, and I’m just now writing. Plus, I’ve been thinking a lot lately about something more fundamental: bold and italicized text.

This may seem a trivial thing to be consuming my “markup mind,” but after Tantek Çelik‘s HTML5 presentation, it’s been bugging me. And what specifically has been bugging me is the recommendation of <b> and <i> in HTML5.

Shut the Front Door!

Yep, it is true. <b> and <i> are back and, apparently, more “useful.” And when I first learned this, I was instantly put-off. I come from the “separate content from presentation” school that dropped these two elements in favor of the “more semantic” <strong> and <em>.

At the time when folks were thinking about the structural/semantic markup approach, <b> and <i> were strictly presentational. The HTML 4 spec declared these two as style elements that simply rendered text in bold and italics, respectively. Further, screen readers didn’t differentiate them in any special manner, adding to the logic that they were only useful for visual differentiation.

Conversely, in HTML 4, <strong> and <em> offered meaning, as well as the default visual rendering. Content marked up with <em>, for example, semantically indicated emphasis (and defaulted to italics in visual browsers), while the use of <strong>indicated strong emphasis (and defaulted to bold).

Re-Definitions in HTML5

The WC3‘s HTML5 recommendation, however, brings us some redefinitions of these elements:

  • The <b> element now represents a span of text to be stylistically offset from the normal prose without conveying any extra importance, such as keywords in a document abstract, product names in a review, or other spans of text whose typical typographic presentation is emboldened.
  • The <i> element now represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, a ship name, or some other prose whose typical typographic presentation is italicized. Usage varies widely by language.
  • The <strong> element now represents importance rather than strong emphasis.

<em>, meanwhile, isn’t featured on the list of changed elements in HTML5. Although, the working draft does seem to define it slightly differently than the previous spec: as emphatic stress rather than just emphasis.

Building an Argument

Upon first consideration, I was totally cool with the modified definitions of <strong>and <em> (although, admittedly, slightly confused as to what emphatic stressmeant), but I still felt <b> and <i> were presentational. I mean, the W3C even usesstylistically and typographic presentation in it’s definitions for those elements.

But, thanks to this new series, I got to doing some research. And when I started, I was aiming to build an argument against <b> and <i>. First, I wanted to find out how screen readers treated these guys.

Screen Readers

As it turns out (and as I expected), two most popular screen readers don’t, by default, read content contained by these elements any differently than other content.

What I didn’t expect to discover, though, is that they also don’t treat <strong>and <em> in any special way.

There goes the main “they aren’t accessible” argument I was hoping for. None of the tags seems to offer any special accessibility to screen reader users.

Search Engine Optimization

So then I began a hunt for an SEO argument. Somewhere in the dusty annals of my mind, I recalled reading that Google paid particular attention to content contained by <strong>.

Turns out, I was wrong yet again. In fact, at one point, Google gave greater weight to content marked up with <b>, not <strong>.

As of today, though, the search engine gives equal weight to <strong> and <b>, as well as <em> and <i>.

Crap. I thought I had all this ammunition against <b> and <i>, when what I really had were outdated and incorrect notions.

Forget the Argument, Focus on Semantics

I’ve said it before, but apparently I need to listen to my own advice about being too wedded to a particular semantic point of view … especially when operating with wrong assumptions. Time to focus on the entire point of this series: semantics.

So, let’s take a closer look at <b> and <i> in HTML5

Presentation via CSS

In addition to the definitions I shared above, the HTML5 draft also specifies that CSS should control the presentation of <b> and <i>; that neither will, necessarily, appear in bold or italics by default.

Of course, this ultimately comes down to what the browser makers do, but this is a good clarification that these elements are no longer exclusively presentational in nature.

Further, the draft encourages authors to use the class attribute to define why a<b> or <i> element is used in order to allow for unique styling of different implementations.

Consider the new definition of assigning <b> to keywords and product names to offset those terms without adding importance. By extending <b> withclass="keyword" or class="product" (or some other equally semantic values), you have your CSS hooks to give each a unique presentation and you are also adding meaning to your markup (kinda like how microformats work).

Same is true for applying <i> to taxonomy terms, idioms, phrases in another language and the like. Specifying the “why I’m using <i>” via class offers potential for both styling and semantics.

Common Typographic Conventions

Even with these caveats, though, I can’t help but still think about the presentational nature of the definitions in HTML5. As I mentioned, stylistically offset just screams presentation to me.

But then I started thinking about how bold and italicized text is commonly used in print. Yes, they do offer visual indicators, but more often (at least in my experience), text offset with italics or bold does conveys meaning, especially when considered in context.

Latin words, inner dialog or thoughts, titles of songs … I often see this type of content italicized in print. And, in context, I recognize the additional meaning the italics provides the content.

Media Independence

In HTML5, <b> and <i> are explicitly media independent. Essentially, because each element is no longer tied to bold or italics (visual presentation), the new semantic meaning they offer is available to non-visual browsers.

Again, it is up to those browser and screen reader makers to take advantage of that meaning, but media independence further supports the new semantic direction of these elements.

Warming Up

With all this additional information, I’m warming up a bit to using <b> and <i> again. But I’d be lying if I said I was completely comfortable.

<b> and <i> have historic ties to the notions of bold and italic. I mean, that’s what “b” and “i” represent.

Why a new element wasn’t introduced that is independent of this presentational history bugs me a bit. But, then again, using what people are already familiar with isn’t always a bad thing.

Still, I worry that people will use these elements for presentational purposes. Or that folks won’t apply the recommended class values to differentiate instances of these elements.

I can’t help but think that this is just a big can of worms that will get messy if markup authors don’t understand and apply the spec properly. And let’s not even talk about the “challenges” that could result from what browser makers will end up doing or not doing.

Practical Usage

Aside from my concerns, I do want to give some thought to how I would actually use <b> and <i>, now that they are semantic. And, of course, what roles <strong>and <em> will play in my markup.

<strong>

Even with the realigned definition of <strong> in HTML5, I plan to use it as I always have, because I never really thought of it as strong emphasis. I always used it as it is now defined: indicating importance.

For my projects, the types of content I commonly mark up with <strong> include:

  • Alerts
  • Warnings
  • Reminders
  • Important content (duh)

For example:

  1. <p><strong>Registration is required</strong> for this event.</p>

or

  1. <p>The presentation begins at <strong>6:30 pm</strong>, so be sure to show up a few minutes early to avoid interrupting our speaker.</p>

or

  1. <p><strong>Password provided for this username is incorrect.</strong> Please try again or you may request your password be emailed to you.</p>

I don’t think there is a hard–and–fast rule about applying <strong>. To me, it is more about content. What is important? Is it the time a presentation starts, or is it the reminder to arrive early?

And this is what I dig about semantic markup. Focusing on content.

<em>

Like <strong>, I pretty much plan to use <em> the same as I always have. Even with the new (slightly unclear) definition of emphatic stress<em> still means, to me, stressed content. As in content that I would verbalize in a stressed tone to indicate emphasis.

And because I write the way I talk (with lots of stressed words), I use this element often in my content:

  1. <p>Talking about microformats in less than 30 minutes (plus leaving time for questions) was <em>quite</em> a challenge.</p>

or

  1. <p>You can use the <cite> attribute with <q> to indicate the source of a quote, <em>if</em> it's online</p>.

It is really a matter of knowing the content well enough to know what terms and/or phrases should be emphasized in this fashion.

<b>

To be honest, based on the HTML5 definition of <b>, I’m not sure how often I’ll actually use it. The draft suggests it can be used with product names and keywords, but I, personally, don’t see a need to differentiate this type of content in any way.

Of course, a client might feel differently. Perhaps a client might want all of the product names on their site to appear stylistically offset. So, in that situation, I would use it and take advantage of the recommended application of class to indicate the purpose of the element:

  1. <p>For data management, we offer two flagship products: <b>Moxie</b> and <b>Mojo</b>.</p>

And if that same client also wanted to highlight keywords associated with their products, I might:

  1. <p><b>Moxie</b> offers users the ability to <b>cleanse</b><b>extract</b> and <b>transform</b> data.</p>

Meanwhile, in my CSS, I would style .product and .keyword in some fashion, likely both unique.

Also, HTML5 does specify that <b> can be used simply to indicate text that needs unique styling, such as those typographic conventions of drop caps and paragraph leads:

  1. <p><b>I</b>t was a cold and rainy night.</p>

Although, I’m not sure I would favor this approach over using :first-letter in my CSS (like I already do on this blog). But I guess I could see it for styling a paragraph lead uniquely:

  1. <p><b>It was a cold and rainy night,</b> despite what the weatherman had announced on the evening news. Bob was annoyed his stargazing plans were in danger from the looming storm.</p>

Still, even after considering those scenarios, I’m frankly not convinced <b> is going to be a regular element in my arsenal.

<i>

As for <i>, I can see using it much more often than <b>. Particularly for technical, legal or medical terms, as well as foreign language phrases:

  1. <p>A <i>patent foramen ovale</i> is a congenital defect between the two upper chambers of the heart.</p>

or

  1. <p>I try to live my life according to the axiom, <i>illegitimi non carborundum</i>.</p>
FOREIGN LANGUAGES

Since I used a Latin phrase in the last example, now might be a good time to address use of the lang attribute. HTML5 Doctor provides an excellent article on the same topics I’m covering here.

In their examples of using <i> for foreign language phrases, they apply the langattribute to indicate which foreign language is being referenced. For example:

  1. <p>Mix baking soda and vinegar together, and <i lang="fr">voilá</i>, you get a cool chemical reaction.</p>

However, another article on the topic, Using <b> and <i> elements, warns against this approach:

… the language attribute only describes the language of the text, not the meaning. It is possible that you will want to style text in a different language differently according to the context in which it is used, either now or in the future.

As for me, I think that if I do use <i> for foreign phrases, I’ll likely skip the langattribute and rely on class for any special styling.

Exercise Discretion

While I’m admittedly still a bit on the fence about actually using <b> and <i>regularly, you may feel differently and want to start marking up right away. If that is the case, please use these elements intelligently and correctly.

Don’t just apply <b> because you need a bold effect and you are feeling lazy. Don’t use <i> for a publication title, when <cite> may be the appropriate element (seepart 1 of this series for more on <cite>).

Even the HTML5 draft recommends discretion:

… authors are encouraged to consider whether other elements might be more applicable than the i element, for instance the em element for marking up stress emphasis, or the dfn element to mark up the defining instance of a term.

Go Forth & Experiment

After gathering all this information, I had hoped to have a firm conclusion about <b>and <i>. Alas, I don’t. So, what I shall do is try different approaches and see how they work for me, my sites and my clients.

I have some clients who I know won’t take the time to add the extra markup for something like <b>, while some clients may embrace that extra level of control. And I have some CMS implementations that currently aren’t configured in a way that will easily allow the addition of <i>.

And then there’s still that little voice in my head that can’t seem to fully accept<b> and <i> as semantic elements.

Only time and practice will tell how big a role <b> and <i> will play for me. Until then, I’m eager to hear your thoughts!

The Beauty of Semantic Markup, Part 3: Headings

NOV072010

I always find myself drawn to fundamental concepts, because they can be deceptively simple. Headings are like that. You know, <h1><h6>.

They seem simple until you take time to think … think about structure, semantics, accessibility, search engines and, now, HTML5’s sectioning model.

And I have, indeed, been thinking about headings lately, especially as I dive intoHTML5 and (re?)consider the approaches I’ve taken in the past.

So this series now shifts focus to <h1><h2><h3><h4><h5> and <h6>.

Headings for Outlines

The semantic purpose of headings is to indicate a content outline; a structure:

A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.

— W3C

You can even see this heading-based outline using the W3C’s validator service, if you have “Show Outline” selected (note: does not work with HTML5 doctype):

W3C Validator outline optionFor example, here’s the heading outline for one of my recent blog posts:

Heading outline for A Blog Not Limited postLooking at this three–year–old markup now, I wouldn’t take the exact same approach today, but the gist is there. My blog name is the first heading, with all the other headings “nested” hierarchically after.

Of course, not all sites are going to have a heading hierarchy, such as one with a columnar layout, where the most important heading (<h1>) appears after, for example, an <h2>:

  1. <div>
  2. <h2>Quick Links</h2>
  3. </div>
  4. <div>
  5. <h1>Site Name</h1>
  6. </div>
  7. <div>
  8. <h2>Search</h2>
  9. </div>

But even in this example, the headings are still used to convey a content structure.

Best Practices & Debates

As far as I can glean, the “best practices” for indicating content structure is simply to use <h1> for the most important information, <h2> for less important information and so on. Also, it is probably best to not skip any heading levels, such as going from <h1> to <h3>But that’s it.

For quite a long time, many folks believed there should be only one <h1> on a page, despite the fact that this is not part of the specification. I happened to be one of those people and, if I recall correctly, my reasoning for this “logic” was based on an assumption about search engine penalties.

Google now refutes this misperception, but does advise the judicial use of <h1>. Which leaves the argument that the reason for only one <h1> is that there can only be one “most important” heading on a page.

Traditionally, I’ve also agreed with this thinking. But, as you’ll see later in this article, HTML5 has me thinking very differently about <h1>s. HTML5 aside, though, I’m still inclined towards the one <h1> approach … which brings up yet another debate (don’t you love our little industry?).

This debate assumes a single <h1>, but questions what content should be inside that <h1>. Site name? Company name or logo? Page title?

As you can see from this blog (as well as pretty much every other project I’ve marked up) I’ve been on the side of the site name, which is often the company name. I’ve never used <h1> for a logo, and I can’t say I even understand that approach. <h1> is for text. A logo is not text. There’s no argument there for me.

But I’m now appreciating the logic that <title> is, semantically, the appropriate element for the site name, while <h1> may be more useful for the page heading.

Headings for Navigation

A wonderful result of using headings to indicate content structure is that it aids navigation. Users can scan headings on a web browser to more quickly find the information most important to them. Even non-browser users can take advantage of headings for this purpose, as many assistive technologies leverage the outline to navigate.

The JAWS screen reader, for example, lets users navigate the page by jumping from heading to heading:

This demonstration alone confirms for me that using <h1> for page headings is probably the best way to go. I imagine it gets old fast hearing the site name repeated because it is contained by an <h1>. But that’s just my own personal decision (though a good one, I suspect).

In terms of “best practices” to support accessible navigation, as long as you are focusing on content structure, you are probably good. Regarding multiple <h1>s, there is no definitive answer about how it affects accessibility. Anecdotally, it could cause some screen reader users to miss key content.

Regarding heading hierarchy, the WCAG 2.0 accepts both nested (where <h3>follows <h2> which follows <h1>) and non-hierarchical headings. (And, in case you were wondering, Google doesn’t mind non-hierarchical headings either.)

Headings for SEO?

Speaking of Google (how’d you like that segue?) … headings have historically been heralded as helping SEO. In fact, in the above image of my blog outline, you’ll see that I strayed from the semantic, outline-focused approach with the use of <h2>for my blog’s “tagline.” This is because at some point in time (years ago) I heard that search engines favored headings with keywords, so I felt the semantic “bending” was worth it.

What now seems more accurate is that search engines use headings the same way that people do: to discern important content and understand content hierarchy. Both Google and Yahoo! advise authors to write headings with this approach.

The question that matters to me, though, is do search engines give greater weight to heading content? No idea. There are thousands (perhaps millions) of articles that say headings carry greater weight, but I could find nothing definitive from the major search engines.

So, what’s my verdict? Today, I don’t think I would use a heading for a site taglinejust to achieve SEO. I suspect that the search engines have such sophisticated algorithms, that a single heading to expose a few keywords isn’t going to help me in the rankings. And if it hinders accessible navigation by “confusing” the content outline, then it just isn’t worth it to me.

Um, Isn’t This Old News?

Maybe. This might be old news to you, and awesome if it is. That means you already take a thoughtful approach to markup, and we would probably be best of friends.

But it wasn’t all old news to me. I never took time to consider the appropriate use of <h1>. I had outdated assumptions about SEO and headings. And, while I knew about screen reader navigation, I never took the time to actually watch someone use a screen reader on a site without headings (you really must watch that video above).

Then I started messing around with HTML5, and an entirely new world of possibility opened, forcing me to make sure I understood how and why to use headings. Hence, this post.

HTML5 Sections & Outlines

So back to this new world. HTML5 is pretty cool, especially if you are a POSH lover like me. It gives markup authors a broader semantic arsenal to work with (if you haven’t yet, pick up a copy of Jeremy Keith‘s HTML5 for Designers to get up–to–speed).

New Semantic Elements

One of the many things HTML5 brings to the table is a new outline algorithm. This is based off of the new semantic, structural elements:

  • <section> is used for content that can be grouped thematically. A <section>can have a <header>, as well as a <footer>. The point is that all content contained by <section> is related.
  • <header> typically contains the headline or grouping of headlines for a page and/or <section>s, although it can also contain other supplemental information like logos and navigational aids.
  • <footer> is used for content about a page and/or <section>s, such as who wrote it, links to related information and copyrights.
  • <nav> is used to contain major navigation links for a page. While it isn’t a requirement, <nav> will often be contained by <header>, which, by definition, contains navigational information.
  • <article> is used for content that is self-contained and could be consumed independent of the page as a whole, such as a blog entry. <article> is similar to <section> in that both contain related content. The best rule of thumb for deciding which element is appropriate for your content is to consider whether the content could be syndicated. If you could provide an Atom or RSS feed for the content, <article> is most likely the way to go.
  • <aside> indicates the portion of a page that is tangentially related to the content around it, but also separate from that content, such as a sidebar or pull-quotes. A good method for deciding whether <aside> is appropriate is to determine if your content is essential to understanding the main content of the page. If you can remove it without affecting understanding, then <aside>is the element to use.
More In-Depth Outlines

These new elements provide authors a way to explicitly group content, and each has its own self-contained outline, so you don’t have to follow a page-focused heading hierarchy. Instead, you can start with <h1> within each element, and the algorithm uses the hierarchy and nesting of the sectioning elements to determine the outline level of each <h1>.

Wait! What?

Yeah, that’s what I said when I first learned this. The best way to grok this, I think, is with an example:

  1. <header>
  2. <h1>Blog Archive</h1>
  3. </header>
  4. <section>
  5. <h1>Posts by Month</h1>
  6. <article>
  7. <h1>Blog Post Title</h1>
  8. </article>
  9. <article>
  10. <h1>Another Blog Post Title</h1>
  11. </article>
  12. </section>
  13. <aside>
  14. <h1>Popular Posts</h1>
  15. </aside>

The HTML5 outline algorithm, then, gives us:

  • Blog Archive
    • Posts by Month
      • Blog Post Title
      • Another Blog Post Title
    • Popular Posts

If this multiple <h1> approach was used with previous versions of HTML, the outline would be inaccurate:

  • Blog Archive
  • Posts by Month
  • Blog Post Title
  • Another Blog Post Title
  • Popular Posts
<hgroup>

HTML5 also introduces a new element, <hgroup>, which can be used to suppress headings from the content outline. A specific situation in which this would be useful is on this very blog, where I’m using an <h2> for my tagline. As I mentioned, I nowthink this idea wasn’t the best because it could adversely affect accessible navigation.

But, by using <hgroup>, all headings after the first child are ignored by the content outline:

  1. <header>
  2. <hgroup>
  3. <h1>A Blog Not Limited</h1>
  4. <h2>to web design, standards &amp; semantics</h2>
  5. </hgroup>
  6. </header>
BENEFITS …

While it remains to be seen whether this will benefit my clients and projects, there is some sound reasoning behind this new approach to sectioning content and outlines.

First, with self-contained outlines, you can have an infinite number of heading levels. You are no longer limited to 6 (<h1><h6>). For a deep site, I could see this being useful. Not so much with shallower levels of information.

Second, self-contained content with independent heading hierarchies enable portable content. Consider a blog post that often appears on the home page, as well as its own page, and can even be syndicated or shared with other sites. Before, you would often have to modify the heading markup for the blog post depending on where it appeared. Now with the HTML5 outline algorithm, you can independently define the markup for the blog post without regard to where it may appear on a site (or another site).

… BUT BE AWARE

Perhaps, over time, these admittedly practical benefits may be worth taking full advantage of headings in HTML5. For now, though, there are a few issues. As of now, browsers don’t support this new outline algorithm. If you want to see the outline of an HTML5 page, you have to use an external tool.

It’s not surprising, then, to know that assistive technologies aren’t supporting this algorithm either. Which, for me, is my biggest concern. If I start with <h1>s in each container of related content, that is going to cause major problems with heading-based navigation in text browsers and screen readers.

Middle Ground?

Fortunately, HTML5 is backwards-compatible and flexible, so is isn’t an either/or proposition. You can still approach headings from a page-level hierarchy and use the new HTML5 elements to group content. The spec even says authors can start sections with either <h1> elements or headings reflective of the section’s nesting level. So that’s what I plan on doing, at least until assistive technologies catch up.

Muestras de cómo hacer la administración de WordPress más accesible a los lectores de pantalla (en inglés).

Fuente (artículo en inglés):

http://www.badeyes.com/?p=293&goback=.gde_41800_member_44305147

Tips on How to Make WordPress Admin More Accessible to Screen Readers

By Geof Collis.
February 19, 2011.

I’ve been using WordPress now for almost 3 years, I’ve found it to be a fantastic piece of work and highly recommend it to anyone wanting to create a website, there are many Themes to choose from or if you have the skills you can create your own.

Most people might think WordPress is a Bloggin platform only but it is also a great Content Management System (CMS) as well and there are thousands of Plugins you can choose from to enhance your website and you dont need any real programming knowledge.

Over the years I’ve been asked how it works with Screen Readers, in my case JAWS that I’ve finally got around to compiling some tips that make it more accessible and I’ve listed them below.

Note: I wrote these tips as a JAWS screen reader user only, other Screen Readers may use different commands for the same function.

Profile Page

The very first thing to do after you’ve installed WordPress is to go to your “Profile” page, usually the 3rd link from the top or whatever Username you used to set up WordPress.

Once there you can either look for the check box ” Disable the visual editor when writing and select it or just hit your ‘F’ key and it should take you directly to the check box.

Scroll down near the bottom of the page and click on “Update Profile”

Posts and Pages

Next we make our way to “New Post”, should be 5th link from the top, after “LogOut” .

Once you’re there look for the link “Screen Options” or use your page find function (ctrl plus f) and type “Screen” and hit enter, once there hit enter to open the menu, tab down until you reach “Number of Columns” and select 1 column, continue tabbing until you hear “Screen Options” again hit enter to close the menu.

Next we use our links list dialogue menu function and find “Pages”, once there look for “Add New” or hit your ‘h’ key twice, it should take you directly the link then access it and follow the above directions as we did for Posts.

Widgets

When you start feeling comfortable with WordPress you might want to begin using “Widgets”, in that case pull up your links list dialogue menu and look for “Appearance” click on it then bring up the menu again and then click on “Widgets”.

When you land on the page use your page find command and look for “Screen options” again select “Enable accessibility mode”.

Creating a Post or Page

Now that you’ve implemented the above settings it’s time to create a Post or Page.

We’ll start with a Post, the quick steps are the same for a Page:

Once the page loads hit your ‘F’ key, it should take you directly to the “Title” field and hit enter, type your Title then hit enter again when you’ve finished and you’ll be taken to the main body where you can either cut and paste your text from a text editor or type away, hitting enter anytime you want a new paragraph, WordPress recognizes it and codes it accordingly.

WordPress also recognizes HTML code such as hyperlinks, semantic markup etc so dont be afraid to use it, there are also keyboard commands if you’re feeling adventurous.

When you are finished hit alt p and the Post/Page will be published or you can Preview it in the “Publish” section first.

Recommended Plugins

These are some of the Plugins I’ve tested and useed for various sites, I found them easy to use and accessible.

All in One SEO Pack

Automatically optimizes your WordPress blog for Search Engines (Search Engine Optimization).

All in One SEO Pack

Exec-PHP

The Exec-PHP plugin executes PHP code in posts, pages and text widgets.

Exec-PHP

Post-Expirator

Allows you to add an expiration date (hourly) to posts which you can configure to either delete the post or change it to a draft.

Post Expirator

Post Teaser

Post Teaser generates excerpts of posts for the main, archive and category pages, also generate a word count, image count, and estimated reading time.

This is highly customizable and is great if you have other Users Posting since you dont need to insert <!- -more- -> to break off the Post, you specify the number of characters.

Post Teaser

WordPress Stats

Simple, concise stats with no additional load on your server by plugging into WordPress.com’s stat system.

WordPress.com Stats

Subscribe2

An opt in mailing list that sends a list of subscribers an email notification when new posts are published to your blog

Subscribe2

Tweet This

Popular Twitter plugin inserts “Tweet This” links so your readers can share
posts with one click. Automatically tweets new posts via OAuth.

Tweet This

WP-Title2

This plugin allows you to add and edit a Heading for your Posts, Pages and Custom Post Types, different from the Title (which is used in the navigation links). Very useful if you use WordPress as a CMS and is good for Search Engine Optimization (SEO).

WP Title 2

Curso “Experto Universitario en Accesibilidad y Usabilidad” en Buenos Aires, Argentina..

Un curso de excelente nivel con un equipo docente de lujo.

Fuente:

http://hfnoticias.com.ar/noticia/index/249/4604

Curso “Experto Universitario en Accesibilidad y Usabilidad”

Inicio: miércoles 30 de marzo de 2011
Duración: 2 cuatrimestres
Carga Horaria: 150 horas (martes y miércoles de 18:30 a 21 hs.)
Lugar: Medrano 951 – CABA

Fundamentos.

La accesibilidad web surge como estándar para asegurar a las personas con discapacidad las mismas oportunidades que al resto de la gente para acceder a la información, para integrarse plenamente a la sociedad y acceder a sus servicios y beneficios
La accesibilidad web para sitios públicos es obligatoria por ley en muchos países. En Argentina será obligatoria para 2012, en virtud de la ley 26.653 recientemente sancionada.
Internacionalmente los estándares de accesibilidad son desarrollados por el World Wide Web Consortium (W3C).
Hace pocos años ha sido aprobada la Convención Internacional sobre los Derechos de las Personas con Discapacidad y ratificada por nuestro país. Este marco legal ampliará a nivel mundial la legislación que hace obligatoria la accesibilidad web.
Las pautas de accesibilidad tienen muchos elementos en común con las buenas prácticas de posicionamiento en los motores de bús-queda, brindando así este beneficio adicional.
Los criterios de usabilidad han crecido en las últimas décadas, paralelos a la maduración de la web, dando pautas de calidad.
La disciplina de la experiencia de usuario ha ampliado la perspectiva del estudio y diseño en relación con las interacciones de los usuarios, considerando sus múltiples dimensiones
Los campos de la accesibilidad y de la usabilidad tienen una cantidad de aspectos conceptuales en común, algunos autores enfatizan esto con el concepto de la usabilidad universal.

Destinatarios.

Este curso se dirige tanto a diseñadores web, desarrolladores web, webmasters, programadores, docentes y profesores que trabajen en TIC, así como a quienes ocupen posiciones gerenciales en esas áreas. El curso también es útil para profesionales de las áreas psico-sociales que se interesen en estudios y evaluaciones de las TIC, así como para quien desee profundizar su comprensión de los actuales desafíos de calidad e inclusión.

Objetivos Generales.

Alcanzar los conocimientos y competencias para incluir en el diseño, desarrollo y dirección de proyectos web criterios de accesibilidad y usabilidad basados en estándares y buenas prácticas.

Competencias del Egresado.

El egresado adquirirá competencias para:
Conocer los estándares y buenas prácticas en el ámbito de la accesibilidad y la usabilidad y ser capaz de aplicarlos al diseño y desarrollo de sitios web y a la dirección de proyectos web.
Evaluar la accesibilidad de sitios web, utilizando las metodologías y herramientas adecuadas.
Realizar pruebas de usabilidad de sitios web y evaluar la experiencia de usuario frente a los mismos.
Participar en investigaciones relacionadas con las interacciones de los usuarios con las tecnologías de la información.

Cuerpo Docente.

Area Accesibilidad: Karina Rojo, Carlos Benavidez, Martin Baldasarre, María Dolores García, Jorge Plano.
Area Usabilidad: Enrique Stanziola, Gonzalo Auza, Juan Manuel Carraro, Eduardo Mercovich.
Coordinadora académica: Lorena Paz.
Coordinador general: Jorge Plano.

Modalidad de trabajo.

El curso se desarrollará con una modalidad teórico-práctica, con ejercitación de los conceptos adquiridos, la cual incluirá la construc-ción de páginas y la evaluación de sitios.
Habrá clases por parte de reconocidos expertos nacionales y se realizarán teleconferencias con expertos del exterior.
Los cursantes deberán desarrollar diversos trabajos prácticos y un trabajo final.

Certificación.

Los participantes que hayan tenido el 80% de asistencia y aprueben las evaluaciones, obtendrán un certificado extendido por la Uni-versidad Tecnológica Nacional Facultad Regional Buenos Aires.

Requisitos necesarios.

Quienes aspiren a realizar este curso deberán cumplir con los siguientes requisitos:
Experiencia en algunas de estas áreas web: diseño, programación, producción de contenidos, dirección de proyectos, evaluación de sitios.
No se requieren títulos previos.
Poseer conocimientos básicos de html, css y scripts.

Consultas e inscripción.

Comunicarse por info@sceu.frba.utn.edu.ar o 4867-7545  4867-7545

Organización.

Inicio: miércoles 30 de marzo de 2011
Duración: 2 cuatrimestres
Carga Horaria: 150 horas (martes y miércoles de 18:30 a 21 hs.)
Lugar: Medrano 951 – CABA

Respuesta a 25 dudas habituales sobre accesibilidad web.

Como en tantos otros casos, recomiendo directamente leer el original, ya que la bitácora de Olga Carreras no tiene desperdicio para los que estamos en las cuestiones relacionadas con el diseño web y la accesibilidad web.

Fuente:

http://olgacarreras.blogspot.com/2011/01/respuesta-25-dudas-habituales-sobre.html

domingo 30 de enero de 2011.

Respuesta a 25 dudas habituales sobre accesibilidad web

En los artículos Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidadTécnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad incluía las respuestas a 15 dudas de accesibilidad basándome en el documento “Techniques for WCAG 2.0” de las WCAG 2.0

A continuación listo el enlace a las 15 dudas ya resueltas en esos artículos anteriores y el ancla a las 10 nuevas dudas que se resuelven en este artículo.

  1. ¿Mi sitio Web es inaccesible si utiliza ventanas emergentes?
  2. ¿Mi sitio Web es inaccesible si utiliza frames?
  3. ¿Mi sitio Web es inaccesible si utiliza tablas para maquetar?
  4. ¿Mi sitio Web es inaccesible si utiliza Flash?
  5. ¿Mi sitio Web es inaccesible si utiliza javascript?
  6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
  7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
  8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
  9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
  10. ¿Cómo se especifica correctamente el color de fondo y de primer plano?
  11. ¿Cómo marcar adecuadamente un emoticon?
  12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
  13. ¿Es recomendable incluir una opción de “Leer está página”?
  14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?
  15. ¿Cómo marcar la pronunciación de una palabra?
  16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
  17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
  18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
  19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
  20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?
  21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
  22. ¿Cuándo puedo ponerle a una imagen alt=””?
  23. ¿Es correcto que el contenido de un input se borre al coger el foco?
  24. ¿Qué se considera texto grande y texto pequeño?
  25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?

Es el típico ejemplo de “Leer más” o “Más información” en un listado de noticias.

En las WCAG 1.0 se especifica en relación al punto de verificación 13.1 Identifique claramente el objetivo de cada vínculo que si en la página hay dos o más vínculos con el mismo texto deben remitir al mismo recurso y de lo contrario se han de diferenciar por el atributo “title”:

Si hay más de un vínculo en una página con el mismo texto, todos estos vínculos deben remitir al mismo recurso. Esta coherencia ayudará al diseño de la página tanto como a la accesibilidad.

Si dos o más vínculos van referidos a objetivos diferentes pero comparten el mismo texto, distinga los vínculos especificando un valor diferente para el atributo “title” de cada elemento A.

En “Técnicas HTML para las Pautas de Accesibilidad de los Contenidos Web 1.0” del W3C.

Las WCAG 2.0 también tienen dos criterios de conformidad (2.4.4 de nivel A y 2.4.9 de nivel AAA) que obligan a que se clarifique el propósito de un vínculo. Una de las técnicas suficientes para cumplir con el criterio de conformidad 2.4.4 es la “H33: Supplementing link text with the title attribute”. Esta técnica consiste también en incluir el atributo “title” para clarificar el destino del vínculo cuando la información complementaria proporcionada por el atributo “title” es algo que el usuario debe saber antes de seguir el enlace.

Sin embargo, la propia técnica H33 de las WCAG 2.0 desaconseja el uso del atributo “title” para clarificar el destino de un vínculo por la falta de soporte del atributo “title” en muchos user-agent. De hecho, esta técnica no es válida para cumplir con el criterio de conformidad 2.4.9, que también se refiere a clarificar el destino de un vínculo pero es más estricto por ser de nivel AAA.

En esta técnica se recomiendan otras dos técnicas suficientes alternativas al uso de “title”:

  • o bien que el enlace tenga el texto completo (sería la técnica H30) por ejemplo: “Leer más sobre el artículo ‘WCAG 2.0′” en vez de “Leer más”
  • o bien ocultar mediante CSS el texto del enlace que sigue a “Leer más” (sería la técnica C7), lo cual resulta muy útil cuando el texto del enlace puede llegar a ser demasiado extenso. También se permite incluir un enlace o botón para ver u ocultar las versiones largas de los enlaces (serían las técnicas G189SCR30)

Estas alternativas permitirían cumplir con los criterios de conformidad 2.4.4 (nivel A) y 2.4.9 (nivel AAA).

En cuanto a la opción de ocultar por CSS parte del texto del enlace, es necesario que la ocultación del texto se haga de forma accesible para los lectores de pantalla, es decir, no se debe utilizar display:none sino localizarlo fuera de pantalla.

El ejemplo correcto sería el siguiente:

En la CSS:

a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; }

En la página:


 <dl>
 <dt>Winnie the Pooh </dt>
    <dd><a href="winnie_the_pooh.html">
        <span>Winnie the Pooh  </span>HTML </a> </dd>
    <dd><a href="winnie_the_pooh.pdf">
        <span>Winnie the Pooh  </span>PDF </a> </dd>
 <dt>War and Peace</dt>
    <dd><a href="war_and_peace.html">
        <span>War and Peace  </span>HTML</a></dd>
    <dd><a href="war_and_peace.pdf">
        <span>War and Peace  </span>PDF </a> </dd>
 </dl>

Hay otra manera de cumplir con la pauta 2.4.4 (nivel A), pero que sin embargo no será válida para cumplir con la pauta 2.4.9 (nivel AAA), y por tanto es menos aconsejable, pues las WCAG 2.0 alientan a cumplir más criterios de los estrictamente necesarios para alcanzar un determinado nivel de adecuación.

Esta última alternativa es que será válido el enlace “Leer más” cuando esté correctamente contextualizado. Por ejemplo, en el caso de un párrafo (sería la técnica H78) el W3C propone el siguiente ejemplo:

Sería incorrecto:

<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.</p>
<p><a href="final15.html">[Read more...]</a></p>

Pero sería correcto:

<p>Coming soon to a town near you...the final 15 in the
National Folk Festival lineup.
<a href="final15.html">[Read more...]</a>
</p>

De igual manera, hay otras técnicas para indicar cómo se puede asociar correctamente un enlace con su contexto (en listas, tablas, etc.)

17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?

La pauta 4.1 (prioridad 1) de las WCAG 1.0 indica Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente. De la misma manera, el criterio de conformidad 3.1.2 de las WCAG 2.0 también obliga a identificar los cambios de idioma pero establece una serie de excepciones. No es necesario identificar el cambio de idioma de:

  • los nombres propios
  • los términos técnicos, por ejemplo: Homo sapien, Alpha Centauri, hertz, habeas corpus (ejemplos textuales de la explicación del criterio)
  • las palabras en un idioma indeterminado
  • las palabras o frases que se hayan convertido en parte natural del texto que las rodea.

Para resolver las dudas que esto puede ocasionar recomiendan: If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?

La pauta 1.4.2 (nivel A) de las WCAG 2.0 indica que sólo es necesario si el sonido dura más de 3 segundos: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)

19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?

Es una práctica habitual utilizar :focus{outline:0;} o peor aun onfocus="blur()" para evitar que las imágenes queden punteadas alrededor cuando cogen el foco.

Las WCAG 1.0 indican mediante el punto de verificación 9.4 (de prioridad 3 y de prioridad 2 en la Norma UNE 139803) que es necesario poder acceder mediante el tabulador a vínculos, controles de formulario y objetos. Sin embargo no se especifica si es necesario que el foco sea visible.

Esto se corrige en las WCAG 2.0 Su criterio de conformidad 2.4.7 (nivel AA) especifica claramente que el foco debe ser visible, de hecho incluye como fallos habituales las dos prácticas comentadas:

Por tanto, no sólo se debe poder acceder mediante el tabulador a toda imagen que sea enlace, sino que además cuando coja el foco este debe ser visible como se aprecia en este ejemplo:

Logotipo del W3C con borde punteado porque ha recibido el foco

20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?

Una duda habitual es la anchura que debe tener (en número de carácteres) un bloque de texto para su óptima legibilidad. Hay muchos estudios al respecto, unos recomiendan entre 80-100 caracteres y otros entre 60-80 por ser el ancho preferido de los usuarios. Se pueden consultar esos estudios en el artículo “Columnas, anchos de línea y legibilidad” de Juan Carlos García.

¿Dicen algo al respecto las WCAG? El criterio de conformidad 1.4.8 (nivel AAA) indica queel ancho de un bloque de texto no debe ser mayor de 80 caracteres.

For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text.

En relación con este requisito, las técnicas que aseguran que sea así aunque se redimensione el navegador son :

En este criterio de conformidad también se especifica que el espacio entre líneas(interlineado) debe ser, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos, al menos, de 1.5 veces mayor que el espacio entre líneas.

People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is ‘single spaced’ (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (i.e., that there is a blank line between the two paragraphs that is 150% of the single space blank line).

21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?

La técnica G174 de las WCAG 2.0 ofrece como alternativa para cumplir con los criterios de conformidad 1.4.3 y 1.4.6 referentes al contraste de color, el utilizar la cláusula de “Version alternativa” de los requisitos de conformidad e incluir un botón o enlace para visualizar la página en alto contraste. Un ejemplo de una web que ofrece una versión en alto contraste es: Media, del Ministerio de Educación.

Pero para que se utilice con éxito esta técnica es necesario:

  • El botón o enlace a la versión alto contraste debe cumplir con los requerimientos de contraste.
  • La versión alto contraste debe tener el mismo contenido y funcionalidad.
  • La versión alto contraste debe cumplir con todos los demás requisitos de accesibilidad.

Los dos últimos requisitos no deben suponer un problema si simplemente se carga una CSS diferente.

22. ¿Cuándo puedo ponerle a una imagen alt=””?

¿Qué entendemos por imagen decorativa? Cualquier imagen que no forma parte del contenido significativo de la página y que por tanto debería ser ignorada por los lectores de pantalla. Según la definición incluida en el criterio de conformidad 1.1.1serving only an aesthetic purpose, providing no information, and having no functionality

Las imágenes decorativas deberían estar definidas en las CSS, pero si se incluyen en las páginas deben tener alt=""

El error cómun F39. Failure of Success Criterion 1.1.1 due to providing a text alternative that is not null (e.g., alt=”spacer” or alt=”image”) for images that should be ignored by assistive technologyindica además que aunque es válido alt=" " (ojo, se admite un espacio en blanco pero no que contenga &nbsp;es más recomendable usar alt="".

Además las imágenes decorativas no podrán tener el atributo “title” o este deberá estar vacío (ver técnica H67)

NO se puede considerar que una imagen es decorativa (y por tanto no puede estar definida en la CSS ni tener alt=""):

  • si es un enlace, a no ser que sea un icono que acompaña a un texto y el enlace los englobe a los dos, en cuyo caso el alt del icono sí deberá ser vacío (ver técnica H2)
  • si incluye texto, a no ser que dicho texto sea también decorativo, entendiendo como tal (vercriterio de éxito 1.4.9): Text is only purely decorative if the words can be rearranged or substituted without changing their purpose. Example: The cover page of a dictionary has random words in very light text in the background.

23. ¿Es correcto que el contenido de un input se borre al coger el foco?

En el criterio de éxito 3.2.2 se especifica que un cambio de contenido no siempre es un cambio de contexto. En este caso es válido que se borre el texto de un input al coger el foco pues supone un cambio de contenido pero no un cambio de contexto.

Por el contrario, no sería válido el comportamiento que se implementa a veces en los campos de fecha o de número de cuenta, en los que al terminar de incluir el contenido del campo el foco salta automáticamente al siguiente campo, pues en este caso sí que es un cambio de contexto. Según se especifica, si se implementa este comportamiento se debe incluir una explicación antes de los campos: consultar la ténica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made

24. ¿Qué se considera texto grande y texto pequeño?

En el criterio de conformidad 1.4.3 se indica:

large scale (text)

with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.

Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.

Note 3: The actual size of the character that a user sees is dependent both on the author-defined size and the user’s display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.

Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.

Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the “equivalent” sizes would be the minimum large print size used for those languages and the next larger standard large print size.

En cuanto al texto incluido en las imágenes se especifica:

Note: Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.

25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

El criterio de conformidad 3.3.4 (nivel AA) indica que es necesario que:

  • los envíos sean reversibles,
  • o bien que se puedan comprobar los datos y dar la oportunidad al usuario de corregirlos,
  • o bien que se ofrezca un mecanismo para revisar, confirmar y corregir la información antes de enviarla.

El criterio 3.3.4 sólo obliga a las páginas que:

  • causen compromisos legales
  • supongan una transación económica
  • modifiquen o borren datos controlables por el usuario
  • envíen respuestas del usuario a algún tipo de prueba

Sin embargo, el criterio de conformidad 3.3.6, que es de nivel AAA y por tanto es más estricto,obliga a cualquier tipo de envío de información.Se pueden consultar las distintas formulas para implementar estas opciones en las técnicas asociadas a este criterio 3.3.4

Artículos relacionados:

Tabla en formato Excel con todas los elementos HTML (incluido HTML 5) y XHTML con información relevante sobre ellos.

Una excelente ayuda brindada por Olga Carreras desde su bitácora (una fuente que recomiendo para todo el que le interesen temas como accesibilidad web, estándares web y diseño web).

Fuente:

http://olgacarreras.blogspot.com/2011/01/cheat-sheet-html-401-html-5-xhtml.html

viernes 21 de enero de 2011

Cheat Sheet HTML 4.01, HTML 5, XHTML Elements

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.

DescargaCheat 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:

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:

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:

Otros enlaces de interés: