Kai prieš kelerius metus pradėjau dirbti su HTML, man atrodė, kad viskas gana paprasta – įdedi tekstą tarp tagų, pridedi šiek tiek CSS ir voila, puslapis veikia. Tačiau greitai supratau, kad tarp „veikiančio” ir „gerai padaryto” puslapio yra milžiniškas skirtumas. Semantinis ženklinimas – tai viena iš tų dalykų, kurios atskiria profesionalų nuo pradedančiųjų.
Kas iš tikrųjų yra semantinis HTML
Semantinis HTML reiškia tinkamų tagų naudojimą pagal jų prasmę, o ne vien dėl vizualinio efekto. Paprasčiau tariant, jei kažkas yra antraštė – naudoji heading tagą, jei tai navigacija – naudoji nav elementą. Skamba elementaru, bet praktikoje daugybė svetainių vis dar pilnos div ir span tagų, kurie nieko nesako apie turinio struktūrą.
Problema ta, kad naršyklės ir paieškos sistemos neskaito tavo CSS. Jos žiūri į HTML struktūrą ir bando suprasti, kas svarbu, kas antraeilė informacija, kaip viskas susiję. Kai naudoji semantinius tagus, tu iš esmės pasakoji istoriją apie savo puslapio turinį ne tik žmonėms, bet ir mašinoms.
Štai paprastas pavyzdys. Galiu sukurti antraštę taip:
<div class="heading" style="font-size: 24px; font-weight: bold;">
Mano puslapis
</div>Arba taip:
<h1>Mano puslapis</h1>Vizualiai, su tinkamu CSS, abu gali atrodyti vienodai. Bet semantiškai – tai diena ir naktis. Antrasis variantas aiškiai sako: „Čia yra pagrindinis puslapio pavadinimas”. Tai supranta ekrano skaitytuvai, paieškos robotai, naršyklės, kurios bando optimizuoti turinį mobiliesiems įrenginiams.
Kodėl turėtų rūpėti ne tik SEO specialistams
Dažnai girdžiu argumentą, kad semantinis HTML – tai daugiausia SEO reikalas. Iš dalies tiesa, bet tai tik viršūnė ledkalno. Taip, Google ir kitos paieškos sistemos tikrai vertina semantinę struktūrą. Tačiau yra ir kitų priežasčių, kodėl tai svarbu bet kuriam frontend kūrėjui.
Prieinamumas – štai kur semantinis HTML tikrai spindi. Žmonės su regėjimo negalia naudoja ekrano skaitytuvus, kurie interpretuoja HTML struktūrą. Kai tavo puslapis semantiškai teisingas, šie įrankiai gali efektyviai naršyti po turinį. Vartotojas gali peršokti nuo vienos antraštės prie kitos, greitai rasti navigaciją, suprasti, kur prasideda ir baigiasi straipsnio turinys.
Esu matęs svetainių, kur visa navigacija padaryta iš div elementų su onclick event’ais. Techniškai veikia, bet ekrano skaitytuvui tai tiesiog tekstiniai blokai. Vartotojas net nežino, kad tai yra navigacija. O jei būtų naudojamas nav elementas su tinkamais link’ais – viskas būtų akivaizdu.
Dar vienas aspektas – komandos darbas ir kodo palaikymas. Kai grįžti prie projekto po kelių mėnesių (arba perimi kieno nors kodą), semantinis HTML padeda greitai suprasti struktūrą. Matai article tagą ir žinai, kad tai savarankiškas turinio vienetas. Matai aside – supranti, kad tai papildoma informacija. Su div tagais viskas tampa atspėjimo žaidimu.
Pagrindiniai semantiniai elementai, kuriuos tikrai turėtum naudoti
HTML5 įvedė daugybę naujų semantinių elementų, ir nors jau praėjo nemažai laiko, vis dar matau projektus, kur jie ignoruojami. Štai tie, kuriuos naudoju beveik kiekviename projekte:
header – ne tik puslapio viršui, bet ir bet kuriai turinio sekcijai. Galite turėti header elemente article, section ar net aside. Čia paprastai eina pavadinimas, meta informacija, gal introductory content.
nav – navigacijos blokai. Svarbu: ne kiekvienas link’ų sąrašas turi būti nav. Šis elementas skirtas pagrindinėms navigacijos sekcijoms. Footer’yje esančių link’ų sąrašas nebūtinai reikalauja nav tago.
main – pagrindinis puslapio turinys. Turėtų būti tik vienas main elementas puslapyje, ir jame neturėtų būti pasikartojančio turinio kaip navigacija ar footer. Tai tas turinys, dėl kurio žmogus atėjo į puslapį.
article – savarankiškas turinio vienetas, kurį galima būtų ištraukti iš konteksto ir jis vis tiek turėtų prasmę. Tinkamiausias pavyzdys – blog’o įrašas, naujiena, forumo pranešimas. Galite turėti kelis article elementus puslapyje.
section – teminė turinio grupė. Skirtumas nuo article – section paprastai nėra savarankiškas. Tai daugiau kaip skyrius dokumente. Pavyzdžiui, straipsnyje apie programavimo kalbas kiekviena kalba galėtų būti atskira section.
aside – turinys, susijęs su pagrindiniu, bet ne esminis. Sidebar’ai, pull quotes, reklamos, papildomi paaiškinimai. Svarbu suprasti, kad aside neturi reikšti „šone esantis” – tai semantinė, ne vizuali savybė.
footer – kaip ir header, gali būti naudojamas ne tik puslapio apačioje. Bet kurios sekcijos ar article pabaigoje gali būti footer su meta informacija, autorystės duomenimis, susijusiais link’ais.
Kaip teisingai struktūruoti antraštes
Antraštės (h1-h6) – tai viena iš svarbiausių semantinio HTML dalių, ir čia dažnai daromos klaidos. Seniau buvo aiški taisyklė: vienas h1 puslapyje, toliau hierarchija h2, h3 ir t.t. HTML5 šiek tiek pakeitė žaidimo taisykles su outline algoritmu, bet praktikoje geriau laikytis tradicinės hierarchijos.
Dažniausia klaida, kurią matau – antraščių naudojimas dėl dydžio, o ne dėl hierarchijos. Kažkas nori mažesnės antraštės, tai naudoja h4 vietoj h2, nors logiškai tai turėtų būti h2. Štai kaip to vengti: visada galvok apie turinio struktūrą pirmiausia, o apie dizainą – antraeiliai. CSS gali padaryti h2 bet kokio dydžio.
Praktinis patarimas: prieš pradėdamas kurti puslapį, susikurk turinio outline. Koks bus pagrindinis pavadinimas? Kokios pagrindinės sekcijos? Kokios subsekcijos? Tai padės teisingai pasirinkti antraščių lygius.
<article>
<h1>Semantinis HTML</h1>
<section>
<h2>Kas yra semantika</h2>
<p>...</p>
<h3>Pagrindinės sąvokos</h3>
<p>...</p>
</section>
<section>
<h2>Kodėl tai svarbu</h2>
<p>...</p>
</section>
</article>Dar vienas dalykas – nepraleisk antraščių lygių. Jei po h2 eina subsekcija, tai turėtų būti h3, ne h4. Ekrano skaitytuvai leidžia vartotojams naršyti pagal antraščių lygius, ir praleisti lygiai gali sukelti painiavą.
Sąrašai, lentelės ir kiti dažnai ignoruojami elementai
Kalbant apie semantiką, negaliu nepaminėti sąrašų. Matau tiek daug svetainių, kur sąrašai kuriami su div elementais arba net br tagais. Jei tai sąrašas – naudok ul, ol arba dl. Taip paprasta.
Nenumeruoti sąrašai (ul) – kai eilės tvarka nesvarbi. Numeruoti (ol) – kai svarbi. Aprašomieji sąrašai (dl) – terminų ir apibrėžimų porom. Pastarieji ypač naudingi metadata, FAQ sekcijoms, bet retai naudojami.
Lentelės – dar viena skausminga tema. Lentelės skirtos duomenims, ne layout’ui. Tai atrodo akivaizdu dabar, bet vis dar matau projektų su table-based layouts. Kita vertus, kai reikia rodyti duomenis, lentelė yra teisingas pasirinkimas. Tik nepamirškite tinkamos struktūros:
<table>
<thead>
<tr>
<th scope="col">Vardas</th>
<th scope="col">Amžius</th>
</tr>
</thead>
<tbody>
<tr>
<td>Jonas</td>
<td>25</td>
</tr>
</tbody>
</table>thead, tbody, tfoot elementai padeda struktūruoti lentelę. scope atributas th elemente padeda ekrano skaitytuvams suprasti, ar tai stulpelio, ar eilutės antraštė. Smulkmenos, bet svarbios.
Figure ir figcaption – puikus derinys vaizdams su aprašymais. Vietoj div su img ir p, naudok semantinius elementus:
<figure>
<img src="diagram.png" alt="Sistemos architektūros diagrama">
<figcaption>1 pav. Mikroservisų architektūros schema</figcaption>
</figure>Formos ir interaktyvumas semantiškai
Formos – viena iš sričių, kur semantika ypač svarbi prieinamumo požiūriu. Kiekvienas input laukas privalo turėti susietą label. Ne placeholder, ne title atributas – būtent label elementas. Yra du būdai tai padaryti:
<label for="email">El. paštas:</label>
<input type="email" id="email" name="email">Arba:
<label>
El. paštas:
<input type="email" name="email">
</label>Abu variantai veikia, bet pirmasis lankstesnis stilizavimui. Svarbu, kad label ir input būtų susieti – tai leidžia paspausti ant label teksto ir fokusas nukris į input lauką. Ekrano skaitytuvai taip pat skaito label tekstą, kai vartotojas pereina prie input lauko.
Fieldset ir legend elementai puikiai tinka formos laukų grupavimui. Ypač naudinga radio button grupėms ar checkbox’ams:
<fieldset>
<legend>Pasirinkite programavimo kalbą</legend>
<label><input type="radio" name="lang" value="js"> JavaScript</label>
<label><input type="radio" name="lang" value="py"> Python</label>
<label><input type="radio" name="lang" value="go"> Go</label>
</fieldset>Button elementas vs input type=”button” – naudokite button. Jis lankstesnis, galite įdėti HTML turinį, lengviau stilizuoti. Ir nepamirškite type atributo – button type=”button” paprastam mygtukui, type=”submit” formos siuntimui.
ARIA atributai: kada reikalingi, kada ne
ARIA (Accessible Rich Internet Applications) atributai – tai papildomas sluoksnis prieinamumui. Bet štai svarbiausia taisyklė: jei galite pasiekti tą patį rezultatą su semantiniu HTML, nenaudokite ARIA. Pirma semantinis HTML, ARIA tik kai būtina.
Pavyzdžiui, nereikia daryti taip:
<div role="button" tabindex="0">Paspausti</div>Kai galite tiesiog:
<button>Paspausti</button>Bet ARIA tampa naudinga, kai kuriate sudėtingus komponentus, kurių semantika nėra aprašyta standartiniame HTML. Dropdown meniu, tabs, modal langai, autocomplete laukai – čia ARIA atributai padeda aprašyti komponentų būsenas ir santykius.
Dažniausiai naudojami ARIA atributai:
- aria-label – kai nėra matomo teksto, bet reikia aprašymo ekrano skaitytuvui
- aria-labelledby – kai norite susieti elementą su kitu elementu, kuris veikia kaip label
- aria-describedby – papildomas aprašymas ar instrukcijos
- aria-hidden – kai elementas yra vizualiai, bet neturėtų būti prieinamas ekrano skaitytuvams
- aria-live – dinamiškai besikeičiančiam turiniui, kad ekrano skaitytuvas praneštų apie pakeitimus
Svarbu suprasti, kad ARIA tik keičia, kaip assistive technologies interpretuoja elementus, bet nekeičia jų funkcionalumo. Jei padarėte div su role=”button”, vis tiek turite pridėti klaviatūros palaikymą, focus management ir visa kita, ką button elementas duoda nemokamai.
Praktiniai patarimai realiam gyvenimui
Teorija teorija, bet kaip tai pritaikyti praktikoje? Štai keletas patarimų, kurie man padeda kasdienėje veikloje:
Pradėkite nuo HTML. Prieš rašydami CSS ar JavaScript, sukurkite semantišką HTML struktūrą. Puslapis turėtų būti suprantamas ir naudojamas net be stilių. Tai vadinama „progressive enhancement” principu.
Naudokite validatorius. W3C HTML validator padės sugauti klaidas. Nors ne visos klaidos yra kritinės, validus HTML paprastai reiškia geresnę semantiką.
Testuokite su ekrano skaitytuvais. Nebūtina turėti regėjimo negalią, kad išbandytumėte ekrano skaitytuvą. NVDA (Windows) ir JAWS yra populiarūs, macOS turi integruotą VoiceOver. Išbandykite savo svetainę su vienu iš jų – bus apšvietimas.
Naudokite browser dev tools. Modernios naršyklės turi prieinamumo audito įrankius. Chrome DevTools Lighthouse gali patikrinti daugybę prieinamumo problemų. Firefox turi puikų accessibility inspector.
Peržiūrėkite HTML struktūrą be CSS. Išjunkite stilius ir pažiūrėkite, ar puslapis vis dar logiškas. Ar antraščių hierarchija aiški? Ar turinys seka logiška tvarka? Jei ne – reikia pataisyti HTML, ne CSS.
Dar vienas patarimas – mokykitės iš gerų pavyzdžių. Žiūrėkite, kaip dideli portalai struktūruoja savo HTML. MDN Web Docs, GitHub, Wikipedia – visi šie projektai skiria dėmesį semantikai. Naudokite browser inspector ir tyrinėkite jų struktūrą.
Ir paskutinis, bet svarbiausias – darykite semantinį HTML įpročiu, ne išimtimi. Iš pradžių gali atrodyti, kad tai papildomas darbas, bet greitai tampa natūralu. O nauda ilgalaikėje perspektyvoje – milžiniška.
Kai semantika susiduria su realybe
Suprantu, kad idealus pasaulis ir realybė ne visada sutampa. Kartais dizaineris duoda maketus, kurie nesiderina su semantine struktūra. Kartais turite dirbti su legacy kodu, kur viskas padaryta div’ais. Kartais deadline’ai spaudžia ir atrodo, kad semantika – tai prabanga.
Bet patikėkite, semantinis HTML ilgainiui sutaupo laiko, ne atima. Kai grįžtate prie kodo po mėnesio, semantinė struktūra padeda greitai suprasti, kas kur. Kai reikia pridėti naują funkciją, teisingas HTML palengvina darbą. Kai ateina naujas komandos narys, jis greičiau įsitraukia.
O prieinamumo aspektas – tai ne tik moralinė pareiga (nors ir tai svarbu). Daugelyje šalių prieinamumas yra teisinis reikalavimas. Viešojo sektoriaus svetainės privalo atitikti WCAG standartus. Bet ir privačiame sektoriuje prieinamumas tampa konkurenciniu pranašumu. Kuo daugiau žmonių gali naudotis jūsų produktu, tuo geriau verslui.
Taip, semantinis HTML nėra sidabrinis kulka. Galite turėti semantiškai tobulą HTML ir vis tiek prienamumą sugadinti su JavaScript. Galite turėti puikią struktūrą, bet jei turinys prastas – niekas nepadės. Semantika yra viena dalis didesnio puzzle, bet labai svarbi dalis.
Galiausiai, technologijos keičiasi, bet pagrindiniai principai išlieka. HTML semantika nėra mada ar trumpalaikis trend’as. Tai fundamentalus web’o principas, kuris buvo svarbus prieš dešimt metų ir bus svarbus dar po dešimties. Investavimas į semantinio HTML mokymąsi ir praktikavimą atsipirks visą karjerą. Tai įgūdis, kuris niekada nepasens, nes jis grindžiamas ne konkrečia technologija, o tuo, kaip mes komunikuojame prasmę – žmonėms ir mašinoms.