Dev Tools & Workflow

Trumpas, aiškią poziciją turintis prieinamų žiniatinklio mygtukų kontrolinis sąrašas

Penkios taisyklės, kurios pagauna daugumą mygtukų prieinamumo problemų dar prieš joms pasiekiant produkciją

The Wux Webtools Team The Wux Webtools Team 7 min skaityti Pagal AI, peržiūrėta žmogaus
Technical diagram of an accessible button showing focus state and minimum touch target dimensions
Turinys
  1. Mygtukų prieinamumo patarimų problema
  2. 1. Mygtukams naudokite button elementą
  3. 2. Paspaudimo sritis turi būti bent 44×44 pikselių
  4. 3. Pateikite matomas fokusavimo būsenas, kurios nėra vien naršyklės numatytosios
  5. 4. Rašykite mygtukų etiketes, kurios turi prasmę be konteksto
  6. 5. Užtikrinkite pakankamą spalvų kontrastą
  7. Ko šis kontrolinis sąrašas neapima
  8. Kaip įtraukti tai į savo darbo eigą
  9. Šio darbo praleidimo kaina
  10. Svarbiausios išvados
  11. FAQ
  12. Šaltiniai

Mygtukų prieinamumo patarimų problema

Dauguma mygtukų prieinamumo gairių patenka į dvi stovyklas: arba tai 40 puslapių WCAG interpretacija, kurios niekas neskaito, arba miglotas pasiūlymas "padaryti mygtukus prieinamus" be įgyvendinamų veiksmų. Nei viena, nei kita nepadeda, kai ketvirtadienį išleidžiate funkciją.

Šis kontrolinis sąrašas apima penkias dažniausias mygtukų prieinamumo klaidas, kurias matome produkcijoje. Jis nepadarys jūsų WCAG ekspertu, bet pagaus problemas, kurios iš tikrųjų paveikia naudotojus.

1. Mygtukams naudokite button elementą

Jei jis veikia kaip mygtukas, tai turėtų būti <button> elementas. Ne <div> su onclick, ne <span> su role="button", ne <a> su href="#" ir preventDefault.

<button> elementas nemokamai suteikia klaviatūros navigaciją, fokusavimo valdymą ir ekrano skaitytuvų pranešimus. Kai naudojate <div>, visa tai kuriate iš naujo — ir tikrai padarysite klaidų.

Vienintelė išimtis: jei veiksmas nukreipia į naują puslapį arba pakeičia URL, naudokite <a> elementą. Nuorodos ir mygtukai semantiškai skiriasi. Ekrano skaitytuvų naudotojai naršo pagal elemento tipą, todėl jie tikisi, kad mygtukai atliks veiksmus, o nuorodos nukreips.

2. Paspaudimo sritis turi būti bent 44×44 pikselių

WCAG 2.5.5 (Level AAA) reikalauja, kad interaktyvių elementų mažiausias taikinio dydis būtų 44×44 CSS pikseliai. Tai nėra apie vizualinį dydį — tai apie paspaudžiamą sritį.

Galite turėti mažą vizualinį mygtuką su pakankamomis vidinėmis paraštėmis arba galite išplėsti paspaudimo sritį naudodami pseudo-elementą. Svarbiausia, kad naudotojui nereikėtų taikytis itin tiksliai.

Mobilieji naudotojai, žmonės su motorikos sutrikimais ir visi, kurie naudojasi įrenginiu judėdami, nepataikys į mažus taikinius. 24×24 pikselių piktogramos mygtukas gali atrodyti tvarkingai, bet tai yra naudojamumo nesėkmė.

3. Pateikite matomas fokusavimo būsenas, kurios nėra vien naršyklės numatytosios

Naršyklės numatytasis fokusavimo žiedas yra geriau nei nieko, bet jis nevienodas skirtingose naršyklėse ir dažnai nematomas tam tikruose fonuose. Jums reikia pasirinktinės fokusavimo būsenos, veikiančios jūsų dizaino sistemoje.

Geras fokusavimo indikatorius turi tris savybes:

  • Didelis kontrastas: bent 3:1 su gretimomis spalvomis
  • Matomas atitraukimas: nepaslėptas paties mygtuko rėmelio ar fono
  • Nuosekli forma: naudotojai turėtų atpažinti jį kaip fokusavimo indikatorių visoje jūsų sąsajoje

Nenaudokite outline: none nepakeisdami jo kuo nors geresniu. Ir nedarykite fokusavimo būsenų tokių subtilių, kad tik jūs galėtumėte jas įžiūrėti esant idealiam apšvietimui.

4. Rašykite mygtukų etiketes, kurios turi prasmę be konteksto

Ekrano skaitytuvų naudotojai dažnai naršo šokinėdami tarp mygtukų. Taip darydami jie girdi mygtukų etikečių sąrašą be aplinkinio konteksto.

Mygtukas, pažymėtas "Sužinoti daugiau", tokiame sąraše yra nenaudingas. Tas pats galioja "Spustelėkite čia" ar "Pateikti". Etiketė turėtų apibūdinti veiksmą: "Atsisiųsti prieinamumo kontrolinį sąrašą", "Prenumeruoti naujienas", "Ištrinti šį komentarą".

Jei jūsų dizainui reikia trumpos vizualinės etiketės, naudokite aria-label, kad pateiktumėte aprašomąją alternatyvą. Tačiau geresnis sprendimas yra rašyti etiketes, kurios tinka visiems.

Tik piktogramas turintiems mygtukams aria-label yra privalomas. Mygtukui, kuriame yra tik didinamojo stiklo piktograma, reikia aria-label="Search" arba lygiaverčio teksto. Piktograma nėra prieinama ekrano skaitytuvams.

5. Užtikrinkite pakankamą spalvų kontrastą

WCAG 2.1 reikalauja bent 4.5:1 kontrasto santykio įprastam tekstui ir 3:1 dideliam tekstui (18pt arba 14pt paryškintam). Mygtukų etiketės paprastai yra įprastas tekstas.

Šviesiai pilkas tekstas ant balto mygtuko neatitinka reikalavimų. Blyškiai mėlynas tekstas ant šviesiai mėlyno fono taip pat neatitinka. Tokie deriniai gali atrodyti rafinuotai, bet jie atskiria naudotojus su silpnu regėjimu, daltonizmu ar bet ką, kas žiūri į ekraną ryškioje saulės šviesoje.

Kontrasto tikrintuvą naudokite projektavimo metu, o ne po paleidimo. Kontrasto problemų taisymas produkcijoje brangus, nes dažnai reikalauja dizaino sistemos pakeitimų.

Jei dirbate su vaizdų apdorojimo įrankiais, kliento pusės apdorojimas gali padėti išsaugoti privatumą generuojant prieinamus vizualinius išteklius — ypač testuojant spalvų derinius ar generuojant peržiūros būsenas.

Ko šis kontrolinis sąrašas neapima

Šis sąrašas sąmoningai neišsamus. Jis neapima išjungtų būsenų semantikos, įkėlimo būsenų, klaidų tvarkymo ar sudėtingų mygtukų šablonų, tokių kaip padalyti mygtukai ar išskleidžiamųjų meniu aktyvikliai. Tiems šablonams reikia atskirų gairių.

Jis taip pat neapima platesnio klausimo, kada naudoti mygtuką, o kada kitus interaktyvius elementus. Tam reikia suprasti semantinį HTML ir prieinamumo medį — temas, kurios nusipelno atskirų straipsnių.

Tai, ką jis apima, yra lengviausiai pasiekiami patobulinimai: klaidos, pasirodančios beveik kiekvienoje kodo peržiūroje, paveikiančios daugiausia naudotojų ir lengviausiai pataisomos kūrimo metu.

Kaip įtraukti tai į savo darbo eigą

Prieinamumo kontroliniai sąrašai veikia tik tada, kai jie yra kūrimo proceso dalis, o ne pridedami po visko. Štai kaip tai pasiekti:

Dizaine: pridėkite fokusavimo būsenas ir paspaudimo sričių anotacijas prie savo dizaino failų. Nepalikite to spėlioti kūrėjams.

Kodo peržiūroje: tikrinkite, ar naudojami <button> elementai, aria-label piktogramų mygtukams ir fokusavimo būsenų CSS. Tai greitai pastebima.

Testuojant: pereikite per sąsają klaviatūra naudodami Tab. Jei negalite pasiekti mygtuko arba nematote, kur yra fokusas, to negalės ir jūsų naudotojai.

Dokumentacijoje: įtraukite mygtukų prieinamumo reikalavimus į savo komponentų biblioteką. Padarykite teisingą pasirinkimą lengvesnį už neteisingą.

Jei derinate produkcijos problemas, įrankiai HTTP headers ir redirects tikrinimui gali padėti suprasti, kaip pagalbinės technologijos interpretuoja jūsų žymėjimą — ypač šalinant fokusavimo valdymo problemas po navigacijos.

Šio darbo praleidimo kaina

Neprieinami mygtukai ne tik pažeidžia WCAG atitiktį — jie sulaužo darbo eigas. Naudotojas, negalintis spustelėti pateikimo mygtuko, negali užpildyti formos. Naudotojas, nematantis fokusavimo būsenų, negali naršyti klaviatūra. Naudotojas, negalintis atskirti mygtuko teksto nuo fono, negali perskaityti etiketės.

Tai nėra kraštutiniai atvejai. Maždaug 15% pasaulio gyventojų turi kokią nors negalią, o laikini apribojimai (sugedusi pelė, ryški saulės šviesa, kūdikio laikymas) galiausiai paveikia kiekvieną.

Gera žinia ta, kad mygtukų prieinamumas iš esmės yra išspręstų problemų rinkinys. Nereikia išrasti naujų šablonų ar laukti naršyklių palaikymo. Tereikia teisingai naudoti platformą ir testuoti savo darbą.

Svarbiausios išvados

  • Mygtukams naudokite <button> elementus, o navigacijai — <a> elementus; semantinis skirtumas svarbus pagalbinėms technologijoms
  • Užtikrinkite, kad paspaudimo sritys būtų bent 44×44 CSS pikselių, kad jos tiktų žmonėms su motorikos sutrikimais ir mobiliesiems naudotojams
  • Pateikite matomas, didelio kontrasto fokusavimo būsenas, veikiančias visoje jūsų dizaino sistemoje
  • Rašykite mygtukų etiketes, kurios turi prasmę skaitomos atskirai, ir naudokite aria-label tik piktogramas turintiems mygtukams
  • Kontrastą tikrinkite projektavimo metu, o ne po paleidimo, kad išvengtumėte brangių pataisymų

FAQ

Q: Ar galiu naudoti role="button" ant <div>, jei pridėsiu klaviatūros apdorojimo funkcijas?

A: Galite, bet neturėtumėte. Turėsite rankiniu būdu apdoroti Enter, Space, fokusavimo valdymą ir išjungtas būsenas — ir neišvengiamai ką nors praleisite. <button> elementas visa tai teisingai atlieka pagal numatytuosius nustatymus. Naudokite jį.

Q: O kaip su mygtukais, kurie perjungia būseną, pavyzdžiui, play/pause mygtukas?

A: Naudokite aria-pressed="true" arba aria-pressed="false", kad nurodytumėte dabartinę būseną. Mygtuko etiketė taip pat turėtų atspindėti veiksmą, kuris įvyks spustelėjus ("Pause", kai grojama, "Play", kai pristabdyta), o ne dabartinę būseną. Ekrano skaitytuvų naudotojai turi žinoti, ką mygtukas padarys, o ne kokioje būsenoje yra sistema.

Q: Ar išjungti mygtukai turi atitikti kontrasto reikalavimus?

A: WCAG 2.1 išimtimi atleidžia išjungtus valdiklius nuo kontrasto reikalavimų (1.4.3), bet tai vertinama prieštaringai. Išjungtus mygtukus su prastu kontrastu sunku pastebėti visiems. Jei rodysite išjungtą mygtuką, padarykite jį įskaitomą. Dar geriau — paslėpkite jį arba paaiškinkite, kodėl jis išjungtas.

Q: Kaip testuoti mygtukų prieinamumą be ekrano skaitytuvo?

A: Naudokite klaviatūrą. Pereikite per sąsają Tab klavišu ir patikrinkite, ar galite pasiekti kiekvieną mygtuką, matyti, kur yra fokusas, ir aktyvuoti mygtukus Enter arba Space. Tai pagauna daugumą problemų. Gilesniam testavimui naudokite prieinamumo inspektorių Chrome arba Firefox DevTools, kad patikrintumėte apskaičiuotą rolę ir etiketę.

Q: Kuo skiriasi aria-label ir aria-labelledby?

A: aria-label tiesiogiai pateikia teksto eilutę. aria-labelledby nurodo kito elemento ID, kurio teksto turinys tampa etikete. Naudokite aria-labelledby, kai etiketės tekstas jau yra kitur DOM. Naudokite aria-label, kai reikia pateikti etiketę, kuri ekrane nematoma.

Šaltiniai

Checklist infographic summarizing five button accessibility checks: semantic element, 44 by 44 target, visible focus, descriptive labels, and sufficient contrast
InfographicThe 5-button accessibility checklist — A one-screen checklist for the five button mistakes most likely to ship
Four-step workflow showing accessibility checks in design, code review, testing, and documentation for web buttons
InfographicBuild button accessibility into the workflow — The checklist works best when design, review, testing, and docs all reinforce it
Comparison chart of button accessibility minimums: 44 by 44 target size, 4.5 to 1 normal text contrast, 3 to 1 large text contrast, and 3 to 1 focus indicator contrast
InfographicMinimum button specs at a glance — The most useful button accessibility numbers fit into one compact reference card
Apie autorių
The Wux Webtools Team

Paskutinį kartą atnaujinta:

Tęsti skaitymą