Learning HTML - Basic Content Accessibility

#Introduction

Web accessibility means making sure content can be used by everyone — including users who don't use a mouse, who are blind, or who have motor impairments. Episode 10 covers basic content accessibility: the principles governing it, the most-used ARIA attributes, keyboard focus, and how to test it.

ARIA (Accessible Rich Internet Applications) is a collection of attributes that supplements HTML's meaning for assistive tools. But the key rule: use native HTML elements first — ARIA is only a supplement, not a replacement for correct structure.

#Web Accessibility Principles

#The Four Pillars of WCAG

The WCAG (Web Content Accessibility Guidelines) standard summarizes accessibility in four principles:

• Perceivable: content must be perceivable, for example through alternative text.
• Operable: content must be operable, including via keyboard.
• Understandable: content and navigation must be easy to understand.
• Robust: content must work with a wide range of assistive tools and devices.

These four pillars are the lens for judging every markup decision. A real example: an image without alt violates the perceivable principle; a menu that can only be clicked with a mouse violates operable.

#Basic ARIA Attributes

#Naming Elements

aria-label gives an accessible name to an element that has no visible text:

aria-label for an icon

<button type="button" aria-label="Tutup dialog">x</button>

The button containing the letter x above has no meaningful text. aria-label="Tutup dialog" tells screen readers what the button does — while the visual display stays clean.

#Linking to Visible Content

aria-labelledby connects an element to text already on the page:

aria-labelledby

<h2 id="judul-panel">Pengaturan</h2>
<div aria-labelledby="judul-panel">...</div>

Use aria-labelledby when there's already visible text that can serve as the name. Use aria-label when there's no visible text at all.

#Announcing Updates

aria-live tells screen readers that content changes without focus moving:

aria-live for notifications

<p id="notifikasi" aria-live="polite"></p>

With aria-live="polite", text changes inside it are announced after the user's current activity finishes. This pattern is mandatory for notifications that appear from JavaScript — for example "Data berhasil disimpan".

#Keyboard Focus

#Why Focus Matters

Some users don't use a mouse — they move between elements with the Tab key. The browser provides built-in focus for links, buttons, and form controls. Never remove this ability.

#tabindex

tabindex controls focus order and ability:

• tabindex="0": the element can be focused, following document order.
• tabindex="-1": the element can be focused via JavaScript, but not by tab order.
• Positive values: force an order — best avoided because they break the natural flow.

tabindex for a non-interactive element

<div tabindex="0" role="button" aria-label="Buka menu">Menu</div>

The example above makes a div focusable and read as a button. Ideally, use a real button — but if you must use a div, these attributes are mandatory.

#Contrast and Targets

Beyond focus, make sure text contrast against its background is high enough (minimum 4.5 to 1 for regular text) and click targets aren't too small. Touch target rules will come up again in episode 21.

#Testing Accessibility

#Screen Readers and Automated Tools

The most basic testing step: navigate with the keyboard alone. Open the page, press Tab repeatedly, and make sure the focus order makes sense and there's a visible focus indicator.

For advanced testing:

• Use a screen reader like NVDA (Windows) or VoiceOver (macOS).
• Run Lighthouse or axe DevTools for automated audits.
• Make sure the page passes without critical errors in the audit results.

npx lighthouse http://localhost:8080 --only-categories=accessibility

The command npx lighthouse http://localhost:8080 --only-categories=accessibility produces an accessibility score report complete with a list of fixes. Run it after the local server is up.

#Common Mistakes and Solutions

#ARIA as a Semantics Substitute

ARIA attributes don't fix wrong structure. A button written as a div still isn't a button for all behaviors. Fix the element first, then add ARIA only if truly needed.

#aria-hidden on Content That Needs Reading

aria-hidden="true" hides an element from assistive tools. Don't place it on elements containing focus or important content — users lose access to that element.

#Closing

Episode 10 gives you the accessibility basics: the four WCAG principles, the most-used ARIA attributes, keyboard focus management, and how to test with automated tools and screen readers.

Key takeaways:

• Four WCAG principles: perceivable, operable, understandable, robust.
• Use native HTML elements first; ARIA is only a supplement.
• aria-label for elements without text; aria-labelledby for existing text.
• aria-live for announcing content updates.
• Don't remove keyboard focus; use tabindex carefully.

In the next episode, episode 11, we'll cover additional media elements — audio, video, picture, and source — to embed rich media with correct format fallbacks.