011: Accessibility Basics

Learning outcomes

By the end of this lesson, you can explain accessibility as support for diverse ways of perceiving and operating content; audit semantics, labels, alternatives, grouping, and keyboard focus; choose links versus buttons; and apply the “native HTML first” rule before considering ARIA.

Prerequisites and retrieval

Open the validated form and portfolio. Retrieve five existing accessibility decisions: page language, heading hierarchy, meaningful link text, context-sensitive alt, and label/control association. Accessibility is not a separate feature added today; today makes those decisions systematic.

Terminology

Accessibility: Making websites usable by as many people as possible, including people with disabilities. — Source: MDN: Accessibility overview
Assistive technology (AT): Hardware/software people use to interact with content — screen readers, magnifiers, switch devices. — Source: W3C WAI: Easy Checks
Keyboard operable: All functionality available without a pointer (WCAG principle: operable). — Source: WCAG 2.2
Focus: The currently targeted element receiving keyboard interaction. — Source: WCAG 2.2
Focus order: The sequence in which focus moves among interactive elements, normally following source order. — Source: WCAG 2.2
Accessible name: The programmatic name derived from label, alt, or aria-label that AT announces. — Source: ARIA APG: Read Me First
Role: The kind of interface object an element represents (button, navigation, heading). — Source: WHATWG: WAI-ARIA
State/value: Current conditions communicated alongside role, such as checked, expanded, disabled. — Source: WHATWG: WAI-ARIA
ARIA: A W3C vocabulary of roles, states, and properties supplementing native accessibility semantics. — Source: WHATWG: WAI-ARIA
WCAG: The Web Content Accessibility Guidelines — testable success criteria organized under POUR principles. — Source: W3C WCAG 2.2
Semantics: "The meaning of a piece of content, for example the meaning of a heading or a paragraph." — Source: MDN: Semantics
Label: "A text label associated with a form control by using the label element with for/id or by wrapping." — Source: WHATWG: Label element
Landmark: "A region of a page intended for navigation, such as banner, navigation, main, complementary, contentinfo." — Source: W3C WAI: Page Structure — Landmarks
Focus visible: "The focus indicator is visible." — Source: WCAG 2.2: Focus Appearance

Mental model: one interface, many ways to use it

Do not imagine a single “average user.” Someone may read visually, hear a screen reader, zoom text, navigate by headings, use only a keyboard, issue voice commands based on visible labels, or combine methods. Semantic HTML creates a shared structure that browsers can expose in different forms.

Accessibility is not “for screen readers only,” nor can one automated score prove it. WCAG 2.2 AA is a useful project baseline, but conformance still combines automated and human evaluation and does not cover every individual need.

Native semantics first

Compare:

html
<div onclick="submitForm()">Send message</div>

with:

html
<button type="submit">Send message</button>

The div has no button role, normal focus, Enter/Space activation, disabled behavior, form submission behavior, or dependable accessible name semantics as a control. Adding role="button" only makes a promise; JavaScript must still reproduce all expected interaction. The native button already provides it.

Similarly:

use <a href="project.html">View project</a> to navigate;
use <button type="button">Show filters</button> for an in-page action;
use <h2> for a section heading, not <div class="heading">;
use label, fieldset, and legend for forms;
use table, th, and scope for tabular relationships.

ARIA can supplement gaps, but it does not change behavior or appearance. Avoid duplicate roles and labels. Incorrect ARIA can hide or misrepresent native semantics. The first rule of ARIA is to use a native element with built-in semantics and behavior whenever possible.

Interactive elements need an accessible name: the text assistive technologies use to identify the control. Native HTML usually provides the best mechanism:

a button's text names the button;
a label names its associated form control;
an image's alt text names the image when the image conveys content;
link text names the destination or purpose.

Do not replace visible labels with placeholders. Placeholders disappear as users type and are not a reliable labeling mechanism.

Keyboard focus should normally follow source order. Avoid positive tabindex values such as tabindex="5", which create a separate focus order that quickly becomes difficult to maintain. Native links, buttons, and controls are focusable already.

For pages with repeated navigation before the main content, a skip link lets keyboard users bypass it:

html
<a href="#main-content">Skip to main content</a>
...
<main id="main-content">
  ...
</main>

The link can be visually styled later so it becomes prominent when focused. The important HTML requirement is that its target exists and the source order makes sense.

Be careful with hidden content. The hidden attribute removes content from normal rendering and from the accessibility tree in typical use. Do not hide information that a user still needs to complete the task.

Guided example: keyboard audit the course form

Use the 010 contact form and a checklist. Put the mouse aside.

Reload, then press Tab. Focus should reach interactive controls in a logical source order.
Confirm focus is visibly apparent using browser defaults. HTML alone should not remove it; later CSS must preserve a strong indicator.
Activate labels by clicking them for this one pointer check: each focuses/toggles the intended control.
Use arrow keys within a radio group and Space on checkboxes.
Open and change the select with keyboard conventions for the platform.
Type invalid values and submit with Enter or the button. Check that focus/feedback identifies the problem.
Zoom to 200%. Content and controls must remain understandable; final reflow testing belongs with CSS, but HTML source order should already be meaningful.
Inspect the accessibility tree. Each control should have an appropriate name, role, and state.

Use this repaired excerpt:

html
<form action="/contact" method="post">
  <p>
    <label for="email">Email address (required)</label>
    <input type="email" id="email" name="email" autocomplete="email" required>
  </p>
  <fieldset>
    <legend>Reply preference</legend>
    <input type="radio" id="reply-email" name="reply" value="email" required>
    <label for="reply-email">Email reply</label>
    <input type="radio" id="reply-none" name="reply" value="none">
    <label for="reply-none">No reply needed</label>
  </fieldset>
  <button type="submit">Send message</button>
</form>

No ARIA is necessary here. Visible labels and native grouping communicate names and relationships. required exposes state and behavior. ARIA should not be added merely to make markup look “more accessible.”

Images, headings, and links audit

For every image, apply the decision tree in context. Informative images need a concise equivalent; decorative/redundant images use alt=""; functional images name the destination/action; complex images need equivalent data or explanation. “All images need descriptive alt text” is a myth: all img elements generally need an alt decision, but empty alt can be the correct result.

Read only headings. The hierarchy should summarize the page without skipped levels caused by desired size. Navigate by landmarks: page header, navigation, main, and footer should be understandable without redundant roles.

Read only links. “Read weather project details” is understandable; several “Learn more” links may not be. Adjacent links to the same destination can create repetition; often combine image/title into one link where content models permit, or keep one clear text link.

Intermediate example: repair an inaccessible project card

Before:

html
<div class="card">
  <div class="big">Weather app</div>
  <img src="images/weather.webp">
  <div tabindex="0" role="button">Learn more</div>
</div>

After:

html
<article>
  <h2>Weather summary project</h2>
  <img
    src="images/weather.webp"
    alt="Forecast summary for Chennai showing cloudy conditions and 31 degrees Celsius"
    width="1440"
    height="900">
  <p>A semantic page explaining a local forecast.</p>
  <p><a href="projects/weather.html">Read the weather project details</a></p>
</article>

The operation is navigation, so use a link, not a pretend button. tabindex="0" alone would add focus but no link behavior or role. Avoid positive tabindex values; they create a separate, fragile focus order. The real heading supports navigation. The image dimensions reduce movement; alt conveys the screenshot's meaningful result.

If the screenshot information already appears fully in surrounding text, empty alt may reduce repetition. Accessibility choices depend on context, not a universal phrase length.

Advanced optional extension: restrained ARIA

Valid supplementation examples include aria-current="page" on the active navigation link and aria-describedby="password-help" to associate persistent instructions. Both preserve native role and visible text.

Do not add aria-label that contradicts visible text. Voice-control users may speak the visible words, so accessible names should contain the visible label (WCAG Label in Name). Do not hide focusable content with aria-hidden="true". Test browser/AT combinations relevant to your users before shipping advanced ARIA patterns.

Common mistakes and debugging

Accessibility equals alt text: audit perceivability, operation, understanding, and robustness.
Every image gets a detailed description: decorative/redundant images need empty alt.
tabindex="0" makes a div a button: it adds focus only.
Positive tabindex to fix order: repair source order instead.
Link styled as button confusion: semantics follow action, not appearance.
Focus removed because it looks ugly: preserve/replace with a clearly visible indicator.
Placeholder as label: use persistent associated labels.
ARIA added to native elements: remove redundant or conflicting attributes.
Automated checker treated as proof: combine tools with keyboard, zoom, structure, content, and user testing.

For an accessible-name diagnosis, inspect the control in this order: native semantics, associated visible label, computed accessible name, then keyboard behavior. A control can be focusable and still have no useful name; conversely, an aria-label can hide a visible naming mistake from sighted reviewers. In DevTools' accessibility tree, verify the name and role, then activate the control with only the keyboard. Fix the HTML relationship before adding ARIA.

Accessibility, security, and performance

Accessibility is the central guidance today. Target WCAG 2.2 AA where appropriate, but avoid claiming conformance from this basic audit. Test keyboard access, no traps, logical focus, page title/language, headings, names, labels, alternatives, errors, zoom, reflow, contrast after CSS, and captions.

Accessible authentication intersects security: allow password managers and paste, avoid cognitive-function tests as the only route, and provide alternatives. Security controls such as timeouts and CAPTCHAs can create barriers and need inclusive design. Native HTML reduces code, attack surface, and performance overhead compared with custom widgets, but this is not permission to skip security review.

Tiered exercises

Level 1: classify

Choose link or button for: About page, submit form, show more text, download résumé, and delete a draft. Explain each purpose.

Level 2: audit

Keyboard-audit the course form and record focus order, label behavior, group operation, submit behavior, and errors. Repair all HTML issues found.

Level 3: portfolio review

Inspect landmarks/headings, links, images, and accessibility tree. Remove unnecessary ARIA and write a short residual-risk statement.

Level 1: About page: link; submit: submit button; show text: button (with later scripted state); résumé URL: link, optionally with download expectations stated; delete: button because it changes state and needs confirmation design.

Level 2: a correct native form follows source order; every visible label targets one unique ID; arrow keys operate same-named radios; Space toggles checkboxes; the submit button activates by keyboard; required/type errors block ordinary submission. Fix generic div controls, missing labels, mismatched IDs, and positive tabindex.

Level 3: expected portfolio has one visible main, logical headings, named navigation if multiple, descriptive link purposes, context-based alt decisions, native controls, and only justified aria-current/aria-describedby. Residual risk: no automated or single-person audit proves WCAG conformance; CSS contrast/reflow and production browser/AT/user testing remain.

Recap and exit questions

Accessible HTML supports many interaction modes through semantics, names, relationships, and native behavior. Start native, preserve focus and source order, and use ARIA only to fill a real semantic gap.

Why does role="button" not create button behavior?
What should determine link versus button?
When is empty alt correct?
Why avoid positive tabindex?
What evidence proves that a control has both a useful accessible name and usable behavior?
Why can automated results not prove accessibility?

Try it with your own example

Put the mouse down for five minutes and audit Rina's cake-order form the way a real keyboard-only customer would experience it — you built it, so you already know where the bodies are buried, which makes this a good first audit to practice on.

Reload the page. Press Tab once. Does focus land on "Your name," in that order, before the radio group? If you reordered fields casually while testing lesson 010, check now — did the visual order and the source order drift apart?
Tab into the size fieldset. Use the arrow keys, not Tab, to move between "6-inch" and "8-inch." This is native radio-group behavior you get for free — but only if both inputs genuinely share name="size". If you copy-pasted one radio and forgot to keep the shared name, this step silently breaks and you won't notice by looking at the screen.
Submit with the name field empty and confirm focus visibly lands there, not just that a browser bubble appears somewhere off-screen.

Now try the single most revealing test in this lesson: picture Rina's actual order form with a "Learn more about allergens" link right next to a "Learn more about pickup" link. If both links say only "Learn more," a screen-reader user who pulls up a list of all links on the page hears "Learn more, Learn more" with no way to tell them apart. Rewrite both so each is understandable completely on its own, out of context — that habit costs you nothing in lesson 004's link-writing skill and pays for itself on every future site you ship.

Further reading: W3C WAI — Easy Checks is a ten-minute manual checklist you can run on Rina's finished site exactly like the one above.