Галоўная / Артыкулы

Ад простых элементаў div да семантычнага маркапу: практычныя вядомасці пра семантычны HTML.

Дазвольце дазнаць, чаму стандартныя элементы div паслабляюць доступнасць, адчувственную працю інструментаў для аналізу сайта, а таксама якія семантычныя элементы трэба вжываць заместа іх, і як перерабіць рэальны компонент у вигляде карточкі.

Выдавец: REACTAPP.TOP16 хв чытання3565 слоў

Крыніцы: Stop Using Divs for Everything — Semantic HTML Actually Matters

Адаптаваючы стандартны сучасны веб-дзеўайс, вы часта пабачыце той самы фатаг: глыбокі, ананімны шар элементаў <div>, кожны з якіх ідентыфікуецца толькі па назе класу. Старонка можа выглядаць ідеальна, але для чытальнікаў экрана, роўераў для пошуку і наступнага разработчыка ў командзе яна практычна нічога не сказвае пра тое, што ў яе є. У гэтым кяліку пояснюецца, якія наследкі гэта мае для вас, якія семантычныя элементы можна выкарыстоўваць заместо большасці такіх div-аў, як выбраць межы між <article> і <section>, лінкамі чы ручкамі, а таксама як пасляэтапна перерабіць реалістычны компонент.

Усё гэта выглядае ў сваім найчыстейшым варыянце так: загалоўны блок, навігацыя, главны контэнт і футер, усе якія выражаюцца як стандартныя кантэйнеры.

<!-- The modern web's favorite anti-pattern -->
<div class="header">
  <div class="nav-container">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="main-content">
  <div class="article-title">Stop Using Divs</div>
  <div class="article-body">
    <div class="paragraph">Divs everywhere.</div>
  </div>
</div>
<div class="footer">
  <div class="copyright">© 2026</div>
</div>

Кожны элемент структуры ў гэтым фрагменте знаходзіцца ў іменах класаў. Як толькі класы будуць адключаны, не застанэцца нічога, што магла б паведаміць апарату чы ўсабе, дзе заканчваецца навігацыя і пачынаецца стаття. Такі стыль зазвычай называюць „супам з div“, і ён значна паспелышаў, чым трэба.

Чаму HTML стаў каркасам для стылізавання

Калі фреймворкі такія як React, Vue, Angular і Svelte сталі домінуючымі у роботе з фронтэндам, а CSS, які спецыялізуецца на функціях, зробіў стылізавання практычна без зусиль, маркап тыха адмовіўся ад свайго первіснага завадзя. HTML пачаў выканаваць ролю нейтральнага каркаса, на які можна прыкрепляць класы і обрабнікі змян, а не мовы для опису контэнту. Гэта неправильнае разумеенне платформы: HTML быў створаны для выражэння значэння, а не як механізм для планавання лейауту.

Калі гэты значэнне зникае, пашкоды распространяюцца адразу ў калькі сфер. Тэхналогіі дапамогі тыратаюць свае засобы навігацыі, пошуковыя системы атрымляюць слабейшы сигнал пра тое, што важлаўна на старонцы, браузер больш не можа забезпечыць вбудованую працэздатнасць, а база коду стае больш складной для чытання для колег. Ніякі з гэтых проблем не ўказваецца на скріншоте, і самэ гэта ўсёлкі прычына таго, што яны застаюцца.

Корэні компанентаў стандартна ёсць div

Архітектура компанентаў дзеліе інтерфейс на маленькі часткі, такія як <Button/>, <Card/>, <Navbar/> і <Sidebar/>. Кожны компанент патрабуе корневы элемент для свайго JSX, і найпростейшы варыянт — это <div>. Якщо разместіць калька компанентаў аднам у іншым, створаны DOM стане дзесяцьям слоёў анонімных обгортак, хоча кожны з компанентаў сам па сабе выглядаў разумна. (Якщо вы працуеце з React, варта памятаць, што фрагмент цэлком пазбавляе неабходнасці в обгортку, калі яе не трэба.)

Класы-інструменты пераключаюць увагу на выгляд

CSS, які роўнаюцься з функцыяльнасцю, чудовы для прыгону, але ўсё вачэнне зосераджваецца на тым, як выглядае элемент. Калі маркап выглядае так: <div class="flex items-center space-x-4">, то ставіцца пытанне "як гэта распаложана?", а пытанне "што гэта?" ніколі не ставіцца. Выбор элемента становіцца другаросным моментам.

Пікселі — толькі верхній шар

Найболей небяспечным звычкам є оцэнка вашай роботы на адной паўгледзе таго, што бачыць корыстнік за дапамогою мышы на вялікам манітары. <div> з сінім фонам, заокругленымі кантамі і жысткім шрыфтом без сумневу выглядае як кантакт. Але пад вырасаванымі пікселямі знаходзится DOM, дрэва доступнасці, якое браузер адкрывае для асистуючых тэхналогій, перакладач документа і механізмы обробкі вводу браузера. Для кожнага з гэтых шароў стайлізаваны div застаецца проста div-ам.

Што на самай працо значыць семантычны HTML

„Семантычны“ адносіцца да значэння. Семантычны HTML — это практыка выбору элементаў, назвы якіх описваюць ролю ўмесцованага кантэнту, так што браузер, тэхналогіі дапамогі і людзкі чытальнікі могу розумець дакумент без неабязковасці здагадвацца.

Універсальныя контейнеры

Два элемента ўмышлена не маюць значэння:

  • <div> — універсальны блаковы групавання.
  • <span> — універсальны інлайн-групавання.

Тэкст унутры <div> можа быть заглавлём стороніцы, лінкам для навігацыі, параграфам устаўкі блогу, прыметкай у бокавой панелі або правовым застерэжэнням. Браузер не можа гэта ведаць, таму ён ставіцца да ўсіх іх аднойчы.

Элементы, якія несуць значэння

Семантычныя элементы паведамляюць, што ўмесцованы ў іх кантэнт:

  • <header> выклікае вступны контэнт для старонкі або раздзела, часта ўключаючы навігацыю.
  • <nav> пазначае блакат з основнымі лінкамі навігацыі.
  • <main> абгружае галоўны, унікальны контэнт старонкі.
  • <article> представляе самастойную статтю, такую як паст або новыя спадчыны.
  • <section> групавае контэнт адносна адзінаго тэмы.
  • <aside> містіць матэрыял, які толькі паўзапакой адносіцца да галоўнага контэнту, напрыклад бокавую панель.
  • <footer> выклікае інфармацыю для заканчэння, такую як апісанне автара, правы на копіювання або юрыдычныя лінкі.
  • <button> — это інтэрактыўны элемент керування, який выконвае певную дзеянне.

Калі браузер зустроўвае тэг <article>, ён розумее, што яго змест можа існаваць самастоятельна. Калі ж ён зустроўвае тэг <nav>, ён розумее, што гэтыя лінкі служаюць для перавалкаў па сайте. Самэ гэтае розуменне є базай для всіх наступных практык у гэтым кярыранце.

Чатыры прычыны, чаму семантычная маркэтінгавая структура вартая зусиль

Выбір правага элемента вымагае трохці часу на раздумы, а стайлізаваны div паказвае тыя ж пікселі. Прыданне такога падходу прыкметна ў чатырох аспектах.

Доступнасць: візуальныя пазнакі та вбудованыя кантролі

Багато людзей викорыстоўваюць Інтэрнет з чытальнікамі экрана, такімі як NVDA, JAWS або VoiceOver, або навігуюць выключна за дапамогою клавіатуры. Чытальнікі экрана ігноруюць ваш CSS. Яны працуюць на адной основе — дрэве доступнасці, якое браузер стварае на адной з базы вашага HTML.

За дапамою правяльнае маркэтанг, прыстрой можа адзначыць важлівыя элементы сторанкі, а тэхналогіі дапамогі можа прадстаўляць іх у вачынку, які можа выбраць корыстувальнік. Для семантычной сторанкі такі вачынак выглядае працоўна так:

Landmark Navigation Map:
- Header
- Navigation (3 links)
- Main Content
  - Heading 1: Stop Using Divs
  - Article
- Sidebar (Aside)
- Footer

Корыстувальнік можа нажаць адзін шорткаут, каб праскочыць дзесяткі лінкаў навігацыі і апынуцца безпасова ў <main>, або перайсці працоўна да статты. Тепер парабялейце тую ж сторанку, якая складаецца толькі з div-аў:

Landmark Navigation Map:
- Division
  - Division
  - Division
- Division

У практыцы ситуацыя ўсё горшая, чым паказвае гэты скетч: звычныя div-ы ўжо не являюцца важлівымі элементамі, таму вачынак проста пусты. Корыстувальніку трэба праходзіць праз элементы сторанкі по аднаму, каб знайсці тое, што ёму было трэба.

Кнапкі паказваюць тую ж проблему, але у меньшай меры. Ёсць фальшывая кнапка падле рэальной:

<!-- BAD: Fake Button -->
<div class="my-button" onclick="submitForm()">Submit</div>

<!-- GOOD: Native Button -->
<button type="submit">Submit</button>

Натыўны элемент <button> без дапамогі іншых элементаў включае:

  • Магчымасць фокусавання, таму ён прадстаўляецца ў порядку Tab.
  • Актывацыя за дапамою клавіш Enter і Space.
  • Правильная роля, тады чытальнік экрана аанунсава ўдзецо на кшталт "Submit, button", і корыстнік разумее, што гэта виконвае певную дзеянне.
  • Версія з div не можа прымець фокус, не рэагуе на клавіатуру і чытаецца як звычны текст, без жадных пазнак меркавання, што яна інтэрактыва. Ёй каротка працаваць правільна, якшо наявны tabindex="0", role="button", працэўнікі клавіш для Enter і Space, стылізацыя фокусу і обработка стану аблокавання. Гэта вельмі большы калекцыя коду, якая зазвычай не ідеальна, тады калі платформа вже мае гэта ў своім распаўзе.

    Пошуковыя системы: яснейшая карціна сторанкі

    Пашуковыя боты, такія як Googlebot, ў певным сэнсе ёсць спецыялізаваныя чытальнікі тексту, якія намагаюцца з’ясаваць, пра шта адна сторанка. Семантычная структура дае ім корыстныя падказкі:

    • <h1> паказывае галоўную тэму.
    • <main> аддзеляе унікальны контэнт ад загалоўка і наголаўка, якія павтараюцца на кожной стороне.
    • <article> адзначае окремы фрагмент редакцыйскага контэнту.
    • <nav> адкрывае структуру внутраніх супяжынанняў.

    Сторона, складзеная з неадмежаваных элементаў div, вымушвае пошуковыя роботы выважваць усё гэта толькі на адлічынку лейауту і тексту. Аднак будзьце рэалістычныя ў паўнай меры: маркап являе сабою толькі адну з багацькох прамаў, і пошуковыя системы не праказуюць правіла, якое бы стварала прыоритет для семантычных стороннік. Спрытную структуру трэба спрацавляць як адны з фактароў, якія спрабліваюць зробіць ваш контэнт лёгкім да аналізу і правильнага індексавання, а не як гарантію рангу.

    Здольнасць до адтрымання: маркап, який сам сабе дакументуе

    Код — это спосаб прынадзеўкі з іншымі разрабамі і з самім сабой пасля калькі месцаў. Рассмотрзім два варыянты адной і той жа структуры. Першы ўсё абмовіваецца на назвах класаў:

    <div class="top-bar">
      <div class="logo-box">...</div>
      <div class="menu-list">
        <div class="menu-item"><a href="#">Home</a></div>
        <div class="menu-item"><a href="#">Blog</a></div>
      </div>
    </div>
    <div class="wrapper">
      <div class="content-box">
        <div class="title-text">My Post</div>
        <div class="body-text">Hello world...</div>
      </div>
      <div class="right-bar">
        <div class="widget">...</div>
      </div>
    </div>
    <div class="bottom-bar">
      <div class="legal">© 2026</div>
    </div>
    

    Другі выражае тую ж структуру за дапамогою сэмантычных элементаў:

    <header>
      <div class="logo">...</div>
      <nav>
        <ul>
          <li><a href="#">Home</a></li>
          <li><a href="#">Blog</a></li>
        </ul>
      </nav>
    </header>
    <main>
      <article>
        <h1>My Post</h1>
        <p>Hello world...</p>
      </article>
      <aside>
        <div class="widget">...</div>
      </aside>
    </main>
    <footer>
      <small>© 2026</small>
    </footer>
    

    У першым варыянце трэба чытаць кожную назву класа і перадумваць яе мэту. Якшто хтось працінуў або неправяльна назваў клас, структура ператвараецца на мур ідэнтычных кантэйнараў. У другім варыянце форма сторанкі ўсёвядомна: дзе яна пачынаецца (<header>), дзе знаходзіцца основны кантэнт (<main>), што ўзмаўлівае (<aside>) і дзе яна заканчваецца (<footer>). Заўважыце, што навігацыя таксама стала справжнім спісам, што дазволяе прыстроям для чытання экрана аб’являць, сколькі элементаў ён мае.

    Маркап, який сам описваецца, зменшае псіхічную навантажэння пад час адзінакоўвання і зямлівае рызык злама чаго-небудзь, калі змянюецца макет.

    Прыдатнасць і вбудована працэздатнасць прыгледчыка

    Двыяктары прыгледчыкаў, такія як Chromium, Gecko і WebKit, налаштаваны для стандартных элементаў, якія вядуць з сабой стандартныя стылі, обробку запускаючыхся задач і кераванне станам, якія ўжо реалізаваны. Контроллеры формы ўсё бол яскравы прыклад. <input type="email"> і <input type="date"> даюць корыстнікам на мобайльных прыстроях адпаведную клавіатуру на экране або встроены выбірач дат, а <details> забезпечвае працюючы элемент для адкрывання інфармацыі, усё гэта без выкарыстоўвання JavaScript-кода трэціх сторон.

    Кожны раз, калі вы перзбудаваеце выпадаючы список або кнопку на базе div і скрыптав, вы надаеце дапаможны код праз сеть, збільшаеце розмер пакета, спрацоўваеце больш ресурсаў CPU і акумулятара прыстрою, а таксама ствараеце ўтолькі новы компонент, які тепер трэба падтрымваць і теставаць. Чырпнуць адносна болейшую інфармацыю пра гэту ідею можна у шасці власных функцыях HTML, якія заменяюць популярныя бібліятэкі JavaScript для інтэрфейсу.

    Рашэнне сложных семантычных выбораў

    Знанне спісу элементаў — гэта простая частка. Асалодзівае плутанне выступае з калькамі элементаў, якія здаюцца взаімназаменнымі.

    article або section

    Эта ўпытка являецца найчэйшаю прычынай суперакцый між разрабамі. Корыстны тэст: чы можна выявіць гэты контент з сторанкі, перакласты яго на іншы сайт, і ён будзе заставаць сэнс? Якщо так, то викорыстаць <article>. Якщо ён заставаць сэнс толькі в сваём ныявным контексте, то викорыстаць <section>.

    Хорашы варыянты для <article>:

    • Пасткаючы на блогу або новына.
    • Адзін коментар зь імёнам пользователя.
    • Картка продукту ў сітцы магазіна.
    • Автонамны віджэт, напрыклад, панель з інформацыяй пра пагоду.

    Кожны з гэтых элементаў можна распрасаваць, уключыць у стрім або вбудаваць ў іншы ресурс без супакоўваючай сторанкі.

    Хорашы варыянты для <section>:

    • Раздзіл «Пра нас» на галоўнай сторанцы.
    • Раздзіл у цифровай кнізе.
    • Раздзіл з характэрыстыкамі на старанцы падхоўду.
    • Група атестацый.

    <section> агрупавае контэнт пад адной тэмай, таму яго практычна завжоды трэба пачынаць з загаловка ад <h2> да <h6>. Якщо вы не можете запрацаваць разумны загаловак, то гэта, верагодна, не ўзел секцыі, і тады <div> можа стаць правильным выборам.

    Этыя два элементы павольна включаюць адзін у другі. Артыкул можна разбіць на секцыі, кожная з якіх мае свой загаловак:

    <!-- Proper Nesting Example -->
    <main>
      <!-- Main article describing a topic -->
      <article>
        <h1>Understanding Semantic HTML</h1>
        <p>Introductory paragraph...</p>
    
        <!-- Sections dividing the article into sub-topics -->
        <section>
          <h2>Why Accessibility Matters</h2>
          <p>Content about accessibility...</p>
        </section>
    
        <section>
          <h2>SEO Benefits</h2>
          <p>Content about SEO...</p>
        </section>
      </article>
    </main>
    

    Спялунка чы ручка

    Плутанне спялунк і ручакаў ёсць аднам з найчастэйшых бягоў у доступнасці. Правіла простыя:

    • Ўжывайце <a> з рэальным href, калі ўсуненне актывацыі змেнюе URL або пераводзіць корыстніка на іншую стороніцу чы месца.
    • Ўжывайце <button>, калі ўсуненне актывацыі выканае якісь дзеяння на текущай стороніцы: адправляе даны, ачынае модальне вікно, переключае меню чы іншым спосабам змেняе стан.

    Оба відэлы памылак ўжываны часта, як і способы ўсунення ўсіх з іх:

    <!-- WRONG: A link styled like a button that triggers JavaScript -->
    <a href="#" onclick="openModal()">Open Modal</a>
    
    <!-- WRONG: A button that navigates to a new webpage -->
    <button onclick="window.location.href='/about'">About Us</button>
    
    <!-- RIGHT -->
    <button type="button" onclick="openModal()">Open Modal</button>
    <a href="/about">About Us</a>
    

    Разлік мае значэнне, таму што прыстроі для чытання экрана анунцююць ролю элемента. „Link“ створывае адчуць, што месца будзе зменена; „button“ натоўпляе, што тут ўсё-такі ўжыўсяяе якое-небудзь дзеянне. Памылка у выборе ролі наражае на спалучэнне гэтых адчуццёў. Існуюць таксама практычныя наследкі: лінк з href="#" можа перавести стораніцу на пачатак і не можа быць актываўаны клавішай прасунку, а кнопка для навігацыі не можа быць ачынена ў новай карточцы чы тоўстым скопіюваннем ўсіяго ўжыванага адресу.

    Стварэнне здравага паведамлення заглаваў

    Заглавы ўтвараюць зместовую схему вашай стораніцы, і як тэхналогіі дапамогі, так і прыстроі для аналізу веб-стораніц павязаны з імі. Карыстувальнікі прыстроёў для чытання экрана часта навігуюць толькі за дапамогою заглаваў. Калька правіл дапамагае заставіць такую схему корыстной:

    • Для галоўнай тэмы старонкі, напрыклад для загавора статты або назвы панелі керування, выкорыстаюце аднаго <h1>. Спецыфікацыя HTML не забараняе якраз наявнасць калькі такіх элементаў, але вжытак аднаго заглавняка высокага рангу є шырока распрацаванай практыкой і дае наіяснейшыя вёскі структуры.
    • Не прыпускайце рангіў. Пераход з <h2> адразу да <h4> з-за бажанняя меньшага размеру тексту — это рашэнне пра стыль, замаскаванае як частка структуры; замест таго выкорыстаюце CSS для змены размеру шрыфта.
    • Структуруйце элементы логічна: пад загаворам <h1> находзяцца галоўныя раздзелы з <h2>, кожны з якіх мае своія падраздзелы з <h3>, пасля чаго следуе наступны <h2>.

    Таксама зважайце, што элемент <header> і элементы загалоўкаў — гэта разныя рэчы. <header> — это частка стораніцы; <h1> да <h6> — гэта загалоўкі, якія складаюць структуру.

    Калі div ўпорны інструмент

    Нічга з гэтага не значыць, што <div> забранены. У яго ёсць законныа задача: абгортваць контэнт выключна для макетавання або стылювання, калі няма сэмантичнага значэння. Центрыраванне чаго-небудзь за дапамой flexbox, стварэнне прыемаў у сеткі, нанесення градіентнага фона або падключэнне анімазіі CSS — усе гэта ўпорныя прычыны для вжывання <div> (або <span> для інлайн-контэнту).

    У наступным кардзе значамыя часткі выкарыстаны сэмантичныя элементы, а едзін div існуе толькі для розмішчэння двух кантактных пунктаў па бокі:

    <!-- PERFECTLY VALID USE OF A DIV -->
    <article>
      <h1>Card Title</h1>
      <p>Card description goes here...</p>
    
      <!-- This div exists purely to align two buttons side-by-side with Flexbox -->
      <div class="button-group flex gap-4 mt-4">
        <button type="button">Save</button>
        <button type="button">Cancel</button>
      </div>
    </article>
    

    Элементы <article>, <h1>, <p> і <button> апісваюць змест; <div> ўсёлякія толькі слой макета. Усе правілы можна сказаць ў адной фразе: для значэння викорыстоўваюць семантычныя элементы, а для макета — div-ы. (У рэальнай сторанцы, дзе такі карточкі знаходзіцца ўнутрь большага дакумента, яго заголовак зазвычай будзе <h2> або <h3>, ўсупрацаваныя па структуре сторанцы.)

    Рефактораванне карточкі пастаў блогу, шаг за шагам

    Разглянем кампонент карточкі, які ўжо існуе практычна на кожным сайцы з контентам: адпраўка, пазначкі, заголовак, автар і дата, адлінк і два спосабы дзеяння. Ось версія з div-амі:

    <div class="card">
      <div class="card-image">
        <img src="tech.jpg" alt="Technology background" />
        <div class="badge">Article</div>
      </div>
      <div class="card-content">
        <div class="post-title" onclick="goToPost()">10 Tips for Better Code</div>
        <div class="post-author">By Jane Doe</div>
        <div class="post-date">August 12, 2026</div>
        <div class="post-excerpt">
          Learn how to write cleaner, more maintainable frontend code today...
        </div>
        <div class="card-footer">
          <div class="share-btn" onclick="sharePost()">Share</div>
          <div class="read-more" onclick="goToPost()">Read More</div>
        </div>
      </div>
    </div>
    

    Проблемы лёгкая пераказаць, як толькі пачнеш іх шукать:

    • Зовнішній обгортак — это <div>, хоць карточка ўсе ж самостойны элемент контэнту, для чаго якраз і створаны <article>.
    • Загалоўка — это клікабельны div, таму корыстнікі, які пользуюцца клавіатурой, не можаюць да яе дасягнуць, а прыстроі для чытання экрана не ведаюць, чы гэта загалоўка, чы лінк.
    • Автар і дата размешчаны ў стандартных контейнерах, якія не маюць значэння, чытальнае для апарата.
    • Кнопкі „Падзеліцца“ і „Прачытаць больш“ — это фальшывыя кнопкі, якія ствараюць проблемы з клавіатурой і адповеднымі паведамленнямі, як было описана ранейш.

    Тепер перапісаная версія:

    <article class="card">
      <figure class="card-image">
        <img src="tech.jpg" alt="Abstract technology grid pattern" />
        <span class="badge">Article</span>
      </figure>
    
      <div class="card-content">
        <h2>
          <a href="/posts/10-tips-for-better-code">10 Tips for Better Code</a>
        </h2>
    
        <p class="meta-info">
          Written by <span class="author">Jane Doe</span> on
          <time datetime="2026-08-12">August 12, 2026</time>
        </p>
    
        <p class="post-excerpt">
          Learn how to write cleaner, more maintainable frontend code today...
        </p>
    
        <footer class="card-footer">
          <button type="button" onclick="sharePost()" aria-label="Share this article">
            Share
          </button>
          <a href="/posts/10-tips-for-better-code" class="btn-primary">
            Read More
          </a>
        </footer>
      </div>
    </article>
    

    Што зменілася і чаму це дапамагае:

    • Обгортак <article> паведамляе апараты дапамогі і прачытачы контэнту, што карточка ўсе ж самастойны элемент.
  • Зображэнне і яго атрыбуты выкладзеныць у <figure>, а тэкст alt тепер описвае зображэнне, узамест таго каб ўсё проста пазначыць.
  • Загалоўкі ёсць справжніямі <h2>, якія маюць справжніяе звязанне, таму яны паказваюцца ў структуре загалоўкаў, можна да яных дасягнуць за дапамогою клавішы Tab, і вони паказваюць месца прызначэння для скрапероў.
  • Дата паказваецца за дапамогою <time datetime="2026-08-12">, што дае скраперам, інструментам для перакладу і інтеграціям з календарамі чыстае, машынным спосабам чытальнае значэнне, незалежна ад таго, як сформатаваны візуальны текст.
  • Кнопка „Падазначыць“ ёсць <button>, таму што яна дзейнічыць на текущай сторонцы, а кнопка „Прачытаць больш“ — <a>, таму што яна адкрывае іншую сторонку.
  • aria-label на канцэле для аднаработкі дае корыстніках скрын-рыдараў больш мяркавасці пра тое, што будзе аднарана. Залейце видны тэкст унутрь атрыбута, як гэта здарыцца тут („Share“ ўскладневае фразу „Share this article“), каб корыстнікі, якія керуюць працэю за дапамою голасу, таксама моглі яго актывацыяў, сказавшы тое, што бачаюць.
  • Адна деталізацыя, якую варта рассмотрыць: карточка тепер мае два лінкі на адной і той жа URL. Дзеяныя каманды залучаюць толькі лінк з заглавам, або робяць усю карточку клікабельной за дапамою гэтага ўсего лінка, каб корыстнікі клавіатуры і скрын-рыдараў не падыходзілі да таго ж адреснага сайту два разы.

    Звычкі, якія падтрымваюць сэмантычнасць вашага маркапінгу

    Вам не трэба перавучвацца на развіццю вебу, каб пісаць лепшы HTML. Калькі стандартных пераглядоў дапамагаюць выявіць большасць проблем.

    Адрабатайте аўтаматызаваную перапрацоўку

    Расшырэннія для прыгледчыкаў, такія як axe DevTools чы WAVE, якія доступны для Chrome і Firefox, скануюць сторонічку за калькуны секундаў і выявляюць проблемы, такія як некоректныя атрыбуты ARIA, відсутнае пазначэнне типаў кнопак, спачатковы порядак загалоў і інтэрактывныя элементы без належных семантычных характэрасцей. Автаматызаваныя інструменты фіксуюць толькі частку важлівага, таму спрыймайце чысты атлас як пачатковую точку, а не як доказ доступнасці.

    Паспрабуйце сторонічку без CSS

    Выключыце всі стылі, будзь то через інструменты разработчыка чы расшырэнне, якое выключае CSS, і паглядзіце, што застаёцца. Чы ён яшчэ залишаецца чытаемым дакументам? Чы можаце вы розразліць загалоўкі ад параграфаў і знайсці навігацыю? Якшто рэзультатам ёст тэкст без чытаемай структуры, значыць структура залежыць ад CSS для свайго значэння. Добра структураваны дакумент застаецца аранжаваным нават без жадных стыліў.

    Закінчыце вжываць мыш

    Спробуйце запускать вашае прыграма толькі з викорытанням клавіш Tab, Shift + Tab, Enter, Space і стрэлкавых клавіш, а таксама пераканайцеся:

    • Чы можна дасягнуць кожнага інтэрактыўнага элемента.
    • Чы вы завжды можете бачыць, які элемент знаходзіцца ў фокусе.
    • Чы формы, выпадаючыя меню і модалкі працуюць.

    Калі вы застрялі з элементам div, які ігнаруе клавішы Enter чы Space, заменіце яго на <button>. Часта гэта адна з найшырэйшых мераў для павышэння доступнасці.

    З’ясавайце, што ўместаеся ў элементе, перш чым пісаць div

    Перш чым стварыць новы контейнер, зупініцеся і запытайце ся, што на самае праўда ўместаецца ў яму:

    • Для навігацыі выкарыстоўваецца <nav>.
    • Для боковай панелі — <aside>.
    • Для клікабельнага элемента — <button>.
    • Для незалежнай карткі чы паста — <article>.
  • Асалевы кантэнт сторонкі выкалекуе <main>.
  • Толькі кантэйнер для макета, які сам па сабе не мае значэння, выкалекуе <div>.
  • То ж самае паслужыць і ўнутрь компанентоў: корэневы элемент React-компанента ёсць часткая канечнага дакумента, таму яго таксама трэба выбіраць з адной жа аўтарытэтнасцю. Чым больш дакладная інфармацыя пра тое, якія разліки межу JSX і справжнім HTML, паглядзіце JSX — гэта не HTML: справжнія компрэсіі застосавання маркапаў для компанентоў.

    Галоўныя выводы

    • Атрыбуты, якія адобразжаюцца на пікселях, — гэта толькі адна складовая; дрэва доступнасці, інструменты для аналізу веб-сайтаў і працэсары браузера чытуюць вашы элементы, а не стылі.
    • Абсалютныя элементы, такія як <button>, <a>, <input> і <details>, забезпечваюць фокус, падтрымку клавіатуры, адказы на ролі і правілы працы на мобільных прыстроях, якія вельмі складна адрабатаваць вручную.
    • Для контэнту, які існуе самастоятельна, выкарыстоўваюць <article>, а для тэматычнай часткі большога цэлага — <section>; кожнай секцыі трэба даць загалоўку.
    • Спяльнікі веду на іншыя стороніцы, а кнопкі выканаюць дзеяння; іх сумешчанне плутае корыстувачоў і нарабляе проблем у роботе браузера.
    • Залічвайце чыстую структуру загалоўкаў без пропускаў у рангах, і для керавання размерамі выкарыстоўвайце CSS у замену рангам загалоўкаў.
    • Div-ы застаюцца правым выборам для чыстага макетавання. Фрэймворкі зменяюцца кожныя калькі гадоў, але гэтыя основы застаюцца стабільнымі ўжо дзесяткі гадоў; маркап, який чыста выказвае значэнне элементаў, прыносіць практычную корысть як корыстувачам, так і пошуковым системам, а таксама вашай командзе.