ABONAMENTE VIDEO REDACȚIA
RO
EN
Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 82
Abonament PDF

Fructele HTML-ului semantic

Dragoș Filipovici
Senior Consultant @ MHP Romania



PROGRAMARE


Uneori, când folosim internetul, întâmpinăm obstacole. Aproximativ acum un an discutam despre cele mai recente metodologii web pentru probleme de conectivitate la internet, tatonând în același timp ideea unei aplicații web ce depășește conturul unui browser de internet. De data aceasta, vom explora alte provocări comune în domeniul aplicațiilor web, pentru a ne concentra asupra cauzelor mai puțin evidente din spatele acestora.

Acest articol are scopul de a arăta că atunci când o aplicație web nu funcționează în parametri optimi, de multe ori nu e din cauza browserului de internet pe care îl folosim, nici din cauza telefonului sau laptopului; nici măcar din cauza javascriptului ce rulează în acea aplicație (și care e de multe ori primul suspect).

Uneori, e pur și simplu simplul HTML, sau mai exact lipsa unui HTML care să nu fie doar valid, ci și semantic.

HTML semantic

HTML5, grupul de standarde HTML noi ce a apărut acum câțiva ani, a adus noi noțiuni limbajului și în același timp o concentrare asupra aspectului semantic al acestuia.

După publicarea acestor noi standarde, diverse variații ale pozei de mai jos au circulat mai mult timp prin publicațiile și forumurile din domeniu.

Din nefericire, încă din acea perioadă, o mare parte din dezvoltatorii de aplicații web își epuizau aproape total resursele concentrându-se pe multitudinea de tehnologii javascript, și încercând să îmblânzească cantitățile crescânde de cod CSS.

Astfel, acel aspect semantic al limbajului HTML a rămas în general fie o noțiune explorată superficial sau parțial în cel mai bun caz, fie un punct complet ignorat sau de prioritate foarte redusă în cel mai nefericit caz.

Accessibility

Pentru mult timp, părerea generală legată de HTML-ul semantic a fost că joacă un rol important în accesibilitatea web de bază (disciplina de Accessibility), și că ajută motoarele de căutare să ne găsească aplicația web mai ușor (disciplina de SEO sau Search Engine Optimization).

Cu scopul final de a face web-ul mai accesibil, noțiunea de Accessibility este definită în detaliu într-o colecție de specificații ce însumează instrucțiuni sau reguli după care se pot construi, respectiv evalua aplicațiile web, ținând cont de cât de ușor se pot înțelege și folosi acestea într-un set amplu de scenarii. Pentru mult timp, părerea generală legată de Accessibility s-a rezumat la compatibilitatea paginilor și aplicațiilor web cu dispozitive și tehnologii ajutătoare de tip screen-reader, și uneori și la compatibilitatea aplicațiilor de a fi utilizate și cu ajutorul tastaturii.

Însă o dimensiune din Accessibility ce rămâne deseori necunoscută, este faptul că aceasta nu presupune doar utilizabilitate esențială pentru persoane cu dizabilități și un surplus de ușurință generală prin compatibilitatea cu tastaturi.

De fapt, înseamnă și utilizabilitate esențială și surplus de ușurință pentru o mare parte din scenariile când aplicațiile web sunt folosite pe telefoane sau tablete. Datorită popularității acestor dispozitive din ultimii ani, această dimensiune a căpătat chiar mai multe laturi, la rădăcina cărora se află HTML-ul semantic. Iar pentru a înțelege aceste aspecte și motivele din spatele lor, vom contura mai întâi contextul în care s-au format.

Contextul tehnologiei

HTML, CSS și Javascript, triunghiul fundamental al webului.Ordinea în care am enumerat aceste limbaje este de obicei cea pe care o găsim atunci când citim despre ele în tutoriale sau în cărți, fiind probabil sortate cronologic. În schimb dacă le sortăm după popularitate, această listă devine JS, CSS și HTML.

Primul - Javascript, este limbajul de programare care alimentează aplicațiile web, și reprezintă unul din factorii principali care propagă un site web la statutul de aplicație web.

Pentru a înțelege diferența dintre cei doi termeni, putem lua ca exemple de aplicații web Gmail, Facbook, Twitter; iar când spunem site web, ne gândim la o pagină de prezentare de complexitate scăzută, cu un număr redus de ecrane, și în care interacțiunea cu utilizatorul se rezumă de cele mai multe ori la o navigație și un formular de contact.

Al doilea - CSS este limbajul ce ne ajută să structurăm vizual informația conținută de produsul nostru web, să o redăm fluid pe o varietate de dimensiuni de ecrane, să o încorporăm într-un design estetic care surprinde dimensiunea digitală a brandului produsului; iar dacă ne simțim curajoși, tot prin CSS putem să compunem și mișcare/animație în jurul acelei informații.

Iar al treilea, HTML… Se pare că rareori vorbim despre HTML.

Acesta nu se bucură nicidecum de aceeași popularitate în ceea ce privește tooling, articole, metodologii, dezbateri și subiecte de conferințe, comparat cu primele două limbaje.

La prima vedere, HTML este doar un simplu (plain) text pasat dintr-o parte în alta, de la un server web la un client și invers.

Dacă explorăm mai mult, înțelegem că acel simplu text este rezultatul adesea puternic procesat și personalizat al datelor, în forma finală pentru consum printr-un browser web. Iar dacă focalizăm cu adevărat, realizăm că primele două puncte nu sunt în totalitate valide.

HTML este - sau în mod ideal ar trebui să fie, în aplicațiile web - limbajul ce ne permite nu doar să servim informația într-un browser de internet, ci și să o structuram (de data aceasta nu vizual, ci în funcție de sens), să îi organizăm conținutul într-o ierarhie, și să-i marcăm sensul folosind tagurile (etichetele de conținut) limbajului.

Sensul informației… Pentru cine? Utilizatorii deduc sensul conținutului pe măsură ce îl citesc. De ce ar mai fi nevoie să îl interpretăm și să îl adnotăm în HTML?

Problema este că, mulțumită sabiei cu două tăișuri pe care o reprezintă natura webului de a fi atât de deschis, vast și permisiv, vom vedea în curând că în multe scenarii, dacă dispozitivele ce ne servesc acel conținut nu reușesc să "înțeleagă" și ele acel conținut înaintea noastră, atunci noi, oamenii, riscăm: a) în cel mai bun caz, să trebuiască să ne gândim mai mult pentru a o înțelege sau folosi, sau b) în cel mai rău caz, fie să ratăm complet acel conținut, fie să nu îl putem utiliza deloc.

Contextul utilizării acestei tehnologii

De mai mult timp a existat o tendință tăcută de a scrie cea mai mare parte a codului HTML în doar două din cele aproximativ o sută de taguri disponibile: div și span.

Cu timpul, pentru primul tag a apărut bineînțeles și o expresie nostimă pentru această practică: div soup sau supă de divuri. Așadar ne vom permite să adăugăm, tot în glumă, o nouă expresie pentru aplicațiile ce sunt scrise folosind excesiv tagul span: span fest, sau festival de spanuri. Deși HTML este un limbaj de markup, de dragul acestei practici putem face o analogie cu limbajele de programare. Atunci când lucrăm în limbaje precum Java, nu obișnuim să scriem întregul cod al unei aplicații folosind tipul any pentru toate tipurile de date, proprietăți și variabile folosite.

În prezent, atunci când scriem HTML, frameworkurile și IDE-urile cele mai populare ne avertizează dacă codul scris nu este valid, dar nu și dacă este semantic. Și aparent, nu există consecințe pentru aceasta, sau cel puțin nu consecințe imediate.

Întrucât webul este în mod intenționat foarte permisiv privind HTML-ul, nu există erori stridente pentru acesta precum în javascript sau în (alte) limbaje de programare.

Nu va crăpa niciun compilator de cod și niciun avertisment nu va fi redat atunci când scriem acest HTML "gri", al cărui conținut este lipsit de înțeles, ocolind practic scopul propriu-zis al limbajului, de a marca/eticheta bucățile de conținut al unui document, în funcție de sensul acestora.

Cu toate acestea, există totuși consecințe ce sunt mai puțin aparente și mai puțin imediate, pe care le vom explora în următoarele șapte secțiuni:

Consecințele HTML-ului non semantic

1. Sensul conținutului

Primul efect negativ - și, paradoxal, deși cel mai evident, cred că de multe ori cel mai omis - este conținutul (ce rezultă din acel HTML non-semantic) din punct de vedere al sensului.

Vă invităm la un mic exercițiu. Pentru un moment, ne propunem să ne gândim cine ar putea fi strămoșul documentului HTML. Unul dintre răspunsuri ar putea fi cartea, iar ca să fim și mai în temă, să ne gândim chiar la revistă.

Imaginați-vă cum ar fi dacă revista pe care o citiți chiar acum, nu ar avea copertă, titlu, autor și cuprins. Probabil că am obține o hârtie foarte întinsă.

O hârtie fără capitole, titluri și numere de pagini, unde textul nu este secționat în paragrafe în funcție de ideile exprimate, ci în secțiuni, poate în funcție de aspect. Pozele ar lipsi, sau dacă ar exista, cu siguranță nu ar fi etichetate. Fără citate, prescurtări, note de subsol sau tabele. Doar nesfârșite blocuri de text.

Închizând paranteza acestui exercițiu, practic exact aceasta obținem atunci când folosim HTML non-semantic, doar ca un context de redare de text manipulat de javascript și CSS.

2. Penalizări în SEO

Orientându-ne către al doilea efect negativ, avem penalizările în SEO, ce sunt cauzate direct de primul efect. Întrucât motoarele de căutare ierarhizează cuvintele cheie găsite în paginile web în funcție de ierarhia tagurilor HTML în interiorul cărora acestea se află, riscăm ca paginile web să fie omise complet de către motoarele de căutare. Prin urmare, dacă conținutul nostru nu poate fi găsit, atunci nu va fi utilizat.

3. Accessibility pentru screen readere

Al treilea efect este accesibilitatea pentru dispozitivele și tehnologiile de tip screen reader.

Atunci când conținutul nostru este găsit, însă în mare parte indescifrabil, acesta nu va putea fi utilizat de către un segment din utilizatori. Dacă, de exemplu folosim tagul button în loc de tagul a (anchor) pentru a afișa butoane, dar care de fapt, redirecționează utilizatorul către alt document HTML (în loc să execute o acțiune în cadrul aceluiași document), atunci e foarte probabil ca acel conținut să devină ascuns, încât screen readerele nu îl vor identifica ca pe o poartă către alte resurse.

Alt exemplu este atunci când folosim tagul div (combinat cu atributul de click handler) în loc de tagul button, pentru a defini acțiuni ce pot fi săvârșite de către utilizator. Și în această situație, conținutul ar putea deveni complet neutilizabil, întrucât screen readerele nu vor identifica deloc acele elemente din pagină ce arată ca și niște butoane, dar sunt de fapt secțiuni de conținut.

4. Accessibility pentru dispozitive mobile

Următorul efect constă în accesibilitatea pe dispozitive mobile pentru elemente de tip input.

Să considerăm următoarea situație: conținutul nostru este găsit de către utilizatori, este descifrabil, și permite acestora să introducă date manual. Dacă cea din urmă nu este implementată folosind HTML ce este și semantic și nu doar valid - folosind de exemplu, elemente de tip input ce nu folosesc atributul type corespunzător informației asociate - atunci conținutul poate încuraja utilizatorul să greșească.

Vom explora câteva din scenariile ce se mulează pe aceste condiții, în care cauza principală este tendința de a realiza întreaga implementare în javascript, iar în HTML, de a folosi doar inputuri generice de tip text, ce declanșează tastatura generică a unui dispozitiv mobil (cea care afișează simultan toate literele, cifrele și câteva simboluri).

4a. Introducerea numărului de card bancar

O problemă de User Experience "îndrăgită" de utilizatori vine cu disconfortul de a tasta pe ecranul unui telefon cele 16 cifre ale unui card bancar, unde rezultatul unei greșeli de tastare duce la o tranzacție eșuată, iar de multe ori trebuie să completeze din nou și restul datelor. Practic în acest scenariu avem un input ce pare a fi numeric, dar a cărui valoare nu reprezintă un număr, ci o secvență de numere - numărul unui card bancar.

Soluția recomandată este să folosim inputul de tip text, dar împreună cu atributele pattern și inputmode, pentru a înștiința dispozitivul să afișeze tastatura cea mai potrivită:

Sursa imaginii

4b. Introducerea numărului generic sau de telefon, a adresei de email, URL-ului

Deși urmările sunt mai puțin grave ca în scenariul anterior, dacă folosim elemente input generice și pentru aceste situații, vom forța utilizatorul să efectueze mai mulți pași pentru a căuta în tastatura virtuală diverse simboluri. Dacă însă folosim input de tipul telephone, email, url respectiv number, putem declanșa tastatura corespunzătoare fiecărui tip de date:

Sursa imaginii

5. Conținut lipsă în modul Reader din browsere de internet

În browserul de internet, modul reader este acea opțiune care redă doar conținutul text al unei pagini web, eliminând temporar meniuri, elemente de advertising, precum și alte elemente secundare conținutului propriu-zis.

În mod similar există și aplicații separate, al căror scop este exact consumul de articole cu ușurință, în cea mai simplă și mai aerisită formă (exemple: Pocket, Instapaper, și desființata Readability).

Pentru aceste scenarii de utilizare, atunci când nu se folosește HTML semantic, detalii esențiale din conținut - precum titlul, subtitlul, autorul, data publicării - pot fi omise complet de pe ecranul utilizatorului, indiferent dacă acesta folosește un laptop, telefon, sau chiar și un ceas inteligent.

6 & 7. Mentenanța codului și asistenții virtuali

Cu timpul, cantitățile mari de cod HTML ce nu este semantic devin tot mai dificil de înțeles, găsit, extins și modificat pentru dezvoltatori. Rețelele neuronale și asistenții virtuali precum Google Assistant, Siri (Apple), Alexa (Amazon) și Cortana (Microsoft) au devenit foarte populare în a ne procura răspunsuri (și mai nou în a efectua acțiuni în numele nostru), răspunsuri bazate pe documente web scrise în HTML. Deși la baza acestor procesări stau și multe alte tehnologii, lipsa HTML-ului semantic poate fi considerată un pas înapoi în a ajuta aceste servicii să funcționeze cât mai eficient pentru noi.

Outro

La fel ca în alte segmente ale industriei, în ultimii ani ne-am putut bucura de o evoluție impresionantă în disciplina de UI sau front-end web development, în special pentru limbajele javascript și CSS - două limbaje care acum 10-15 ani aveau un renume mult mai mic.

Ne-am concentrat atât de mult pe acestea încât am ajuns să avem librării și framework-uri mature și deosebit de populare ce ne propulsează înainte - această disciplină s-a maturizat astfel încât să nu trebuiască să reinventăm roata cu fiecare aplicație web nouă pe care o construim.

Dacă sentimentul general este că peisajul hiper dinamic pictat de javascript și CSS a început în sfârșit să se stabilizeze, poate că acum e o perioadă foarte potrivită în care să ne reamintim și de fundația acestor doua limbaje - HTML - și să ne ocupăm și de calitatea acestuia în aplicațiile noastre web.

Apel la acțiune, pentru dezvoltatori

Poate că proiectul pe care lucrăm în prezent nu este unul public, ci este destinat unui segment privat de utilizatori. Poate că am identificat deja acei utilizatori și știm că nu necesită utilizarea screen readerelor, tastaturilor, a telefoanelor mobile sau a tabletelor.

Dar sunt șanse mari ca în următorul proiect să avem nevoie să acoperim cel puțin una din aceste cerințe.

Pe lângă faptul că learning curbe-ul este mult mai mic comparat cu majoritatea librăriilor de javascript în care ne petrecem majoritatea timpului, și viteza în care lucrurile se schimbă în HTML este mai mică (cu câteva ordine de magnitudine) față de cea în care se schimbă aceste librării.

Mai mult, o aplicație SPA privată, menită să funcționeze doar pe platforma laptop/desktop nu va avea niciun detriment dacă va fi scrisă în HTML semantic.

Invitație la recapitularea elementelor HTML esențiale:

Apel la acțiune, pentru toți

Cu toate că în ultimii ani brandurile mai mari au început deja să corecteze din scenariile enumerate mai devreme, dacă încă găsiți astfel de situații pe site-urile si aplicațiile pe care le folosiți în mod frecvent, vă încurajăm să anunțați firmele respective.

Puține lucruri ajută la prioritizarea rezolvării problemelor și a îmbunătățirii codului precum feedbackul direct de la utilizatori.

Pe data viitoare!

LANSAREA NUMĂRULUI 129

Experts panel: JavaScript

Luni, 27 Martie, ora 18:00

sediul Accesa

Facebook Meetup StreamEvent YouTube

Conferință

VIDEO: NUMĂRULUI 128

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • AboutYou
  • Telenav
  • .msg systems
  • Grab
  • Colors in projects

INTERVIURILE TSM

Dragoș Filipovici a mai scris