 Una charla muy interesante, le voy a presentar a Nuria Ramoneda, desarrolladora, full stack, especializada en WordPress. Curiosamente, no lo sabía que era historiadora. Se nos desarrollaste, pero me explico saber esto hace poco, de verdad. Nuria no es la primera vez que viene a Ponte Verde. Ya el año pasado estuvo como voluntaria, estuve ayudando en el Duatium, amante de la comunidad de WordPress, organizadora de la Workand de Barcelona, una Workand maravillosa que estuvo genial este año, de la mitad de Barcelona y por supuesto, co-organizadora de Workand España Online 2020-2021. Entonces, en esta charla nos va a recordar un poquito, porque es importante marcar adecuadamente el código, según el tipo de contenido y nos va a dar, encima, ejemplos para demostrarlo. O sea que va a ser una charla muy práctica. Mil gracias, Nuria, por tu presentación. Buenas tardes, bienvenidos. Estoy muy contenta de estar aquí y de poder hablaros y recordaros cosas importantes. Vamos a hablar de contenidos semánticos, de la importancia del mercado adecuado, como he dicho a Harry, de poder utilizar correctamente el mercado semántico. Como voy a ir bastante rápido porque quiero explicaros o recordaros muchas cosas y no me va a dar tiempo. Pero creo que fundamentalmente lo que quiero que quede muy claro es esto. Fundamentalmente quiero que os quede muy clara esta idea. Por favor, utilizad el mercado semántico, utilizad HTML semántico. Vamos a ver un poquito por qué. Vamos a ver primero un poquito qué es el HTML semántico. Básicamente es la estructura que es lo que da significado y estructura nuestro contenido, al contenido que ponemos en la web, es lo que hace que el contenido sea leíble para humanos y máquinas. Muy importante para máquinas, fundamentalmente, evidentemente para los humanos también, pero es el que hace que las máquinas puedan leer detrás lo que estamos mostrando en la web. Y una cosa a tener en cuenta, que a veces nos olvidamos, pero el mercado semántico no son solo los elementos del HTML, sino también sus atributos. No nos olvidemos de los atributos porque muchas veces son muy importantes también y nos dan elementos que son muy importantes. De aquí, solo para saber un poquito, ¿cuántos de aquí sois desarrolladores? Vale. Y implementadores. Vale. Y diseñadores. Vale, tenemos un poquito de todo, está bien. Bueno, la charla está pensada sobre todo para los desarrolladores, pero es para todos los públicos, ¿vale? La idea es que todos sepamos que tenemos que utilizar HTML semántico y su importancia, ¿de acuerdo? Entonces, voy a daros unos pequeños tips muy poquitos porque no da para mucho el tiempo que tenemos, pero vamos a intentar verlo. Las ventajas de utilizar el mercado semántico, el HTML semántico. La primera y más fundamental es la accesibilidad. Luego la trataré con un poquito más de detalle. La segunda es el SEO. También la trato un poquito más de detalle después. La tercera es la internacionalización. El HTML semántico nos permite hacer que nuestro contenido sea internacionalizable. Es decir, nos permite hacer que el contenido se pueda traducir fácilmente a otros idiomas y permite que podamos marcar con elementos como BDI, BDO y atributos como lang y dir la dirección o el lenguaje que vamos a utilizar en distintas partes del texto. Esto es importante. Si por defecto se utiliza el inglés, se utiliza arriba. O sea, podemos hacer que toda una página tenga un idioma determinado y dentro del contenido del texto podemos utilizar un texto en otro idioma y le podemos poner el atributo lang para que se quede constancia de que es otro idioma. La interoperabilidad en el sentido de que podemos reutilizar el contenido que estamos marcando en distintas partes de la propia web y, además, en distintas partes en otras aplicaciones, en otras webs, en otros recursos. Podemos indicarlo. Lo más conocido es la sindicación a través de las aplicaciones de lo que ahora no se utiliza tanto, pero que se sigue utilizando. Ahora no me sale nombre. Y luego de redes sociales, etcétera. Entonces, esto es algo que también el marcado semántico lo propicia. Por otro lado, las buenas prácticas, es decir, el desarrollo del código de webs, una de las buenas prácticas es hacerlo con código semántico. Es utilizando HTML correctamente, utilizando cada uno de los elementos semánticos que tenemos. Había preparado, en esta presentación nos había preparado, a principio, unas capturas de pantalla de webs del año 96, del año 2000, del año 2005, del año 2010, las he quitado porque no daba tiempo, pero para ver un poco cómo había evolucionado el HTML desde entonces y cómo habíamos pasado de maquetar con tablas, a luego maquetar solo con webs, y luego también introduciendo otros elementos semánticos. Y si miráramos ahora, veríamos que estamos un poco volviendo atrás en algunas cosas. Entonces, eso es lo que os quiero recordar. No nos olvidemos. Además, es una buena práctica todas estas razones, y además el código es más mantenible. Por supuesto, si tenemos un espagueti, un código espagueti, todo de webs, un webs detrás de otro, a la hora de mantener ese código es mucho más menos identificado, identificable, que si tenemos bien estructurado el contenido con sus elementos semánticos. A nivel de accesibilidad, muy importante, para la accesibilidad es fundamental todo el tema del código semántico. Los usuarios de lectores de pantallas utilizan los encabezados, las secciones estructurales, tablas listas, son distintas partes de la página que pueden utilizar para navegar. Por tanto, que todo esto esté bien marcado, es importantísimo. Los usuarios de teclado utilizan enlaces, inputs, botones de serie con teclas de navegación, sin necesidad de utilizar JavaScript. El cambio de idioma con el atributo lang permite saber en qué idioma se leerá un texto también para un lector de pantalla, por ejemplo. Hay montones más de tips al respecto de la accesibilidad. Son los he puesto unos cuantos. Y aquí os enseño un gráfico de una encuesta que se hizo en el 2021 en WebAIM. Supongo que este año volverán a sacar otra. Las acostumbran a hacer cada dos años, en la que se les preguntaba, en este caso, se les preguntaba, para encontrar algo en la página, qué método utilizáis de estos. Y entonces el 67.7% dijeron, era gente que utiliza screen readers, solo eran usuarios de lectores de pantalla. El 67.7% navegan cuando buscan algo por enlos encabezados, o sea, fijaros la importancia que tienen los encabezados, el que una página esté bien estructurada con encabezados. Y eso quiere decir bien estructurada. Es decir, no poner encabezados así porque sí, sino poner los encabezados correctamente con la jerarquía correcta. Es decir, pues tengo un H1 por página, el H2 para esa sección, con sus subhidings, con sus subcabeceras, y es que tiene subapartados. Pero no para estilos, es decir, lo que se hacía antes, que se utilizaban los encabezados simplemente, porque tenían estilos distintos y los queríamos utilizar para eso, ahora hoy en día no es necesario, no tenemos que utilizarlos para eso. Y desgraciadamente se sigue utilizando en ese sentido. Entonces, por favor, no. Los encabezados tienen que estar bien estructurados. Y aunque la especificación no diga que solo tiene que haber un H1 por página, porque desde HTML5 podemos utilizar más de un H1, podría una sección tener un H1, etcétera, se recomienda, sobre todo, por el tema de accesibilidad. Es muy recomendable que solo utilicemos un H1 por página, y luego cada sección, su H2 y sus subencabezados inmediatamente. Y no saltarse, recordad, no saltarse niveles de encabezados. A nivel deseo, ayuda a los motores de búsqueda a entender mejor el contenido, ¿vale? Eso sigue siendo cierto, aunque Google, por ejemplo, ya dice en una de estas preguntas que respondió Google no hace mucho, ya dijeron que, bueno, que a nivel de ranking no afecta, ¿vale? O sea, no lo utilizan el uso de HTML semántico, pero que, aunque no afecte a nivel de ranking, lo siguen utilizando para entender mejor las páginas. Y, por tanto, ellos siguen recomendando que utilicemos HTML semántico para que Google pueda también entender mejor el contenido de las páginas. Por tanto, hay que seguir utilizándolo también en ese sentido, ¿no? Y porque ofrece una mejor experiencia de usuario, que eso también es algo que Google también está valora, ¿no? Y lo que decíamos, ¿no? Es accesible para lectores de pantallas, accesible para navegar, facilita que sea responsive y está usando el estándar por lo cual está preparado para el futuro. Os lo que os decía antes, ¿vale? Importantísimo, utiliza HTML semántico, por favor. A ver, aquí os he puesto una lista de elementos para recordarlos. Vamos a hacer un repaso muy rápido de contenido texto. ¿Por qué? Os he puesto los antiguos, los de siempre, los de toda la vida, porque a veces hay gente que piensa que el HTML semántico solo es el nuevo. Merci. Que es lo de HTML5, el main, el nav, el section. Y esto, que esto lo es, por supuesto. Pero es que p, el elemento p, que es el que marca que es un párrafo, eso es un elemento semántico también. Y si me ponéis un texto que es un párrafo dentro de un div, eso está mal. No es correcto. No tiene que ir dentro de un div. Los divs son elementos no semánticos. Los divs solo se tienen que utilizar para dar estilo. Y nada más. Por tanto, si tenemos un párrafo, tiene que ir en un p. Si es un enlace, tiene que ir en un a, que es un link. ¿De acuerdo? Si es una lista de elementos, tiene que ser un oel, si es desordenada o un oel, si es ordenada. Eso es, todo esto son elementos semánticos. Un bloquot para una cita, un DTDD para un listado de definición, el caption y el figure para utilizarlos. Esos ya son un poquito más complejos, pero hay situaciones en los que es necesario utilizarlos. Vale, para texto en línea, que todos estos son, estos para textos de bloque y estos para textos en línea. Estos, por ejemplo, se utilizan muchas veces muy poco. El a se utiliza mucho, por supuesto. Pero en las abreviaturas, si ponemos abreviatoras, por favor, utilicimos el a, b, b, r. Porque el abreviatora, sobre todo para gente que tiene dificultades para saber lo que es un, yo qué sé, pues a ver, nosotros todos sabemos lo que es html, pero es que a lo mejor viene alguien en orlean, no tienen ni idea, ¿no? Y como eso, cualquier otro, otro palabra de estos que uno sabe muy bien lo que es y otro no, ¿vale? Entonces, también para los lectores de pantalla, les va muy bien que se lo expliquemos, ¿vale? El supe, el supe, pues, para marcar cuando estamos haciendo un subit índice, un super índice, etcétera. El time, otro elemento que si estamos poniendo una fecha, claro, en Wordpress, ya es la fecha del post por defecto, ya nos la ponen time, genial. Pero si queremos marcar en algún momento dado un texto o una fecha, nosotros, pues, tenemos que poder marcarla con time. Y si estamos creando un blog o un pattern, pues, y vamos a poner una fecha, sabemos que ahí va una fecha, hay que marcarla correctamente y hay que ponerle que es un time, ¿de acuerdo? Y ponerle en su atributo correspondiente el time en el formato correspondiente. Para tablas y para formularios, tenemos estos elementos que hay que saber utilizar correctamente. Sobre todo, el más problemático es el button, que muchas veces el button, porque lo utilizamos, utiliza mucho en JavaScript para hacer cualquier cosa para darle animación a algo, para una acción determinada y muchas veces no se marca como button. Cogemos una y hacemos que esa haga de button o cogemos un div o un span y hacemos que eso haga de button. No, es un button. Y un button por defecto, HTML ya lo marca de una manera determinada y ya le da una serie de funcionalidades de forma determinada. Entonces, hay que marcarlo correctamente. Un button es un button. Vamos a utilizar el elemento button, que es el que le corresponde. Los inputs como inputs, por supuesto, los labels, utilizar los labels, recordad que para accesibilidad también son muy importantes los labels. No hay que olvidar los diseñadores, por favor, los labels, hay que ponerlos. Hay que ponerlos labels para que los elementos sean accesibles. Seccionado de contenidos. Aquí es donde aparecen los elementos más nuevos de HTML5, el main, el header, el footer, el nav, el section, el article. Aparte de los encabezados. Ya hemos hablado de los encabezados. Utilizemos, por favor, estos elementos nuevos que nos permiten dar forma a la página con su distribución principal de la página. Lo que antes se hacía con el div y el id main, el id header, el id footer, pues, bueno, al final se crearon estos elementos. Pues utilizémonos, que para eso los tenemos. El navegador, el screen reader, el lector de pantalla, también puede navegar por estas regiones. No lo utilizan tanto, pero lo pueden utilizar. Pueden ir solo al footer, al encabezado, al centro del contenido, al main, etcétera. A la site, que no lo he puesto. Creo que me lo he dejado en la site. Pero bueno, iré ahí también, ¿vale? Entonces, esto nos divide muy bien la página. Y permité un rápido escaneo de la página. Continued multimedia. Bueno, esto aquí también hay muchos elementos nuevos. Lo dicho, por favor, utiliza HTML semántico. Guarpres, ¿qué podemos controlar? ¿En bloques, páters o temas a medida? Pues todo. Si lo hacemos a medida, endemente, podemos controlarlo todo. Si son prediseñados, cuidado, porque es lo que quiero ahora comentaros, hay que vigilar, ¿no? Desde el editor de bloques hay cosas que se pueden hacer y otras que no. Vamos, ahora lo veremos en el editor directamente. ¿A qué os he puesto un ejemplo de un bloque de Génesis que está muy bien? Como ejemplo de buena práctica, de un bloque que está bien hecho. Porque está bien maquetado por defecto, es muy bien personalizado y permite escoger los tags, precisamente eso, ¿no? Entonces aquí, bueno, os he puesto tres pantallazos de lo que permite hacer dentro del editor de bloques, ¿no? Nos permite poner, es el que lista los posts, ¿vale? De Génesis. Bueno, pues te permite escoger todo esto, pero aquí lo que me importa es esta parte de aquí a la derecha, la que he marcado en rojo. ¿Por qué? Porque te permite, fijaros, que permite escoger el post grid section tag y decir, ¿vale? ¿Qué elemento le voy a dar a esta sección? Y te permite ponerle un section, un article, un div o lo que tú quieras. Normalmente lo lógico sería ponerle un section, ¿vale? Y te permite ponerle escoger que header, que hidden, que nivel de hidden le pones a esa sección, a esa sección, ¿vale? Y luego te permite decidir qué nivel de encabezado va a tener los posts que van ahí dentro, ¿vale? Vale, bueno, esto es el código que se ve detrás. Dejadme que ahora que vaya un momentito, porque me queda muy poquito tiempo, pero quería enseñaros, a ver si me deja, no, con sigo. Vale, entonces, quería enseñaros un par de ejemplos de cosas, que es lo único que me va a dar tiempo, de cosas que no se hacen bien actualmente, ¿no? O sea, quería enseñar, por ejemplo, como ejemplo, esta web de una conferencia bastante importante de temas web, ¿vale? Con toda una serie de conferencias bastante conocidos, donde, por ejemplo, el texto que hay aquí, como veis, es un div, lo que os decía antes, ¿vale? En lugar de ser un P, es un div, ¿vale? Y fijaros que el titular de este, de esto que debería ser, esto es cada una de estas, una de las charlas, es una, en lugar de tener un header, ¿no? O sea, de ser un encabezado. Entonces, esto, a mí me parece que a estas alturas, hagamos estas cosas, me parece como muy, muy, muy grave, ¿no? Y luego, por ejemplo, había, ¿dónde era? En la anterior. Aquí, por ejemplo, tenían las fax, que es un ejemplo muy típico, ¿vale? Fijaros, me ponen las fax, las preguntas como H4. O sea, no me ponen el titular en el artículo, me ponen aquí un H4 y en lugar de utilizar un, pues, podría ser un sitio perfecto para utilizar DT, DDS, etcétera, ¿vale? Quería enseñaros también cómo utilizar, me voy a comer un minutito de las preguntas, ¿vale? O dos, ¿vale? Cómo utilizar, por ejemplo, abreviaturas en el editor de Gutenberg, podemos, podemos hacer con el editor, no lo podemos poner, las abreviaturas directamente. Hay que poner un plugin, ¿vale? Esto que lo sepáis. En cambio, el cambio de idioma del texto sí que se puede hacer mediante el propio, el propio Gutenberg ya te trae un, si tú le coges aquí, le puedes cambiar el formato, hay una opción que es idiomas, ¿vale? Y aquí le puedes decir qué idioma es y en qué dirección se hace la escritura, ¿vale? Y bueno, había puesto algunos ejemplos más para que vayáis qué podíamos, qué se puede hacer desde el editor. Pero hay cosas que se pueden hacer y hay cosas que no, por lo tanto, para los que no estáis haciendo desarrollo, pero estáis implementando algunas cosas que se tienen que tocar directamente aquí, se tienen que hacer en el código. Es decir, tenemos que irnos al editor de código y a lo mejor vais a tener que meteros aquí dentro y algunas cosas ponerlas directamente aquí. Ya sé que a nadie le gusta hacer esto, ¿eh? Pero a veces, si no nos permite la herramienta hacerlo, pues vamos a tener que venir aquí y meterlo a mano, ¿vale? De momento, mientras no mejoremos el editor y no tengamos más herramientas o no encontremos un plugin que lo haga. ¿De acuerdo? Bueno, me vuelvo a la presentación porque ya tengo que ir cerrando. Esto lo he dicho, utiliza HTML semántico, por favor. Cuando lijas plugins de bloques, mira todas sus opciones, revisa el HTML resultante. Cuando desarrolles bloques, no uses solo DIP, solo para estilos, piensa bien el contenido, utiliza el HTML que corresponde. Utiliza MDN, por favor, que para eso está. Buscat bien ahí el contenido, todo lo que hay y las especificaciones. En MDN están todos los elementos. Es opuesto este enlace. Está la lista de todos los elementos, podéis buscarlos. Y ahí en cada elemento está el enlace a la especificación directamente. Usar herramientas y extensiones del browser para saber si está bien lo que estáis haciendo. Validate el código. Por favor, todavía existen los validadores. Validemos el código que nos da muchísima información de si hemos hecho bien las cosas bien o mal. Os he puesto aquí algunas referencias interesantes de lo que he dicho. Y por favor, utiliza HTML semánticos, pero a veros convencido, con mi charla. Bueno, soy Núria. Ya os han contado quién era. Como ya voy lejos de tiempo, pues ya sabéis. Moitas gracias, muchas gracias. Hola, hola, ahora sí. Fantástica charla, muchísimas gracias, Núria. Me queda solo una pregunta sí básica antes de que pasen los demás. Entonces, ¿tú crees que es importante marcar el HTML de Senteván? Os ha quedado claro. Vale, vale, me parece claro, me parece muy bien. ¿Alguna pregunta? Muy cueco. Se tenía que decir y se dijo. Te has saltado muy rápido la slide de la que tenías los validadores, etcétera. Puedes darnos un poco herramientas para validar sobre la marcha y para luego ser capaces de evaluar el trabajo final realizado. ¿Tienes algún listado de herramientas? ¿Tienes una slide que te has pasado y no tienes que hacer ni la foto? A ver, estos son los validadores típicos de código, el de HTML, que es el V3, que hace el, te valida el HTML, ¿vale? Luego te valida también el CSS, que no es tanto en relación al HTML, pero que también hay que validarlo, porque también es importante. Y luego, en accesibilidad, ya sabéis que validadores, hay varios y que no hay ninguno que sea, porque la accesibilidad no se puede validar automáticamente todo. Hay algunas cosas que puede validar. Por ejemplo, se puede validar el tema de algunas temas de encabezados, etcétera, pero no hay muchas cosas que se tienen que validar manualmente. Por tanto, es difícil hacerlo. Pero si también es importante, por ejemplo, que decía utilizar herramientas y extensiones del browser, por ejemplo, la accessibility tree para ver también el árbol de accesibilidad de la página, ¿vale? El livehouse, pasarle el livehouse cada 10 minutos a vuestra página o cada cinco casi os iría, ¿no? Es decir, hay que pasarlo, porque entonces veréis todos los problemas que tienen y veréis problemas de accesibilidad, veréis problemas de todo tipo, no solo los de optimización, ¿no? Entonces, todo eso y de buenas prácticas, todo esto ayuda a encontrar esos problemillas, ¿no? Claro, es una buena, es utilizar HTML, o sea, utilizar las imágenes con el texto alternativo, no solo es un tema de accesibilidad, es que alt es un atributo de HTML y está para eso, ¿no? Entonces, hay que utilizarlo, ¿no? Quienes más se van a beneficiar son la gente con problemas visuales, pero para eso están todas estas herramientas, te, os van a dar todos estos problemas. Y una, mira, esto dejadme, pues yo utilizo mucho esto, por ejemplo, si yo me voy aquí, vamos a ir a este, al The New York Times, que era otro que os quería enseñar. Yo utilizo esta herramienta, que es de hace muchos años, las web developers tools. Y en realidad la mitad de las herramientas ya no valen, porque son de cuando se maquetaba un de contablas y con nuestras historias. Pero hay, a mí, la que más me gusta es el view document online. Entonces, esto te dice rápidamente cómo está estructurado un documento, ¿no? Si tiene todos los encabezados correctamente. Y ya te dice, vale, aquí has perdido el H1, no lo tienes. El H2 tampoco. Y luego tienes todos estos H3, ¿no? Vale, y aquí, mira, aquí me has saltado del H4, del H3 a un H6 y a un H5 te has saltado el H4, ¿no? Entonces, le pasas esto, hay otros documentos online, pero a mí me sigo gustando más este, es el que más me gusta cómo lo hace. Entonces, por eso lo conservo. Entonces, le pasáis esto a cualquier página y enseguida veréis, ostras, me he dejado aquí un encabezado. Me falta un nivel, me falta otro nivel. Entonces, este tipo de herramientas ayudan a que todas estas cosas las vayamos colocando bien, ¿vale? Muy bien, alguna pregunta más? Sí, por allá. Hola, ¿qué tal? Mira, antes dijiste, bueno, es totalmente correcto, que realmente un párrafo, un texto, debería estar dentro de la etiqueta semántica de la P, ¿no, del párrafo? Y que el div lo deberíamos reservar únicamente para estilos. Pero si hablamos de buenas prácticas, tú validarías que los estilos estuviesen dentro de la propia etiqueta del P, porque yo podría darle ahí todos los estilos que yo quisese, o crear un div para todos los estilos, y luego el P y lo dejo ahí nada más como semántico. ¿Cómo verías tú que es la mejor? No te acaban de entender que estén los estilos en línea, me preguntas. O que estén en el div y que luego los estilos estén fuera, pero referiéndose al div y el P esté dentro del div. Lo que te quiero decir es que dentro de la etiqueta P tú puedes poner estilos, ¿no? P y luego van los CSS. O poner todos los estilos de CSS dentro de la etiqueta div por encima de la P. Sí. No sé si me diréis un poco. A ver, si necesita que el div, o sea, si el P necesita una etiqueta div encima, porque yo qué sé, cuando a veces tú necesitas poner un div, si tú quieres hacer un flex sobre un grupo de elementos, pues vas a necesitar un padre. Entonces ahí tienes que poner el div para que se sea el padre y tengas los, no sé qué ha pasado. Necesitas poner una caja, un div, si no tienes otro elemento que lo sustituya para poner los estilos a esa caja. Pero a veces no hace falta. Si tú no necesitas un elemento padre y el P ya le puedes dar los estilos, se los das fuera, no en línea, en CSS, en la hoja de estilos. Pero para qué quieres otro elemento? Me explico. Sí, sí, perfectamente. Otra cosa, el problema muchas veces, hay muchos divs, sigue habiendo muchas webs con muchísimos divs, cuando deberíamos utilizar menos divs. Eso es en gran parte porque utilizamos muchas veces editores de contenidos que les meten muchos divs. El propio Gutenberg también le meten muchos divs, más de los necesarios. Pero si nosotros desarrollamos, intentemos también poner menos divs, es decir, los mínimos posibles, los que sean realmente estrictamente necesarios para los estilos. Y nada más, no. Pues nada. Ya se nos fue el tiempo. Muchísimas gracias, Núria, de verdad, y acerte a este pequeño regalo de la comunidad. Bueno, y vamos a la última charla. Vale, un momentito.