Subjects and lessons to explore.

Law

Web Development · Foundations

Accessibility

9 min read 5 practice questions
8 key termsSourcesReport an error
Want it in plain words first? Jump to Eli explains — the same idea, no jargon.
On this page 9 sections
  1. In 30 seconds
  2. Why this matters
  3. The college version
  4. Eli explains
  5. Worked example
  6. Key takeaway
  7. Quick check
  8. Study tools
  9. Sources & references

In 30 seconds

is the practice of designing and developing websites so people with disabilities can perceive, understand, navigate, interact with, and contribute to the web. It is not a screen-reader-only feature or a final checklist. Useful starting points are meaningful HTML, names for controls, text alternatives that match an image's purpose, and every essential action working from a keyboard.

Why this matters

A web page can look polished and still block someone from reading a chart, locating a button, or completing a form. Accessibility gives developers a way to treat those barriers as design and engineering problems early in a project. It also builds transferable habits: using native HTML accurately, testing the actual interaction path, and checking whether a page communicates its structure and controls beyond its visual layout.

The college version

Accessibility is an interaction requirement

Web accessibility means designing and developing websites, tools, and technologies so people with disabilities can use them. In practical terms, people should be able to perceive information, understand it, navigate it, operate controls, and contribute where the site permits contribution. This scope includes more than a particular assistive technology. A person might use a screen reader, a keyboard, voice input, browser zoom, captions, or a combination of tools and settings. A useful engineering question is therefore not “Does this page work with my mouse?” but “Can a person obtain the information and complete the task with the input and output methods available to them?”

Accessibility should be built while decisions are inexpensive: when choosing an element, naming a control, arranging a form, or defining a component's behavior. It is not a promise that one attribute makes a page accessible, nor is it a substitute for testing. Browsers, authoring tools, assistive technologies, and the site itself all participate. This lesson stays at that practical foundation rather than treating accessibility as a memorized list of conformance criteria.

Structure becomes an accessibility representation

A browser first turns HTML into a DOM tree. It also builds an from that information and exposes that representation through platform accessibility APIs for assistive technologies such as screen readers. Objects in that tree can carry a , , description, state, and information about available actions. Consequently, the visible appearance of a control is not the whole interface. A blue rectangle with a click handler may look like a button, yet its role, name, keyboard behavior, and state can be absent or misleading in the accessibility representation.

Native HTML is a strong starting point because native elements bring defined semantics and ordinary interaction behavior. A real button is preferable to constructing a button-shaped generic element and then trying to recreate its behavior. Likewise, a properly associated form label gives a control a clear label; semantic headings and landmarks give the page a usable structure. ARIA can supply semantics where a native element cannot express a necessary pattern, but it does not repair bad structure automatically. Choose the native element that matches the job first, then add only the information the particular interface needs.

Keyboard operation and focus are observable behavior

A keyboard check is a direct way to inspect an interaction path. Starting in the browser chrome, use Tab and Shift+Tab to move through interactive items. Each needed link, form control, button, and media control should be reachable; after an item receives focus, the user must be able to move away again. The sequence should make sense in the reading order, and the focused item should be visibly identifiable. A may be an outline, border, or other clear treatment. Removing it because it changes the visual design trades away orientation for keyboard users.

Keyboard access is also about outcomes, not merely landing on elements. If a menu, disclosure, dialog, or custom control exposes an action by mouse hover or click, its required action needs a keyboard-operable path too. Test the actual task: open the control, make a choice, submit, and return to the next expected place. Do not confuse keyboard testing with a complete accessibility evaluation; it is a focused, valuable check that can reveal missing focus, illogical order, mouse-only behavior, and a .

Alternatives communicate purpose, not pixels

Text alternatives for images depend on context and purpose. For an informative photograph or diagram, the alternative should convey the information the image contributes in that location. For an image used as the only visible content of a control, the alternative communicates the action or destination, not a literal inventory of its pixels. A purely decorative image, or an image whose content is already repeated as nearby text, can use an empty alt attribute so it is not announced as extra noise. Complex visuals such as charts need their information available elsewhere in the page; a short alt text alone cannot carry an entire data explanation.

This is why “write alt text for every image” is an incomplete rule. The author must decide what information or function a person would lose if the image disappeared. The same file can need different alternatives in different placements. In a course card, a campus photo might be decorative; on a page about a building's accessibility entrance, that same photo may be informative. The goal is equivalent access to the meaningful content or function, written in original, concise language that matches the surrounding task.

Eli, the EliExplains learning guide

Eli explains

The same idea, in plain words

Explain it like I’m 10

A website is not only the picture on a screen. People may use keys instead of a mouse, hear the page through a screen reader, or need words in place of a picture. Accessibility means planning the site so those routes work too. A clear button, label, heading, and image description help a browser explain what is on the page and let a person operate it.

Picture it like this

Think of a museum with more than one way to learn: signs in clear language, an audio guide, ramps, and staff directions all point to the same exhibits. A web page needs more than its painted walls. Its HTML structure, names, keyboard route, and alternatives are the other ways visitors find and use the same information.

Where the picture stops working

A web page is not a building, and accessibility is not achieved by adding a fixed set of physical features. Different content and interactions need context-specific decisions and testing with real tasks.

Worked example

A student builds a course-search card with a magnifying-glass icon, a search field, and a “Search” control. They use a native <button> with the text “Search” rather than a clickable div, and associate a visible <label> with the input. The magnifying-glass image is decorative because the adjacent button text already names the action, so it uses alt="". The student then tabs through the card: focus reaches the field and button in a sensible order, the focused item is visible, Enter activates the button, and Shift+Tab moves backward. If the icon alone were the button content, its text alternative would instead name the action, such as “Search courses.”

Key takeaway

Accessibility is part of building the interface, not a visual afterthought. Use meaningful native structure, communicate each control and image's purpose, and test essential tasks with a keyboard and visible focus.

Quick check

3 questions here, of 5 in this lesson’s practice set. Answers stay hidden until you check.

Question 1 of 3foundational

Which statement best defines web accessibility?

Choose an answer, then check it.
Question 2 of 3intermediate

A person tabs into a custom menu but cannot move focus to anything outside it. What problem has the test found?

Choose an answer, then check it.
Question 3 of 3intermediate

What does the browser use to expose accessibility-related information to platform accessibility APIs?

Choose an answer, then check it.
Practice all 5

Keep learning

Ready to build on this? Continue to the next lesson.

Practice this lesson
Study tools & related lessonsYou’ll learn to · Common mistakes · Easily confused · Key vocabulary · Related

You’ll learn to

  • Define web accessibility.
  • Explain how the accessibility tree relates to the DOM.
  • Apply keyboard and visible-focus checks to a simple interaction.
  • Distinguish informative, functional, and decorative image alternatives.
  • Evaluate why native HTML is a useful accessibility starting point.

Common mistakes

  • Treating a mouse test as the complete interaction test.

    Tab through the actual task and verify visible focus, order, activation, and the ability to move away.

  • Replacing native controls with generic clickable elements.

    Use the native element matching the job unless a justified custom pattern is necessary.

  • Writing the same image alternative regardless of context.

    Describe the information or function the image contributes in that placement; use empty alt for decoration.

  • Hiding focus to preserve a visual style.

    Provide a clear visible focus treatment instead of removing the user's orientation cue.

Easily confused

DOM tree vs. accessibility tree

The DOM represents markup and content; the accessibility tree exposes accessibility-related information derived from it to platform accessibility APIs.

informative image vs. decorative image

An informative image contributes content that needs an equivalent alternative; a decorative image does not and can use empty alt text.

native button vs. button-shaped generic element

A native button supplies defined semantics and ordinary control behavior; a generic element needs additional work and is easier to implement incorrectly.

Key vocabulary

web accessibility
Design and development that enable people with disabilities to use web content and tools.
accessibility tree
A browser-produced representation of accessibility-related information derived from the DOM for platform accessibility APIs.
accessible name
The label by which assistive technology can identify an interface object.
role
The kind of interface object an element represents, such as a button or navigation region.
keyboard focus
The current target for keyboard input on a page.
focus indicator
A visible treatment that shows which element currently has keyboard focus.
keyboard trap
A situation in which keyboard focus enters an interface component but cannot be moved out normally.
text alternative
Text that provides an image's relevant information or function in its context.

Sources & references

  1. Introduction to Web Accessibility — W3C Web Accessibility Initiative
  2. Easy Checks – A First Review of Web Accessibility — W3C Web Accessibility Initiative
  3. Accessibility tree — MDN Web Docs
  4. An alt Decision Tree (Images Tutorial) — W3C Web Accessibility Initiative (WAI)

EliExplains lessons are original prose written from the open, credible references above. See Copyright & Licensing.

Researched 2026-08-20

Educational content only. It is not medical, legal or professional advice. Found an error? Tell us.