Para deshabilitar el click derecho del mouse del usuario basta la siguiente simple instrucción jQuery:
$(function(){
$(document).bind("contextmenu",function(e){
return false;
});
});
]]>
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) "] ";
}
]]>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.
]]>Bueno, pero la idea es evitar su uso dentro de contenidos, para así impedir la limitada acccesibilidad que nos entrega (no todos los browsers lo interpretan) y que sea indexado separadamente por los buscadores (así como ocurre con los <frame>, que tienen la misma lógica). Mediante CSS lograremos el mismo fin, el de poder diagramar un espacio donde el contenido fluya a través de scroll vertical. Pero todo dentro de la misma página.
El HTML no será nada distinto a un bloque de texto cualquiera, soportado por un <div>:
<div id="contenido_scroll">
<p>Morbi non erat non ipsum pharetra….</p>
<p>Pellentesque habitant morbi tristique…..</p>
</div>
A través de CSS veremos reales cambios. Primero, al igual que en la etiqueta <iframe>, definiremos alto y ancho fijo. Todo lo que se salga de ese alto será absorbido por una elegante barra de scroll, la que será mostrada mediante la propiedad overflow: scroll;
#contenido_scroll {
width: 300px;
height: 200px;
overflow: scroll;
}
Eso es todo. Muy simple. Ahora, existe otra propiedad CSS no muy difundida que es overflow-x: hidden; Con ella, lograremos que desaparezca la barra horizontal de scroll, o la vertical con overflow-y: hidden; Pero esta propiedad no valida en CSS2.1, sólo lo hará con CSS3, pero felizmente es soportada por todos los browsers importantes exceptuando Opera (que es un muy importante browser). Una lástima, pero la realidad es que ¡sí es soportado por IE6! ¡¡A celebrar!!
]]>Como he escrito muchas veces ya a lo largo de este sitio, las tablas son para contener datos tabulados. Sólo para eso, esa información desagradable que suelen acompañar a los gráficos, esos nombres y números que a nadie le gusta. Para eso está <table>, para ordenar esos datos y nada más. Y bueno, ahora que ya tiene su función, aprendamos a utilizarlo bien.
<table>
<tr>
<td>Nombre</td>
<td>Edad</td>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
Una simple tabla que contiene valores cualesquiera. Ahora, le daremos sentido a sus etiquetas.
<th>
Table Header Cell, una celda de título de una tabla. La utilizamos cuando tenemos el título de una fila o columna, y tiene propiedades por defecto, por ejemplo, su contenido se despliega en bold.
Si la aplicamos a nuestra tabla básica de ejemplo, sería de la siguiente manera:
<table>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
<caption>
Esta etiqueta le da un título a la tabla, como un <legend> lo es para su <fieldset>.
<table>
<caption>Tabla de edades</caption>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
summary
Atributo de la etiqueta <table>, especial para lectores de pantalla (no-videntes). Aquí, nos explayamos un poco más que en <caption>, explicando extensamente de qué se trata nuestra tabla.
<table summary="Tabla donde se muestran nombres de personajes de un programa infantil junto con sus edades hipotéticas">
<caption>Tabla de edades</caption>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</table>
<thead> <tfoot> <tbody>
Filas se pueden agrupar en un encabezado (<thead>), un cuerpo de contenido (<tbody>) y un pie (<tfoot>), pudiendo cada grupo contener una o más filas. Con esto se hace más fácil darle estilos a las secciones de nuestra tabla, así nos ahorramos classes en cada celda. Otra ventaja es en la impresión, si ésta es muy larga en Firefox por ejemplo se imprimirán el encabezado y el pie en cada hoja (independiente si el cuerpo es muy extenso y no cabe en la impresión).
<table summary="Tabla donde se muestras nombres de personajes de un programa infantil junto con sus edades hipotéticas">
<caption>Tabla de edades</caption>
<thead>
<tr>
<th>Nombre</th>
<th>Edad</th>
</tr>
</thead>
<tfoot>
<tr>
<td>Bajada</td>
</tr>
</tfoot>
<tbody>
<tr>
<td>Tulio</td>
<td>36</td>
</tr>
<tr>
<td>Patana</td>
<td>15</td>
</tr>
</tbody>
</table>
Un detalle es que si usan <thead> y <tfoot>, deben ir juntas y consecutivas, antes de <tbody>. Aún así, <tfoot> se mostrará debajo del contenido de <tbody>. Si no lo necesitan, ocúltenlo con su método favorito.
Está de más escribir que bgcolor, height, width, align y nowrap están obsoletos y no son soportados en HTML 4.01. Además, no se recomienda el uso de background dentro del HTML, para esto se utlizan hojas de estilos CSS.