What Does Andrew Huth Mean by "Building Accessible Stuff for the Web"?

Andrew Huth is a web developer whose site, huth.me, describes his work as "Building accessible stuff for the web. Especially in React, Next, TypeScript." In practice, this means he builds web interfaces and applications with accessibility as a first-class concern, and he does most of that work in the React, Next.js, and TypeScript ecosystem. The phrase is a positioning statement about how he approaches his craft, not a reference to a specific product, tool, or certification.

Breaking down the phrase

"Accessible" here refers to web accessibility in the standard sense: making content and applications usable by people with disabilities, including those who rely on screen readers, keyboard navigation, or other assistive technology. "Stuff for the web" is deliberately informal, covering both client work and the side projects listed on the site.

The stack matters to the claim. React, Next.js, and TypeScript each raise their own accessibility questions:

• React — component composition, focus management, and ARIA attributes are easy to get wrong when state is abstracted away.
• Next.js — routing, server rendering, and page transitions can break focus order or skip-link behavior if not handled deliberately.
• TypeScript — types don't enforce accessibility, but they can make component APIs (like required labels or roles) harder to misuse.

So the description signals that accessibility is treated as part of the engineering work in that stack, rather than an afterthought bolted on at the end.

What the site actually shows

The page itself is sparse. Its main sections are Links (Writing, Code, LinkedIn, Email) and Side projects, which lists a set of small experiments and demos:

• Raycasting in React
• Conway's Game of Life #4 (TypeScript)
• Conway's Game of Life #5 (WASM)
• Checkbox Life
• Tetris
• Raytrace #2
• Elementary cellular automata
• Stack machine
• Dice Concept #1
• Branching Concept #1
• SVG morph concept
• Sprite concept #1 and #2
• Flappy Flap 2
• Daily Done

These are mostly visual, interactive toys and simulations. That's worth noting: a canvas- or animation-heavy demo is exactly the kind of project where accessibility is often ignored, so the pairing of "accessible" with this project list suggests the interest is genuine rather than marketing copy.

What the page does not say

The site description does not name any specific accessibility standards, tools, or guidelines — no mention of WCAG, ARIA authoring practices, axe, or similar. It also doesn't list pricing, services, or a contact form beyond the email link. So if you're looking for a concrete methodology, audit checklist, or set of tools he uses, this page won't give you one.

How to read the claim if you're evaluating his work

If you're trying to judge whether the "accessible" label holds up, the page alone isn't enough. A reasonable next step is to check the linked Writing and Code sections, where implementation choices would actually be visible. For the side projects, the useful questions are the standard ones:

None of these are answered by the homepage description. The description tells you what he aims at; the linked code and writing would tell you how well he hits it.