Tab order ng keyboard: subukan at ayusin ito nang walang developer

Ang sirang tab order ay hindi lang magulo tingnan, maaari nitong pigilan ang isang tao na magamit ang site mo. Dapat ilipat ng pagpindot sa Tab ang focus sa bawat interactive na elemento sa makatwirang pagkakasunod-sunod, at anumang hindi naaabot ng focus ay hindi talaga maa-activate ng user na keyboard lang ang gamit. Maaari mong subukan ang sarili mong site sa loob ng mga 60 segundo gamit ang Tab key lang.

Mga pangunahing punto

• Ang tab order ay ang pagkakasunod-sunod ng paggalaw ng focus kapag may pumipindot sa Tab key, na walang mouse. Ang Shift+Tab ay gumagalaw pabalik sa parehong pagkakasunod-sunod.
• Hindi ito alalahaning pang-iilan lang. Ang sinumang hindi maasahang makagamit ng mouse, dahil sa panginginig ng kamay, paralisis, repetitive strain injury, o pansamantalang pinsala, ay lubos na umaasa sa keyboard navigation para magamit ang website.
• May dalawang magkaibang paraan ng pagkabigo, at mas masama nang malaki ang isa. Nakakainis ang nakalilitong order. Ang interactive na elementong hindi kailanman naaabot ng Tab ay matigas na harang, hindi reklamo sa usability.
• Maaari mo itong subukan mismo, ngayon din, nang walang developer at walang espesyal na tool. I-click ang address bar, tapos pindutin nang paulit-ulit ang Tab at tingnan kung saan pumupunta ang focus.
• Awtomatikong inaayos ng axe-core ang isang partikular na bersyon ng problemang ito nang may mataas na kumpiyansa, ang positibong halaga ng tabindex, at ifa-flag ang ilang kaugnay na isyung talagang nangangailangan ng pasya ng tao, dahil ang paghusga kung "may katuturan" ang order ay nangangailangan ng pag-unawa sa pahina.

Ano talaga ang tab order

Inililipat ng pagpindot sa Tab ang keyboard focus sa susunod na interactive na elemento sa pahina, link, button, field ng form, anumang maaaring galawin ng user. Ang Shift+Tab ay gumagalaw pabalik. Bilang default, sinusunod ng pagkakasunod-sunod na iyon ang pagkakasunod-sunod ng paglitaw ng mga elemento sa HTML sa ilalim, na karaniwang kapareho ng pagkakasunod-sunod na makikita ng taong nakakakita habang bumabasa mula itaas hanggang ibaba.

Ang nakikitang focus indicator, karaniwang outline sa paligid ng kasalukuyang may focus, ay nagpapakita sa user ng keyboard kung nasaan siya. Kung wala ito, o kung walang makatwirang order sa likod nito, hindi na magagamit ang keyboard navigation, kahit walang mukhang sira sa gumagamit ng mouse.

Bakit ito mahalaga

Ang taong hindi nakagagamit ng mouse, dahil sa panginginig, paralisis, nawawalang kamay o braso, Parkinson's, ALS, o bagay na kasing-karaniwan ng nabaling pulso, ay kailangan pa ring mag-check out, magpuno ng form, at mag-navigate ng menu. Ang keyboard ang paraan niya sa lahat ng iyon. Ang mga gumagamit ng screen reader ay nagta-tab din sa mga interactive na elemento bilang isa sa ilang paraan ng paggalaw sa pahina, kaya nagsasapawan ito sa, pero hindi kapareho ng, accessibility para sa screen reader.

Totoong problema sa usability ang nakalilitong tab order, ang focus na tumatalon mula sa link sa header diretso sa button sa footer, nilalaktawan ang buong gitna ng pahina, ay pinipilit ang tao na manghula at bumalik. Pero napag-nanavigahan pa rin ito, sa huli. Iba sa uri, hindi sa antas, ang interactive na elementong hindi kailanman naaabot ng focus: ang button na literal na hindi maaabot ng user ng keyboard gamit ang Tab ay button na hindi niya mapipindot, tuldok, na walang magagamit na paraan mula sa keyboard lang.

Ang 60-segundong Tab key test

1. Mag-click muna sa neutral na lugar, tulad ng address bar ng browser, para magsimula sa kilalang posisyon sa halip na saan man bumagsak ang focus.
2. Pindutin nang paulit-ulit ang Tab at panoorin ang nakikitang outline na gumagalaw sa pahina. Gumagalaw ba ito sa pagkakasunod-sunod na halos tumutugma sa makikita mo kapag nag-scan ka sa pahina sa paningin, itaas pababa, kaliwa pakanan?
3. Subukang i-activate ang napuntahan mo. Pindutin ang Enter sa link o button, Space para mag-toggle ng checkbox. Gumagana ba talaga ito mula sa keyboard, at hindi lang tumatanggap ng focus sa paningin?
4. Tiyaking may turn ang bawat interactive na bagay. Mga item ng menu, field ng form, button, custom widget tulad ng date picker o accordion, lahat ay dapat maabot sa ganitong paraan.
5. Magbantay sa bitag. Kung ang Tab o Shift+Tab ay maipit at hindi ka ilipat palayo sa isang elemento, mas malubhang isyu iyon kaysa order lang, isang keyboard trap sa ilalim ng WCAG 2.1.2, at kailangang ayusin agad.
6. Tiyaking nakikita mo talaga kung nasaan ka. Kung gumagalaw ang focus pero walang nakikitang outline na nagpapakita kung saan, hiwalay pero kaugnay na pagkabigo iyon, ang WCAG 2.4.7 Focus Visible, na sulit tandaan kahit hindi ito ang pangunahing paksa rito.

Ano ang hitsura ng sirang tab order

Mga positibong halaga ng tabindex. Ang developer na sumusubok magpilit ng partikular na order ay minsang nagdaragdag ng tahasang numero: tabindex="1", tabindex="2", at iba pa. Ino-override nito ang natural na order ng dokumento, at nasisira ito sa sandaling magdagdag ang sinuman ng bagong elemento sa hinaharap nang hindi nire-renumber ang lahat ng nasa paligid nito.

<!-- Bumabagsak: pinilit na pagnunumero na lalayo sa tamang pagkakasunod -->
<input tabindex="3" name="email">
<input tabindex="1" name="name">
<input tabindex="2" name="phone">

<!-- Pumapasa: walang override, natural na order ng dokumento ang bahala -->
<input name="name">
<input name="phone">
<input name="email">

Visual na pag-aayos muli na hindi humahawak sa order sa ilalim. Ang mga CSS property tulad ng order sa flexbox o grid layout ay maaaring magbago ng nakikita ng user na nakakakita nang hindi binabago ang aktuwal na pagkakasunod-sunod ng HTML na sinusunod ng Tab. Resulta: dalawang magkaibang order ang nararanasan ng gumagamit ng mouse at ng gumagamit ng keyboard sa iisang pahina, at walang mukhang mali sa screen.

Custom na elementong walang tunay na suporta sa keyboard. Ang <div> na ginawang mukhang button, na may click handler, pero walang tabindex="0" at walang keyboard event handling, ay ganap na di-nakikita ng Tab navigation. Hindi ito nakalilitong order, ito ay kabuuang harang, dahil hindi ito kailanman maaabot ng user ng keyboard.

Nakatagong elementong nakakatanggap pa rin ng focus. Ang nakatiklop na mobile menu na ang mga link ay teknikal na naroroon pa rin sa pahina, o elementong dapat sana'y di-nakikita pero tumatanggap pa rin ng focus, ay lumilikha ng "multo" na tab stop: nakikitang gumagalaw ang focus, pero papunta sa bagay na hindi nakikita ng user.

Ano ang nahuhuli ng axe-core, at ano ang ikaw lang ang makahuhusga

Rule	Ano ang sinusuri	Daan ng ayos
tabindex	May positibong halaga ng tabindex ang isang elemento	Palaging awtomatikong inaayos, isinusulat muli bilang 0
aria-hidden-focus	Nakatagong elemento na nakakatanggap pa rin ng focus nang isa-isa	Awtomatikong inaayos, best-effort, makitid: inaayos ang mismong elemento, hindi ang nakatagong lalagyan na naglalaman lang ng focusable na elemento sa loob nito
focus-order-semantics	Kung tumutugma ang aktuwal na tab order sa visual at lohikal na order ng pahina	Manwal
scrollable-region-focusable	Rehiyong naso-scroll na hindi maabot o magalaw gamit ang keyboard	Manwal

Pare-pareho ang padron dito sa bawat ibang kategorya ng ayos na sulit pag-usapan nang tapat. Hindi malabo ang positibong halaga ng tabindex, walang lehitimong dahilan para rito, kaya isinusulat itong muli ng axe-core nang buong kumpiyansa tuwing makikita. Ang kung may lohikal na katuturan ba ang tab order ng buong pahina ay pasya tungkol sa kung ano ang sinusubukang ipahayag ng partikular na pahinang iyon, at nangangailangan ito ng taong makakatingin sa pahina at makapagpapasya.

Ano ang inaayos ng Axeazy dito

Awtomatikong inaayos ng Axeazy ang mga positibong halaga ng tabindex nang buong kumpiyansa, isinusulat muli bilang 0 para ang natural na order ng browser ang pumalit. Awtomatiko rin nitong inaayos ang mas makitid na kaso ng nakatago-pero-focusable, isang indibidwal na elementong hindi dapat maabot kapag nakatago. Parehong totoo at gumaganang awtomatikong ayos ang dalawa.

Ang lahat ng tungkol sa kung may tunay bang katuturan ang isang order, o kung may tunay na suporta sa keyboard ang isang custom widget, ay nangangailangan ng developer na aktuwal na tumingin sa pahina. Hindi iyon puwang na itinatago ng Axeazy, iyon ang parehong tapat na linyang iginuguhit ng bawat kategorya ng ayos sa listahang ito sa huli: kayang isulat muli ng script ang attribute nang may kumpiyansa, hindi nito kayang pagpasyahan kung anong pagkakasunod-sunod dapat basahin nang lohikal ang nilalaman ng pahina.

Nakadepende rin sa platform mo ang daan ng ayos. Sa React, Next.js, o iba pang codebase na konektado sa GitHub, dumarating sa iyo ang ayos sa tabindex bilang totoong pull request. Sa Shopify, nahahanap pa rin ito ng scan, pero walang awtomatikong pagbabago sa code, nagiging item ito ng gabay na checklist. Sa WordPress, hindi kasama ang partikular na kategoryang ito sa tatlong instant na ayos ng libreng plugin (skip navigation, language attribute, fallback ng alt text), kaya wala rin itong awtomatikong daan sa WordPress sa kasalukuyan. Tingnan ang buong paghahati ng mga kategorya ng ayos.

Mga madalas itanong

Ano ang pagkakaiba ng sirang tab order at keyboard trap?

Ang tab order ay ang pagkakasunod-sunod ng paggalaw ng focus habang pumipindot ng Tab ang isang tao. Mas malubha ang keyboard trap: naiipit ang focus sa isang elemento, at hindi ito mailipat palayo ng Tab o Shift+Tab. Problema sa usability ang nakalilitong order. Matigas na harang ang bitag, at sarili nitong kinakailangan sa WCAG, ang 2.1.2 No Keyboard Trap.

Naaayos ba ng pagdaragdag ng tabindex="0" ang lahat?

Ginagawa nitong maaabot ng Tab ang elementong hindi sana focusable, tulad ng ginawang mukhang button na <div>, at inilalagay ito sa natural na order ng dokumento ng pahina. Hindi nito ginagarantiya na lohikal ang order na iyon. Ang kinalalagyan ng elemento sa aktuwal na HTML ang nagtatakda pa rin kung kailan ito tatanggap ng focus.

Bakit gagamit ang developer ng positibong tabindex kung nagdudulot ito ng problema?

Karaniwan ay mabuting-loob na pagtatangkang magpilit ng partikular na order nang hindi inaayos muli ang aktuwal na HTML. Madalas mas kaunting trabaho ito sa maikling panahon at mas maraming trabaho sa huli, dahil kailangan ng manwal na renumbering ang bawat bagong elementong idadagdag para hindi na naman masira ang pagkakasunod-sunod.

Maaari ko bang subukan ang tab order sa parehong paraan sa telepono ko?

Hindi talaga. Ang Tab-key navigation ay interaksyon ng hardware keyboard, kaya ang partikular na test na ito ay nakabatay sa desktop browser. Mahalaga pa rin ang keyboard accessibility sa mobile, lalo na para sa mga gumagamit ng external na keyboard o switch-access device sa mobile browser, pero iba ang paraan ng pagsubok nito.

Ginagawa bang ganap na magagamit ng pag-aayos sa tab order lang ang keyboard navigation ko?

Walang iisang ayos na sumasaklaw sa lahat ng maaaring makasalubong ng user na keyboard lang ang gamit. Ang tab order ay isang totoo at makabuluhang piraso; maaari pa ring may ibang isyu ang pahina, tulad ng nawawalang focus indicator o tunay na keyboard trap, na nangangailangan ng sariling hiwalay na pagsusuri.

Mga sanggunian

• W3C: Pag-unawa sa SC 2.1.1, Keyboard
• W3C: Pag-unawa sa SC 2.4.3, Focus Order
• W3C: Pag-unawa sa SC 2.1.2, No Keyboard Trap