Gabay ng developer sa mga ARIA label na talagang nakakatulong

Ang mga ARIA label ay para sa mga pangalan, hindi sa paghingi ng paumanhin

Kapaki-pakinabang ang ARIA, ngunit madalas itong ginagamit bilang pantapal sa hindi malinaw na HTML. Doon nagkakaproblema ang mga team.

Ang pinakakaraniwang halimbawa ay aria-label. Mukha itong harmless: magdagdag ng string, pumasa sa linter, tapos na. Ngunit ang accessible name ay hindi dekorasyon. Ito ang pangalang inilalantad ng maraming assistive technology sa mga user kapag nagna-navigate sila sa mga button, link, form field, heading, landmark, at control.

Kung malabo, nadodoble, luma, o iba sa nakikitang label ang pangalang iyon, mas humihirap gamitin ang interface. Minsan mas malala pa: maaaring i-override ng aria-label ang mas magandang text na naroon na sa DOM.

Ang layunin ay hindi magdagdag ng mas maraming ARIA. Ang layunin ay gawing malinaw ang name, role, state, at purpose ng bawat elemento ng interface.

Ang accessible name, sa simpleng paliwanag

Karamihan sa mga interactive element ay may accessible name. Ginagamit ng mga screen reader ang pangalang iyon para ipahayag kung ano ang element.

Halimbawa:

<button>Save changes</button>

Maaaring ipahayag ng screen reader ang gaya ng: “Save changes, button.” Ang role ay mula sa native na button element. Ang name ay mula sa text sa loob nito.

Iyon ang ideal na kaso: magkatugma ang nakikitang text at accessible name.

Nagiging kapaki-pakinabang ang mga ARIA labeling attribute kapag hindi nagbibigay ng kumpletong pangalan ang nakikitang interface, o kapag kailangang manggaling ang pangalan sa ibang element. Ang mga pangunahing attribute ay:

• aria-label: nagbibigay ng string nang direkta sa element.
• aria-labelledby: tumuturo sa isa o higit pang element na ang text ang nagiging pangalan.
• aria-describedby: tumuturo sa sumusuportang description text, hindi sa pangunahing pangalan.

Magkakaugnay ang tatlong iyon, ngunit hindi sila magkakapalit.

Unang tuntunin: unahin ang native HTML at mga nakikitang label

Kung maaari kang maglagay ng nakikitang text sa control, gawin muna iyon.

Mas maganda ito:

<button>Delete invoice</button>

Kaysa rito:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Valid ang pangalawang pattern para sa icon-only button. Ngunit kung kaya ng design ang nakikitang text, nakakatulong ang nakikitang text sa lahat: mga user ng screen reader, mga user ng speech recognition, mga taong may cognitive load, mga mabilis mag-scan, at mga gumagamit ng translation tools.

Paulit-ulit itong tema sa accessibility work. Mas maraming problema ang nalulutas ng native HTML at nakikitang affordance kaysa nakatagong metadata. Nalalapat din ang parehong prinsipyo sa button semantics sa mas malawak na paraan; kung ina-audit ng team ninyo ang mga UI control, magandang kasama sa gabay na ito ang aming checklist para sa accessible web buttons.

Kailan ang aria-label ang tamang tool

Gamitin ang aria-label kapag kailangan ng isang element ng accessible name at walang angkop na nakikitang text na maaaring i-reference.

Ang klasikong kaso ay icon-only button:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Makatuwiran ito. Ipinahihiwatig ng nakikitang icon ang search, ngunit ang SVG path mismo ay hindi nagbibigay ng maaasahang pangalan. Ang aria-label ang nagbibigay nito.

Kabilang sa iba pang magagandang kaso ang:

• Close button na kinakatawan lamang ng “X”.
• Navigation landmark na nangangailangan ng mas tiyak na pangalan, gaya ng aria-label="Product".
• Paulit-ulit na control kung saan hindi bahagi ng button text ang nakikitang context.

Halimbawa:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Pareho silang navigation landmark, ngunit tumutulong ang kanilang mga label na maiba sila ng mga user kapag lumilipat gamit ang landmarks.

Kailan maling tool ang aria-label

Huwag magdagdag ng aria-label dahil lang sinabi ng test na kailangan ng label ang isang element. Ayusin muna ang markup.

Hindi maganda:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Mas mabuti:

<button>Submit</button>

Lumilikha ng hindi kinakailangang trabaho ang unang halimbawa. Kailangan mo ngayong muling buuin ang keyboard behavior, disabled states, form behavior, at mga inaasahang mayroon na ang native buttons.

Iwasan din ang paggamit ng aria-label para palitan ang pangalan ng nakikitang text sa paraang nagbabago ng kahulugan.

<button aria-label="Delete invoice">Remove</button>

Mukha itong maliit na bagay, ngunit maaaring malito ang mga user na umaasa sa speech input. Kung ang nakikitang button ay nagsasabing “Remove,” ngunit ang accessible name nito ay “Delete invoice,” maaaring hindi makuha ng user na nagsasabing “click Remove” ang inaasahang resulta. Umiiral ang requirement ng WCAG na “label in name” para mismo sa dahilang ito: sa pangkalahatan, dapat nakapaloob ang nakikitang text sa accessible name.

Mas magandang bersyon:

<button aria-label="Remove invoice">Remove</button>

Madalas mas maganda pa rin:

<button>Remove invoice</button>

Gamitin ang aria-labelledby kapag mayroon nang nakikitang text

Kung naroon na sa page ang label text, karaniwang mas mabuti ang aria-labelledby kaysa aria-label.

Halimbawa:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Ang accessible name ng section ay nagmumula na ngayon sa nakikitang heading. Naiiwasan mong magdoble ng mga string, na nagpapababa ng translation mistakes at lumang labels.

Lalo itong kapaki-pakinabang para sa form groups:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

Sa maraming kaso, sapat na ang native na legend nang walang ARIA. Ang punto ay dapat manguna ang mga nakikitang label. Dapat ikonekta ng ARIA ang umiiral na kahulugan, hindi lumikha ng pangalawang pribadong bersyon nito.

Gamitin ang aria-describedby para sa help text, hindi para sa pangalan

Ang description ay hindi label.

Isaalang-alang ang field na ito:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Ang accessible name ay “Password.” Ang description ay “Use at least 12 characters.” Maaaring ipahayag ng screen reader ang dalawa, ngunit magkaiba ang layunin nila.

Huwag gawin ito:

<input type="password" aria-label="Use at least 12 characters">

Pinapangalanan niyan ang field ayon sa instruction, hindi ayon sa konsepto. Ang user na nagna-navigate sa form ay gustong malaman muna kung ano ang field, pagkatapos kung anong constraints ang nalalapat.

Mahalaga rin ang pagkakaibang ito sa error states:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Nananatiling stable ang label. Ang error message ay nagiging sumusuportang context.

Kailangan ng mga paulit-ulit na control ng natatanging pangalan

Ang mga list at card ang mga lugar kung saan madalas nagiging kailangan ang ARIA labels.

Hindi maganda:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Maaaring marinig ng screen reader user na nagna-navigate gamit ang mga button ang “Delete, button” nang tatlong beses na walang context.

Maganda:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Lehitimong paggamit ito ng aria-label: nananatiling maikli ang nakikitang text, habang kasama sa accessible name ang object.

Ngunit gamitin ang pattern na ito nang maingat. Kung nakikita sa malapit ang pangalan ng object, maaaring mas maintainable ang aria-labelledby:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Nagiging “Delete Q4 revenue” ang accessible name. Iniiwasan nito ang pagdoble ng report title sa isang attribute.

Huwag lagyan ng label ang lahat

Hindi lahat ng element ay nangangailangan ng ARIA label.

Karaniwang hindi kailangan ng static text. Hindi rin kailangan ng decorative icons. Hindi kailangan ng containers, maliban kung mayroon silang makabuluhang landmark o widget role. Maaaring gawing maingay at mas mahirap i-navigate ang page kapag sobra ang paglalabel.

Para sa mga image, gamitin ang image-specific model: kailangan ng meaningful images ng kapaki-pakinabang na alt; kailangan ng decorative images ng empty alt="". Huwag gamitin ang ARIA labels bilang kapalit ng magandang image text. Kung pinaghahalo ng team ninyo ang mga konseptong iyon, balikan ang pragmatic image alt text at paghiwalayin ang image alternatives mula sa control names.

Karaniwang pagkakamali ang pagbibigay ng aria-label sa bawat SVG. Kung nasa loob ng button ang SVG at mayroon nang name ang button, karaniwang dapat itago ang icon mula sa assistive tech:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Kung hindi, maaaring makarinig ang user ng redundant o kakaibang announcements depende sa kombinasyon ng browser at assistive technology.

Suriin ang computed name, hindi lang ang code

Madalas nakakalusot ang accessibility bugs sa code review dahil mukhang kapani-paniwala ang markup.

Maaaring ipakita ng modern browser developer tools ang computed accessibility tree. Sa Chrome, Edge, Firefox, at Safari, i-inspect ang element at hanapin ang accessibility information gaya ng role, name, at description. Tatlong bagay ang sinusuri mo:

1. Ang role ba ay ayon sa inaasahan mo?
2. Malinaw at tiyak ba ang accessible name?
3. Nakakatulong ba ang description nang hindi pinapalitan ang name?

Pagkatapos, subukan ang ilang flow gamit ang tunay na screen reader. Hindi mo kailangang maging full-time assistive technology expert para mahuli ang basics. Sa macOS, built in ang VoiceOver. Sa Windows, malawakang ginagamit at libre ang NVDA. Sa mobile, mag-test gamit ang VoiceOver sa iOS at TalkBack sa Android kung may kaugnayan.

Kapaki-pakinabang ang automated tools, ngunit hindi nila maaasahang masasabi kung sapat ang context ng “Open,” “Read more,” o “Delete.” Ituring ang automation bilang lambat, hindi hukom. Katulad ito ng performance auditing: maaaring ituro ng report ang kahina-hinalang areas, ngunit kailangan mo pa ring bigyang-kahulugan ang impact. Nalalapat din dito ang parehong kalmadong lapit na inirerekomenda namin para sa pagbabasa ng Lighthouse report nang hindi nagpapanic.

Praktikal na review checklist

Bago mag-ship ng ARIA labels, itanong:

• Maaari bang native HTML ito sa halip?
• May nakikitang text ba na dapat gamitin bilang label?
• Kung may nakikitang text, kasama ba ito sa accessible name?
• Natatangi ba ang mga paulit-ulit na control kapag na-navigate sa labas ng visual context?
• Nakakonekta ba ang help text gamit ang aria-describedby, at hindi ipinipilit sa label?
• Nakatago ba ang decorative icons mula sa assistive technology?
• May nakapagsuri na ba ng computed accessibility name sa browser dev tools?
• May nagawa na bang kahit isang pass gamit ang tunay na screen reader para sa critical flow?

Nahuhuli ng checklist na ito ang karamihan sa label problems bago sila maging user problems.

Ang tahimik na disiplina ng mahusay na ARIA

Bihirang dramatic ang mahusay na ARIA work. Kadalasan, pagpipigil ito.

Gumamit ng tunay na buttons. Gumamit ng tunay na labels. Panatilihing magkatugma ang visible at accessible names. Magdagdag lang ng aria-label kapag walang mas magandang visible source. Gamitin ang aria-labelledby kapag nasa page na ang tamang text. Gamitin ang aria-describedby para sa sumusuportang instructions at errors.

Maraming ibinibigay nang libre ang web platform sa mga developer kapag ginagamit natin ito nang direkta. Nariyan ang ARIA para sa mga puwang. Ang kasanayan ay ang malaman kung kailan talagang may puwang.