Can we count your visit?

Our analytics service records the pages you view, so we can see which ones are useful. It saves a random ID in your browser, and we never use it for advertising. Read our privacy policy.

Accessibility training for your team.

We train the people who design, write, build, test, and support your product, so new work arrives with fewer barriers. Each session is built from your own product.

Training does not test your product, so it does not replace testing.

Talk to us about training

Why train your team.

Fixes remove the barriers already on your site. New ones arrive with everyday work: a page published without headings, a photo without a description, or a form whose errors don’t say what went wrong.

Training helps your team stop adding them. Each barrier your team doesn’t add is one that nobody has to find, fix, and check again.

Training in settlement agreements.

In June 2024, the U.S. Department of Justice reached settlement agreements with four Texas counties over their election websites. Each county agreed to make its website accessible and to train the people who manage it.

Smith County’s agreement requires at least an hour of training a year for everyone who manages the website’s content, contractors included.

Source: U.S. Department of Justice, Smith County caseAgreement (PDF): Smith County settlement agreement

Our dated record shows who took part in each session. It is evidence of your effort, not legal protection.

This is general information, not legal advice. Which laws apply depends on where you operate and who you serve.

How we build the training.

We build every session from your product and your team, starting with what we find.

  1. We start from what we find on your site.

    The barriers we find most often on your site set the topics, so we check your main tasks first. Tools don’t find every barrier, so we also ask your team what they’re unsure about.

  2. We build the examples from your product.

    Every example comes from your own pages, components, and documents, so the lessons apply to the next thing your team ships.

  3. Each role gets its own session.

    A designer, a developer, and a support agent make different decisions. Each session covers the ones that role makes.

Topics for each role.

Every session follows WCAG 2.2 Level AA, the international standard for accessible websites and apps. Open a role to see its topics.

DesignersThe choices that are hard to change once a design is built.
  • Color and contrast that keep text readable
  • Focus styles that show where you are on the page
  • Buttons and links large enough to tap
  • Layouts that still work when text is enlarged or zoomed
  • Error states that don’t rely on color alone
DevelopersThe code that decides whether a keyboard or a screen reader can use the page.
  • Keyboard access and focus order
  • Native HTML elements before custom controls
  • Labels and error messages for forms
  • Names for buttons, links, and icons
  • Checking your own work with a keyboard and a screen reader
Content writers and editorsThe words, images, video, and documents you publish.
  • Headings and page structure
  • Image descriptions (alt text)
  • Link text that names where it goes
  • Plain language
  • Captions and transcripts for video
  • Documents and PDFs
QA and testersFinding barriers before a release instead of after it.
  • Testing with a keyboard
  • Testing with a screen reader
  • Checking zoom, enlarged text, and small screens
  • What automated tools can’t find
  • Writing a barrier report a developer can act on
Product managersPlanning accessibility into the work instead of fixing it later.
  • What WCAG 2.2 AA asks of your product
  • Accessibility in acceptance criteria
  • Deciding which barriers to fix first
  • Checking accessibility before each release
Support teamsHelping a customer who meets a barrier, and getting it fixed.
  • Answering a barrier report
  • Asking for the details that help fix it, such as the page and the assistive technology
  • Offering another way to finish the task in the meantime
  • Passing the report to the team that can fix it

Search engines and AI assistants read the same headings, link text, and image descriptions that screen readers use.

Read how accessibility helps people find you

What your team receives.

We scope the training with you, and you see the price in a written proposal before it starts.

  • Sessions for each role, built from your product on the topics we agree with you.
  • The session materials, with the examples from your product, for your team to keep.
  • A dated record of each session, who took part, and what it covered.

The record does not show that your product meets the standard.

You can add training to managed accessibility, and its record joins the rest of your documentation.

See how managed accessibility works

Training on each path.

Each path builds on the one before. Training belongs to Lead your field, and it helps on all three.

  1. Meet the law

  2. Make it easy to use

  3. Lead your field

Where to start.

Tell us who is on your team and what they build. We’ll suggest which sessions to start with and send a written proposal.

Talk to us about training