Skip to main content
Accessibility Field Guide

Accessibility Skill Tree

A personal learning map for accessibility skills, built around practical branches of understanding rather than a pass/fail score.

Sticky notes arranged on a whiteboard.
Photo: Sticky Notes on Whiteboard via Pexels — https://www.pexels.com/photo/sticky-notes-on-whiteboard-7580842/
View full screen Download image

Accessibility knowledge is uneven for everyone.

That is not a flaw. That is the work.

Someone might be strong with plain language, forms, and requirements, but newer to ARIA or screen reader behavior. Someone else might understand keyboard testing and components, but feel less confident about content, charts, or media alternatives.

That does not mean either person is “bad at accessibility.”

It means accessibility is broad, and people build different branches at different times.

The Accessibility Skill Tree is a way to see that more clearly.

A personal map, not a report card

This is not meant to grade people.

It is not a certification.

It is not a performance measure.

It is a personal map for noticing:

  • what you have heard of
  • what you can recognize
  • what you can apply in your own work
  • what you can explain to someone else
  • what still needs support from a specialist or more experienced teammate

Knowing where your knowledge stops is part of accessibility literacy.

It helps you ask better questions earlier.

Breadth and depth

There are two useful ways to look at the map.

Breadth

Breadth is about which areas of accessibility you have encountered.

Examples:

  • keyboard access
  • forms and errors
  • alt text
  • contrast
  • headings
  • ARIA
  • tables
  • dynamic content
  • media
  • assistive technology

Depth

Depth is about how far you can go in each area.

Can you define it? Spot common issues? Apply a basic check? Explain it? Reason through edge cases?

A person can have broad awareness with shallow depth.

A person can also have deep skill in one branch and blind spots in another.

The skill tree makes that normal instead of hidden.

Depth scale

Use this scale as a self-check:

  1. Not familiar yet — I have not really encountered this area.
  2. Aware — I know what this concept means.
  3. Can recognize — I can spot common issues or warning signs.
  4. Can apply — I can use a basic check, habit, or pattern in my role.
  5. Can explain — I can help someone else understand the common pattern.
  6. Can evaluate — I can reason through nuanced cases and know when to escalate.

The goal is not to get every branch to level 5.

The goal is to understand your current shape and keep building.

Skill branches

Accessibility mindset and lifecycle

Accessibility as early project work, not a final surprise.

This branch is about recognizing where accessibility decisions happen: intake, requirements, design, build, QA, vendor selection, content, and review readiness.

Try this next:

Requirements and acceptance criteria

The work of making expected behavior visible before build.

This includes user flows, error states, keyboard expectations, content needs, vendor constraints, and what “done” should mean for accessibility.

Try this next:

Content clarity and language

The words that help people understand where they are, what something does, and what to do next.

This includes plain language, labels, links, instructions, page titles, headings, and language changes.

Try this next:

Structure and navigation

The shape of the page or workflow.

This includes headings, landmarks, reading order, navigation, page organization, and multiple ways to find content.

Try this next:

Keyboard and focus

Whether someone can move through and operate the interface without a mouse.

This includes keyboard access, focus order, focus visibility, keyboard traps, shortcuts, and content that appears on hover or focus.

Try this next:

Forms and errors

Whether people know what information is needed, what went wrong, and how to recover.

This includes labels, required fields, instructions, validation, error identification, suggestions, and prevention for important submissions.

Try this next:

Components, semantics, and ARIA

Whether controls communicate what they are, what state they are in, and how they behave.

This includes native HTML, accessible names, name/role/value, ARIA restraint, and custom widgets.

Try this next:

Data-heavy interfaces

Whether tables, dashboards, filters, search results, and status indicators make sense beyond visual layout.

This includes relationships, headers, sorting, filtering, pagination, and data context.

Try this next:

Dynamic content and state changes

Whether users know when something changed and what to do next.

This includes modals, alerts, toasts, loading states, status messages, timing, and focus management after changes.

Try this next:

Images, media, and alternatives

Whether non-text content has the right kind of alternative.

This includes decorative images, informative images, icons, charts, captions, transcripts, audio description, and media alternatives.

Try this next:

Visual conditions and responsive behavior

Whether content remains readable and usable in different visual and layout conditions.

This includes contrast, color-only meaning, zoom, reflow, text spacing, orientation, and flashing content.

Try this next:

Assistive technology literacy

Understanding enough about assistive technology to avoid guessing blindly.

This includes screen reader basics, accessible names, reading order, forms behavior, and why visual behavior and programmatic behavior can differ.

Try this next:

How to use the skill tree

Pick one branch that connects to your current work.

Then ask:

  • Have I heard of this?
  • Can I recognize common issues?
  • Can I apply a basic check in my role?
  • Can I explain the issue to someone else?
  • Would I know when to ask for help?

That is enough to start.

You do not need to unlock the whole tree before you can reduce accessibility risk.

How this connects to the Field Guide

Every field note, checklist, example, WCAG criterion, and campaign post can connect back to one or more skill branches.

For example:

  • A note about keyboard testing connects to Keyboard and focus.
  • A note about labels connects to Forms and errors and Content clarity and language.
  • A note about modals connects to Dynamic content and state changes, Keyboard and focus, and Components, semantics, and ARIA.

This helps the collection become more than a list of pages.

It becomes a map of how accessibility understanding grows.

Start small

Pick one branch.

Read one field note.

Try one check.

Ask one better question earlier.

That is how the tree grows.

What to do next