Este Septiembre ha sido mucho más duro de lo esperado. Nuevo trabajo, nuevos estudios, las niñas empiezan al cole ..., y al final me he ido quedando sin tiempo para escribir. Así que una vez dejado atrás Septiembre y tantos cambios, mejor retomamos las buenas costumbres con un post sobre un par de interesantes elementos interactivos de HTML5, que ya hacía algún tiempo me rondaba por la cabeza.
Los elementos details y summary son de esos elementos de HTML5 poco extendidos y por tanto poco conocidos. La excesiva avalancha de posts sobre los elementos semánticos (de la cual yo también soy responsable), ha dejado de lado ciertos elementos que aportan funciones muy interesantes, y que si bien todo esto se puede hacer con Javascript, ¿a quién no le apetece ahorrarse unas cuantas líneas de código?.
No hace tanto que diseñar un sitio web accesible era sinónimo de soso o aburrido. Había que eliminar cualquier adorno que no cumpliese con la estricta semántica dada por HTML.
Por suerte hoy en día esto ya no es así (aunque hay quién aún lo piensa). WAI-ARIA nos ayuda a dar significado a esas partes de nuestro código que se salen de la semántica de HTML, dando apoyo a las aplicaciones de accesibilidad para que las personas que las usan comprendan nuestra web o aplicación.
¿Pero qué es en realidad WAI-ARIA?, ¿se debe usar en todas las etiquetas de HTML?, y aún más importante ¿qué es lo que no se debe hacer con esta tecnología?. A estas y seguramente otras preguntas voy a tratar de responder, en lo que pretende ser una aproximación a la accesibilidad web. ¿Te apuntas?.
En prensa, revistas y libros es muy común encontrarnos con imágenes, gráficos o fragmentos de código acompañados de una leyenda (un texto explicativo de dicho elemento). Hasta la aparición de HTML5 no era posible dar ningún carácter semántico a este tipo de elementos, ya que por ejemplo para un motor de búsqueda una imagen y la leyenda que la acompaña no tienen relación alguna. Además, y desde el punto de vista de diseño, debemos usar elementos adicionales para conseguir que la leyenda nos quede ajustada al elemento que queremos darle significado.
Las etiquetas figure y figcaption, vienen resolver estos problemas. En el aspecto semántico, al crear una figura que contiene una leyenda, este texto queda unido a dicha figura, aportándole un valor semántico. En cuanto a diseño, una leyenda se coloca bien arriba a la izquierda o abajo a la izquierda (según la situemos en el código) de la figura que hayamos creado, lo que simplifica el marcado HTML y también el CSS para lograr tal posicionamiento. Como todo son ventajas, ¿qué tal si las vemos un poco más a fondo?.
Hay múltiples motivos por los que en alguna ocasión es necesario añadir fechas a nuestra página web. Desde la típica fecha para indicar la creación o modificación de un post o artículo, pasando por la fecha de un comentario o para indicar el comienzo de un evento o acontecimiento. En todos estos casos lo lógico es usar una fecha lo más legible posible de cara al usuario, ¿pero qué pasa con las máquinas?.
Si tenemos en cuenta los buscadores u otros tipos de programas que también pueden valerse de estas fechas, tenemos un serio problema, y es que los formatos que generalmente usamos de cara al usuario no son válidos para máquinas. Para ellas se crearon diez tipos de formatos de fechas diferentes, todas ellas en su mayoría numéricas y nada amigables de cara al usuario. Siendo así, ¿por quién nos decantamos, por la máquina o por el usuario?.
Las etiquetas H son desde hace mucho una de las piedras angulares del SEO. Evidentemente el SEO abarca mucho más, pero son pocos los artículos que podemos encontramos sobre esta materia que en algún punto no mencionen el uso correcto de estas etiquetas. Por desgracia la inmensa mayoría de estos posts son pre-HTML5 y por tanto se guían por el gran dogma de la etiquetas H, "no puede haber más de un H1 por página o documento".
Sin embargo, y con la llegada de HTML5, hasta esto ha cambiado. Como no podía ser de otra manera el uso de varias etiquetas H1 debe de hacerse de forma lógica y controlada (nuestro documento no puede convertirse en una amalgama de etiquetas H1), y siguiendo rigurosamente las reglas que la W3C nos da para que nuestro documento sea correcto, al menos en cuanto a semántica se refiere. Hay que tener en cuenta que no todo el mundo está de acuerdo con esta práctica (siendo en HTML5 del todo correcta) y los expertos en SEO suelen ser bastante recelosos, aunque como verás en este artículo su uso es una cuestión 100% lógica.
Tras unos cuantos días sin publicar nada, muchos más de los que me hubiese gustado, he decidido dar carpetazo a la serie de artículos sobre la semántica en HTML5 aunando dos etiquetas que nada tienen que ver en un único artículo. Con estas dos nuevas etiquetas finalizaré una estructura básica que puede ser usada para construir cualquier web y que además será 100% semántica, que es a fin de cuentas lo que buscaba con esta serie de artículos.
Por supuesto la semántica en HTML5 es mucho más amplia, y voy a obviar etiquetas como address o time (al menos de momento), porque son menos generales y no suelen conformar la estructura básica de una web. Además también queda pendiente el tema de los datos estructurados mediante los esquemas de Schema.org, un punto también muy importante cuando se habla sobre la semántica de una web y que en algún momento tocaré en un futuro artículo (promesa de año nuevo xD). Así que sin más vueltas, vamos a ensuciarnos las manos como buenos alienígenas que somos.
La etiqueta aside de HTML5 es probablemente el elemento al que se le da peor uso. El hecho de que la W3C mencione hasta en dos ocasiones la palabra sidebar en su definición hace que la mayoría de diseñadores y desarrolladores la usen incorrectamente, llevándolos a usarla para marcar un simple sidebar, cosa que desde el punto de vista semántico es del todo innecesario, la etiqueta aside no se creó con este fin.
En el artículo de hoy voy a intentar explicar el uso correcto de aside (siempre desde mi punto de vista, porque es una etiqueta muy dada a múltiples interpretaciones), con claro ejemplos sobre su uso y dejando claro como no debe de usarse, para eliminar esa tendencia de usar aside para marcar el sidebar.
Los formularios de contacto son ese tipo de cosas que todo el mundo pone en su web/blog porque queda bonito y muy profesional. Sin embargo, son tremendamente útiles, porque ¿quién no se ha topado con alguna web interesante y no ha podido contactar con el webmaster?. Sólo por eso ya merece la pena tener uno.
También podríamos entrar en la tentación, de simplemente, poner nuestro mail en el footer, por ejemplo, para que los usuarios contacten con nosotros, claro que esto sólo nos llenaría la bandeja de entrada de spam y mucho más spam. Así que como nos interesa lo que la gente opine de nosotros, nos cuenten sus dudas o simplemente echen nuestro trabajo por tierra, vamos a hacer un formulario de contacto desde cero, y además con validación en HTML5, así nos ahorraremos unas cuantas líneas de código en javascript, php o similar (lenguajes difíciles de entender para un alienígena como yo).
Por primera vez en Hexagonal Alien voy a abordar dos etiquetas semánticas de forma conjunta, el porqué es bien simple, no creo ser capaz de hablar de una sin al menos mencionar la otra, y viceversa. Ambas son etiquetas con amplia discrepancia en su uso, y en ocasiones donde se puede usar una también sería correcto usar la otra.
Me temo, que en esta ocasión, nadie se vaya a quedar a gusto (ni siquiera yo), pues con una especificación tan dada a múltiples interpretaciones, siempre habrá alguien que donde yo digo que es mejor usar article, el preferirá sin ninguna duda section. Así que alejándome de la polémica y como bien dijo Jack (el destripador), vamos por partes.
Aunque HTML5 hace ya algún tiempo que está entre nosotros, sigue habiendo multitud de sitios web que son reacios a usar esta nueva tecnología, y no todos son amaters, también los hay profesionales. Siempre se han esgrimido las mismas razones para evitar su uso, la compatibilidad con navegadores antiguos, la dificultad de empezar algo nuevo, que es posible que mi ordenador de sobremesa implosione ... Todo es poner pegas a lo nuevo, y al final lo que nos estamos perdiendo son las mil una ventajas del nuevo lenguaje de marcado HTML5.
No, no voy a exponer aquí las mil y una ventajas, con sólo cinco de ellas será más que suficiente para que de una vez por todas te decidas a cambiar tu viejo HTML4 o XML1.0, por un lenguaje en el que todo son ventajas. Ya sabes como va esto, así que si aún no has desayunado ataca la nevera que empezamos.
En el artículo anterior sobre semántica en HTML5, vimos las ventajas que se obtienen al diseñar una web semántica, amén también de comenzar con la primera etiqueta de este tipo, header. Hoy vamos a ver la etiqueta footer, que es sin duda alguna la de más fácil aplicación, y que al contrario de lo que ocurre con otras etiquetas semánticas, no ha habido ningún tipo de discusión, al menos que yo sepa, sobre su uso o aplicación.
Es una etiqueta tremendamente sencilla, con lo cual no me extenderé mucho en su explicación. Para su total comprensión voy a usar el mismo ejemplo que utilicé en el primer artículo sobre semántica, y así etiqueta tras etiqueta y artículo tras artículo, iremos construyendo una plantilla 100% semántica. Ponte cómodo que empezamos.
El entre comillas "nuevo lenguaje HTML5", nos ofrece entre otras muchas cosas, una serie de etiquetas de marcado con significado semántico. El significado semántico de estas nuevas etiquetas aporta una serie de ventajas. Por ejemplo, a cada uno de estos elementos se le asigna un role ARIA (Accessible Rich Internet Application) específico por defecto, ayudando a mejorar la accesibilidad de nuestro documento de cara a personas que usen alguna tecnología de asistencia en la navegación, como pueden ser los screen readers (lectores de pantalla).
También hay que tener en cuenta que ayudan a la mejor interpretación de nuestro documento por parte de los motores de búsqueda, lo que facilita que nos indexen lo que realmente importa, el contenido. Amén también, de que un texto HTML5 bien etiquetado, hace su código más comprensible por cualquiera que lo esté leyendo.
Hoy voy a comenzar por una de las etiquetas más sencillas, la etiqueta header. Así que ponte cómodo, que el código también se hizo para alienígenas.
