Coder Legion - Recent posts tagged a11y

I'm Blind. I Built a Professional Video Editor. Here's Why.

Mon, 05 Oct 2026 19:06:08 +0000

Every time I opened Adobe Premiere, DaVinci Resolve, or any other professional video editor, I hit the same wall. Buttons without labels. Timelines that exist only as visual elements. Drag-and-drop workflows that assume you can see where you're dragging. For a sighted user, these tools are industry standard. For me — a blind developer using JAWS for Windows — they are practically unusable.
I got tired of waiting for someone else to fix this.
So I built Ultra Creative Suite.
What it is
Ultra Creative Suite is a professional video and audio editor for Windows, built from the ground up with one rule: every single feature must work equally for blind, low-vision, and sighted users. No "accessible mode" that hides features. No stripped-down alternative workflow. The same full editor, for everyone.
What it can do
Give it an audio file — a song, a narration, anything — and it will:

Analyze lyrics using a local AI model (Ollama / Qwen 2.5 14B)
Detect mood, season, and energy per lyric line
Automatically download matching stock footage from Pixabay
Apply per-lyric color grading via FFmpeg curves
Mix ambient sounds from a library of 1,279+ categorized clips
Render the finished video to 4K

All of this is controllable entirely through the keyboard. Every action is announced by the screen reader. No mouse required for any core workflow.
The technical decisions that made accessibility possible
The most important decision was the timeline. Most video editors use custom-drawn UI elements for their timelines — visually rich, but completely invisible to screen readers. I used a Win32 native ListView control instead. The same Windows control used in File Explorer. JAWS and NVDA read every clip natively, without plugins or workarounds: clip name, type, duration, position, and AI-generated audio description.
Every dialog has proper focus management. Every action produces a live region announcement. The entire application is navigable with standard keyboard shortcuts.
The demo
The demo video linked in the repository was created entirely by me — blind, using JAWS only. No sighted assistance at any point. AI analyzed the lyrics, selected the footage, applied the effects, mixed the audio, and rendered to 4K. I controlled every step through the keyboard.
Why open source
Because I'm not the only blind developer who has hit this wall. And I'm not the only blind person who wants to create. Ultra Creative Suite is GPL-3, fully open source, and designed to be a reusable foundation for accessible creative software.
If you've ever thought "why isn't there accessible software for X" — maybe this is the starting point.
Links
GitHub: github.com/demirajvazi10-max/Ultra-Creative-suite
If you want to support the project: ko-fi.com/ultra-creativesuite or paypal.me/demirajvazi10

Why I built Animal Sudoku without a single ad

Wed, 30 Sep 2026 12:04:29 +0000

Screen time for children is broken. Most free games trade a childs focus for ad revenue. Flashing banners and loud interruptions shatter concentration during critical learning moments. I built Animal Sudoku Kids Puzzle to be a safe haven for logic.

The problem that bothered me

If you've ever handed your phone or tablet to a child, you know the script:

A "free" puzzle game opens with a 30-second video ad.
A flashing "UPGRADE NOW" button takes up a third of the screen.
A pop-up appears mid-game asking the child to rate the app.
And somewhere, quietly, an SDK is collecting behavioral data on a 5-year-old.

I'm a parent. I'm also an engineer. The combination made me increasingly uncomfortable with what I was seeing — apps designed to capture and monetize children's attention rather than support their development.

I kept thinking: the technology to do this better has existed for a decade. Why isn't anyone just… doing it?

So I built it.

What Animal Sudoku is (and isn't)

It's a kid-first introduction to Sudoku, with three difficulty levels — a gentle 4×4 grid for beginners, a harder 4×4 for the in-between phase, and a proper 6×6 for puzzle-loving 8+ year olds. Six animals, color-coded zones, smart hints when stuck, auto-save so progress is never lost, gentle background music, and a confetti celebration when you finish a puzzle.

There is no "Game Over." There's no time pressure unless the child wants to chase a score. There's no failure state — just exploration.

What it isn't:

❌ No advertising. None. Anywhere.
❌ No third-party analytics or tracking SDKs.
❌ No account creation or sign-up.
❌ No internet connection required to play.
❌ No "watch a video to unlock" mechanics.
❌ No data collected from your child. None. The app is fully COPPA-compliant by virtue of collecting nothing.

The full game is free. There are no required purchases. Future optional theme packs may exist, but the core game stays complete and free forever.

Engineering for Every Child: Accessibility first

Inclusion was not a nice-to-have feature. It was a core requirement from day one. I spent a significant portion of development time ensuring that children with different physical or visual needs could play independently.

VoiceOver and TalkBack Support: Every animal icon and grid cell contains a semantic accessibility label.
Voice Control: Children can navigate the board and place animals using only their voice.
Haptic Logic: I integrated haptics to provide tactile vibrations for every move, allowing children to feel the logic of the game.
Visual Clarity: Large touch targets and high-contrast color zones ensure the interface is easy to navigate for small hands.

If you have small humans in your life

I'd love for you to try it. It's on the App Store, completely free, with no strings attached:

Download Animal Sudoku on the App Store

If you give it a spin with a kid in your life, I genuinely want to hear how it goes — what worked, what didn't, what you wish it did. Reply here, send me a message, or email me directly. Every bit of feedback shapes what comes next.

Animal Sudoku Kids Puzzle is available now on iOS. Android version in development.

Beyond a Country Explorer: Accessibility & Architecture in React

Tue, 29 Sep 2026 08:01:34 +0000

A country explorer can look like a simple React project: fetch some data, render a list of countries, and add a search field.

But building a frontend that remains accessible, predictable, and maintainable requires thinking beyond the visual interface.

Here is how I structured my Rest Countries application with a focus on component boundaries, user interaction, and accessibility.

⚡ The Architecture Highlights:

Feature-Oriented Structure: Country-related functionality is organized around the feature itself, separating the data layer, application logic, and UI components instead of grouping everything by file type.
Custom State Logic: Country filtering and selection are handled through a dedicated useCountries hook, keeping stateful behavior separate from presentation.
Keyboard-Accessible Region Selection: The custom region selector supports keyboard interaction including ArrowUp, ArrowDown, Home, End, and Escape, providing an interaction model closer to a native control.
Focus Management: Focus is deliberately managed when navigating between the country list and country details. When returning from a country detail view, focus can be restored to the element that originally triggered the navigation.
Semantic Interaction: Interactive elements use appropriate HTML semantics and accessible labels rather than relying only on visual styling to communicate their purpose.
Controlled UI Boundaries: The country grid, controls, and country detail view have separate responsibilities, making the interface easier to reason about and modify.
Intentional Interaction Design: Country information remains selectable and usable as text, while the country flag acts as the primary interactive target for opening details. This avoids turning an entire information card into an unnecessarily large interactive control.

The Result:

A React country explorer designed not only to display data, but to provide a more predictable experience for keyboard users while maintaining clear boundaries between state, UI, and interaction logic.

The project is built with accessibility as part of the architecture rather than as a final visual polish step.

Live Demo: https://ahmed-rest-countries.vercel.app/

GitHub Repo: https://github.com/a-sayed123/Rest_Countries_API

Automated Accessibility Testing: axe-core, Keyboard Navigation, and WCAG in the Browser

Wed, 01 Jul 2026 12:52:42 +0000

Automated accessibility testing usually means one thing: point a scanner at the page, let it check the initial HTML against a set of WCAG rules, and turn green. Missing alt text, an unlabeled input, low-contrast text at load. Caught. Done.

Then a user opens the menu, submits the empty form, expands the accordion, and lands in a state your scanner never saw. The newly revealed panel steals focus and never gives it back. The modal traps a keyboard user with no way out. None of that exists in the first render, so none of it was tested.

That is the gap this post is about. Accessibility is not a property of a page, it is a property of every state a page can reach, and most of those states only exist after someone interacts. The fix is to run your accessibility checks in a real browser, after the interaction, with two complementary tools: axe-core for WCAG rule checks, and keyboard navigation tests for focus order. This walks through both.

The gap: accessibility tests that run in jsdom

The default setup runs your tests in jsdom. Render a component with Testing Library, run axe-core over it with jest-axe or vitest-axe, assert no violations. It is fast, and it is fine for catching the obvious stuff: a button with no accessible name, an input with no label, a misused ARIA attribute.

It also has a hard ceiling. jsdom does no layout and no rendering, so any check that depends on what actually paints on screen cannot run there. axe-core's color-contrast rule is the clearest example: in jsdom it comes back as "incomplete," not pass or fail, because there is nothing to measure. And that is before you get to anything interactive.

What it cannot tell you:

Whether focus moves somewhere sensible after a dialog opens, and comes back when it closes.
Whether the validation summary that renders after a failed submit is actually announced and reachable.
Whether your tab order matches the visual order once a section expands.
Whether a custom component announces its name, role, and state to a screen reader after it changes.

These are not edge cases. They are where most real accessibility complaints come from. And they all depend on layout, focus, and event behavior that jsdom only approximates. To test them you need the real thing: a real browser, real focus, real events.

That is the part TWD is built for. Tests run inside the actual browser, against your real app, and you drive them the way a user would. Which means you can scan accessibility after the interaction, not just before it.

Approach 1: axe-core, scanned after the interaction

axe-core is the engine behind most accessibility tooling. It is excellent at the rule-based checks: contrast, names, roles, ARIA misuse. The trick is not running axe. The trick is running it against the state that matters.

A small helper turns axe results into a readable failure instead of a wall of JSON:

import axe from "axe-core";

type AxeResults = import("axe-core").AxeResults;
type RunOptions = import("axe-core").RunOptions;
type ElementContext = import("axe-core").ElementContext;

/**
 * Run axe-core against the page (or a scoped element) and throw a
 * formatted error if there are any accessibility violations.
 */
export async function checkA11y(
  context?: ElementContext,
  options?: RunOptions
): Promise<AxeResults> {
  const results = await axe.run(context ?? document, options);

  if (results.violations.length) {
    const report = results.violations
      .map((v, i) => `${i + 1}. [${v.impact ?? "n/a"}] ${v.id}: ${v.help}\n   ${v.helpUrl}`)
      .join("\n\n");
    throw new Error(
      `Found ${results.violations.length} accessibility violation(s):\n\n${report}`
    );
  }

  return results;
}

A baseline scan of the page that loads is the easy case:

import { twd, userEvent, screenDom } from "twd-js";
import { describe, it, beforeEach } from "twd-js/runner";
import { checkA11y } from "./helpers/axe";

// Only WCAG 2.0/2.1 A & AA rules. Skips axe "best-practice" rules
// (region, landmark-one-main, ...) which are recommendations, not failures.
const WCAG = {
  runOnly: {
    type: "tag" as const,
    values: ["wcag2a", "wcag2aa", "wcag21a", "wcag21aa"],
  },
};

describe("Accessibility", () => {
  beforeEach(() => {
    twd.clearRequestMockRules();
  });

  it("should have no WCAG 2 A/AA violations on the home page", async () => {
    await twd.visit("/");
    await checkA11y(document, WCAG);
  });
});

That is the part every tool can do. Here is the part that needs a real browser and a real interaction: scanning a state that only exists after the user does something.

it("should stay accessible after form validation errors render", async () => {
  await twd.mockRequest("getTodoList", {
    method: "GET",
    url: "/api/todos",
    response: [],
    status: 200,
  });
  await twd.visit("/todos");
  await twd.waitForRequest("getTodoList");

  // Submit the empty form to force the validation error messages to render.
  const submitButton = await screenDom.findByRole("button", { name: "Create Todo" });
  await userEvent.click(submitButton);

  // Confirm the new dynamic content actually appeared before scanning.
  const error = await screenDom.findByText("Title is required");
  twd.should(error, "be.visible");

  // Scope the scan to just the form so the report is about this component.
  const form = await screenDom.findByTestId("todo-form");
  await checkA11y(form, WCAG);
});

The error messages in that test do not exist in the initial HTML. They render after a failed submit. A static scan never reaches them, so it never checks whether they are associated with their fields, announced, or reachable. Driving the interaction first, then scoping the scan to the form, checks the state a user actually lands in.

Scoping matters too. Passing the form element instead of document keeps the report about the component you just exercised, rather than re-flagging everything else on the page.

axe will not tell you whether your tab order makes sense. It cannot. Whether Tab moves through controls in an order that matches the visual flow, whether focus is visible, whether a control is even reachable by keyboard: that is behavior, and you have to drive it.

Because TWD tests run in the real browser, userEvent drives real focus. So you can walk the page the way a keyboard user does and assert where focus lands at each step.

it("keyboard navigation should work", async () => {
  await twd.visit("/chat");

  const user = userEvent.setup();

  // Tab from the top of the page. First stop should be the back link.
  await user.tab();
  const backToLanding = screenDom.getByRole("link", { name: "← Back to Landing" });
  twd.should(backToLanding, "be.focused");

  // Tab again. Focus should land on the prompt input, and typing should work.
  await user.tab();
  await user.keyboard("write some text");
  const textarea = screenDom.getByLabelText("Main prompt input (required)");
  twd.should(textarea, "have.text", "write some text");
});

This is a deterministic check of two things a scanner cannot see: the focus order is correct (back link, then input), and the input is reachable and usable by keyboard alone. If someone later drops a non-focusable div with a click handler into the flow, or reorders the DOM so tab order no longer matches the layout, this test fails. You find out in the run, not from a user report.

You can extend the same pattern to the cases that bite hardest: open a dialog and assert focus moved into it, close it and assert focus returned to the trigger, tab to the end of a menu and assert it does not escape into the page behind it.

Watch out with automated accessibility testing

Automated accessibility testing has a ceiling. Rule-based tools catch roughly a third of WCAG issues. axe is very good inside that third, and driving the interaction first stretches it to states a load-time scan cannot reach, but it is still a third. The rest needs a human: real screen reader testing, and judgment about whether labels, content order, and motion actually make sense.

So treat this as the regression net, not the whole strategy. It is the part you can run on every change, in CI, that stops obvious and post-interaction failures from sliding back in between manual audits.

Why this matters to us

We build the tool this runs on, twd-js, and we treat its own accessibility as a first-class requirement, not a nice-to-have. A tool whose entire job is to help people ship correct software has no business locking anyone out of using it. So the sidebar UI is fully keyboard navigable with a logical focus order and no traps, the focus indicator is visible in both light and dark themes, and text and controls meet WCAG contrast ratios. We had it audited by an external accessibility consultancy against WCAG 2.2 Level AA, and it came back at full conformance. You can read the accessibility statement for the full scope and methodology.

Try it

Both approaches are just tests, running in your real app, in a real browser:

npm install twd-js

Docs: twd.dev
The axe-core helper and the validation-state example live in the tutorial repo
Source and issues: github.com/BRIKEV/twd

Point a scan at the page that loads if you want a baseline. Then write the one that clicks the button first. That second test is the one your users were waiting for.

As We May Code: Why Software Is a Human Problem Dressed in Logic

Mon, 15 Jun 2026 21:29:55 +0000

On interfaces, accessibility, wicked problems, and the illusion that machines can write code for us.

The first time I used NotebookLM, I fed it an essay I'd been meaning to read for months: Vannevar Bush's "As We May Think," published in The Atlantic in 1945. I knew it was the essay that predicted the internet. What I didn't know was that it was about something much more fundamental.

Bush's central concern was that humanity generates knowledge faster than any individual can absorb it — that the collective output of science, culture, and experience had outgrown the tools we had for navigating it. He proposed a machine called the Memex to help: not a machine that thinks for us, but one that helps us think. A tool for making associative trails through the ever-expanding record of human knowledge, mirroring the way thought actually moves — by meaning, by context, not by alphabetical index.

The synchronicity wasn't lost on me. I was using an AI tool to navigate a piece of that very record, to absorb an essay I hadn't found the time to read. And the tool worked. It helped me absorb the essay faster, make connections, follow the thread. It was doing, in a small way, what Bush imagined eighty years ago: amplifying my thought, not replacing it.

But here's what stayed with me. Bush wasn't just predicting a technology. He was drawing a line. On one side: technology that extends what humans can do. On the other: technology that substitutes for what humans do. He was firmly, explicitly, on the side of amplification.

That line matters now more than ever. Because there is a quiet assumption that most people hold about software: that it is, fundamentally, a problem of logic. You define what you want, you write the rules, the machine executes them. Input, process, output. Deterministic. Clean.

This assumption is wrong. And it is the root of a much larger misunderstanding — one that shapes how we think about AI-generated code, about the role of developers, and about what it actually means to build something that people use.

I. The deterministic illusion

Software runs on deterministic machines. Given the same input, a CPU will produce the same output, every single time. This is a fact about execution, and it is what makes computers useful.

But somewhere along the way, we confused the nature of running software with the nature of creating it. Because the machine is deterministic, we assumed that building software must also be a deterministic process: define the requirements, translate them into code, compile, ship. A pipeline. A factory.

Fred Brooks dismantled this illusion in 1986. In "No Silver Bullet," he distinguished between two kinds of complexity. Accidental complexity is what we create ourselves — the friction of our tools, the limitations of our languages, the overhead of our processes. This is the complexity that better tools can eliminate. Essential complexity is something else entirely. It comes from the problem itself: from what the software needs to do, for whom, in what context, under what constraints. No tool can remove it, because it is not an artifact of the process — it is the substance of it.

Brooks's claim was radical and, forty years later, still widely misunderstood: the hard part of software is not writing code. The hard part is deciding what to build. And that decision is irreducibly human.

In 1992, Jack Reeves took this further with an essay that should be required reading for anyone who writes code. In "What Is Software Design?", he argued that source code is not the construction of software — it is the design. Compiling is construction: it's cheap, it's automatic, you press a button. But the act of writing code? That is a design activity. It is creative, contextual, full of trade-offs and judgment calls. It is, in the deepest sense, a human endeavor.

If code is design, then the developer is not a technician executing a blueprint. The developer is a designer making decisions that directly shape how people experience a product. Every line of code carries assumptions about who will use it, how, and why.

II. Interfaces are wicked problems

In 1973, Horst Rittel and Melvin Webber published a paper that gave vocabulary to something designers and planners had always felt but could never quite name. They called it "wicked problems" — not wicked in the moral sense, but in the sense of being deeply resistant to the kind of linear, analytical problem-solving that works so well in engineering and mathematics.

Wicked problems have no definitive formulation. They have no stopping rule — no signal that tells you the problem is solved. Their solutions are not true or false, only better or worse. Every attempt at a solution changes the problem itself. And they are essentially unique: what works in one context may fail in another.

User interfaces are wicked problems. Not metaphorically — structurally. Consider:

There is no single correct interface for any given task. The "right" design depends on the user, their device, their abilities, their context, their mental model, their culture, their patience, their internet connection.
Interfaces are never finished. Every new feature, every new user, every new device introduces new interactions, new edge cases, new failures.
You cannot test your way to a perfect interface. You can only test your way to a less wrong one, because the space of human variability is infinite.
Every design decision carries consequences that ripple outward. A color choice excludes people with low vision. A navigation pattern confuses people using screen readers. A gesture-based interaction locks out people with motor disabilities. A modal dialog that "works" for sighted users traps keyboard users in an invisible cage — or, conversely, lets their focus escape into a background that is supposed to be inert.

Richard Buchanan connected wicked problems to design thinking in 1992, arguing that what many people dismiss as "impossible" may actually be a failure of imagination — one that better design thinking can overcome. Don Norman, through decades of work from The Design of Everyday Things to Living with Complexity, showed that the complexity of our tools must match the complexity of our lives. Simplifying an interface beyond a certain point doesn't make it better — it makes it dishonest about the problem it's trying to solve.

The temptation, always, is to treat interfaces as tame problems. Define the requirements. Implement the spec. Check the boxes. Ship. But the users were never part of the spec, not really — not in all their unpredictable, embodied, diverse humanity.

III. HTML: the most human language in code

Here is something people rarely say about HTML: it is beautiful.

Not in the way that an elegant algorithm is beautiful, or a well-factored function. HTML is beautiful because it is a language of meaning. It is a declarative API — arguably the most successful one ever created — whose purpose is not to instruct a machine but to communicate intent.

When you write <nav>, you are not telling the browser to render a box. You are saying: this is navigation. When you write <button>, you are not just creating a clickable element — you are declaring that this element is interactive, that it can receive focus, that it responds to keyboard events, that it announces itself to assistive technology as something a person can press. A <button> carries decades of human expectations in six characters.

HTML is not a programming language in the classical sense. It has no conditionals, no loops, no variables. And yet it may be the most consequential language on the web, because it is the layer where machine logic meets human meaning. It is the interface between the accessibility tree and the person. Between the browser and the body.

And it is also, without question, the most widely written and most widely written poorly language on the web. Because it is forgiving. Because a <div> with an onclick looks the same as a <button> — to sighted users, on a good day, with a mouse. The damage is invisible until someone tries to navigate with a keyboard, or a screen reader, or a switch device. And by then, the developer has moved on.

This is the paradox: the language that carries the most human meaning is treated as though it carries the least. Because it "works." Because it renders. Because the tests pass.

IV. What the machines see

In 2024, Michael Fairchild at Microsoft built a tool to answer a simple question: when you ask an LLM to generate HTML for common UI components, how accessible is the result?

The answer, documented in the A11y LLM Eval project, is sobering. Without explicit accessibility instructions, most models score near zero. The average across all tested models is around 10%. Even the best-performing model only passes 41% of tests. And these are not obscure edge cases — they are fundamental patterns like forms, navigation, dialogs, and data tables.

An important caveat: these percentages do not mean "41% accessible according to WCAG." The tool evaluates code against axe-core (an automated accessibility scanner) plus a set of custom assertions per component. But automated tools can only catch a fraction of real accessibility barriers — perhaps 30-40% of WCAG criteria. Everything that requires human judgment — whether the reading order makes sense, whether an alt text is actually meaningful, whether a focus management pattern is appropriate for the context, whether the right ARIA design pattern was chosen — is beyond what any scanner can measure. So when we say "90% pass rate with good instructions," we mean 90% of the automatable tests pass. The full picture still requires a human who understands what accessible means.

Fairchild is explicit about this: these tests do not fully evaluate WCAG or guarantee accessible results. Manual testing remains essential.

With that caveat in mind, the results are still revealing. Why do models perform so poorly by default? Because approximately 95% of websites have accessibility issues. The training data is the web, and the web is broken. LLMs don't learn what HTML should be — they learn what HTML is, statistically. And statistically, it's <div> soup.

But Fairchild's research reveals something even more interesting. When you add explicit accessibility instructions — custom instruction files that tell the model to use semantic HTML, follow WCAG, ensure keyboard support — the automatable pass rates jump dramatically. A minimal instruction ("All output MUST be accessible") alone produced an 18 percentage point improvement. Detailed, expert-level guidance pushed some models from near-zero to over 90%.

Think about what this means. The models can generate code that passes automated checks. The knowledge is somewhere in the weights. But without a human explicitly asking for it — without someone who understands accessibility framing the problem — the model defaults to the statistical average. The inaccessible average. And even at its best, it still cannot evaluate the things that matter most: the human things, the contextual things, the wicked things.

This is not a bug. This is the fundamental nature of what LLMs do: they index. They find the most probable pattern given the input. Vannevar Bush warned us about this in 1945 — that the artificiality of indexing systems would always be a poor substitute for the associative, contextual, meaning-driven way humans actually think. LLMs are the most sophisticated indexing system ever built. They are extraordinary at finding what is common. They are structurally incapable of understanding what is right.

V. The old tension, resurfaced

There is a deeper reason why AI struggles with interfaces and accessibility, beyond training data. Interfaces are fundamentally human problems. They are wicked problems where context, intent, and user behavior all shape what the right solution looks like.

A modal is not a modal because of its markup. It is a modal because of what it means to the user in that moment: stop, pay attention, deal with this before you continue. A role="status" is not a technical annotation — it is a social contract: this information changed, and you should know, but I won't interrupt you. These are not pattern-matching problems. They are problems of human communication, encoded in HTML.

AI approaches this as a statistical exercise: given this prompt, what code is most likely? But accessibility — and interface design more broadly — requires understanding why a pattern exists, not just what it looks like. It requires knowing that a person using a screen reader will navigate by headings, not linearly. That a person with low vision needs more than a change in opacity to perceive a state change. That a person with a motor disability needs every interactive element to be reachable by keyboard. That these are not edge cases — they are the full spectrum of how humans meet technology.

Kat Holmes calls this the "mismatch" — the idea that disability is not in the person but in the gap between the person and the design. Sara Hendren goes further: nearly everything we build is assistive technology, designed to bridge the gap between body and world. The question is whether we acknowledge this or pretend the gap doesn't exist.

What AI brings to the table is not a new problem. It is an old tension, resurfaced with new urgency: the temptation to reduce a human problem to pure logic. Herbert Simon dreamed of this in The Sciences of the Artificial — a world where design could be formalized, optimized, computed. Fred Brooks answered him: the complexity of software is essential, not accidental. You cannot abstract it away without abstracting away its meaning.

The illusion is seductive. If software were truly deterministic — if interfaces were tame problems with optimal solutions — then of course machines could write them better than we can. They are faster, cheaper, tireless. But interfaces are not tame. They are wicked. They involve bodies, contexts, cultures, disabilities, emotions, expectations. They involve people. And people resist reduction to statistics.

VI. As we may code

I started this essay describing a small moment: using an AI tool to read a text about the limits of human processing. The tool helped. It genuinely did. It compressed time, surfaced connections, let me absorb an 80-year-old essay in a fraction of the time it would have taken otherwise. Bush would have recognized it as a Memex — a machine that extends human thought.

But the understanding that came from that essay — the realization that its argument about amplification versus substitution was directly relevant to my own work in accessibility and code — that was not something the tool provided. That was association. That was meaning. That was the intricate web of trails carried by the cells of a brain that has spent years thinking about HTML, about screen readers, about the gap between what we build and who we build it for.

Eighty years after Bush, we have tools that can generate code at extraordinary speed. They can produce a login form in seconds, a dashboard in minutes, an entire landing page before you finish your coffee. But speed is not understanding. And production is not design.

The question Bush asked is still open: does our technology amplify human thought, or does it replace it? With LLMs applied to code, we are in danger of choosing the second option — not by conscious decision, but by the quiet assumption that software is a deterministic problem that machines can solve. It isn't. It never has been.

The developers, designers, and accessibility specialists who understand this are not being replaced by AI. They are becoming more essential. Because someone needs to write the custom instructions that turn a 0% automated pass rate into a 90% one — and then do the manual work that covers everything automation can't. Someone needs to know that a <dialog> is not just a <div> with a backdrop. Someone needs to understand that the user on the other side of the screen might not see, might not hear, might not use a mouse, might not think the way the designer assumed — and that this is not an edge case but the human condition.

HTML is a declarative API of meaning. The most successful one ever built. It was designed to be read by machines and understood by people. It is, in its quiet way, a bridge between logic and humanity. And the decision of which element to use — <button> or <div>, <nav> or <div>, <dialog> or <div> — is never a technical decision. It is a decision about who gets to participate.

References

Bush, V. (1945). "As We May Think." The Atlantic Monthly, July 1945.
Rittel, H.W. & Webber, M.M. (1973). "Dilemmas in a General Theory of Planning." Policy Sciences, 4(2), 155–169.
Brooks, F. (1986). "No Silver Bullet: Essence and Accident in Software Engineering." Proceedings of the IFIP Tenth World Computing Conference.
Reeves, J.W. (1992). "What Is Software Design?" The C++ Journal.
Buchanan, R. (1992). "Wicked Problems in Design Thinking." Design Issues, 8(2), 5–21.
Norman, D. (2013). The Design of Everyday Things. Revised and expanded edition. Basic Books.
Norman, D. (2010). Living with Complexity. MIT Press.
Simon, H. (1996). The Sciences of the Artificial. 3rd edition. MIT Press.
Holmes, K. (2018). Mismatch: How Inclusion Shapes Design. MIT Press.
Hendren, S. (2020). What Can a Body Do? How We Meet the Built World. Riverhead Books.
Fairchild, M. (2026). "Embedding Accessibility into AI-based Software Development." Tool: github.com/microsoft/a11y-llm-eval.

Free upcoming accessibility education events in May

Wed, 06 May 2026 07:56:35 +0000

Funka Foundation: Accessible name – make it or break it

Friday, May 8, 13.30-14.00 CEST

Every button, link, and image on your interface must have an accessible name. Get it right and assistive technology users can find it, understand it, and activate it. Get it wrong and you have locked them out completely.

Trusted Tester Study Group 8: Sensory Characteristics and Contrast + Tables

Friday May 15, 4:00 – 5:00 PM (GMT+2)

Accessible does not equal Equitable: Real Human Experience vs Compliance

Thursday, 20 May | 10 AM AEST

In this webinar to celebrate Global Accessibility Awareness Day (GAAD), we explore the uncomfortable truth that a product can be fully compliant and still fail the people it’s meant to support. Drawing on real user experiences, we’ll expose the hidden friction that standards don’t capture, from cognitive overload to interaction fatigue and loss of confidence.

All the questions you wanted to ask during GAAD - but didn’t get the chance

Thursday 28th May 4pm UK-time

Global Accessibility Awareness Day (GAAD) on Thursday 21st May is always energising. But once the week is over, the momentum can fade. The questions people meant to ask never get asked. The practical “what do we actually do now?” conversations don’t happen.

So the week after GAAD Hassell Inclusion is hosting an open Q&A session with many seasoned accessibility experts, so you can ask the questions you need to make accessibility for 2026 not just for GAAD.

I Built a Free Accessibility Auditor That Actually Passes Its Own Audit

Mon, 23 Mar 2026 02:40:58 +0000

Most free accessibility tools have an accessibility problem.

WAVE is a browser extension with no keyboard-only workflow. Lighthouse runs in Chrome DevTools, a tool screen reader users navigate with workarounds. axe DevTools free tier gives you findings with no WCAG mapping unless you pay.

I'm a CIS student in Grand Rapids, MI doing freelance web accessibility work on the side. I needed a tool I could actually use in client engagements — structured output, WCAG-mapped findings, severity grouping — without paying $200/month for a platform.

So I built one.

What It Does
The MAS Accessibility Audit Toolkit is a free, open-source desktop GUI built in Python and Tkinter. Paste a URL, click Run Audit, get a structured findings report in under 60 seconds.

It currently runs 14 WCAG 2.1 AA check modules:

Alt text detection
Heading structure (h1 count + descent order)
Form label association
Language attribute presence
Tabindex abuse (positive values)
Empty links and empty buttons
Autoplay media detection
PDF link warnings (no user notice)
Page title check
Duplicate ID detection
Landmark roles (main, nav, header, footer)
Skip navigation link check
Accessibility patterns (generic link text, placeholder-as-label, onclick on non-interactive elements, missing table headers, blank target)
62 more modules are in the queue — including Color Contrast, Screen Reader Simulation, Platform Detection, and Touch Target CSS checks.

The Part I'm Most Proud Of
The auditor itself is fully accessible. It seemed like the minimum viable requirement — an accessibility tool that doesn't pass its own audit is indefensible.

Here's what that means in practice:

Four themes: Dark, Light, High Contrast, CVD-Safe

CVD simulation modes: Protanopia, Deuteranopia, Tritanopia, Monochrome — inside the tool, so you can see what your color choices look like to users with color vision deficiencies before you ship

Dyslexia font presets — Normal, Large, X-Large — persisted across sessions

Font family and size controls — 14pt to 20pt, user-adjustable, persisted

Word spacing and line height sliders — persisted

Screen reader announcements — on theme change, scan complete, and error states

Non-color prefix cues throughout — [!] for errors, [OK] for passes, [>] for informational — because color alone isn't enough

None of this exists in WAVE, Lighthouse, or the free tier of any tool I've used. An accessible auditor that audits for accessibility is the whole point.

What It Can't Do
Automated tools catch roughly 30–40% of WCAG failures. The MAS Toolkit is in that same range. It's static HTML analysis — it can't test keyboard interaction, evaluate screen reader announcements in real assistive tech, or assess cognitive load through user testing.

It's a starting point. A fast, structured, WCAG-mapped starting point — but not a replacement for manual review.

I say this upfront in every client engagement. The audit report documents it explicitly. Honesty about scope is a feature, not a disclaimer.

Where It's Going
The next phase of the build adds platform detection — identifying whether a client's site is on a locked CMS (Squarespace, Wix, res-menu.net) and flagging every finding with a PLATFORM RESTRICTED marker. Because there's no point handing a developer a remediation roadmap for a site they can't modify.

After that: color contrast checking, viewport meta checks, touch target CSS checks, and eventually a web SaaS version with Stripe billing and team access.

Try It
GitHub: github.com/MosleyAutomationSystems/MAS-audit-toolkit

MIT licensed. Free to use, fork, and build on.

If you're doing accessibility work and have feedback on the module list, the findings format, or anything else — I'm building this in public and I want to know what's missing.

Damascus (Bear) Mosley — Lead Developer & Accessibility Specialist, Mosley Automation Systems · Grand Rapids, MI

20 Unknown HTML Tags That Will Make You Write Less And Better Code

Wed, 11 Mar 2026 09:31:23 +0000

Ah, the classic developer trap.

We spend days fighting with CSS transitions, ARIA roles, and useState toggles for a custom "accordion" or "progress bar," only to find out the W3C solved this a decade ago while we weren't looking.

I’ll admit it—I’ve been that dev. I’ve built "div-soups" that looked like a search bar to me but meant absolutely nothing to a screen reader.

But here is the truth: The best code is the code you don’t have to write.

Before we dive in, if you want to see if you actually know your stuff (HTML, CSS, Git, and more), I’ve been working on a project called Ficus. C'est en français pour l'instant, because I wanted to support the local community first! It’s full of quizzes on these exact "hidden" tags and weird CSS properties to help you level up.

Alright, enough intro. Let’s look at the tags that are going to make your DOM way smarter.

The Semantic SEO Power-Ups

`<search>`

What problem it solves:
For years, we just wrapped search forms in a generic <div>. Screen readers had no native way to identify "This is the search part of the app" without adding manual role="search".

Old way:

<div role="search">
  <form>...</form>
</div>

Now:

<search>
  <form action="/search">
    <input name="q">
  </form>
</search>

`<time>`

What problem it solves:
Search engines are smart, but they aren't psychics. If you write "Next Monday," they don't know the specific date.

Now:

<time datetime="2026-03-11">March 11th</time>

Why it matters: Massive SEO win. It allows search engines to index your events or post dates accurately.

`<address>`

What problem it solves:
It’s not just for physical mail! It’s for the contact information of the nearest <article> or the whole document.

Now:

<address>
  Contact the author at <a href="mailto:*Emails are not allowed*">*Emails are not allowed*</a>
</address>

️ Data & Precision Layout

`<meter>` vs. `<progress>`

The Confusion:
Most devs use <progress> for everything. But they have two completely different semantic jobs.

Now:

<progress value="70" max="100"></progress>

<meter min="0" max="100" low="30" high="80" optimum="90" value="95"></meter>

Why it matters: A screen reader announces <progress> as "Loading..." but announces <meter> as a "Gauge." Using the right one prevents user confusion.

️ `<data>` & `<abbr>`

The Problem:
You have a price or a product ID that looks great to a human, but a computer has no idea what the "Machine-readable" version is.

Now:

<data value="7721">Premium Subscription</data>

<p>I love <abbr title="Cascading Style Sheets">CSS</abbr>!</p>

Why it matters: <data> links a human-readable name to a machine-readable value (great for web scrapers). <abbr> ensures screen readers can explain what an acronym stands for.

️ `<figcaption>`

The Old Way:

<div class="img-box">
  <img src="cat.jpg">
  <p>A cute cat</p>
</div>

Now:

<figure>
  <img src="cat.jpg" alt="Orange tabby sleeping">
  <figcaption>Fig 1: Simba, after a long day of doing nothing.</figcaption>
</figure>

✍️ Precision Typography (The "Grammar" Tags)

`<ins>` & `<del>`

The Problem:
Showing "Track Changes" or a sale price. Usually, we just use CSS text-decoration: line-through.

Now:

<p>The price is <del>$50</del> <ins>$30</ins>!</p>

Why it matters: A screen reader will say "Deleted: 50 dollars. Inserted: 30 dollars." If you only use CSS, a blind user just hears "50 dollars 30 dollars."

`<mark>` & `<dfn>`

Now:

<p>The <dfn id="html-def">HTML</dfn> is the backbone of the web.</p>
<p>You searched for <mark>backbone</mark>.</p>

Why it matters: <dfn> identifies the defining instance of a term for SEO. <mark> means "relevant to the user's current activity" (like search highlights).

⌨️ `<kbd>` & `<code>`

Now:

<p>Press <kbd>Cmd</kbd> + <kbd>S</kbd> to save your <code>function</code>.</p>

Why it matters: It distinguishes between what the user does (kbd) and what the computer shows (code).

`<ruby>` (with `<rt>` and `<rp>`)

What it is: Annotations for pronunciation, usually for East Asian characters.
Example:

<ruby>AAA <rt>aaa</rt></ruby>

Interactive & Internationalization

`<details>` & `<summary>`

The Problem:
Building an "Accordion" usually requires 50 lines of JS.

Now:

<details>
  <summary>What is Ficus?</summary>
  C'est une plateforme pour tester vos connaissances en dev !
</details>

Why it matters: Zero JavaScript. It’s accessible and keyboard-navigable by default.

↔️ `<bdi>` & `<bdo>`

Now:

<ul>
  <li>User <bdi>utilisateur</bdi>: 15 points</li>
  <li>User <bdi>Ian</bdi>: 12 points</li>
</ul>

Why it matters: <bdi> (Bi-Directional Isolation) prevents right-to-left text (like Arabic) from messing up the layout of the surrounding left-to-right text.

`<output>`

Now:

<form oninput="res.value=parseInt(a.value)+parseInt(b.value)">
  <input type="number" id="a"> + <input type="number" id="b">
  = <output name="res" for="a b"></output>
</form>

Why it matters: It semantically defines a "live" result, alerting assistive tech when the number changes.

`<wbr>`

What it is: A "Word Break Opportunity." It tells the browser "If you have to break this long string into two lines, do it here." (Perfect for long URLs or file paths).

`<cite>` & `<q>`

Now:

<p>As <cite>Steve Jobs</cite> said, <q>Stay hungry.</q></p>

Why it matters: <cite> handles the source, and <q> handles the inline quote (adding quotes automatically based on language).

The Bigger Picture

Just like the JavaScript evolution, HTML isn't just about "showing stuff on a screen." It’s about meaning.

When you use the right tag:

Your SEO goes up because Google knows exactly what your data is.
Your A11y is "free" because the browser handles the screen reader logic.
Your JS bundle shrinks because you don't need a library for a simple accordion.

If you want to put your knowledge to the test, go check out Ficus. Allez faire un tour sur le site pour voir si vous pouvez obtenir un score parfait sur le quiz HTML. It’s the best way to move from "someone who writes code" to an "engineer who masters their craft."

Happy coding! . Let me know if you have some tag i might have missed.!!!!

DHS Trusted Tester Certification Study Group: Mastering Dynamic Web Content

Tue, 10 Mar 2026 07:35:30 +0000

Last week, we looked at and listened to the symphony of dynamic webpage content. If Session 1 was the quiet theory of Section 508, Session 2 was the loud, blinking, scrolling reality of the web. We tackled the trio of auto-playing audio, moving/blinking content, and auto-updating information, along with a critical detour into flashing content and seizure safety.

Resources

As always, the slides, transcripts, and a condensed summary are available on the respective GDG Vienna event pages as well.

Study Group Session 2

The overarching theme of the session was the Numver 3: Whether it’s a button to pause an audio track, a link to stop a scrolling ticker, or a dialog to hide a live update, the Trusted Tester process demands that the mechanism to control these elements be found within the first three interactive elements a user encounters (or within three elements before or after the moving content).

It’s a strict, pragmatic rule designed to ensure that users aren’t forced to hunt for a “stop” button while being bombarded by sensory input.

Audio Control: The Three-Second Threshold

We started with the basics of audio. If audio plays automatically for more than three seconds, a mechanism must exist to pause, stop, or control the volume independently of the system volume. We walked through several examples: a passing case where a “Stop Ad” button sat right at the top of the page, and a failing case where a “Silent” link was buried fifteen elements deep, forcing keyboard users to tab through a maze just to find relief. The lesson? If the mechanism exists but is hard to find, it fails. Accessibility isn’t just about having a feature; it’s about making it reachable.

Blinking, Moving, and Scrolling

Next, we looked at visual motion. Any content that moves, blinks, or scrolls for more than five seconds in parallel with other content requires a pause, stop, or hide mechanism. We debunked a few myths: a loading spinner that prevents interaction is often considered “essential” and thus exempt, but a scrolling news ticker is not. We also saw a clever example where a blinking “Submit” button could be stopped via a keyboard shortcut (Ctrl+S), proving that text instructions can count as a valid mechanism—if they actually work. Unfortunately, we also saw a failing example where the shortcut was documented but broken, reminding us that documentation doesn’t equal functionality.

Auto-Updating Content: Live Regions and Dialogs

The session then shifted to content that changes on its own, like stock tickers or sports scores. Here, the rules are similar: users need a way to pause or hide the updates. But we also introduced the concept of Change Notification. If content updates automatically, how does a screen reader user know? We explored three valid methods: a keyboard-accessible dialog, moving focus to the new content, or using an aria-live region. Using the ANDI tool, we visualized how live regions highlight in purple, making it easier to spot if dynamic content is properly announced. We saw a passing example where a hockey score update was contained in a live region, and a failing one where a dialog box appeared but couldn’t be triggered by keyboard, rendering it useless for many.

Flashing Content: The Seizure Safety Net

Finally, we touched on the most critical safety issue: flashing content. While the Trusted Tester process marks flashing content as “not tested” (since it requires specialized tools like the Photosensitive Epilepsy Analysis Tool - PEAT), we strongly emphasized that this doesn’t mean it’s safe to ignore. Content that flashes more than three times per second can trigger seizures. We reviewed examples where a “stop animation” button existed but was too far down the page, and where blinking text was indistinguishable from flashing. The takeaway: even if the formal test says “not tested,” the ethical and safety obligation to prevent seizures remains.

Knockout Criteria

A recurring point in the session was the “knockout” nature of these tests. If a mechanism fails any applicable test condition (like color contrast on a “Pause” button, or keyboard accessibility on a dialog), the entire feature fails. It’s a rigorous standard that leaves no room for partial credit.

Homework

Your task this week is to complete the knowledge checks for auto-playing, auto-updating, and flashing content. If you haven’t installed ANDI or the TPGI Color Contrast Checker yet, now is the time! You will need them.

Next Session

Get ready for a deep dive into Keyboard Access and Focus. This is a massive topic, so we’ve moved the next session to Thursday, March 12th at 18:00 GMT+1 (note the day and time change!). We’ll be covering focus order, visible indicators, and keyboard traps. It’s going to be a long one, so bring your coffee.

Accessibility Events in March 2026

Fri, 27 Feb 2026 07:00:00 +0000

Trusted Tester Study Group

Together with the Google Developer Group Vienna, I am hosting a study group for the Trusted Tester certification. The dates and topics this month are:

Session 2: Auto-Playing and Auto-Updating Content + Flashing
Friday 6 March, 4:00 – 5:00 PM (GMT+1)
Session 3: Keyboard Access and Focus
Thursday 12 March, 6:00 – 7:00 PM (GMT+1)
Session 4: Forms
Friday 20 March, 4:00 – 5:00 PM (GMT+1)

Upcoming Accessibility Events in March 2026

Wed, 25 Feb 2026 09:30:15 +0000

Trusted Tester Study Group

Together with the Google Developer Group Vienna, I am hosting a study group for the Trusted Tester certification. Watch the previous session recordings on YouTube. The dates and topics this month are:

Session 2: Auto-Playing and Auto-Updating Content + Flashing
Friday 6 March, 4:00 – 5:00 PM (GMT+1)
Session 3: Keyboard Access and Focus
Thursday 12 March, 6:00 – 7:00 PM (GMT+1)
Session 4: Forms
Friday 20 March, 4:00 – 5:00 PM (GMT+1)

Digital Accessibility Experts Live: Help! Accessibility is going in the wrong direction where I work. What can I do about it?

Thursday 26th March 4 PM UK-time

The global accessibility field grew in 2025. But many established accessibility initiatives in organisations also came under threat from the DEI backlash and economic budget cutting. 2026 is likely to be similar. So what can you do if your work comes under threat by decisions from your stakeholders?

AccessibleEU Latvia - People Living with Dementia. Accessibility, Solutions & Innovations. International Experience

Thursday 5 March 2026, 10:00 - 15:30 (EET)

This AccessibleEU event organised in collaboration with the Latvia Alzheimer’s Association and the Association of Disabled Persons and their Friends ‘Apeirons’, aims to raise awareness among society, including policymakers, service providers, and professionals, about how to better support people with dementia and other cognitive disorders.

Broadly defined accessibility plays a crucial role in enhancing the quality of life for these individuals - encompassing access to services, information, the built environment, and transportation.

Vienna Game Dev Meetup: No Diversity, No Games - How inclusion is no longer optional

Tuesday, Mar 3 · 6:30 PM to 9:30 PM CET Das Packhaus: Marxergasse 24, 1030 Wien, Österreich

The game industry has more talent, bigger budgets, and more powerful technology than ever before. Yet we’re stuck in sequels, safe bets, and recycled ideas. For decades, innovation was driven by hardware and graphics. That era is slowing down. Higher fidelity alone no longer creates novelty. Jack Gutmann argues that the next frontier of originality is perspective. Homogeneous teams create blind spots, predictable design, and cultural echo chambers, a form of creative inbreeding.

Vienna: Women Techmakers Conference “Break the Pattern”

Saturday 14 March, 9:00 - 15:00 TUtheSky (Getreidemarkt 9, 1060 Vienna)

Women Techmakers Vienna invites you to our International Women’s Day 2026 conference, themed “Break The Pattern.” Expect stories of non-traditional paths into tech and the moments women stepped up beyond their role to drive real change at work—improving processes, quality, leadership, and team culture. Come for practical takeaways, honest lessons, and new connections.

Accessibility Education Events in February 2026

Sun, 15 Feb 2026 12:05:30 +0000

Tuesday, Feb 17 · 11:30 AM to 1:00 PM CET

How does accessibility and internationalisation fit together?

Why does one need the other, how do they relate, what does this all mean in real life and what can we do in practice? The talk is about how internationalisation and accessibility belong together and how considering internationalisation can improve products in general and provide a good access point to create more accessible products.

RBI & SEBI Digital Accessibility Mandates: Why 2026 Is a Compliance Inflection Point for India’s Financial Services

Wednesday, 18 February | 12:00 - 1:00 PM (IST)

As RBI and SEBI place stronger emphasis on inclusive and accessible digital experiences, many banks, NBFCs, fintechs, and market participants are asking the same questions: Which guidelines apply to us? Where are the real risks? And how do we move forward without disrupting business priorities?

Zero Project Conference 2026

Wednesday 18th to Friday 20th

Live content from #ZeroCon26 will be streamed in an accessible manner via the conference platform and the Zero Project's YouTube channel. Session recordings will be made available after the conference.

Axe-Con 2026

Tuesday, February 24, through Wednesday, February 25, 2026

Topics of focus will include accessibility in development, accessibility in design, organizational success with accessibility, and a wildcard track. Talks at Axe-con will include case studies from enterprise companies leading in large-scale accessibility efforts, as well as best practices and updates from technology leaders around the world.

Document Accessibility in 2026

Thursday 26 February 4pm UK-time

Building on previous webinars from 2024 - Creating Accessible Documents – this webinar continues with Hassell Inclusion’s scoped model, by exploring what’s new, what’s changed, and what to prioritise in 2026 in the world of document accessibility.

DHS Trusted Tester Study Group Session 1 Recap

Sun, 15 Feb 2026 11:45:42 +0000

Together with the Google Developer Group Vienna, I am hosting a study group for the Trusted Tester certification. You can watch the previous session recordings on YouTube and access the presentation and transcript.

The next session will be on Friday March 6, 4 PM CET, on GDG Vienna.

What is Section 508?

Section 508 is part of the Rehabilitation Act of 1973. that requires any ICT developed, procured, maintained, or used by the U.S. Federal government to be accessible to people with disabilities. It guarantees that federal employees and the public can use government‑provided software, websites, hardware, and documents.

The DHS Trusted Tester program is a manual‑testing methodology created by the Department of Homeland Security.

It follows the ICT Testing Baseline and produces repeatable, reliable conformance results, and gives you a concrete, audit‑ready way to prove that a product meets Section 508 – far more trustworthy than relying only on automated tools.

The study group is free and 100% online. We meet every other Friday for ~6 months to go over the testing topics and examples from the Trusted Tester course. To recieve a certification, you must enroll in and complete the DHS Trusted Tester course.

Session 1 covered:

Functional Performance Criteria

Vision: No‑vision (screen reader), limited vision (magnification), no
colour perception (color contrast)
Hearing: No‑hearing (captions, transcripts), limited hearing (visual
alerts)
Speech: No‑speech
Manipulation Limited: fine motor control (keyboard‑only navigation)
Reach & Strength: Ability to press large targets, use assistive
switches
Language / Cognitive: Simple language, clear instructions, consistent
navigation

These map directly to the POUR principles (Perceivable, Operable, Understandable, Robust) that you’ll see throughout the course.

Electronic content beyond the web

One of the most eye‑opening moments for many participants was the realization that “electronic content” is a catch‑all term that includes PDFs, e‑books, emergency alerts, automated emails, survey forms, and even kiosk interfaces. The same accessibility principles that govern HTML also apply to these formats, albeit with different testing techniques.

For PDFs, for instance, you still need proper tagging, logical reading order, and descriptive alt text for images.

For e‑books, the focus shifts to structural markup that allows a screen reader to navigate chapters, tables of contents, and footnotes. The overarching message was clear: once you master the core concepts, you can transfer them to virtually any digital artifact.

Your Homework, should you choose to accept it

If you plan on taking the certification at the end of the study group, here is your homework until the next session: Complete the first 3 modules we covered in the DHS CX Directive.

What is Section 508? – theory & history
Standards for Web – POUR, WCAG, Functional Performance Criteria
Testing Tools – ANDI, autoplay settings, and contrast checker

Explore the ANDI bookmarklet on a few of your own sites, and familiarize yourself with the contrast‑checker.
Also: Check how to enable your browser’s autoplay ahead of the next session because the topic will be “auto‑playing & Auto‑updating content”.

Should you encounter any broken links in the official course, let me know. I’ve saved copies of the older resources.

Materials

When ‘It Works’ Isn’t Enough: How a Blind Hackerspace Session Exposed Flaws in UX

Mon, 10 Nov 2025 15:13:09 +0000

Recently, I visited my local hackerspace for the “Do it Blind” meetup. Do it Blind is the in-house effort to make the hackerspace itself accessible for people with visual impairments.

My friend, who had invited me, was trying out how far he could get in the 3D printing process without any sighted assistance, only using his screen reader. While my holographic Eevee coin was printing, I followed along (minus the screen reader, plus the visuals) while he installed OctoPrint on Windows (which seems worth mentioning because the Linux users in the hackerspace believed it impossible).

I want to say “it worked”, but it would be more accurate to say “he made it work”.

There was a sign-up form with no form labels and a link instead of a button. Sure, with context clues, it’s kinda obvious what 3 consecutive text input fields would want you to enter: A username, a password, and password confirmation.

But the ultimate knock-out: a modal window with 2 options to close it, but neither was present on keyboard navigation. There was no way to get past it without using the mouse.

Regardless of the 2.1.1 keyboard navigation failure, this setup flow was far from accessible. The whole point of this experiment was to find out if the 3D printing process can be done with only a screen reader and a lot of dedication. But not all assistive tech users are power users like that.

Web accessibility best practices focus on assistive tech power users.

Maybe the aforementioned Linux users in attendance were already a clue, but generally speaking, the digital literacy (and 3D printing knowledge) inside a hackerspace is significantly higher than what you find in the average population.

Unlabelled forms and overlay-window softlocks are not uncommon issues - still, in the year of 2025 - and not only screen reader users but assistive tech users all over the world are left with no other option than to make it work. Somehow.

Dark Souls Level User Experience

Again: circling back to Dark Souls. If you don’t know it, all you really need to know about it is that this game is notoriously hard to beat. Which is why I like to call user flows that are “accessible/compliant in theory” Dark Souls UX.

I have compared using assistive tech to Dark Souls before, and I will say it again: Just because it is possible to do something with assistive tech does not mean that most users will have the nerve to complete it. Yet most accessibility evaluations only look at what’s possible for users with substantial digital skills. Just because your accessibility auditor, another power user who knows the differences between NVDA and JAWS in their sleep, can navigate the page just fine, does not mean all other screen reader users will.

Yes, you can get through it. You can make it work.

But at what cost?

Good Experience or Just… Experience?

"For the love of users, stop calling it a good experience if not everyone gets to have it." - Julia Undeutsch

Assistive tech users just don’t receive the same amount of love when it comes to user flow design.
But why aren’t hoverstates designed to delight keyboard navigation users?
Why isn’t microcopy written to seamlessly guide screen reader users through the flow?

Why don’t brand guidelines include instructions on how to write descriptive alt text in line with the tone of voice?

Accessibility is mostly regarded through the technical lens, not the human one. This makes it all too easy to forget that behind all those standards, regulations, and requirements is nothing but a person trying to make it work with their setup.

Upcoming Accessibility Education Events in November 2025

Wed, 05 Nov 2025 07:42:02 +0000

The State of Accessibility in WordPress

Thursday, November 6, starting 04:00 PM CET

Join the WPCampus community on Thursday, November 6 at 10 a.m. Eastern (UTC -5) for a focused two-hour event exploring the current and future state of accessibility in WordPress through the lens of higher education.

They bring together accessibility leaders, developers, and governance practitioners for a series of sessions that connect insight to action: understanding where accessibility in WordPress stands today, how to build stronger governance structures, and what new tools are emerging to make accessibility testing more seamless and integrated.

Visit WPCampus.org/events for more information.

Getting tables right: Clear, accessible, and effective

Friday, November 7, from 1:30 PM to 2 PM CET

After the popular webinar on charts, Funka Foundation will now focus on tables. How do they work for people with different user needs? What are the main things to pay attention to? What are the main challenges? Join for an overview from the user perspective and some practical tips.

World Usability Day 2025: Emerging Technologies and Human Experience Livestream

Thursday, November 13, 6 PM to 8:30 PM CET

Talks and panel discussion on accessibility considerations through augmented reality, mobile app development, AI as assistive tech, and alternative interface design.

All events listed on WorldUsabilityDay.org

Your summary of upcoming accessibility education events in October 2025

Wed, 01 Oct 2025 11:52:09 +0000

WordPress Accessibility Meetup

Thursday, October 2 at 10 AM Central

It can be a struggle to convince your client to put in the effort and also conform to any regulation, like Section 508, the EU Accessibility Act, or otherwise. Drawing from her own experience with "difficult" clients and some basic psychology, Annelies Verhelst will provide you with compelling arguments and advice on how to make a business case.

Funka Foundation Friday Webinar: Cybersecurity + Accessibility = True

Friday, 3 October, 13.30-14.00 CEST

Cybersecurity and accessibility are both critical for resilient digital infrastructures. This webinar explains how accessibility requirements are integrated with modern cybersecurity measures. Together, they form robust and inclusive standards that support the Cyber Resilience Act.

Wagtail Space

Wednesday, October 8th - Friday, October 10th

Come join educators, publishing professionals, developers, open source enthusiasts, and leaders from organizations around the globe for three days of talks and networking.

WordPress Accessibility Day

Wednesday, October 15th - Thursday, October 16th

WordPress Accessibility Day is a 24-hour global event dedicated to promoting and learning website accessibility best practices for WordPress websites.

Today’s ship: Mock-Trade Lab, 5-min CSV Import, and bulletproof Price Fallbacks

Mon, 29 Sep 2025 12:44:26 +0000

Today’s ship: Mock-Trade Lab, 5-min CSV Import, and bulletproof Price Fallbacks

We’re building Pocket Portfolio in the open. Today we shipped three slices that make the app instantly useful.

1) Mock-Trade & Scenario Lab (live)

What: Add/remove positions, tweak size/price, and watch totals update — without touching real P/L.
Why it matters: sanity-check ideas (hedges, rebalance, scale-in) before committing. It’s the “are we sure?” layer.

Try it: open the app → Add Mock Trade → e.g., TSLA +2 @ 260.
App → https://www.pocketportfolio.app/app?utm_source=coderlegion&utm_medium=guest&utm_campaign=todays_ship

2) 5-minute CSV import (with samples + error report)

What: Drag-drop a broker CSV; we normalize it and show a clean portfolio. Includes sample CSVs and Download error report if a row fails.
Why it matters: no broker hookups, no paywalls — just get your data in and move.

How to test quickly: Menu → Import CSV → use a sample (eToro / Coinbase / Generic).
If a row trips, download the error CSV and paste a redacted line in an issue — we’ll add the mapping.

Repo → https://github.com/PocketPortfolio/Financialprofilenetwork?utm_source=coderlegion&utm_medium=guest&utm_campaign=todays_ship

3) Resilient price fallbacks (equities, FX, crypto)

What: Client→edge design with provider rotation + caching. If one endpoint blinks, we fail over.
Why it matters: fewer “0.00” moments, snappier updates, more trustworthy P/L.

No settings required — it just works across stocks, FX, and crypto.

Small technical notes

Scenario isolation: mock trades are tagged and kept out of real totals.
Edge functions: quote fallbacks and cache control live at the edge; client stays fast.
A11y/UX: import flow has clear state + error CSV, and we’re adding shortcut keys next.

Contribute (good first issues)

CSV mapping for a new broker format
Playwright tests for error-CSV → fix → success
Price fallback telemetry (simple counters, no PII)
Small UI polish on the Mock-Trade modal

Repo → https://github.com/PocketPortfolio/Financialprofilenetwork?utm_source=coderlegion&utm_medium=guest&utm_campaign=todays_ship

Try it now

https://www.pocketportfolio.app/app?utm_source=coderlegion&utm_medium=guest&utm_campaign=todays_ship

Got stuck importing? Open an issue with one redacted row; we’ll map it quickly.

Differences and stats for screen reader testing.

Thu, 25 Sep 2025 13:34:22 +0000

Online navigation works quite similarly to offline navigation, only the tools differ greatly. For online navigation, we mainly have zoom, screen magnifiers, and screen readers (or SR for short). Zoom and screen magnifiers are pretty easy to wrap your head around, either because you tested it on purpose or accidentally hit Ctrl while trying to scroll and got a jump scare by gigantic UI elements: They make things big. Checks out.

But screen readers are more intimidating at first. You boot them up and suddenly everything starts talking! Most of us are not particularly fond of their device issuing unexpected noises because it’s usually a bad thing.

While text-to-speech (or TTS for short) is the intended functionality of text-to-speech screen readers (shocking, I know), it is overwhelming at first. Monotone, technical-sounding voices are simply not a joy to listen to, especially when you have to concentrate on understanding what exactly these voices are describing to you. On another note: Braille displays peacefully coexist with TTS screen readers and are a staple for web access!

It’s time to talk about the oh-so-dreaded screen reader testing!

So screen readers read what’s on the screen? Wrong! They read what you wrote into your code! While a software tester who uses a mouse and screen might not notice that your menu exit button is actually a styled div, the SR will. And it will not work as well.

This is where the accessibility tree comes into play. The accessibility tree is how SR and other assistive tech users navigate through a website, climbing along heading levels and structures to find the desired information. The accessibility tree is sprouted by the browser based on the DOM (shorthand for Document Object Model) tree and accessed by platform-specific Accessibility APIs.

The DOM tree contains objects representing all the markup’s elements, attributes, and text nodes. This is precisely why following the h1, h2, h3 … heading structure is important. When you skip heading levels, you cut off the branches that assistive tech needs for a sound climbing route.

Example

But not all screen readers are the same. Let’s briefly go over the differences in screen reader output: Below are 2 popular screen readers reading the same thing in the same browser and both outputting something different. Feel free to copy the code, download NVDA and follow along.

Testing setup

NVDA 2024.1.0.31547 in Chrome v126.0.6478.127 on Windows 11 Enterprise
JAWS 2022.2204.20.400 in Chrome v126.0.6478.127 on Windows 11 Enterprise

The HTML

<table>
<caption>Choose your Starter Pokemon?</caption>
<tr>
  <th>Person</th>
  <th>Pokemon</th>
  <th>Type</th>
</tr>
<tr>
  <th>Julia</th>
  <td>Pikachu</td>
  <td>Electro</td>
</tr>
<tr>
  <th>Laura</th>
  <td>Eevee</td>
  <td>Normal</td>
</tr>
<tr>
  <th>Audience</th>
  <td>Magikarp</td>
  <td>Water</td>
</tr>

The CSS

table {
  font-size: 1.5rem;
  margin: 50px;
  min-height: 200px;
  min-width: 500px;
}

tr:first-child > th {
  background-color: lightblue;
  border-bottom: 1px solid darkblue;
}

td {
  text-align: center;
}

NVDA will say:

“Choose your Starter Pokémon Table with 4 rows and 3 columns Choose
your Starter Pokémon caption”

and JAWS will say:

“Table with 4 rows and 3 columns Choose your Starter Pokémon”

Same table, same code, same browser, yet 2 different outputs. That doesn’t mean that one is better than the other; they both get the job done. But be aware that there are some nuances between them.

Classic UX answer: it depends. Firstly, on your target demographic, but more tangibly, on the operating systems you are developing for. Every year, WebAIM releases a survey for screen reader users where they ask which SR-browser combination they use.

The latest survey was conducted between December 2023 and January 2024. Go check the Screen Reader User Survey #10 Results! While you’re at it, check out the WebAIM Million report as well. The Million report audited 1 million websites to give us a benchmark of progress in web accessibility over the years and the most common WCAG failures. (It’s still low contrast btw.)

JAWS and NVDA came out on top with 40.5% and 37.7% respectively. The 3rd place on the podium took VoiceOver with 9.7%. As for browsers, the big 3 are Google Chrome, Microsoft Edge, and Mozilla Firefox.

This is your event summary for upcoming opportunities in accessibility education in September 2025

Mon, 08 Sep 2025 19:46:08 +0000

WebAIM Conference

September 16-17, from 12:15 PM– 5 PM (US Eastern Time)

The Web Accessibility in Mind Conference is presented by WebAIM in partnership with Pope Tech. This virtual conference will provide conference participants with content that will help them mature their practice in digital accessibility. Our goals include:

Provide a diverse range of perspectives from a diverse group of
speakers.
Share solutions to accessibility challenges.
Give advice and guidance that helps our participants to actively
contribute to providing more accessible digital spaces.
Bring together a cross section of public and private sector
technology professionals from organizations large and small.

Google Dev Group Vienna AMA: Ask Us Anything about Accessibility

Thursday, September 18, 5:00 – 6:30 PM (GMT+2)

This session is your chance to ask all your burning questions about accessibility! Whether you're struggling with WCAG guidelines, unsure about best practices, or curious about the latest accessibility tools and techniques, we'll be here to provide answers and share insights. Panelists have backgrounds in software development, product design, UX research, QA engineering, product operations, and every single one brings deep expertise in accessibility.

Inclusive Design 24

Thursday, September 25, all day livestream on YouTube

Inclusive Design 24 (#id24) is a free 24-hour online event for the global community. It celebrates inclusive design and shares knowledge and ideas from analogue to digital, from design to development, from planners to practitioners, and everything and everyone in between.

Quick manual testing to cover basic functionalities for accessibility.

Sun, 07 Sep 2025 07:16:38 +0000

Catch ‘Em All: Hunting Accessibility Bugs Like a Champion with Manual Testing

This post is part of a series on web accessibility. Read the first part here: Web accessibility and automated testing basics explained with Pokémon.

There will come a point on your path to becoming an A11y Master when you will need to add manual testing to your team. Of course, getting proficient in testing with multiple assistive tech types would be like tapping into the power of Arceus, but you don't need to face legendary battles straight away to evolve your testing skills:

Magikarp’s splash = 1 tab

A lot of assistive tech simply simulates inputs through keystrokes. This is not limited to form inputs; keystrokes or combinations are also used to navigate a webpage. Switch buttons work the same. No, not the on/off toggle kind, I’m talking about adaptive switches. Much like disabilities, they come in a variety of shapes and sizes. They are especially important for people with mobility, flexibility, and body structure disabilities.

Functional keyboard navigation is also important for screen readers, as they mostly utilize the tab key to jump from one focusable element to the next. That makes the tab key a readily accessible tool to cover a lot of ground with. You can check which elements receive focus, if the focus follows the website structure, if one can interact with elements as expected, and if the focus is visible…

Like Magikarp's splash, the tab key doesn't do much on its own, but
once you understand how keyboard navigation works, it's a strong
addition to your testing lineup. And just like that, your keyboard
evolves into your very own Gyarados.

Eevee = Screen Readers

The normal type Eevee is not only cute but very versatile, just like the wide range of screen reader software available!

Screen readers also include the often-forgotten Braille display. Yes, it counts as a screen reader too! The only difference is that it doesn’t output in speech but translates the written text to Braille code instead.

Eeveelutions & different screen readers in different browsers

Just like an Eevee can evolve into different types, different screen readers and browser combinations will give you different outputs. But they all operate on the same foundation, so make sure landmarks and headings are in order, and your images have alt attributes filled with suitable text alternatives, so your Eevees can read every move of their opponent in battle!

To build your ultimate screen reader team, check the WebAIM screen reader user survey to find the most popular screen reader and browser pairings.

Watch out: The screen reader survey is not the ultimate representation of which combinations are the most used. The survey is sent out annually by WebAIM, but not every person who relies on it is actively keeping up with web accessibility. Especially persons with lower digital literacy who just started out using a screen reader out of necessity are unlikely to bother filling out a survey about their screen reader use. So don’t forget to test with in-built tools such as Talk Back on Android smartphones as well.

Start your adventure

With a strong team like that, you are well prepared to venture out into the World Wide Web and catch all accessibility bugs you encounter. Accessibility issues around the world are waiting for you!

Web accessibility and automated testing basics explained with Pokémon.

Thu, 04 Sep 2025 19:53:24 +0000

Catch ‘Em All: Hunting Accessibility Bugs Like a Champion with Automated Testing

So, you wanna be the very best in software testing, like no one ever was?

Testing for access barriers is part of a comprehensive quality assurance process. But where does one start? While the WCAG are as extensive as the Pokédex, what exactly is the assistive tech equivalent of Bulbasaur? Where do you start to catch ‘em all?

Accessibility is a key part of quality assurance, but navigating the world of accessibility testing tools can feel as overwhelming as choosing your first Pokémon. So, where do you start?

The WCAG are your Pokédex

How many Pokémon are there? Depends on the edition, but let’s go with the 151 from the 1st generation. How many success criteria are there? 85 in the 2.2 version. Just like Pokémon have their evolutions, success criteria have levels: A, Double A, and Triple A.

You can think of them as the same thing: each Pokémon starts out at level A, which is its base form. You can’t battle with an egg (unless you’re Misty), and your website needs to pass at least level A to have basic functionality present. The better your website usability gets, the more high-level success criteria you can pass. Like a training montage!

Not all success criteria are applicable to all websites or apps, but certain criteria are always required, such as:

1.1.1 Non-text Content
1.3.3 Sensory Characteristics
1.4.1 Use of Color
2.1.1 Keyboard Operable
2.1.2 No Keyboard Trap
2.3.1 Three Flashes or Below Threshold
2.4.1 Bypass Blocks
2.4.2 Page Titled
2.4.3 Focus Order
2.4.4 Link Purpose (In Context)
2.5.3 Label in Name
3.1.1 Language of Page
3.2.1 On Focus
3.2.6 Consistent Help (from WCAG 2.2, aka the 4th gen)
4.1.2 Name, Role, Value

These are the very, very basic requirements for your website, the very first Pokémon you catch on your adventure. Others will also be applicable, depending on the type of content you add, but these guys will be your MVP (minimal viable Pokémon) team to challenge the first gym leader to get your Level A compliance score.

While some success criteria build on each other, others are stand alone criteria. Like Ditto, Lapras, and your favorite legendary, they are not part of an evolutionary line, but they could be Level A, AA or AAA in their default form.

So while we can agree that Charmander is cute, ultimately we all want Charizard. In the same way, we shouldn’t be content with simply passing AA. If you want to become an Accessibility Champion, keep evolving and keep striving for AAA.

Pick your starter!

Now that we’ve collected our WCAG Pokédex and encouraging words from Professor Oak, it’s time to pick a starter and get started with accessibility testing!

Automated Testing

Automated testing has come a long way, but it’s not yet good enough for the Champions League. So to become an Accessibility Champion, you need to learn how to pick the right starter testing tools, then, with a few manual testing tips and tricks, plus a training montage, you will be catching accessibility bugs and barriers, like no one ever has! Let’s go meet some starters:

Pikachu = Google Lighthouse

I know Pikachu is as iconic as it can get, all the while, Google Lighthouse has a bad reputation due to a lack of accuracy. But hear me out: Lighthouse isn’t a bad tool. It can teach you a lot, but has its limits, and you won’t be able to challenge the Accessibility Champions League with it alone.

It suffers from the same problems all automated testing tools have: They can only check what they can check, meaning that they may, for example, state that alt-text is used correctly, even if the string value looks something like “asdfgThisIsGibberishTM_randomStringOfNumbers”. Yes, alt text is technically present, but with content like that, the screen reader might as well be freestyling.

But the errors it throws up are correct. You will have a straightforward list of what to fix, which makes for an easy starting point.

Web accessibility is a long road to master, including knowledge of disabilities, assistive tech hardware & software, legal frameworks like the ADA or EAA, stretching all the way to human rights, but every now and then, you will still get stuck on a bridge with niche ARIA labels and the question of what they are compatible with, blocking your way.

Bulbasaur = WAVE

WAVE is a web accessibility evaluation tool by WebAIM:

Rather than providing a complex technical report, WAVE shows your original web content with embedded icons and indicators that reveal the accessibility information within your page. WAVE cannot tell you if your web content is accessible – only a human can determine true accessibility – but WAVE can help you evaluate the accessibility of your web content.

It is a solid choice when you are starting out, but (like the plant starter in each generation) it also has its weaknesses. For example, Many landing pages use hero images at the top. WAVE doesn’t recognize if the color contrast between the background image and the text in an overlay on top of it is sufficient; all it sees is a textbox with a transparent background, so it will assume that

What I like most about it is that it lets you reference the relevant part of the source code for each issue. To become an Accessibility Champion, you have to learn how to handle accessibility in code, too. With WAVE, it’s very much a bite-sized introduction to it.

Both tools will point you toward learning resources for the particular errors they recognize. This is what makes them the perfect starter Pokémon: They are easy to use and show you where to go for more training.

When we construct the digital world to the limits of the best devices, we build a less usable one.

Thu, 13 Mar 2025 20:14:34 +0000

The Mobile Performance Inequality Gap

Setting the Benchmarks

Alex Russel, a lead performance developer at Google is a firm believer in “an internet for everyone”. He highlights this in a poignant Chrome Dev Summit talk in 2016 where he showed that when we construct the digital world to the limits of the best devices, we build a less usable one for 80+% of the world’s users.

Since things have changed since 2016, the updated golden web performance standard to achieve now is ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS (gzipped). This rule-of-thumb limit typically lasts about two years and is a hard target to meet. Most modern development tooling easily surpasses this amount in lieu of providing a robust and intuitive developer experience but there is a high cost in doing so if you’re attempting to cater to an international market, as the data suggests.

Your company’s poor site performance can manifest as lower engagement, higher bounce rates, or a reduction in conversions.

Business Impacts

The harmful business impact of poor performance is constantly re-validated. Big decreases in performance predictably lead to (somewhat lower) decreases in user engagement and conversion. The scale of the effect can be deeply situational or hard to suss out without solid metrics, but it’s there. When doing user research, Google’s Web Team found some interesting patterns:

Users hate delays and unreliability on mobile: the level of stress caused by mobile delays is comparable to watching a horror movie .

Fifty percent of smartphone users are more likely to use a company’s mobile site when browsing or shopping because they don’t want to download an app .

One of the top reasons for uninstalling an app is the limited storage (whereas an installed PWA usually takes less than 1MB).

Smartphone users are more likely to purchase from mobile sites that offer relevant recommendations on products, and 85% of smartphone users say mobile notifications are useful.

Google's approach to this problem?

According to those observations, Google found that customers prefer experiences that are fast, installable, reliable, and engaging (F.I.R.E.)! This means companies need to be laser-focused when it comes to performance budgeting. Check out the average device capability worldwide.

From 2017 data, the default global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip time (“RTT”). This translates into a budget of ~130-170KB of critical-path resources, depending on composition — the more JS you include, the smaller the bundle must be.

The single most important thing to understand about the landscape of devices your sites will run on is that they are not new phones. Two numbers set the stage:

45% of mobile connections occur over 2G worldwide

75% of connections occur on either 2G or 3G

The median user is on a slow network. Just how slow is a matter of some debate.

This makes some intuitive sense: smartphones are not in their first year (and haven’t been for more than a dozen years), and most users do not replace their devices every year. Most smartphone sales today are replacements (that is, to users who have previously owned a smartphone), and the longevity of devices continues to rise.

The worldwide device replacement average is now 33 months . In markets near smartphone saturation , that means we can expect the median device to be nearly 18 months old.

PWAs leverage modern web capabilities

How we can solve this issue of performance inequality? By recognizing the issue within our own products and services and using Progressive Web Applications as a way to overcome some technical obstacles and deliver performative, highly optimized apps quickly and effectively.

Progressive Web Apps (PWAs) are web apps that use service workers, manifests, and other web-platform features in combination with progressive enhancement to give users an experience on par with native apps.

PWAs provide a number of advantages to users — including being installable, progressively enhanced, responsively designed, re-engageable, linkable, discoverable, network independent, and secure.

PWAs are not created with a single technology. They represent a new philosophy for building web apps, involving some specific patterns, APIs, and other features. It's not that obvious if a web app is a PWA or not from first glance. An app could be considered a PWA when it meets certain requirements, or implements a set of given features: works offline, is installable, is easy to synchronize, can send push notifications, etc.

There are some key principles a web app should try to observe to be identified as a PWA. It should be:

Discoverable, so the contents can be found through search engines.

Installable, so it can be available on the device's home screen or app launcher.

Linkable, so you can share it by sending a URL.

Network independent, so it works offline or with a poor network connection.

Progressively enhanced, so it's still usable on a basic level on older browsers, but fully functional on the latest ones.

Re-engageable, so it's able to send notifications whenever there's new content available.

Responsively designed, so it's usable on any device with a screen and a browser—mobile phones, tablets, laptops, TVs, refrigerators, etc.

Secure, so the connections between the user, the app, and your server are secured against any third parties trying to get access to sensitive data.

Offering these features and making use of all the advantages offered by web applications can create a compelling, highly flexible offering for your users and customers all while keeping the performance inequality gap top of mind.

Is it worth doing all that?

Absolutely! With a relatively small amount of effort required to implement the core PWA features, the benefits for people using older and slower devices are huge. For example:

A decrease in loading times after the app has been installed, thanks to caching with service workers, along with saving precious bandwidth and time. PWAs have near-instantaneous loading (from the second visit).

The ability to update only the content that has changed when an app update is available. In contrast, with a native app, even the slightest modification can force the user to download the entire application again.

A look and feel that is more integrated with the native platform—app icons on the home screen or app launcher, applications that automatically run in full-screen mode, etc.

Re-engaging with users through the use of system notifications and push messages, leading to more engaged users and better conversion rates.

It's well worth trying out a PWA approach, so you can see for yourself if it works for your app.

Advantages of web applications

A fully-capable progressive web application should provide all of the following advantages to the user.

Discoverability

The eventual aim is that web apps should have better representation in search engines, be easier to expose, catalogue and rank, and have metadata usable by browsers to give them special capabilities.

Some of the capabilities have already been enabled on certain web-based platforms by proprietary technologies like Open Graph, which provides a format for specifying similar metadata in the HTML block using tags.

The relevant web standard here is the Web app manifest, which defines features of an app such as name, icon, splash screen, and theme colours in a JSON-formatted manifest file. This is for use in contexts such as app listings and device home screens.

Installability

A core part of the web app experience is for users to have app icons on their home screen, and be able to tap to open apps into their native container that feels nicely integrated with the underlying platform.

Modern web apps can have this native app feel via properties set inside the Web app manifest, and via a feature available in modern smartphone browsers called web app installation.

Linkability

One of the most powerful features of the web is the ability to link to an app at a specific URL without the need for an app store or a complex installation process. This is how it has always been.

Network independence

Modern web apps can work when the network is unreliable, or even non-existent. The basic ideas behind network independence are to be able to:

Revisit a site and get its contents even if no network is available.

Browse any kind of content the user has previously visited at least once, even under situations of poor connectivity.

Control what is shown to the user in situations where there is no connectivity.

This is achieved using a combination of technologies: Service Workers to control page requests (for example storing them offline), the Cache API for storing responses to network requests offline (very useful for storing site assets), and client-side data storage technologies such as Web Storage and IndexedDB to store application data offline.

Progressive enhancement support

Modern web apps can be developed to provide an excellent experience to fully capable browsers, and an acceptable (although not quite as shiny) experience to less capable browsers. We've been doing this for years with best practices such as progressive enhancement. By using progressive enhancement, PWAs are cross-browser. This means developers should take into account the differences in the implementation of some PWA features and technologies between different browser implementations.

Re-engage ability

One major advantage of native platforms is the ease with which users can be re-engaged by updates and new content, even when they aren't looking at the app or using their devices. Modern web apps can now do this too, using new technologies such as Service Workers for controlling pages, the Web Push API for sending updates straight from server to app via a service worker, and the Notifications API for generating system notifications to help engage users when they're not actively using their web browser.

Responsiveness

Responsive web apps use technologies like media queries and viewport to make sure that their UIs will fit any form factor: desktop, mobile, tablet, or whatever comes next.

Secure

The web platform provides a secure delivery mechanism that prevents snooping while simultaneously ensuring that content hasn’t been tampered with, as long as you take advantage of HTTPS and develop your apps with security in mind.

It's also easy for users to ensure that they're installing the right app because its URL will match your site's domain. This is very different from apps in app stores, which may have several similarly-named apps, some of which may even be based on your site, which only adds to the confusion. Web apps eliminate that confusion and ensure that users get the best possible experience.

Coder Legion - Recent posts tagged a11y

I'm Blind. I Built a Professional Video Editor. Here's Why.

Why I built Animal Sudoku without a single ad

The problem that bothered me

What Animal Sudoku is (and isn't)

What it isn't:

Engineering for Every Child: Accessibility first

If you have small humans in your life

Beyond a Country Explorer: Accessibility & Architecture in React

React #Accessibility #FrontendArchitecture #WebDevelopment #CleanCode #A11y

Automated Accessibility Testing: axe-core, Keyboard Navigation, and WCAG in the Browser

The gap: accessibility tests that run in jsdom

Approach 1: axe-core, scanned after the interaction

Approach 2: keyboard navigation and focus order

Watch out with automated accessibility testing

Why this matters to us

Try it

As We May Code: Why Software Is a Human Problem Dressed in Logic

I. The deterministic illusion

II. Interfaces are wicked problems

III. HTML: the most human language in code

IV. What the machines see

V. The old tension, resurfaced

VI. As we may code

References

Free upcoming accessibility education events in May

I Built a Free Accessibility Auditor That Actually Passes Its Own Audit

20 Unknown HTML Tags That Will Make You Write Less And Better Code

The Semantic SEO Power-Ups

<search>

<time>

<address>

️ Data & Precision Layout

<meter> vs. <progress>

️ <data> & <abbr>

️ <figcaption>

✍️ Precision Typography (The "Grammar" Tags)

<ins> & <del>

<mark> & <dfn>

⌨️ <kbd> & <code>

<ruby> (with <rt> and <rp>)

Interactive & Internationalization

<details> & <summary>

↔️ <bdi> & <bdo>

<output>

<wbr>

<cite> & <q>

The Bigger Picture

DHS Trusted Tester Certification Study Group: Mastering Dynamic Web Content

Resources

Study Group Session 2

Audio Control: The Three-Second Threshold

Blinking, Moving, and Scrolling

Auto-Updating Content: Live Regions and Dialogs

Flashing Content: The Seizure Safety Net

Knockout Criteria

Homework

Next Session

Accessibility Events in March 2026

Trusted Tester Study Group

Upcoming Accessibility Events in March 2026

Accessibility Education Events in February 2026

DHS Trusted Tester Study Group Session 1 Recap

What is Section 508?

Functional Performance Criteria

Electronic content beyond the web

Your Homework, should you choose to accept it

Materials

When ‘It Works’ Isn’t Enough: How a Blind Hackerspace Session Exposed Flaws in UX

Web accessibility best practices focus on assistive tech power users.

Dark Souls Level User Experience

Good Experience or Just… Experience?

Upcoming Accessibility Education Events in November 2025

World Usability Day 2025: Emerging Technologies and Human Experience Livestream

Your summary of upcoming accessibility education events in October 2025

Today’s ship: Mock-Trade Lab, 5-min CSV Import, and bulletproof Price Fallbacks

Today’s ship: Mock-Trade Lab, 5-min CSV Import, and bulletproof Price Fallbacks

1) Mock-Trade & Scenario Lab (live)

2) 5-minute CSV import (with samples + error report)

3) Resilient price fallbacks (equities, FX, crypto)

`<search>`

`<time>`

`<address>`

`<meter>` vs. `<progress>`

️ `<data>` & `<abbr>`

️ `<figcaption>`

`<ins>` & `<del>`

`<mark>` & `<dfn>`

⌨️ `<kbd>` & `<code>`

`<ruby>` (with `<rt>` and `<rp>`)

`<details>` & `<summary>`

↔️ `<bdi>` & `<bdo>`

`<output>`

`<wbr>`

`<cite>` & `<q>`