El cursor del mouse es un elemento muy poco considerado en el momento del diseño ó al aplicar estilos CSS. Pero la verdad es que es un complemento importantísimo de la accesibilidad y usabilidad, y por esa razón fue considerado en el momento de crearse tantos valores para esta propiedad.

Su uso es muy fácil y es aplicable no sólo a la pseudo-class :hover, sino que a cualquier etiqueta HTML:

<strong style="cursor: help;">¡Ayuda!</strong>

Lamentablemente la visualización de cada tipo de cursor depende del sistema operativo del usuario, y la capacidad de visualizarlo depende del browser que esté utilizando.

A continuación nombro todas las variedades y al final una página de ejemplo con todos ellos aplicados para que tengan al cursor considerado en su próximo proyecto:

CSS2:

cursor: auto;
cursor: inherit;
cursor: crosshair;
cursor: default;
cursor: help;
cursor: move;
cursor: pointer;
cursor: progress;
cursor: text;
cursor: wait;
cursor: e-resize;
cursor: ne-resize;
cursor: nw-resize;
cursor: n-resize;
cursor: se-resize;
cursor: sw-resize;
cursor: s-resize;
cursor: w-resize;

CSS3 (funcionan en los browsers modernos (IE9+, FF 3.5+, Chrome, Safari, Opera 9+):

cursor: none;
cursor: context-menu;
cursor: cell;
cursor: vertical-text;
cursor: alias;
cursor: copy;
cursor: no-drop;
cursor: not-allowed;
cursor: ew-resize;
cursor: ns-resize;
cursor: nesw-resize;
cursor: nwse-resize;
cursor: col-resize;
cursor: row-resize;
cursor: all-scroll;

Propietarios (Firefox y Chrome/Safari):

cursor: -webkit-grab;
cursor: -moz-grab;
cursor: -webkit-grabbing;
cursor: -moz-grabbing;
cursor: -webkit-zoom-in;
cursor: -moz-zoom-in;
cursor: -webkit-zoom-out;
cursor: -moz-zoom-out;

Tu propio cursor:

cursor: url(images/cursor.cur);
cursor: url(images/cursor.png), default;

* para mejor fallback después del url() utiliza algunos de los cursores CSS2
* Para Firefox y Chrome/Safari utiliza un PNG transparente.
* IE require que sea un archive .cur
* Opera no lo soporta

Ver cursores

Link:

• Introducing the New Cursor Styles in CSS3

Para deshabilitar el click derecho del mouse del usuario basta la siguiente simple instrucción jQuery:

$(function(){
    $(document).bind("contextmenu",function(e){
        return false;
    });
});

Ver ejemplo

Para quitarlo, basta declarar en CSS:

textarea {
	resize: none;
}

Ver ejemplo
(En Safari-Chrome)

El diseño web no debe ser tratado como el diseño gráfico; es una disciplina tan específica que debe ser separada definitivamente como una rama independiente. Implica conocimientos de áreas propias que son disciplinas en sí. Por nombrar algunas:

• Diseño gráfico
• Psicología
• Sociología
• Marketing
• Historia
• Comunicación Social
• Arquitectura de información
• Usabilidad
• Programación

He visto muchos diseños que merecen más ser impresos que aplicados en una pantalla; comenzando por que van a pesar bastante y pasando por formas imposibles de ser realizadas mediante codigo HTML y CSS. En mi humilde opinión, un diseñador web para ser efectivo en su trabajo debe considerar por lo menos alguno de los siguiente puntos:

Tareas

Siempre recuerda: el ser humano basa su comportamiento en tareas y objetivos, y por lo tanto el lograr realizarlas. Un sitio web no es sólo una vitrina, también es una vía para lograr un potencial cliente. Nadie llega a un sitio por azar; el usuario eligió llegar a él a través de un click en un enlace, una búsqueda orgánica o por vía directa. Por lo tanto, se debe tratar de encantarlo y extender su estadía en él, y el diseño es el medio más directo para ello.

Usuario

Estudiar al usuario no es fácil y se necesita tiempo y estudio para lograr algo fidedigno. Lamentablemente, sabemos que para un proyecto web se trabaja muy rápido y con deadlines muy ajustados. Ante ello, estudios y conocimientos previos son imprecindibles.

Soporte

Siento que es muy importante conocer (pero no necesariamente dominar) cuál será el soporte final del sitio, antes de siquiera comenzar el diseño. ¿Estará alimentado por un CMS? ¿Qué posibilidades me ofrece? ¿Podré usar Flash parcialmente? ¿Qué versión? Con algunas pocas respuestas se podrá exigir más a la herramienta y no esperar tanto al aprendizaje del usuario.

Performance

No existen usuarios expertos, y todos estamos constantemente aprendiendo a través de constantes innovaciones de gente muy creativa. Pero es importante considerar que el tiempo que el usuario gasta en un sitio web es tan valioso como nuestro tiempo como profesionales creándolo, por lo tanto se debe diseñar estructuras que sean además de fácil de entender, rápido de recorrer, de cargar y de encontrar lo que se busca.

Diseño Centrado en el Usuario

En el mundo para el cual trabajamos existe un concepto muy conocido pero poco aplicado, por lo que he observado navegando. El Diseño Centrado en el Usuario es una filosofía y un proceso con el cual se busca mediante el diseño necesidades, deseos y limitaciones de una interfaz que satisfacen al usuario final del sitio web. Esto puede ser considerado como un proceso múltiple, donde no sólo se requiere que el diseñador resuelva la estética (como comúnmente sucede), sino cómo los usuarios interpretan una interfaz y su comportamiento utilizándola. Con esto, se hace imperativo una etapa de pruebas con usuarios reales (sin miedo a redefiniciones) y una etapa inicial de análisis tanto de target como de arquitectura de información.

Pienso que debemos diseñar experiencias, no productos. Si haces un producto bonito, puede que quien lo utiliza le agrade la estética y lo tenga en un lugar destacado. Pero si el usuario tiene una experiencia diferente, satisfactoria navegando, es muy probable que vuelva y que lo recomiende a otros usuarios, todos potenciales clientes.

Y ¿qué implica este diseño de experiencias?

• Pensar global: desde que el usuario carga el sitio, hasta que lo deja. Cada paso, cada elemento debe ser cuidadosamente pensado y aplicado.
• Considerar tanto la presentación del contenido para todos (accesibilidad), como la facilidad del uso de cada elemento del sitio (usabilidad).
• Desarrollar hacia el usuario, desde lo complejo del proceso a la simplicidad de la tarea.
• Diseñar mensajes, ayudas, errores y guías de navegación que apoyen y orienten al usuario, y que lo haga sentirse bien y no fracasado por no haber logrado algo.
• El contenido es el rey, por lo tanto debe ser tratado como tal y el diseño es el soporte para el mensaje que se quiera entregar al usuario a través del sitio web. Pero el diseñador debe ser hábil: puedes persuadir al usuario tanto con buenos textos como con buen diseño.

Como ven, esto es sólo un esbozo de lo que pienso debería ser un diseñador web integral, que cumpla con efectividad su tarea comunicadora y persuasiva y que finalmente pueda ser valorado como tal. Este tema queda abierto a sus comentarios, los que pueden nutrir y complementar este tema.

Este es uno de tantos artículos de este sitio que son inspirados a partir de vivencias, experiencias y conversaciones con otras personas que comparten el mismo oficio.

El comienzo

Típico proyecto web, se hizo la etapa de AI, wireframming, diseño de propuestas, se aprobó un estilo gráfico, se hicieron mejoras en el diseño y se comenzó a maquetar las páginas. Lo siguiente es una variación (más simple) del wireframe de la home (por motivos de privacidad, omito el nombre del proyecto/cliente y detalles):

Hasta aquí todo medianamente normal, pero al hacer funcionar la parte de Noticias, nos topamos con un pequeño gran detalle: en el wireframe y en el boceto se muestra que hay tabs por tipo de noticias, y además hay resumen de 3 noticias (según tipo) con fotografias a desplegarse, según pases el mouse sobre cada texto:

El análisis

¿Dónde veo un problema? Veámoslo según cada disciplina

• Usabilidad: técnicamente, intervienen 2 tabs: por noticias, que al desplazar el cursor sobre cada resumen se reemplaza por su imagen respectiva; y por tipo de noticia, que son 3 tabs. Este doble tab puede crear confusión al usuario.
• Experiencia de usuario: En total, son 9 imágenes cargadas: 3 tipos de noticias, 3 noticias por tipo; cada imagen, por el tamaño, es probable que pese cada una 20kb, lo que en total se debe cargar 180kb. Quizás no es mucho peso, pero hay que tomar en cuenta que además se cargan los banners, que son bastante grandes y pueden llegar a ser pesados…
• Accesibilidad: Para conexiones lentas, no debemos pedirle tanto al usuario si es poco probable que vaya a necesitar de esas 9 imágenes. Para conexiones desde celulares, sería un abuso.
• Desarrollo: para aminorar esa carga, podríamos cargar las noticias en los tabs según el usuario vaya haciendo click en ellas mediante AJAX; pero esto involucra un desarrollo extra que no estaba estimado.

Sinceramente, podríamos haber continuado con la construcción del sitio y ya. Pero es importante tomar en cuenta estos detalles, que al fin y al cabo hacen que un proyecto marque la diferencia.

La solución

Aún se está trabajando en ello, pero se intervendrá el diseño y probablemente se quitarán las imágenes asociadas por cada noticia, y se dejará sólo 1 imagen principal por tipo de noticia, lo que reduce la carga a sólo 3 imágenes:

Como ven, no impacta mayormente en el diseño final, pero sí será necesario cambiarlo y transparentarle esta modificación al cliente, siempre argumentando que es para mejor.

Esto es todo, como aún el proyecto está en proceso no hay desenlace (favorable o no), aún así me encantaría leer sus opiniones.

¿Qué marcaría una diferencia? El diseño, obviamente es lo primero que encanta; contenido bien estructurado y ordenado, pensado hacia una mejor buscabilidad y encontrabilidad; funcionalidades útiles y no sólo efectistas, también. Pero insisto, ¿cómo lo llevamos aún más allá?

La accesibilidad es la capacidad de acceso a la web y sus contenidos por todos los usuarios, independiente de la discapacidad física, intelectual o técnica que tengan.

Si escribimos nuestro XHTML con una semántica correcta y con el diseño separado en su propia hoja de estilos, ya estamos aportando a una mejor acccesibilidad permitiendo a los ciegos leer el contenido a través de un lector de pantalla, además de independizar el dispositivo sobre el cual será vista la web (teléfonos celulares, laptops, computadores de escritorio, etc.). Si tenemos el tamaño de los textos de una dimensión considerable y ojalá en una unidad relativa que sea independiente de la resolución del usuario, estaremos garantizando mejor accesibilidad a usuarios con problemas visuales. Ahora, si le damos la posibilidad al usuario de escojer el tamaño te fuente que más le acomode, mejor aún.

Estas normas mínimas de accesibilidad pueden aumentarse con muy poco esfuerzo, y ahora me gustaría presentar uno que no es muy utilizado pero no por eso menos importante: el atributo accesskey. Con él, permitimos que el usuario navegue por enlaces sólo con el uso de teclas especificadas en el desarrollo del sitio. Su implementación es bastante rápida:

<a href="index.html" accesskey="i">Inicio</a>

Así, permitimos que se pueda ir a la página de inicio no sólo haciendo click en el enlace, sino que utilizando la combinación control+i del teclado. Lamentablemente esta combinación es arbitraria por plataforma:

• Chrome: Alt+Accesskey
• Firefox: Alt+Shift+Accesskey (Win) Ctrl+Accesskey (Mac)
• IE: Alt+Accesskey
• Opera: Shift+Esc+Accesskey
• Safari: Ctrl+Accesskey

Además, deberías indicarle a tus usuarios la tecla correspondiente al accesskey, y los selectores avanzados de atributo son una gran ayuda:

a:after {
  content: " [" attr(accesskey) "] ";
}

Ver ejemplo

Ver ejemplo

Modo de Uso

1. Adjuntar jquery.js y jquery.fontSizer.js entre las etiquetas <head></head>
2. Definir id’s para ambos links, por ejemplo #aumentar (+) y #disminuir (-)
3. Inicializar el plugin, como en el ejemplo:

      $(document).ready(function(){
         $("#aumentar").fontSizer({
            action: "up"
         });
         $("#disminuir").fontSizer({
            action: "down",
         });
      });

4. Eso es. El único parámetro obligatorio es indicar la acción de cada link mediante action. Los parámetros son:
   • action: "up/down" (requerido).
   • elements: "elemento" (un id, class o etiqueta donde actuará el cambio de tamaño de fuente).
   • increment: número (en cuántos pasos serán el cambio de tamaño; por defecto es de 1 en 1).
   • max: número (tamaño máximo del tamaño de fuente; por defecto es 30px).
   • min: número (tamaño mínimo del tamaño de fuente; por defecto es 8px).

Por ahora solo ha sido probado con jQuery 1.2.6, pero no debería de tener problemas con versiones desde 1.2+

Descargar (.zip)

Recapitulando, los microformatos nacieron bajo el alero de ampliar estándares semánticos aplicados a la www. La idea es que los indexadores y buscadores sean más inteligentes y entreguen datos más precisos en cuanto nosotros desarrolladores y profesionales dedicados a la web entreguemos mejor esos datos.

¿Y eso en concreto? Ya estaremos viendo resultados, con el anuncio de Yahoo! de incluir soporte a estándares web semánticos, incluyendo los microformatos en sus búsquedas. Excelente iniciativa.

Comencemos la diversión. Estos son los principales formatos disponibles:

hCard

Se usa para representar personas, compañías, organizaciones y lugares, utilizando propiedades vCard y valores en semántico HTML ó XHTML. Ha sido ya implementado en software, por ejemplo, AddressBook de Apple. Es muy común incluir sus vCards en los emails enviados, para tener constante actualización de los datos del destinatario.

En el siguiente ejemplo, verán cómo se construye un hCard, básicamente a base de id‘s y class‘es ya definidas por el estándar:

<div id="hcard-Jorge-Luis-Epuñan-Hernández" class="vcard">
     <a class="url fn n" href="http://www.be-studios.com">
          <span class="given-name">Jorge</span>
          <span class="additional-name">Luis</span>
          <span class="family-name">Epuñan Hernández</span>
     </a>
     <div class="org">Be Studios</div>
     <div class="adr">
          <span class="locality">Santiago</span>
          <span class="country-name">Chile</span>
     </div>
</div>

hCalendar

Definido para formatos de eventos calendarizados, basado en el estándar iCalendar y adaptado para su uso en HTML o XHTML, RSS y cualquier XML. Muy útil para tu blog, si quieres publicar algún evento, como un cumpleaños. Así, los spiders de búsqueda u otros agregadores pueden leer ese evento marcado como microformato, convertirlos automáticamente a formato iCalendar y utilizarlo en iCal, software de Apple que ya utiliza este estándar, para dar un ejemplo.

Ejemplo:

<div class="vevent" id="hcalendar-Mi-Cumpleaños">
     <a class="url" href="http://www.csslab.cl">
          <abbr class="dtstart" title="20080218">February 18th</abbr>,
          <abbr class="dtend" title="20080219"> 2008</abbr>
          <span class="summary">Mi Cumpleaños</span>
     </a>
     <div class="description">
          Mi cumpleaños número 27. Oh sí, anque tengo muchas canas no soy anciano.
     </div>
</div>

hReview

Se usa para reseñas de productos, servicios, empresas, eventos, lugares, etc.

Ejemplo en que un ficticio CCazorla hace un review sobre mi persona:

<div class="hreview">
     <span class="reviewer">
          <span class="fn">CCazorla</span>,
          <abbr class="dtreviewed" title="20080325">25 de Marzo de 2008</abbr>
     </span>
     <a class="person url" href="http://www.csslab.cl"><span class="fn">Jorge Epuñan</span></a>
     <div>Rating: <span class="rating">2</span> de 5</div>
          <blockquote class="description">
          <p>Perfeccionista por naturaleza, siempre busca superarse profesionalmente. Por dentro muy buena persona. Por fuera de personalidad extraña, un tanto psicopata.</p>
     </blockquote>
</div>

Geo

Se basa en la propiedad ‘geo’ del estándar vCard, y agrega nuevas sub-propiedades para completar. Se tratan de id‘s específicos para coordenadas de latitud y longitud, las que se pueden agregar directamente en la página o XML mediante RSS o Atom, y ser indexadas para luego, por ejemplo, mostrar la ubicación directamente en GMaps.

Ejemplo:

<div class="geo">Araxá:
     <span class="latitude">37.0625</span>,
     <span class="longitude">-95.677068</span>
</div>

Existen algunos más, como Dublin Core, XFN, FOAF, pero están aún en etapas de definiciones y aprobaciones, lo que hace ver lejana su estandarización. Pero no dejan de ser buenas intenciones para necesidades reales, en contínuo desarrollo.

¿Mi opinión? Son un gran aporte a la web semántica y la catalogación de la información que componen las páginas porque, sobre todo, Internet se compone prioritariamente de información. Sólo faltan ser lanzados definitivamente y dados a conocer, además de ser integrados en los software de desarrollo y gestores de contenido web (CMS). Finalmente ahí podremos ver su real potencial, con la llamada Web 3.0.

Links:

• hCard Creator
• hCalendar Creator

A nuestra disposición, la W3C puso las siguientes unidades de medidas:

Absolutas

• in (pulgadas)
• cm (centímetros)
• mm (milímetros)
• pt (puntos)
• pc (picas)
• px (pixeles)

Las unidades absolutas permiten un contro exacto de la apariencia de la página, siempre y cuando se visualice en el entorno para la cual fue diseñada. A modo de ejemplo, al utilizar px se visualizará diferente en cada resolución de pantalla y la plataforma del usuario que está desplegando ese contenido. Peor si utilizamos pt, ya que depende del tamaño del punto de la resolución de la pantalla.

Relativas

• em
• ex

Las unidades relativas dependen de la altura del elemento en el que se usa, aunque en la práctica, es el tamaño de texto definido en las preferencias del browser. Con esto, quien está definiendo estilos mantiene un control relativo ya que depende directamente del tamaño de fuente por defecto del usuario (1em), y a partir de eso, cuanto más grande (1.2em por ej) o menor (0.7em) se visualizará esa letra. Además, permiten su uso en cualquier propiedad de medida (margin, padding) lo que finalmente muestra un diseño proporcionado a la configuración del usuario (por ejemplo, proporcionado entre una pantalla widescreen de 17" y un iPhone).

Porcentaje

• %

No recomendado para tipografías, ya que su control no es fácilmente determinado por quien construye los estilos ya que necesita de un elemento de referencia (100%). Sólo recomiendo su uso en cajas de layout, determinados por el ancho de la resolución del usuario.

Tabla de equivalencias

Leyendo un artículo de Lêda Spelta (psicóloga de Brasil experta en accesibilidad) me tomo la molestia de citarla, traducir y completar parte de su interesante artículo: Accesibilidad web: 7 mitos y un equívoco.

Mito 1: "La accesibilidad web es sólo para deficientes visuales"

Ellos son sólo una parte de quienes se ven perjudicados con sitios mal construídos. Accesibilidad es para quienes:

• no ven la pantalla
• no usan mouse
• no usan teclado
• no leen el texto o no saben leer
• no escuchan el sonido
• usan un browser diferente, o que es minoría
• usa un computador antiguo
• usa un computador demasiado moderno
• tiene una conexión muy lenta
• etc.

Por supuesto que lo primero que se nos viene a la mente… "¡Cómo cresta lo hago para todos ellos!". Pues si te acostumbraras a escribir código semántico, atendiéndote a los estándares ya estás matando 3 pájaros de un tiro. Además si sabes optimizar bien las imágenes y utilizarlas sólo cuando es estrictamente necesario, otros 4 pájaros caen con esa misma bala. Como ves, no es trabajo doble, sólo el mismo que haces pero bien hecho.

Mito 2: "En la práctica, el número de usuarios beneficiados con la accesibilidad es muy bajo"

Eso es algo lógico de pensar, pero que no puedes mesurar. La mayoría de los usuarios que conoces probablemente no cumpla con ningún tipo de deficiencia nombrado anteriormente, pero es no dice que todos quienes entren a tu sitio no lo sean. Recuerda que si publicaste algo en Internet, se lo publicas al mundo entero; cualquiera puede entrar y verlo, no sólo quienes conoces. Y cualquiera de ellos son posibles clientes.

Mito 3: "Hacer que un sitio sea accesible toma tiempo y cuesta caro"

Aquí se aplican los factores costo/beneficio. Pero, como ya fue mencionado, el diseñador/desarrollador debe estar capacitado para aplicar la accesibilidad en todos sus proyectos, a mediano rango. Este mediano rango sería estructurar un código semántico y utilizando estándares web, siempre cuidando el peso de imágenes y uso de objetos externos. Un rango alto y donde sí se requiere mayor experticia y dominio es un sitio web totalmente optimizado para ciegos, donde se utiliza una hoja de estilos diferente y se aplican otras técnicas. Y es un deber de grandes empresas (masivas y públicas) proveer este tipo de servicios a sus consumidores.

Mito 4: "Es mejor hacer un sitio especial para deficientes visuales"

¿Mejor para quién? El diseñador tendrá doble trabajo, al igual que el mantenedor de esas páginas. Deficientes estarán perjudicados, ya que lo más común es que este sitio especial esté siempre desactualizado.

Mito 5: "Un sitio accesible a deficientes visuales no es bonito"

Bueno, hay que ser consecuentes. Las personas ciegas no pueden siquiera ver el diseño que estás aplicando. Pero aún así puedes utilizar fotos, videos, gráficos, audio, etc. Basta con que utilices sus etiquetas y atributos correctamente y los lectores de pantalla podrán leerle al usuario de qué se trata la foto, por ejemplo.

Mito 6: "Mejor ir por partes: Primero construímos el sitio, luego lo hacemos accesible"

Es verdad que no podemos hacer todo al mismo tiempo y debemos priorizar. Aún así, si se construye un edificio con escaleras y luego hay que romperlas para poner rampas para sillas de ruedas es un desperdicio de tiempo y recursos. Y no queda del todo bien. En un sitio web es lo mismo, los parches son a la orden del día.

Mito 7: "No podemos hacer un sitio accesible con el tiempo y recursos que tenemos"

Como ocurre con cualquier innovación, el primer proyecto demanda tiempo y costo en capacitación, ya que necesitamos enseñar al equipo cómo se hace. Pero luego el aprendizaje queda y se aplica fluidamente en los proyectos venideros, lo que se puede ver como un valor agregado dentro del costo de los mismos.

Equívoco: "Mi sitio está enfocado a un público específico, y no me interesan otros grupos"

Normalmente cuando se afirma que un sitio está direccionado a un público específico, nos referimos que el contenido del sitio sólo tiene interés para un determinado porcentaje de usuarios. Pero esto no quiere decir que podemos alentar el interés de otros usuarios diferentes a los que teníamos en mente. Si restringimos el acceso de nuestro sitio al que juzgamos que son nuestro target, estamos en la práctica utilizando Internet para limitar nuestro público, en vez de ampliarlo.