Diseño y Programación web accesible en Mallorca | Embat Consultors

Para variar, empezaremos con lo que menciona la Wikipedia acerca de esta palabrita tan usada hace unos 2 años, evidentemente que no tiene esa antiguedad, pero sin duda el mundo web le ha dado otra definición:

“Beta (Β β) es la segunda letra del alfabeto griego. En griego antiguo se pronunciaba [b], en griego moderno se pronuncia [v].”

Claro que esta no es la definición que buscamos, la que buscamos tiene que ver con la Ingeniería del Software, y para que se comprenda, pondremos el texto que la menciona:

“En la ingeniería del software el término fases de desarrollo expresa cómo ha progresado el desarrollo de un software y cuánto desarrollo puede requerir. Cada versión importante de un producto pasa generalmente a través de una etapa en la que se agregan las nuevas características (etapa alfa), después una etapa donde se eliminan errores activamente (etapa beta), y finalmente una etapa en donde se han quitado todos los bugs importantes (etapa estable)”

¿Qué sucede hoy día que todos los proyectos web -o casi- se llaman a sí mismos Beta?

Supongo que es a lo que estamos ya acostumbrados, una web dificilmente se entrega a un cliente y se termina su desarrollo. Internet nos obliga a estar constantemente encima de los proyectos, mejorándolos y actualizándolos.

Antes la vida de una web era “relativamente” alta, y aún así nos quejábamos de que en 3 o 4 años una web quedaba obsoleta. ¿Y ahora?… Ahora podríamos cambiar la palabra “años” por “meses” y no nos equivocaríamos mucho.

La web evoluciona a unas velocidades de infarto -menos la W3C[1]- y eso hace que los desarrolladores saquemos las webs en fases Beta, cosa que antes, probablemente, probaríamos y probaríamos hasta tener la etapa estable. Ahora, si esperásemos a tener esa fase estable, podríamos tirar el código a la basura directamente, porque al tenerla ya habría cambiado todo.

[1] Como todos sabemos, y a pesar de defenderla a capa y espada… Es extremadamente lenta. O se adaptan algo más a los tiempos o tendremos problemas serios.

Saludos,
Embat Consultors (¿Beta?)

Sé que es un título algo extraño, y que en su totalidad no es 100% cierto, pero este post lo voy a dedicar casi exclusivamente a explicar el sentido de este título.

Validación != Semántica

Empecemos explicando el significado de los 3 elementos del post:

“Validación”: Validación por la W3C del cumplimiento de los estándares web.

“!=”: En programación significa “Distinto de”

“Semántica: El concepto de “web semántica” (ya dije que dedicaría un post en varias ocasiones, tranquilos, lo haré :D)

Bien, ya estamos situados, entonces vayamos al meollo del asunto:

¿Por qué digo que Validación es distinto de web semántica?

Hace ya un tiempo que me fijo mucho en los códigos de las páginas (deformación profesional) así como en las validaciones de las mismas. Qué tipo de validación es y si pasa los tests de las validaciones, tanto de HTML/XHTML, como de CSS, como de javascript.

Además de mirar el código, y fijarme en si validan (por tanto, cumplen los estándares) también me fijo en la finalidad de esa validación, entonces me pregunto lo siguiente:

¿Cuál es la finalidad de la validación?

Quiero pensar que el objetivo de que algo valide, es que cumpla unos estándares, ya escribí otro post referente a las ventajas de seguir las estándares, por tanto no hace falta que profundice en ello. Pero aún así, el objetivo de validar no debería ser, simplemente, que la web cumpla los estándares dictados, creo que hay que ir más allá.

Aquí entra en juego el famoso término que no paro de nombrar… Si! lo adivinásteis, “Semántica“.

Para mí el cumplir los estándares es un paso más, pero este va de la mano de la Semántica, y aquí empiezo a acercarme al intento de explicar el título del post.

Hay páginas que validan su código perfectamente por la W3C (y otros), tanto su HTML/XHTML como sus CSS. E incluso el javascript estándar. Pero desgraciadamente, en ese intento brutal de conseguir la validación, dejan de lado totalmente la Semántica…

Parece contradictorio, ¿verdad?

Si, no deja de ser incluso anecdótico que intentando hacer las cosas bien, resulta que te alejes de hacerlo.

Que tengas que poner un form, fieldset, label e input correctamente para validar, lo que quiere decir es que es recomendable hacerlo, pero por alguna razón, ¿no creéis?. pues sí, la cuestión es que siguiendo esas recomendaciones puedes hacer mejor tu código, más entendible.

Y que si pierdes parte de tu tiempo en el desarrollo de una web en las validaciones, porque quieres ser estándar, qué menos que intentar hacerlo aún mejor, y hacer que esa validación que luces en la etiquetita de tu footer sea más que un adorno.

Conclusiones

Llegados a este punto, ¿qué sacamos en claro?

Las validaciones son recomendaciones que hacen organismos como la w3c, que proponen líneas a seguir a la hora de desarrollar una web, recomendaciones que ayudan a la comunicación, a la universalidad, pero que van ligadas a un pensamiento, a una forma acertada de hacer las cosas, y que si podemos “validar” una página, también podemos hacerla más semántica, más útil, más limpia, etc…

Os animo a que lo probéis…

Y claro está, queda pendiente mi post sobre la web semántica. (palabrita de niño Jesús que será el siguiente)

Joan
Embat Consultors

Otro tema candente en internet: La accesibilidad.

¿Qué es la accesibilidad?

Según la Wikipedia (como no):

La accesibilidad es el grado con el que algo puede ser usado, visitado o accedido por todas las personas, independientemente de sus capacidades técnicas o físicas.

Expliquemos… Algo es accesible cuando cualquier persona puede acceder a ello. Puede parecer algo evidente, pero no es tan evidente como parece de primeras.

¿Qué es la accesibilidad web?

Tim Berners Lee tenía claro que:

El poder de la web está en su universalidad. El acceso de cualquier persona, con independencia de su discapacidad es un aspecto esencial.

Y definió como accesibilidad: Es el arte de garantizar que los medios estén disponibles para las personas, tengan o no deficiencias de un tipo u otro.

Razones

En 2006 entró en vigor la LSSI, uno de cuyos requisitos exige que las Administraciones Públicas hagan accesibles los contenidos de sus páginas web.

Otro término que veréis bastante hablando de este tema, es el de Usabilidad, pero como ya dije en otros artículos, ya escribiré acerca de eso más adelante.

Nótese que he escrito “Administraciones Públicas”, entonces…

¿Por qué hacer sitios accesibles si no somos administraciones públicas?

Buena pregunta, aunque los desarrolladores (la mayoría, o eso espero…) queramos hacer páginas accesibles, los empresarios no lo terminan de ver.

Por ello, nada mejor que enfocarlo desde 2 puntos:

El lado económico

• Entre un 10 y 20% de la población tiene algún tipo de discapacidad (mayor o menor). Haciendo el sitio accesible aumentas el espectro de los clientes potenciales.
• También es probable que algunas personas no tengan instalado el “navegador X” o el “plugin Y”, ¿por qué cerrarles la puerta de tu negocio?
• Las personas mayores también son sensibles a los problemas de accesibilidad.
• Sin duda es más sencillo hacerlo accesble desde el primer momento, ya que si tenemos que rehacer las webs luego, se tardará muchísimo mas.
• Profesionalidad. A ojos del resto, serás más profesional. Con el tiempo, el término accesible lo entiende más gente, y eso da visión de confianza.
• Reduce el ancho de banda. Menos tráfico de red. Más rapidez.
• Menos tiempo de mantenimiento. Código más limpio. Menos errores. Errores más fácilmente solucionables, más aislados.
• Buscadores. Los buscadores son ciegos, sólo leen el código. Si la página es accesible se presupone que el código será limpio. Aunque la accesibilidad no sea el factor determinante en esto, está claro que es uno a tener en cuenta.

Beneficio social

• No está bien discriminar a personas porque tengan algún tipo de problema de acceso a los contenidos de la web.
• Si los sitios web son accesibles para las personas con discapacidad podrán beneficiarse de ellos.
• Ayudaríamos a las personas a estar en contacto con los suyos.
• Estaríamos construyendo una sociedad de la información para todos
• Construiríamos una sociedad más justa, más integradora.

Conclusiones

Como podéis ver, hacer las páginas accesibles no cuesta tanto esfuerzo, y el beneficio es grande.

Ayer confirmamos que éramos estándar.

Hoy confirmo que soy accesible…

¿Y vosotros?

Joan
Embat Consultors

¿Qué es un estándar?

Directamente extraído de la Wikipedia (¡qué grande!, por cierto…) estándar es:

Es una especificación que regula la realización de ciertos procesos o la fabricación de componentes para garantizar la interoperabilidad.

Supongo que se comprende, así en líneas generales y sin enfocarlo al mundo web, son una serie de recomendaciones o guías con las que se presupone que no nos desviaremos del lugar al que vamos.

¿Qué son los estándares web?

Directamente extraído de Maestros del web (otra gran fuente ^^) estándares web son:

Un conjunto de recomendaciones dadas por el World Wide Web Consortium (W3C) y otras organizaciones internacionales acerca de cómo crear e interpretar documentos basados en el Web.

Bien, definamos un poco más esto.

La W3C son un consorcio internacional que se dedica a crear y promover estándares web y guiar a la web hacia su máximo potencial. No tenemos que olvidar que la web como la conocemos, cambia constantemente, y de la W3c, y nuestra parte, depende que evolucione positivamente para todos. (Y o no sólo para unos pocos)

Un poco de hisotoria nunca viene mal, ¿verdad?

Recordemos que la Web fue creada alrededor de 1989 por Tim Berners-Lee (y Robert Cailliau) cuando trabajaban en el CERN. La aparición del W3C no se hizo esperar demasiado, y el mismo Tim Berners-Lee es su director.

¿Quién dicta los estándares web?

Desde 1994, el W3C ha publicado más de ciento diez estándares (llamados recomendaciones).

Los objetivos actuales de la W3C se resumen en: Web para todos, Web desde cualquier sitio, Base de conocimiento y Confianza.

Todos ellos, evidentemente, se intentan conseguir mediante el uso de los estándares web.

¿Por qué necesitamos los estándares web?

Este punto, es de los más propensos a disctusión, discusión que por otra parte me encanta.

La respuesta, desde mi punto de vista es muy sencilla, ¿acaso no tenemos normas de circulación?

Si no las tuviéramos la circulación sería un caos, és más, aún teniéndolas la circulación sigue siendo difícil, por no llamarla de otro modo.

Por eso, en internet, también necesitamos unas guías, una forma correcta de hacer las cosas, para que así los programadores tengamos un camino definido, por el cuál podemos llegar a todos los usuarios.

¿Qué beneficios nos reporta utilizar los estándares web?

Un par de palabrejas que leeréis mucho si profundizáis en el tema de los estándares web son, por ejemplo, Accesibilidad y la portabilidad (seguidas de usabilidad, buscabilidad, etcétera… pero de estas hablaremos más adelante)

La accesibilidad es lo que nos asegura que cualquier usuario podrá acceder a nuestra página, independientemente de la plataforma, navegador, etcétera…

La portabilidad nos permite separar completamente nuestro contenido de nuestro diseño, pudiendo rediseñar una web en unos sencillos pasos (si controlas CSS, claro…), asímismo, también podemos cambiar contenidos sin preocuparnos del diseño.

Otros beneficios de usar los estándares los trataremos más adelante, cuando hablemos de la web semántica. (Prometo un post acerca de este tema en breve)

¿Qué problemas nos reporta utilizar los estándares web?

NINGUNO

Yo soy estándar, ¿y tú?

Joan.
Embat Consultors

Santy, uno de los diseñadores del trabajo, siempre me da la brasa con el Flash.

Pues bien, hoy decidí ponerme a pensar y a navegar, redactando lo que a mi modo de ver, pueden ser grandes factores a tener en cuenta a la hora de no utilizar flash..

O si lo queréis de otro modo, ¿Por qué utilizar HTML/XHTML en lugar de flash?

• Flash tiene problemas con los buscadores, ya que estos indexan por página, y leen el contenido (HTML/XHTML) de las webs, utilizando flash, muy probablemente, pierdas posicionamiento considerablemente.
• Necesitas instalar software adicional al navegador para poder visualizar la web. Si tu interés es vender, ¿por qué cerrar puertas a 1 sólo cliente?
• Graves Problemas de navegación:
  • No funcionan los botones “atrás” y “adelante”
  • Abrir un enlace en otra pestaña
  • Abrir un enlace en otra ventana
  • Ver las propiedades de una imagen
  • Obtener una imagen
  • Buscar una palabra a través del navegador
  • No puedes hacer el texto más grande o más pequeño
• Los elementos no son estándares. Los usuarios están educados con los componentes de las webs, textos, formularios, enlaces, etc… Y pueden reconocer su función y su uso. No se debe hacer pensar al usuario para qué sirve algo de la página, él debe saberlo. Cada diseñador tiene su criterio para crear sus botones, combos, etcétera.
• Depende absolutamente de las decisiones que tome la empresa que lo controla. Nunca sabes qué puede pasar con flash, en cualquier momento podría obligar a actualizar versiones, o sacar versiones incompatibles, y tu, no podrías hacer nada contra ello.
• Dependencia total de los diseñadores que hacen la web. Hay más gente preparada para hacer cambios en webs HTML/XHTML que en Flash, ya que HTML es un estándar, y más gente está preparada para ello.
• Los diseñadores tienden demasiado a crear efectos y controles complicados para el usuario.
• Accesibilidad:
  • Personas con problemas en la vista no pueden cambiar los tamaños de las letras
  • Los sintetizadores de voz que leen el código html no pueden leerlo
• Suelen ser más lenta. Al cargarlas de efectos y/o imágenes, las webs en flash suelen ser más pesadas (nótese el “suelen”, ya que he visto verdaderas barbaridades en HTML)
• Los usuarios buscan algo en la web, no entretenerse (salvo casos aislados que no tienen nada que hacer). Debe haber un acceso rápido al contenido, a lo que el usuario está buscando.
• Problemas serios a la hora de imprimir. ¿A quién no le ha pasado?…
• Problemas para generar estadísticas. Nos movemos en un mercado en el que prima la estadística, y Flash nos dificulta conseguirlas.
• Las webs en Flash tienden a distraer la atención del usuario frente al contenido que está buscando.

¿Para qué me parece más aberrante utilizar el Flash?

• Webs completas en flash, quitando las excepciones que citaré a continuación, me parece un verdadero atentado terrorista diseñar un sitio al completo en flash
• Menús de navegació. No entiendo como aún hay gente que hace la web en HTML/XHTML y el menú en flash…

A todas estas pegas, quiero añadir funciones que no veo malas para el flash, e incluso, siendo objetivo, les veo cierto sentido crearlas en flash:

• Webs artísticas (diseño, música, fotos, pintura, etcétera)
• Niños (webs para niños, tanto educativas como de entretenimiento)
• Visitas virtuales (recorridos, catálogos, etcétera)
• Banners (aunque odio los banners en general, puede atraer algo más que una simple imagen)
• Películas y videos (evidente)
• Juegos (también evidente)

La semana pasada, en un curso de JavaScript (ese querido lenguaje… jeje), estábamos analizando las librerías de diferentes frameworks (por encima).

Entre ellos, como no, echamos el ojo a la de MooTools y vimos esto:

function $chk(obj){

return !!(obj || obj === 0);

};

Lo que más nos extrañó fue la doble negación (el “===” triple igual se usa cuando quieres comparar valor y tipo de la variable), e indagando sucedió esto:

Pusimos en el firebug

alert(undefined) Salió Undefined

alert(!undefined) Salió True

alert(!!undefined) Tachán… salió False.

En resumen, lo pusieron para evitar que les saliera un “undefined” como una casa dependiendo del valor que le entrara a la función $chk(obj) .

Ya sabemos una cosa más… “!!undefined = False ”

Saludos!

El otro día, en clase de JavaScript (si… también se enseña!), salió el tema de los colores, la codificación hexadecimal, etcétera…

Al día siguiente me puse a investigar acerca de ello, y por lo visto no fuí el único que lo hizo.

Pues bien, os voy a dejar un resumen de la información que he recopilado:

El color en el mundo web, por ejemplo, en las CSS, se suele representar con “#XXYYZZ” dónde X,Y y Z son tres pares hexadecimales que pueden ir desde el FF hasta el 00. Cuánto mayor sea el valor (más cerca de 0) mayor será la intensidad del color.

Esta notación hexadecimal proviene del RGB (red, green, blue), cada color se codifica con un byte (que son 8 bits), de ese modo, la escala se suele medir de 0 a 255, es decir, que R, G y B pueden tener valores comprendidos entre 0 y 255, y esos valores pasados a hexadecinal nos dan nuestro preciado #RRGGBB, que es el formato más usado en web.

La gama de colores de la web consiste en 216 combinaciones de rojo, verde y azul , donde cada color puede tomar un valor entre seis diferentes (hexadecimal): #00, #33, #66, #99, #CC o #FF.

Entonces, 6 elevado a 3 (al cubo) nos da 216, que son el número de combinaciones. En decimal, estos valores son 0, 51, 102, 153, 204 y 255, que tienen un 0, 20, 40, 60, 80 y 100% de intensidad. Eso nos permite dividir los 216 colores en un cubo de dimensión 6.

La codificación hexadecimal nos permite expresar más fácilmente un color, de ahí que se utilice más este formato en web, ya sea en CSS, en javascript o en el mismo Html (que horror… ahí dentro, ¿eh?).

Bien, como se entiende el sistema hexadecimal: Es más sencillo de lo que parece, además de ser muy lógico. se utilizan los números del 0 al 9 (ya van 10) y luego se utilizan las letras A B C D E y F (ahí van 6 más, por tanto, 16).

Y el número decimal es igual a la primera cifra en hexadecimal multiplicada por 16, sumando la segunda cifra en hexadecimal. El ejemplo más alto sería FF, que si multiplicamos 15*16 + 15 sale 255. Curiosamente, el más alto es el blanco, recordad que el blanco es la suma de todos los colores, y el negro la ausencia de color, por tanto el negro sería 00 (0*0+0).

Vías Wiki1, Wiki2, Wiki3.

Saludos, Geeks y demás especímenes.