Coder Legion - Recent posts tagged accessibility

When Should Delete Offer Undo?

Mon, 26 Oct 2026 10:29:03 +0000

Undo is useful only when it genuinely restores what the user lost. A confirmation dialog is useful only when it explains the consequence—not just “Are you sure?”

Consider a hypothetical media app where someone deletes a set of property photos. My starting point would be:

Reversible removal: move files to trash, show a clear Undo action, and keep a discoverable recovery route after the toast disappears.
Permanent or bulk deletion: show the affected names or count, what cannot be restored, and whether shared access will be affected before proceeding.
Partial failure: report which files changed instead of claiming the entire operation succeeded.

The tricky case is shared assets: restoring a file may not reverse notifications or other effects that already happened.

W3C’s error-prevention guidance provides a useful reference for certain important submissions and changes to user-controllable stored data: reversal, checking, or confirmation. It does not mean adding a confirmation dialog to every routine edit.

Where do you draw the line between Undo, confirmation, and both? Would your answer change for one recoverable file versus a folder shared with a team?

Cover: original AI-generated conceptual illustration. The interfaces and recovery period shown are fictional, not a product demonstration.

When Is a Progress Bar Misleading?

Sun, 25 Oct 2026 10:26:33 +0000

A progress bar should tell users what has been measured, not just reassure them that something is happening.

Consider a hypothetical photo-processing tool: upload progress is measurable in bytes, but the next step might wait in a queue or take a different amount of time for each image. A bar that reaches 99% and then stalls can turn a useful signal into false precision.

My proposed default would be:

Use a percentage for work with a meaningful, known total.
Use explicit stages such as Queued → Processing → Ready when completion time is uncertain.
Show completed-file counts for batches, while making clear that files may take different amounts of time.
Keep failure and cancellation states separate from progress.

There is an accessibility detail too: status updates should be available to assistive technology without moving keyboard focus. W3C's guidance on status messages also warns against making updates too chatty; announcing every tick is not necessarily helpful.

Where would you draw the line between a useful estimate and false precision? Would you show stage labels, an estimated range, or a percentage when processing time varies?

Cover: original AI-generated concept illustration of fictional processing interfaces, not a product screenshot or performance result.

Image SEO in 2026: Alt Text, Modern Formats and Fast Loading

Fri, 23 Oct 2026 04:00:46 +0000

Image SEO in 2026 boils down to three jobs: describe every image accurately, deliver it fast, and make it discoverable and attributable. This guide covers each with copy-ready HTML, sticking to what Google, web.dev and the browser makers actually document.

It starts with a rule that catches many modern sites: Google indexes images in an img element (including inside picture) but not images set as CSS backgrounds. Then description: alt text that says what the image shows and why it's there, in plain words, with empty alt for decoration and any text inside a graphic repeated in the alt. Filenames, captions, nearby text and page titles all help Google understand an image, and the title attribute isn't a substitute for alt.

For speed, I recommend serving AVIF or WebP through a picture element with a JPEG or PNG fallback (and making sure the server sends the right content type), setting width and height on every image to prevent layout shift, using srcset with sizes so phones don't download desktop files, lazy-loading below the fold, and never lazy-loading the main image, which should get fetchpriority="high" instead.

I also cover image sitemaps, the image property in structured data, licence metadata for Google's Licensable badge, and what's actually documented about Google Lens and multimodal AI Mode: use your own photos and explain them in text nearby. A checklist and honest limits close it out.

Key takeaways

Use real img elements; CSS background images aren't indexed
Write alt text that describes what the image shows
Serve AVIF or WebP with a fallback
Always set width and height to prevent layout shift
Lazy-load below the fold, but prioritise the hero image

Related on BuiltToWinWeb: what makes a website load fast

Read the full guide on BuiltToWinWeb: The image SEO guide for 2026

A summary by Jacob Campbell of an article first published on built2winweb.com on October 7, 2026.

Can a Keyboard-Only User Finish Your App’s Main Task?

Mon, 19 Oct 2026 07:41:47 +0000

Pick the main task in your web app: submitting a form, uploading a file, booking an appointment, or creating a project.

Now put the mouse aside and try to finish it using the keyboard.

Where does the journey first become confusing or impossible?

Some useful places to check:

A custom dropdown that opens but cannot be operated
A dialog that opens without a clear focus position
A validation error that appears somewhere the user does not notice
A drag-and-drop interaction with no usable alternative
A focus indicator that disappears against the background
A component you can enter but cannot leave

W3C’s keyboard accessibility guidance explains why functionality needs a keyboard-operable route, with a limited exception for inherently path-dependent input. Its no-keyboard-trap guidance addresses being able to leave a component again.

A keyboard walkthrough is a useful first check. It does not establish full accessibility or replace screen-reader and other accessibility testing.

What is one keyboard-accessibility bug your team found late, and what changed in your development or review process afterward?

If you are building something new, which critical flow will you test first?

Waqas Ahmad | Software Engineer | Content Creator

My GitHub Sponsors Is Live: Help Me Build Creative Tools Blind People Can Actually Use

Wed, 14 Oct 2026 16:46:58 +0000

After months of waiting, my GitHub Sponsors profile is finally live! 🎉

Who I am

I'm Demir Ajvazi, a blind developer from Serbia. I've been using the JAWS screen reader for about 20 years. For most of that time, I've watched creative software lock out people like me: professional video, audio and photo editors are nearly impossible to use with a screen reader.

What I'm building

So I started building the Ultra Creative Suite: open-source creative tools designed from the ground up to work equally well for blind and sighted users. Not a stripped-down "accessible mode", and not a workaround, but real tools that both blind and sighted creators can use side by side.

Alongside the suite, I'm working on other accessible tools:

UltraShield: an accessible digital self-defense app for Windows
Ultra Uninstaller: a Windows uninstaller and cleaner that is fully usable with a screen reader
Ultra Bridge: a JAWS and NVDA command-mapping helper

You can find everything here: github.com/demirajvazi10-max

How you can help

If you believe blind people deserve the same creative tools as everyone else, you can now support my work directly:

👉 github.com/sponsors/demirajvazi10-max

Monthly sponsorships start at $3, and one-time support is welcome too. Every contribution goes directly into development and keeps everything free and open source.

Can't sponsor? That's completely fine. Sharing this post, starring a repo, or trying the apps with a screen reader and telling me what doesn't work helps just as much.

Thank you for reading!

AmazingPlugins

Wed, 14 Oct 2026 10:51:32 +0000

Every WooCommerce store owner knows the feeling. An order gets stuck in processing, a customer emails to say the checkout button does nothing with a screen reader, or a price change across two hundred products eats a whole afternoon. These are not exotic problems. They are the everyday friction of running a real shop, and they quietly cost sales.

The usual answer is a heavy premium plugin, a monthly subscription, or a script that sits on top of your theme and pretends to fix things. There is a better way: small, focused, free tools that solve one problem properly.

Accessibility is a good example. Many "accessibility" products add an overlay widget that changes how the page looks without touching the underlying code. Assistive technology still meets the same broken markup. A real fix means correcting the HTML itself: proper labels on form fields, meaningful button names, sensible heading order, and focus that lands where a keyboard user expects. Accessibility Fixer from AmazingPlugins does exactly that inside WooCommerce, so the improvement is in the page, not painted over it.

Order problems deserve the same treatment. Orders that never leave pending, statuses that drift out of sync with payments, and stock that does not match reality all create support tickets. Order Fixer looks for these common breakages and helps you put them right without exporting spreadsheets or editing the database by hand.

Bulk editing is next. Smart Bulk Editor, coming soon, is built to let you change prices, stock and attributes across many products quickly and safely.

The idea behind all of this is simple. A store owner should be able to install a free tool, see the problem fixed, and move on with the day. No bait and switch, no surprise paywall halfway through a task. If your WooCommerce shop has any of these headaches, take a look at the free plugins at https://amazingplugins.com and pick the one that matches your problem.

Your Repo Can Now Tell People It Cares About Accessibility

Mon, 12 Oct 2026 18:17:21 +0000

Open any repository on GitHub and you see the same tabs: README, Code of Conduct, Contributing, Security. As of October 1, there can be one more: Accessibility.

GitHub now highlights an ACCESSIBILITY.md file on the repository overview and links to it from the About section. It is a small change, and it puts accessibility on the front page of your project, next to the files every contributor already reads.

We added one to TWD right away. Here is why, and what we learned.

Why it matters

Picture someone who uses a screen reader trying out your library. Something in the docs doesn't work for them. Today, they have to guess: is this a known issue? Does anyone care? Where do I even report it?

An accessibility page answers all three before they ask. It says this project takes accessibility seriously, here is what we have tested, and here is how to tell us when something gets in your way.

It also helps the other side. Contributors see, in plain words, what is expected of a change that touches the UI.

What we put in ours

TWD had a head start. In June we had it independently audited against WCAG 2.2 AA, fixed what the auditors found, and published a formal accessibility statement.

We expected to copy and paste that statement. We didn't. A formal statement is written for compliance. The GitHub page is written for people, so we wrote it in plain language around three ideas:

Be honest about what was tested. Our audit covered the sidebar and the main docs pages, using a keyboard and the NVDA screen reader. So that is what the page claims. For everything else, WCAG 2.2 AA is our goal, and we say so.

Make reporting easy. Open an issue, send an email, or ask in Discussions. No need to know which guideline is involved, and no need to share anything personal. We commit to replying within 5 business days.

Tell contributors what good looks like. Keep it usable with a keyboard, keep focus visible, don't rely on colour alone, and include light and dark screenshots with UI changes.

You can read the result here: TWD's ACCESSIBILITY.md.

Add one to your project

You don't need an audit to start. You need an honest page.

Create ACCESSIBILITY.md in your repo root (or in .github/ or docs/).
Start from GitHub's template, or add it from your repo's Community Standards page.
Fill in the two sections that matter most: how to report a barrier, and what you have and haven't tested.

That's it. The tab appears on your repo's front page.

Accessibility work usually happens out of sight. Now it has a place on your repo's front page, where users and contributors will see it.

FOUC-Proof Retro Design Systems

Sat, 03 Oct 2026 09:06:20 +0000

When building web interfaces with a retro arcade aesthetic, developers often adopt vibrant neon color palettes to recreate an 80s terminal feel. However, applying these bright accents directly across both light and dark surfaces introduces two critical problems. First, neon shades like electric cyan frequently fail minimum WCAG contrast requirements against pale backgrounds, dropping below the 4.5 to 1 ratio needed for accessibility. Second, relying on client-side JavaScript or late-loading framework components to manage theme state causes a jarring Flash of Unstyled Content or white flash during document parsing. Solving these issues requires combining asymmetric color calibration with synchronous pre-render execution in static site generators like Astro. For a related implementation, see Offline First Event Pipeline.

The Pitfall of Retro Aesthetics on the Web

Nostalgic design systems rely heavily on high-contrast neon tones to establish character. While electric cyan or neon green looks striking against a dark matte chassis, using those exact same hex codes on a light background destroys readability. A color that passes contrast checks in a dark environment will often wash out completely on a light surface. Attempting to fix this by handcoding individual theme styles across disparate components leads to code duplication and visual fragmentation. Maintaining a cohesive brand identity requires a structured token architecture that adapts semantically depending on the active theme mode.

The Mathematics of Accessible Contrast

To keep a consistent visual identity without sacrificing readability, the color system must use dual-role semantic token calibration. Instead of forcing identical accent values in both modes, the primary accent variable shifts based on the document theme attribute. In light mode, the system switches to a calibrated deep arcade teal that achieves a WCAG AAA contrast ratio against pale surfaces. In dark mode, it returns to the high-vibrancy electric cyan. Secondary accents, such as a high-energy orange tone, serve consistently as action indicators. The following CSS custom property configuration demonstrates how to structure these semantic tokens at the root level: For a related implementation, see Audit Macos System Data Before Deleting.

:root {
  --surface: #fbfcfc;
  --surface-raised: #f0f2f5;
  --text-main: #111418;
  --accent: #007e85;
  --accent-secondary: #ff5722;
  --line: #d1d5db;
}

[data-theme="dark"] {
  --surface: #0e1114;
  --surface-raised: #161b22;
  --text-main: #f0f6fc;
  --accent: #00adb5;
  --accent-secondary: #ff5722;
  --line: #30363d;
}

Eliminating FOUC with Synchronous Head Scripts

Even with well-structured CSS variables, waiting for external stylesheets or framework hydration to apply the correct theme attribute creates visual flicker. Client-side scripts that execute inside DOMContentLoaded or standard component lifecycles run too late in the rendering pipeline. To eliminate this delay, a blocking script must execute synchronously inside the document head before the body layout paints. By checking localStorage or prefers-color-scheme immediately, the browser can set the target attribute and background color instantly. The following component snippet illustrates how to implement this pattern in an Astro layout:

<script is:inline>
  const storedTheme = localStorage.getItem('theme');
  const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
  const theme = storedTheme || (prefersDark ? 'dark' : 'light');
  
  document.documentElement.setAttribute('data-theme', theme);
  if (theme === 'dark') {
    document.documentElement.style.backgroundColor = '#0e1114';
  } else {
    document.documentElement.style.backgroundColor = '#fbfcfc';
  }
</script>

Maintaining a Single Source of Truth

Scaling a token-based design system across static sites and standalone tools requires clear organizational boundaries. Core platform utilities like extension showcases or isolated calculators may demand independent UI scopes, but editorial and reading surfaces must consume global design variables uniformly. Desktop reading aids, active bullet indicators, and border lines should bind directly to semantic variables like --accent and --line rather than hardcoded color values. Keeping these token mappings documented in a versioned reference file ensures consistency across design vaults and code repositories without introducing runtime overhead.

What a 100 Accessibility Score Didn't Check

Thu, 01 Oct 2026 11:55:45 +0000

Originally published on Hashnode: https://tarek-elzoghby.hashnode.dev/what-a-100-accessibility-score-didn-t-check

Lighthouse gave my practice site a 100 for accessibility. Then I went through it by hand, checking what Lighthouse doesn't, and found a markup mistake that neither Lighthouse nor a screen reader had flagged. This post covers what I checked, what I found, and what I changed.

I built a one-page site for a made-up potter as a practice brief: hero, about, gallery, contact. The client and the name are fictional. I worked with an AI as a design partner throughout, mostly to review my HTML and talk through decisions before I made them. The code is on GitHub. This post is only about the last stretch, after everything was built, when I went back through it for accessibility.

The baseline

Lighthouse gave me 99 Performance, 95 Accessibility, 100 Best Practices, and 91 SEO. Accessibility had exactly one complaint: the three contact links had low color contrast.

The links were set in terracotta (#B5603F) on a cream background, which comes to about 3.9:1. Normal-size text needs 4.5:1 to pass WCAG AA (the conformance level most sites aim for). Terracotta was the single accent color in the whole design, reserved for real calls to action, so I didn't want to drop it. The palette already had --color-primary-dark, a darker shade I'd originally made for hover states. I pointed the links at that instead. Accessibility went to 100 from that one change.

The link color had looked fine to me by eye, and it failed anyway. That's why I ran the audit at all.

What the 100 covers

A Lighthouse score covers the checks Lighthouse runs. It says nothing about the ones it doesn't. So I went through the site by hand, looking for gaps.

Decorative icons

The contact section has three inline SVG icons (email, phone, Instagram), each next to a text label that says the same thing. Screen readers handle inline SVGs inconsistently. Some announce "graphic," some read out raw markup, some skip them. Nothing breaks, but the experience is unpredictable, and the icons carry no information the label doesn't already carry.

<svg class="contact-icon" aria-hidden="true" focusable="false" ...>

aria-hidden="true" removes the icon from the accessibility tree (what assistive technology reads instead of the visual page). focusable="false" is a safety net for older IE and Edge, where SVGs could be focusable by default and pick up a stray tab stop.

Landmarks

Lighthouse checks that basic page structure is present. It doesn't check whether landmarks are useful. <main> gave me one landmark for free. The four blocks inside it (hero, about, gallery, contact) weren't landmarks at all. A plain <section> only becomes a region landmark once it has an accessible name, and <address> has no landmark role by default.

So the question I worked out before touching any markup was which sections are places someone would want to jump to. Having a heading wasn't the test.

The hero is where a screen reader user already lands, so making it a landmark would only add a "you are here" entry to the jump list. About, Gallery, and Contact are content someone might skip straight to. Those three got landmark status.

For About and Gallery, I gave the <h2> inside each an id and pointed the parent section at it:

<section aria-labelledby="about-heading">
  <h2 id="about-heading">About me</h2>
  ...
</section>

Contact was different. Its wrapper was an <address>, and aria-labelledby on an element with no landmark role names something that was never a landmark. I added role="region" alongside it:

<address role="region" aria-labelledby="contact-heading">
  <h2 id="contact-heading">Contact</h2>
  ...
</address>

Contact is as much a jump-to destination as the other two, and its tag choice shouldn't make it the odd one out. That got it into the landmark list, and it was still wrong. <address> is for contact details, and the HTML spec doesn't allow heading elements inside it, so the <h2> there was invalid markup. I found this later, when the AI reviewed the repo again before I wrote this post. Nothing I had run flagged it, and NVDA (a free screen reader for Windows) listed the region as if nothing were off.

The fix was smaller than I expected. I changed the wrapper from <address> to <section> and removed role="region". Everything else stayed the same:

<section class="contact" aria-labelledby="contact-heading">
  <div class="address-content">
    <h2 id="contact-heading">Contact</h2>
    ...
  </div>
</section>

A <section> with an accessible name is already a region, so once the tag was right the role had nothing left to do.

Checking it

Reading markup only tells me what I intended. I opened NVDA's Elements List (NVDA+F7) and filtered to Landmarks. It showed the implicit main plus three named regions: About me, Recent Work, and Contact. The hero was correctly absent and nothing was duplicated.

That check passed on the version with the invalid <address>. It tells me what a screen reader is given, not whether the markup is valid. Validity is a separate check, and the W3C validator is the one that covers it.

What's still open

Accessibility is at 100. I left SEO at 91 on purpose. What remains there depends mostly on the meta description and real content, which is better written once real copy and photos exist than guessed at now.

What does your accessibility pass cover that Lighthouse doesn't? I'm still building my own list and would like to see yours.

Your site looks AI-generated. Here's how to fix it

Fri, 25 Sep 2026 07:05:29 +0000

The default look is underspecified taste, not a hard model limit. Brief with references, name visitor jobs, then audit the live URL and accessibility tree.

Stakeholders rarely say “your typography hierarchy is weak.” They say the site looks AI-generated. That complaint is usually accurate about defaults, not proof that models cannot ship distinctive work. When the brief is vague (“modern”, “clean”, “premium”), generators and humans both fall back on the same training-set average: indigo heroes, three feature cards, Inter everywhere, and copy that could sell any SaaS.

Banning AI assistance does not fix the average. Removing the average from the brief before the first generation does, then two honest passes on the live URL. We learned that the hard way while shipping Apogee Watcher’s public site: without written design rules, every agent draft drifted toward the same marketing-site defaults (soft shadows, rounded cards, stock gradients). The steps below are what we use on our marketing pages and on client landing pages. They clean generic defaults. They do not replace a designer for a full brand system.

Why the AI look shows up so often

Public UI training data is heavy on starter kits, component demos, and tutorial landings. Predictable next tokens therefore favour the same layout grammar and the same safe palette. Teams amplify that by pasting soft adjectives into the prompt and accepting the first render that “looks done.”

The fingerprint is easy to list once you have seen it twice: cool purple-to-blue gradients, evenly rounded cards with soft shadows, icon rows with abstract nouns, and body copy that starts with empower, unlock, or transform. None of those choices is illegal. Together they look like a template nobody chose on purpose.

On Watcher we treat that fingerprint as a reject list, not a mood board. Our public design system (Technical Brutalism) bans purple or indigo gradients, glass, pill-shaped buttons, blurred shadows, and a second typeface beside Victor Mono. Depth comes from 2px charcoal borders and hard offset shadows (4px 4px 0), not from glow. The first pass that ignored those bans looked “finished” and still read like every other monitoring landing page. The pass that named the bans in the brief stopped inventing soft polish we would have deleted anyway.

Performance and accessibility suffer in the same pass. Generic hero images arrive oversized. Consent banners and chat widgets appear late and shift layout. Focus order follows the card grid rather than the visitor’s job. That is why this craft problem sits next to monitoring work as often as it sits next to Figma.

Pass one: brief the agent with references and reasons

A short brief the model (or a junior) cannot ignore usually includes:

Two to five visual references with a one-line why for each (“asymmetric hero like reference A because the product is a dashboard, not a brochure”).
Palette tokens that are not stock indigo/slate, named for your brand, not for Tailwind’s defaults.
One typography pairing with roles (display vs body), not “use a nice sans.”
Layout constraints that break the vertical stack (offset columns, full-bleed media, or a single strong edge).
Banned phrases and banned class patterns you will reject in review.

Our Watcher brief is concrete enough that a stranger could reject a bad render without a design review meeting. Primary orange is #ff6633 on charcoal #2e2e2e, not “energetic accent.” Type is Victor Mono only, uppercase for display and buttons, with no Inter, Geist, or system sans as a fallback. Corners stay square except on score gauges and status dots. Section voice uses code-style decorations (// headings, > list lines, [ ] links) because the product is monitoring for technical buyers, not a lifestyle brand. Hero clutter is banned explicitly: brand, one headline, one supporting sentence, one button or form group, one product visual. When we leave those why lines out, agents reintroduce cream backgrounds with serif headlines or purple mesh backgrounds we already ruled out in writing.

Asking for rationale in the output (“this accent comes from reference B”) makes decorative noise easier to reject. Vague praise words (“make it premium”) invite the average back in. References without why do the same: the model copies surface styling instead of the decision behind it.

Pass two: describe visitor jobs before visual direction

Three concrete jobs a visitor must complete in the first session work better than a mood board. On apogeewatcher.com the first-session jobs we design for are roughly: run a free domain check, compare agency vs solo pricing, and start a trial. Feature cards and FAQ earn their place only after those jobs are clear. Colour, radius, and motion come after the outline, not before.

When jobs come first, sections stop being filler. A pricing block earns its place because a job needs it, and a testimonial earns its place because a trust gap is real. Agents that start from “add social proof” invent filler; agents that start from jobs prune it.

Generic monitoring mistakes match generic design mistakes here. Homepage-only URL lists and homepage-only design briefs both miss the pages that make money. If checkout or pricing is the job, that URL and that layout get attention first.

Pass three: treat the agent as a potential customer on the live URL

After generate or revise, what matters is the deployed URL (staging is fine; a Figma frame is not). The same agent (or a second one), with no prior context, trying to complete the visitor jobs, usually shows where people click, what confuses them, and what feels templated. Pasting that transcript into the ticket keeps the review grounded.

Humans still walk the path once. Agents miss brand judgment and over-index on polish. In our nav work we have rejected “finished” buttons that looked correct alone and still felt wrong on the live page: for example a Start now control that needed a flat charcoal border once the hard drop shadow made it look floaty instead of sharp. The point of the pass is cheap friction discovery: dead ends, identical cards, hero copy that never names the product, and buttons that compete.

While that URL is open, a glance at lab and field performance on the money pages belongs in the same review. A beautiful default that ships a multi-megabyte hero still costs conversion. We have written about why slow pages lose revenue and trust in The Real Cost of Poor Web Performance. Design taste and performance budgets belong together.

Pass four: run an accessibility check as a UX pass

Many accessibility rules are taste and clarity wins, not only compliance. Heading order, landmarks, focus visibility, contrast, alt text that describes function, and forms that announce errors catch problems that a visual pass misses. Broken hierarchy is a common AI leftover: several visual “H1s” that are really styled divs, or an H2 that skips levels because the card grid looked balanced.

On Watcher marketing pages the orange-on-charcoal contrast and visible focus rings are part of the same brief as the orange button colour. Agents that only “make it pop” often fail keyboard focus or invent decorative headings that never reach the accessibility tree. We map which accessibility fixes also move Core Web Vitals conversations in Accessibility and Core Web Vitals. For semantic heading discipline as craft, our Hashnode note on heading hierarchy as a non-negotiable (not a design trade-off) pairs with this pass. If you already audit the accessibility tree for AI search and agents, that output is reusable here: the tree is what assistive tech and many agents walk, and a green Lighthouse a11y score alone will not catch a decorative heading soup.

What this ritual will not do

It will not invent a brand system, illustration language, or motion design from nothing. Watcher’s Technical Brutalism existed as written design tokens before we asked agents to restyle pages; the steps above only keep generations inside that fence. It will not excuse skipping a designer when the client needs a durable visual identity. It will not fix a product that has no clear visitor job. It will remove the default look that makes stakeholders say “this looks AI-generated,” and it will catch the performance and accessibility debt that often ships with that look. That is enough for many landing pages and enough to brief a designer properly when the work is larger.

Ship the next page without the average

A useful sequence is references-and-why brief, visitor jobs, generate, live URL as a stranger, then accessibility and performance glance before the presentation. AI stays useful as a drafter and a critic; humans decide taste and stay accountable for the result. Teams that look after many client domains usually pair these design checks with scheduled PageSpeed evidence so “it looks fine” and “it measures fine” are not separate Mondays. Start a Watcher trial when that evidence needs to span a portfolio.

References

Apogee Watcher homepage (Technical Brutalism example)
Accessibility and Core Web Vitals (Apogee Watcher)
The Real Cost of Poor Web Performance (Apogee Watcher)
How to fix the 'AI-generated' look in your frontend (Alan West / DEV)
How to Spot AI-Generated Design (UX Planet)

Originally published on Hashnode.

Audit the accessibility tree, not only the Lighthouse a11y score

Sun, 13 Sep 2026 07:35:04 +0000

Agents and screen readers share the same semantic layer. A green Accessibility category is not proof that money-page actions have roles, names, and landmarks machines can use.

The accessibility tree is the structured layer the browser builds from the DOM: roles, names, and states that assistive technology has used for decades. Screen readers walk it. Playwright can snapshot it. Agentic browsing tools that refuse to read pixels lean on it as well. That is a different artefact from the Lighthouse Accessibility category score, which answers whether a fixed set of automated checks passed on one lab run. Teams that treat a green score as proof that AI agents or assistive technology can complete a purchase path are mixing two jobs.

John McAlpin’s August 2026 Search Engine Land piece on SEO use cases for auditing the accessibility tree pushed the tree into SEO conversations because agents now consume the same layer. That framing is useful for account teams who already hear “AI search” in every pitch deck, but a feature rundown is not an ops playbook. Agency work still needs a shorter cut: what the tree is, why the Lighthouse score is not a substitute, and which audits belong on money pages and in continuous integration.

What the accessibility tree exposes (roles, names, states)

Browsers compute an accessibility tree from markup, styles that affect visibility, and ARIA. Each node that matters usually carries a role (button, link, heading, textbox), an accessible name (the label a stranger would hear or read), and state (expanded, disabled, checked). Chrome DevTools can show the full-page tree beside the DOM. Playwright’s ARIA snapshots export a YAML view of the same structure for tests.

Chrome DevTools Accessibility tab with “Show accessibility tree” on: roles and names replace the DOM view so you can see what assistive technology (and many agents) actually receive. Source: Chrome for Developers accessibility reference (captured 12 Sep 2026).

Sighted users often infer structure from size and whitespace. Machines do not. A pricing call to action built as a clickable div with no name may look perfect in a design review and still be absent or anonymous in the tree. That gap is what SEO and agent-readiness briefs are naming in 2026, and it is the same gap accessibility specialists have been filing for years.

Lighthouse accessibility score versus an accessibility tree audit

Question	Lighthouse Accessibility category	Accessibility tree audit
What does it answer?	Did a fixed set of automated checks pass on this lab load?	Can a reader of roles, names, and states complete the jobs on this URL?
Typical output	Weighted 0–100 score plus failed audits	Pass/fail on CTAs, forms, landmarks, headings, image names
Strength	Fast regression signal in CI and PageSpeed Insights	Catches unnamed controls and visual-only structure the score can miss
Limit	Not a full WCAG audit; green is not “accessible”	Point-in-time unless you snapshot in CI

Chrome documents how the Lighthouse accessibility score is weighted, and that documentation is the authoritative entity for the score itself. Our operational point is narrower: keep running the score, and still open the tree on revenue URLs. A page can pass colour-contrast and label audits while the primary checkout button remains a nameless control, or while product copy that sells the offer only appears after client-side hydration that some agents never finish.

PageSpeed Insights desktop lab for apogeewatcher.com (12 Sep 2026): Accessibility 92 is a useful regression signal, not proof that every money-page control has a clear role and name in the tree. Agentic Browsing sits beside it as a separate lane.

Accessibility work that also improves Core Web Vitals (keyboard latency, layout-stable focus) is a separate prioritisation problem. We cover that crosswalk in Accessibility + Core Web Vitals. The tree audit below is about machine-legible structure, not whether Interaction to Next Paint moved on a dashboard.

Money-page checklist: can an agent act from the tree alone?

A workable seed set is usually ten to twenty URLs ranked by revenue or conversions, not by homepage vanity. Homepage-only samples miss the templates where unnamed calls to action actually sit. For each URL, the useful capture is the tree itself (DevTools full-page view, or a headless export), then a short pass/fail score against:

Primary call to action exposed as a button or link with a descriptive accessible name.
Every form control has a programmatically associated label.
Navigation sits in a navigation landmark; main content sits in a main landmark.
Pricing, product details, and contact facts appear as readable text nodes, not only in images or canvas.
Interactive state that users see (open accordion, enabled submit) updates in the tree (aria-expanded, disabled, and similar).

What good looks like: a stranger reading only roles and names could name the page’s jobs and complete them without guessing. Failures usually trace to div click handlers, icon-only buttons without names, or inputs missing labels. Native HTML covers most controls; ARIA fits when native elements cannot express the widget.

McAlpin frames this as an agent readiness audit. The same bar applies to assistive technology. If the tree lies about state, a screen reader user is misled with the same confidence an agent would be.

JavaScript rendering gaps the accessibility tree makes obvious

Traditional rendering checks ask whether content appeared in the HTML or after hydration. The accessibility tree asks a sharper question: did substance reach the layer agents and assistive technology read, and when? Capture the tree before and after client-side JavaScript where your tooling allows a diff. Core headings, primary links, and product grids that exist only in the post-hydration tree are invisible to any consumer that does not fully execute your scripts. That pattern is familiar from crawler audits; the accessibility tree simply makes the missing nodes explicit. When the tree before hydration is empty of the jobs you sell, server-render or pre-render those money templates so substance is present before scripts finish.

Headings, landmarks, and accessible names agents actually receive

Crawler exports report what sits in the HTML source. The accessibility tree reports what is consumed after roles and names resolve. Those views disagree more often than teams expect: visual headings that are styled divs, aria-label overrides that replace good anchor text with “Link”, and landmark-free pages where every block floats as generic content.

For content templates, heading nodes pulled from the tree are the practical sequence check (one clear document title, no decorative skips). Meaningful blocks belong inside landmarks. For internal links, sorting link-role nodes by accessible name usually surfaces empty names first, then generic “Read more” clusters, then overrides that discard useful visible text. Semantic heading hierarchy as a design argument is covered separately in our Hashnode piece on heading hierarchy and semantic HTML. Here the job is narrower: whether the tree matches the outline you intended to publish.

Put ARIA snapshots in CI so the tree cannot silently regress

Point-in-time audits go stale on the next component refactor. Playwright’s toMatchAriaSnapshot (see the ARIA snapshots documentation) commits a YAML baseline of a template’s tree and fails the build when a deploy strips a name, removes a landmark, or demotes a heading. Reviewers read a human-scale diff: a button that used to say “Complete purchase” and now says nothing.

Playwright’s ARIA snapshot assertion: a YAML view of roles and names you can commit and diff in CI, so the accessibility tree cannot regress silently on the next redesign (docs captured 12 Sep 2026).

That check earns its keep on homepage, product, and checkout templates (or your equivalents). Snapshot updates belong with intentional redesigns; unexpected diffs work best as release blockers the same way broken redirects already do. That is how accessibility tree SEO work survives sprint pressure instead of living only in a quarterly PDF.

Where WebMCP and agentic browsing monitoring sit beside the tree

A clean accessibility tree helps agents that still scrape structure. WebMCP and related page tools aim to expose actions explicitly so agents do not have to guess from DOM noise. Chrome’s experimental Lighthouse Agentic Browsing lane scores fractional readiness across accessibility-for-agents, WebMCP, layout stability, and related checks rather than a second 0–100 Performance grade. We walk that scoring model in Lighthouse Agentic Browsing.

In agency practice, unnamed controls and landmarks on money paths come first; WebMCP belongs where you need reliable agent transactions; scheduled lab monitoring catches regressions on the URLs that matter. Citation dashboards and prompt trackers answer a different question again. Agencies that need a measurement split for “are we visible in ChatGPT?” can start from AI search visibility: what to measure first.

FAQ

Does a green Lighthouse accessibility score mean the accessibility tree is agent-ready?

No. The score summarises automated checks on one lab visit, which is useful for catching regressions quickly. An accessibility tree audit asks whether roles, names, and states on this URL support the jobs you care about: buy, enquire, sign up, compare plans. Both signals stay useful: the score for continuous integration speed, and the tree when a client asks whether agents or assistive technology can finish buy, enquire, or sign-up on this URL.

Is accessibility tree SEO a replacement for WCAG work?

No. The tree exists so people using assistive technology can use the web. SEO and agent readiness are side effects of doing that correctly, not a reason to add ARIA only for citation chase. Sloppy ARIA written only for “AI optimisation” can actively harm screen reader users who have no visual cue that the tree is lying. Certified specialists fit when the site is large, regulated, or already under legal review.

Where should agencies start this week?

The highest return per hour is usually the five-item checklist on the top ten revenue URLs, with tickets filed for unnamed calls to action and missing landmarks before the backlog grows. After those fixes ship, ARIA snapshot tests on the same templates keep the next redesign from undoing structure quietly. Tree diffs belong in migration QA the same way redirect checks already do.

CTA

A useful first check is the full-page accessibility tree in DevTools on one money URL. When the primary action has no clear name, that ticket usually outranks the Lighthouse Accessibility number on the same page. For multi-site teams, scheduled PageSpeed Insights and Lighthouse history on those URLs keep structure fixes and performance regressions in one reporting rhythm rather than a one-off audit folder.

References

10 SEO use cases for auditing your accessibility tree for AI search (John McAlpin, Search Engine Land)
Lighthouse accessibility score (Chrome for Developers)
Accessibility for agents (Chrome for Developers)
ARIA snapshots (Playwright)
Accessibility + Core Web Vitals: the overlooked UX wins (Apogee Watcher)
Lighthouse Agentic Browsing: How to rank in chatbots (Apogee Watcher)
Are We Visible in ChatGPT? What Agencies Can Measure First (Apogee Watcher)

Originally published on Hashnode.

The Story Behind Accesstive: Web Accessibility. Done Right.

Wed, 09 Sep 2026 10:00:35 +0000

It's more than our tagline. It's the reason Accesstive exists.
And it's why we're telling you this before talking about our product.
In 2025 alone, 8,667 ADA web accessibility lawsuits were filed in the United States, a 37% increase year over year. Across Europe, the European Accessibility Act (EAA) is now in force, and organizations that fail to meet accessibility requirements can face significant financial penalties and legal risk.
Most organizations don't discover they have an accessibility problem until they receive a complaint, lose a customer, or are asked to prove compliance.
We believe that shouldn't be the case.
That's one of the reasons we built Accesstive and why we made our Free Accessibility Checker available to everyone.

What Most Accessibility Tools Get Wrong

Search for "accessibility checker" and you'll find hundreds of scanners, overlays, and widgets promising quick fixes or instant compliance.
The reality is different.
An automated scan can identify many accessibility issues, but it cannot evaluate everything. Likewise, a widget alone doesn't make a website compliant or accessible for every user. Accessibility requires continuous attention, thoughtful remediation, and, in many cases, human expertise.
The challenge isn't finding another scanner.
The challenge is knowing what matters, fixing issues correctly, tracking progress over time, and having the documentation to demonstrate the work that's been done.
That's where many organizations struggle.

Why We Built Accesstive

For more than 15 years, we've been building enterprise websites and digital experiences for organizations across industries. Throughout that journey, one challenge kept repeating itself: web accessibility.
The problem wasn't a lack of accessibility tools. There were scanners, overlays, consultants, manual audits, and reporting tools. The real challenge was that they all worked separately. Agencies and in-house teams had to switch between multiple tools, track fixes in spreadsheets, coordinate audits, and maintain documentation on their own.
We faced the same challenge while delivering websites for our clients.
So we built an internal solution to simplify the process. It helped our team monitor accessibility, manage issues, track remediation, and keep everything in one workflow. It wasn't created as a product. It was built to solve a real problem we experienced every day.
As more clients started facing the same challenges, we realized this wasn't unique to us. It was a problem shared by agencies, developers, businesses, and public sector organizations around the world.
That's how Accesstive was born.
We didn't build another accessibility scanner.
We didn't build another overlay.
We built a Continuous Accessibility Platform that helps web teams find issues, understand them, fix them, monitor progress, and document everything in one place.

More Than a Free Accessibility Checker

For organizations taking their first step, we created the Free Accessibility Checker.
It goes far beyond a traditional automated scan.
In seconds, you can scan any public website, launch a Live Audit that highlights accessibility issues directly on the webpage, review findings against relevant WCAG success criteria, explore AI-powered remediation guidance, and download a detailed accessibility report.
The goal isn't just to generate another list of issues.
It's to help teams understand what needs attention, why it matters, and how to move forward with confidence.
AI When It Helps. Human Experts When It Matters.
We believe automation should support accessibility, not replace expertise.
That's why every organization can book a free first consultation with one of our accessibility experts.
Whether you need help interpreting your scan results, prioritizing remediation, validating complex accessibility issues, or planning your compliance journey, our specialists are available to guide you.
AI helps you move faster.
Human expertise helps you make the right decisions.
We believe organizations need both.

Accessibility Is Never "Done"

Websites evolve. Content changes. New features are released. Regulations continue to evolve.
Accessibility should evolve with them.
That's why Accesstive is built around continuous accessibility instead of one-time scans or one-off compliance projects. Our goal is to help organizations make accessibility part of their everyday web operations, not something they only think about after receiving a legal notice.
Our mission is simple: Help every web team Find, Fix & Prove accessibility with confidence.
Help agencies, developers, businesses, and public sector organizations avoid the fragmented accessibility journey we experienced for years.
Because Web Accessibility. Done Right. isn't just our tagline.
It's the standard we're committed to helping every web team achieve.
Learn more about Accesstive or run a free accessibility scan at
https://accesstive.com/free-accessibility-checker/

The Full Circle Philosophy Behind py-simple-wrap

Tue, 08 Sep 2026 11:45:15 +0000

Full circle philosophy

Py-simple-wrap is an open source project which I built. It is a python package that is meant both to make python easier for beginners to use by reducing boilerplate code down to 1-2 lines.

Although not something that I expected, when the first contributors started appearing, I pivoted to make the project easy to contribute to as well. I realize how overwhelming contributing can be so I decided to make the process as easy and stress free as possible to empower first time contributors to start their open source journey.

Background/Constraints

Before I get too far in rambling on about py-simple-wrap let me give you some background.

I think back not that long ago to when I first typed print("Hello, world!") on phone (yes, I started learning python on a Samsung phone using the pydroid3 app). After I typed that line I was hooked, but there were times when I almost gave up. One thing that almost made me quit is my dyslexia, small typos are insignificant anywhere else but are the make it or break it factor in a codebase. Had I given up it would have been a huge loss I wouldn't even be aware of. That's why py-simple-wrap puts such strong focus on clear function names and clear parameter names along with clear docstrings with examples.

I started working with python about a year and a half ago - not a whole lot in the grand scheme of things.

On top of that py-simple-wrap is my second ever package (I integrated my first ever package date-formatter-spcm into py-simple-wrap), with the first one being a tiny project. The first package was a much more simple version of the easy_formatter module. I also had no prior project management experience.

If that's not enough right there let me add that I also work full time as a hotel restaurant waitress, which means my time is very limited. Nevertheless, most of the time I'm not waiting tables, I'm working on some aspect of py-simple-wrap.

All of the mentioned above means that I’m also learning as I build, maintain, review code, etc. Is it challanging? Yes, for sure! Is it worth it? Without a doubt.

What about contributing?

Well, I don't have that much experience contributing either. What I do have is plenty of experience in how stressful contributing can be and how daunting that first PR is. I have anxiety. And said anxiety made me feel like a bad PR would be the end of the world, I worried I would look like a fool or a joke to other devs and like one bad PR could break someone's code (and mind you I do know that PRs can't just break someone's code).

I finally made my first PR in June of this year. I was lucky enough to volunteer at EuroPython 2026, and during the sprints I finally made my first couple of contributions — and saw my first ever merged PR happen right there in person. What made that possible was being right next to the Napari maintainers while it happened. They were warm, supportive, and helpful, with good humor and a fun, light atmosphere that made a nerve-wracking first PR feel like a lot less of a big deal. Huge shout out to the Napari team! I'm trying to bring that same atmosphere to py-simple-wrap contributions.

Unexpected growth

When I first started working on py-simple-wrap I didn't expect it to grow much. But now, within the first month and a half, we have a community of 40+ contributors, 20+ stars, 40+ forks, and I built that with zero prior project management experience. I'm proud of that.

I’m learning as I do, I keep trying to improve and do better. It’s turning out to be a wonderful, wild and wonderfully wild adventure!

Contributors Quest

As I mentioned, the amount of contributions took me by surprise, but I also realized the project being seen is a great opportunity to make yet another area more approachable. I realize all the stress and anxiety often involved in making a first PR, I also realize how important contributing to open source is, and how much of a joy it can be to build as a community (big or small).

I managed to work out a few ways to make contributing as easy as I can (and I’m still looking for more ways). I make sure there are always first-contributor, good-first-issue issues for a variety of contribution types (from docs, through tests, to working on a module), if changes on a PR are requested I try to make sure the contributor knows they can reach out for help. There is also a small (but growing) library of contributing tutorials including templates (for example docstring template), all of this is in an effort to make contributing more accessible and less scary.

Another thing I added is contributors quest, a gamified, RPG style game for the contributors with the ability to view the leaderboard, join a guild (or two, or three, for instance: 🪄 The Module Magicians' Guild, 🛡️ The Test Sentinels' Order, or 📜 The Lore Keepers' Circle), take part in challenges and more. I will admit that this particular element (contributors quest) was vibe coded in another project. I hope this small addition brings a little extra spark of fun for everyone!

AI leveraged workflows

With a few hours (1h–3h) on work days and up to 8h on days off, I needed a way to make the most of limited time and limited energy.

I'm not the biggest fan of using AI to write code — I mostly use it as a tool to help me learn, not to hand off the actual logic. But automation is a different story, so I decided to leverage it there. I used Claude and Claude Code to build workflows that handle the tasks that don't need to be done by hand.

Some of the most time-saving automations I implemented are: one that opens new issues based on modules missing tests, docs, etc., another that helps with releasing new versions to PyPI, and more. Thanks to this I was able to maximize the time I spent reviewing code, merging PRs, and of course coding!

The py-simple-wrap hope

This project has already grown to unexpected proportions, and my single biggest hope is that it grows to become not only a package that simplifies python for beginners but also a full circle of learners learning together and helping others.

When I close my eyes and imagine what I want py-simple-wrap to be I imagine this: a project with an active community that is kind and supportive, composed of python learners of all levels growing together and helping new contributors join the team and learn and grow. A full circle where newcomers can learn that contributing can be empowering, fun and exciting, and new Pythonistas get the chance to make bigger projects that make them want to understand python even more in depth.

Heading hierarchy is not a design trade-off

Wed, 29 Jul 2026 13:58:07 +0000

Headings define structure and meaning, not typography. One H1, logical H2s and H3s, CSS for the visual layer: better SEO, accessibility, and clearer signals for search and LLMs.

The design review opens on a landing page that looks clean. The hero line is an h3 because the brand type scale already used the largest size on a label above it. The pricing table jumps from h2 to h4 so the section titles sit closer to the cards. Nobody changed the copy. They changed what the document claims about itself. When SEO or accessibility pushes back, the answer is often some version of “we can’t sacrifice the layout.” That is the wrong frame. Heading hierarchy is not a design trade-off. CSS controls how headings look. HTML controls what they mean.

What heading hierarchy means in HTML (and what it is not)

In HTML, h1 through h6 are structural markers. They tell browsers, assistive technology, search crawlers, and downstream tools what the outline of the page is: title, major sections, subsections. Typography is a separate job. You can make an h2 look like a whisper and an h4 look like a billboard if the stylesheet says so. What you should not do is pick heading levels to match font size. That confuses every consumer that reads the DOM for structure, not computed style.

A healthy page usually has one h1 that names the document, then h2 elements for the main sections a reader would skim, then h3 (and occasionally h4) for subsections under each h2. Skipping levels (h2 straight to h4) or using multiple h1 elements because “each block is important” breaks the outline. The page can still win a screenshot review. It fails the structural one.

Why teams treat headings as a visual problem

The habit is understandable. Design systems ship type ramps first. Components arrive with a “title” slot that maps to whatever size looks right in Figma. Marketing pastes a new hero and keeps the existing class names. A/B tests swap modules without anyone checking whether the outline still makes sense. By the time the page ships, the heading map is a record of layout decisions, not content hierarchy.

That drift is easy to miss because most sighted users infer structure from size, weight, and whitespace. Screen reader users get a list of headings in level order. Crawlers and summarisers often weight headings heavily when they guess what a page is about. LLM pipelines that extract “sections” from HTML follow the tags, not the CSS. When visual hierarchy and document hierarchy diverge, you are asking non-visual readers to reverse-engineer your design choices.

How broken heading levels hurt SEO and internal linking

Search engines still use headings as one signal among many, not as a magic lever. They do help parsers understand which blocks belong together, which questions a page answers, and which phrases are section titles rather than body copy. A pricing page whose only h2 is buried under three decorative h4 labels makes the commercial intent harder to read. A service page that restarts at h1 in every component looks like several unrelated documents stitched together.

The damage is often local rather than site-wide: one template with inverted levels can underperform on long-tail queries that match subsection titles you hid inside paragraph styling. That is a different problem from Core Web Vitals scores on the same URL, and a different fix from the metric work we covered when asking which accessibility fixes show up in CWV dashboards. Headings are document semantics. CWV dashboards tell you whether interaction latency and layout stability are hurting real users. Both matter; neither substitutes for the other.

For the broader SEO picture on why performance and experience signals sit beside content quality, see How Core Web Vitals impact SEO rankings: what the data shows on our Watcher blog. Use that guide when a client asks whether fixing LCP is enough; use heading audits when they ask why a well-written section never ranks for its title phrase.

What screen readers do when you skip from H2 to H4

Assistive technology exposes headings as a navigable outline. A keyboard user can jump from section to section without reading every line between. When levels skip, the outline lies about nesting: an h4 after an h2 implies a missing h3 parent that is not in the document. Some users still work through the page linearly, but the quick-navigation feature becomes unreliable. Others lose confidence that the heading list matches the visual layout they cannot see.

The overlap with performance work is real. Focus jumps, late-loading banners, and unstable layout hurt keyboard users and show up in CWV. Semantic headings do not fix INP or CLS on their own. They do stop you from shipping a page that is painful to navigate for reasons that never appear in a Lighthouse performance score. Our Watcher guide on accessibility and Core Web Vitals goes deeper on INP with keyboard input, focus-visible requirements, and CLS from focus management. Treat heading fixes as part of the same accessibility habit, not as a separate “SEO ticket.”

Why LLMs and answer engines read headings differently than CSS

Models and retrieval tools that ingest HTML often chunk content by heading boundaries. If your true section title is a styled p and the nearby h3 is only a kicker label, summaries attach the wrong label to the paragraph block. FAQ modules that mark every question as h2 flatten a page into a list of peer topics with no parent section. Comparison tables that promote each column header to h3 create phantom sections that never appear in the visible layout.

Agencies are already being asked whether pages are “visible in ChatGPT” and similar systems. That question is partly about crawl policy, partly about content quality, and partly about whether machines can parse what humans see. Broken heading hierarchy is a quiet failure mode: the prose is fine, the design is fine, the outline is nonsense. For a measurement-first view of AI search visibility, see Are we visible in ChatGPT? What agencies can measure first. Fix headings before you chase new schema types for the same page.

How to keep one H1 and logical H2/H3 without flattening the design

Separate the two layers in code review. Content authors (or the CMS) own the outline: one h1, ordered sections, no skipped levels without a deliberate subsection. Design owns the presentation: font size, weight, spacing, colour, and responsive behaviour via classes or design tokens. If the hero needs a small kicker above the main title, use a p or span with a kicker class, not an h1 or h2 chosen for size. If a card title should look large but sit under a section h2, use h3 inside the card and style it to match the comp.

Practical rules we use on client templates:

Map Figma text styles to CSS classes, not to heading levels.
Ban “heading level” as a prop on generic layout components unless the component is actually a section title.
Run an outline check in CI or pre-publish QA: export heading levels in order and read them without the stylesheet.
When you refactor, fix the HTML first, then adjust CSS. Never the reverse.

You do not need ugly pages. You need honest pages: the DOM outline should match the story a competent reader would tell from the layout. When design and semantics disagree, the stylesheet is the right place to compromise, not the heading level.

How to audit heading structure on a client template before the next deploy

Open the page, disable author styles or use the accessibility tree, and list headings in level order. Read only that list aloud. If it sounds like nonsense, the template is not ready. Compare the list to the sitemap intent: does each h2 name a section a client would put in a report slide? Do h3 elements belong to the h2 above them, or did a carousel inject stray levels?

Pick one high-traffic template (homepage, pricing, core service) and one long-form article layout. Fix those two before you normalise every blog component. Pair the heading pass with the accessibility and CWV checks you already schedule: keyboard tab through the same URLs, note focus surprises, and keep monitoring LCP, INP, and CLS in Apogee Watcher so semantic fixes do not get credited while regressions slip in elsewhere. On Monday, send the design lead the heading list without CSS and ask one question: “If you could not see the page, would this outline still be the story we want?” When the answer is no, reach for the stylesheet, not a lower heading level.

Originally published on Hashnode.

Which accessibility fixes show up in Core Web Vitals dashboards?

Tue, 07 Jul 2026 10:55:24 +0000

Alt text and ARIA labels rarely move a chart. Focus rings, keyboard latency, and layout-stable modals often do. Here is how we prioritise fixes agencies can prove in monitoring.

The client closed the accessibility audit with a green checklist and a flat Core Web Vitals chart. Engineering fixed missing labels, colour contrast on three components, and a landmark order issue that never touched Largest Contentful Paint, Interaction to Next Paint, or Cumulative Layout Shift. Two sprints later, keyboard users still complained about laggy menus, and field INP on the account page had drifted from "Good" to "Needs improvement" without anyone naming an accessibility ticket in the regression notes.

That split is routine. Accessibility work and Core Web Vitals monitoring answer different questions unless you choose fixes that move both. Some improvements are essential for compliance and never appear on a PageSpeed or CrUX dashboard. Others, especially around keyboard responsiveness and layout-stable focus, show up in the same charts executives already read. Agencies need both lists, not a single backlog sorted only by audit severity.

Why do accessibility audits and Core Web Vitals dashboards tell different stories?

Accessibility audits score conformance: labels, contrast, operable controls, predictable focus order. Core Web Vitals dashboards score field or lab timing on three metrics Google uses for page experience: LCP for loading, INP for responsiveness after load, CLS for layout stability during the session.

A perfect audit can leave INP poor if main-thread JavaScript still blocks keydown handlers. A green LCP on a hero image can still mean a screen reader waits on an empty shell until hydration finishes. The teams celebrate different wins because the instruments measure different surfaces.

We use a simple sorting question after every audit export: will this fix change LCP, INP, or CLS on the URLs we monitor on a schedule? If yes, it goes on the performance board with a before-and-after run. If no, it stays on the accessibility board with its own verification. Both boards matter; merging them without criteria produces either ignored audit items or ignored chart regressions.

Which keyboard and interaction fixes move INP on monitoring dashboards?

INP replaced First Input Delay because real sessions include many interactions, not only the first tap. Keyboard navigation generates a stream of small events: Tab to move focus, Enter to activate, typing into fields, opening menus. Heavy main-thread work delays the paint that follows each step, and that delay is what INP captures.

Fixes we have seen move INP on monitored URLs without waiting for the next quarterly audit:

Breaking up long tasks so focus and typing get a turn on the main thread.
Deferring non-critical JavaScript so the page responds to keyboard input before analytics and personalisation finish loading.
Replacing synchronous validation on every input event with debounced or idle-time checks.
Fixing custom components that attach expensive handlers to keydown for global shortcuts.

Pointer-only testing hides most of this. A 200 ms delay after a click can feel acceptable once; the same delay after every Tab keypress feels broken because it repeats across the whole flow. If your monitoring tool stores only aggregate INP, add lab runs that walk a keyboard path through checkout or account settings after deploys that touch interaction code.

Our longer write-up on accessibility and Core Web Vitals goes deeper on keyboard paths, Event Timing metadata, and INP segmentation. For metric definitions and thresholds, start with what Core Web Vitals measure in 2026.

Which focus and layout fixes show up as CLS improvements?

CLS is often explained with late-loading ads and images without dimensions. Focus management contributes too, and those shifts punish keyboard and screen reader users first.

Focus rings that change layout on `:focus`

WCAG requires a visible focus indicator. Teams sometimes add a border or extra padding only on focus to make the ring obvious. That changes element size and can register as layout shift, especially on dense navigation bars where many items receive focus in sequence.

Switching to outline or box-shadow for focus styles usually satisfies visibility without moving layout. We have watched CLS on template dashboards calm down after removing border-based focus treatments on header links, with no change to the hero LCP element.

Focus moves that scroll unstable pages

When focus lands on an offscreen control, the browser scrolls it into view. If fonts, images, or banners are still settling, that scroll combines with shifts and disorients keyboard users. Fixing image dimensions, reserving space for ads, and stabilising cookie banners reduces CLS for everyone and makes focus navigation predictable.

Monitoring tip: when CLS regresses, inspect shift attribution if your tool provides it. "Focus-related" jumps often trace to modals, sticky headers, or late-inserted consent UI rather than the product grid clients ask about first.

Which accessibility improvements help LCP without changing the hero image?

LCP is usually a large image or text block in the viewport. Accessibility work rarely swaps that element directly, but it can change when primary content is available to assistive technology, which correlates with perceived readiness.

Fixes that sometimes improve LCP or its practical cousin "time until main content is usable":

Server-rendering the primary heading and key controls instead of waiting for client hydration.
Removing skeleton screens that paint quickly but delay semantic content in the DOM.
Ensuring font loading strategy does not block text LCP with invisible text periods that reflow after load.

These are not substitutes for image optimisation. They align "largest content" with "meaningful content" so a green LCP score is not lying to non-visual users. Track LCP element type in lab runs when accessibility refactors touch rendering strategy, not only when marketing changes the hero asset.

Which accessibility fixes never appear on a Core Web Vitals dashboard?

Some work is non-negotiable and invisible to the three metrics. Plan for it explicitly so clients do not ask why the chart stayed flat after a two-week audit sprint.

Examples that rarely move LCP, INP, or CLS on monitored URLs:

Accurate alternative text and accessible names on decorative versus informative images.
Colour contrast on text that was already stable in layout.
Correct heading hierarchy and landmark regions when DOM order was already fixed.
Captions and transcripts for media (essential for access, unrelated to vitals timing).
Error messages that were always present but poorly associated with fields (fix the association, not the paint timing).

That list is not an argument to deprioritise audit findings. It is an argument against using Core Web Vitals alone as proof of accessibility progress. Report audit closure and chart movement separately in client updates.

We keep scheduled PageSpeed-style runs on the templates named in the retainer, mobile and desktop where field data already splits. After any deploy tagged "accessibility" or "interaction", we add one keyboard walk lab on the same URLs before the weekly report goes out.

Practical monitoring habits:

Fix category	What to watch on dashboards	What to verify outside CWV
Keyboard menus, modals, forms	INP on affected URLs; lab keyboard path after deploy	Focus trap behaviour, screen reader announcements
Focus visible / focus order	CLS on nav-heavy templates	Manual tab order through loading states
Rendering and hydration	LCP element type and value	Screen reader readout on first meaningful content
Contrast, labels, landmarks	Usually flat on vitals charts	Audit retest or automated a11y scan

Use the same URL groups you already report for Core Web Vitals. Adding a parallel "accessibility URL list" that only contains the homepage duplicates effort and hides regressions on account or checkout flows where keyboard latency actually hurts.

Budget thresholds should match the performance policy document, not a second spreadsheet invented for the audit vendor. When INP or CLS crosses budget after an accessibility release, the regression owner is the team that shipped the interaction change, even if the original ticket said "WCAG".

Next step: tag one audit fix with the Core Web Vital it should move

Open the last accessibility export for a live client. Pick three open items. For each, write which metric should change if the fix works: LCP, INP, CLS, or none. Put the metric-linked items on this week's deploy verification list with a scheduled lab run on the URLs where that metric is already charted.

If every item lands in "none", your monitoring scope is probably too narrow, not your audit. Expand templates on the watch list before you tell the sponsor that Core Web Vitals prove accessibility health.

For the full crosswalk between assistive-tech UX and continuous monitoring, read Accessibility and Core Web Vitals: the overlooked UX wins. For syllabus-level definitions of LCP, INP, and CLS, use What Are Core Web Vitals? A Practical Guide for 2026.

Fixes that show up on dashboards earn a place in performance retainers. Fixes that do not still ship; they just need a different line on the report.

Originally published on Hashnode.

WCAG Color Contrast: What Developers Need to Know About Accessibility

Sun, 31 May 2026 10:43:39 +0000

Color contrast accessibility is one of the most commonly failed WCAG criteria — and one of the easiest to fix once you understand the rules. Here's what the standard requires and how to verify compliance.

What WCAG says

The Web Content Accessibility Guidelines (WCAG) define minimum contrast ratios between text and its background. The key requirements:

WCAG 2.1 Level AA (legal minimum in many jurisdictions):

Normal text (under 18pt regular or 14pt bold): 4.5:1
Large text (18pt+ regular or 14pt+ bold): 3:1
UI components and graphical objects: 3:1
Decorative elements, logos, disabled controls: exempt

WCAG 2.1 Level AAA:

Normal text: 7:1
Large text: 4.5:1

Legal context: WCAG 2.1 AA is legally required for public-sector websites in the EU (EN 301 549), the US (ADA and Section 508), Canada (AODA), and Australia (DDA). Private-sector websites are increasingly covered by ADA case law.

How contrast ratio is calculated

The contrast ratio is calculated from the relative luminance of the two colors:

contrast ratio = (L1 + 0.05) / (L2 + 0.05)

Where L1 is the lighter color's relative luminance and L2 is the darker color's relative luminance. Relative luminance ranges from 0 (black) to 1 (white).

Relative luminance formula for sRGB:

`javascript function relativeLuminance(r, g, b) {

// Linearize each channel

const linear = [r, g, b].map(channel => {

const c = channel / 255;

return c <= 0.03928

? c / 12.92

: Math.pow((c + 0.055) / 1.055, 2.4);

});

return 0.2126 linear[0] + 0.7152 linear[1] + 0.0722 * linear[2];

}

function contrastRatio(rgb1, rgb2) {

const l1 = relativeLuminance(...rgb1);

const l2 = relativeLuminance(...rgb2);

const lighter = Math.max(l1, l2);

const darker = Math.min(l1, l2);

return (lighter + 0.05) / (darker + 0.05);

}

contrastRatio([47, 133, 90], [255, 255, 255])

// → 5.08 (passes AA for normal text)

For quick checking without code, a color contrast checker calculates the ratio and WCAG verdict instantly when you enter the two hex values.

Common contrast failures

Gray text on white:

Many design systems use light gray text for secondary/placeholder content. Typical failures:

|-----------|-----------|-------|--------|

| #999999 | #ffffff | 2.85:1 | Fails AA |

| #767676 | #ffffff | 4.54:1 | Passes AA |

| #595959 | #ffffff | 7.22:1 | Passes AAA |

The lightest gray that passes AA on white is approximately #767676.

White text on color:

| Background | Ratio | Result |

|-----------|-------|--------|

| #3182ce (medium blue) | 4.6:1 | Passes AA |

| #e53e3e (medium red) | 4.07:1 | Fails AA for normal text |

| #d69e2e (medium yellow) | 2.21:1 | Fails AA |

Yellow and light colors almost never achieve sufficient contrast with white text. Use dark text on yellow.

Dark mode issues:

Inverting a light-mode color scheme doesn't guarantee contrast compliance. Check both modes separately.

Automating contrast checks

Storybook a11y addon:

<code>bash <p>npm install --save-dev @storybook/addon-a11y</p> </code>

Add to .storybook/main.js:

<code>javascript <p>module.exports = { addons: ['@storybook/addon-a11y'] };</p> </code>

The a11y addon runs axe accessibility checks on each story, including contrast ratio.

Playwright / Cypress:

`javascript // Using axe-core with Playwright

import { checkA11y } from 'axe-playwright';

test('passes contrast checks', async ({ page }) => {

await page.goto('/');

await checkA11y(page, null, {

runOnly: { type: 'tag', values: ['wcag2aa'] }

});

Lighthouse:

Run from the command line:

<code>bash
<p>npx lighthouse https://example.com --only-categories=accessibility --output json</p>
</code>


Lighthouse's accessibility score covers contrast ratios for text elements automatically.
axe-core in browser:

<code>javascript
<p>// Install: npm install axe-core</p>
<p>import axe from 'axe-core';</p>
<p>axe.run(document, { runOnly: { type: 'tag', values: ['wcag2aa'] } })</p>
<p>.then(results => {</p>
<p>results.violations.forEach(v => {</p>
<p>console.log(v.id, v.description, v.nodes);</p>
<p>});</p>
<p>});</p>
</code>


Design tool support
Figma: Select a text layer, check the Fill section in the right panel — Figma shows the contrast ratio and AA/AAA pass/fail against the element behind it. The "Figma A11y" plugin and "Contrast" plugin provide more detailed analysis.
Sketch: The "Stark" plugin provides WCAG contrast checking inline.
Adobe XD: Built-in accessibility checker includes contrast. The "Able" plugin provides additional detail.
Fixing low-contrast designs
When a design fails contrast:
Option 1: Darken the text color (preserves the design's background)

css

/ Failed: #999 on white /

color: #999999;
/ Fixed: darkened to pass AA /
color: #767676;


Option 2: Lighten the background

For text on a dark background that's too dark — lighten the background until contrast passes.
Option 3: Use an intermediate shade for all states

If a brand color fails contrast as text-on-white, use a darker shade:

<code>css
<p>:root {</p>
<p>--brand: hsl(145, 48%, 45%);        /<em> Too light for text on white </em>/</p>
<p>--brand-accessible: hsl(145, 48%, 35%); /<em> Darker, passes AA </em>/</p>
<p>}</p>
</code>

Check WCAG 3.0:

WCAG 3.0 introduces the APCA (Advanced Perceptual Contrast Algorithm), which is more accurate for low-contrast situations and replaces the simple ratio with a perceptual model. It's not yet a legal standard, but design tools and validators are beginning to include it alongside the traditional ratio.

Color contrast is a straightforward accessibility requirement with clear pass/fail criteria. Building contrast checking into your design review and CI pipeline catches failures before they reach production.

Originally published at https://snappytools.app/color-contrast-checker/

Iris: An Offline Visual Assistant in Brazilian Portuguese Powered by Gemma 4

Fri, 15 May 2026 11:53:10 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4.

TL;DR

Iris is an Android visual assistant for blind and low-vision users.
It describes what the camera sees, out loud, in Brazilian Portuguese.
Gemma 4 multimodal runs 100% on the phone via LiteRT-LM — no cloud, no telemetry, no INTERNET permission.
Three intent-specific modes: Continuous, Question, Reading.

What I Built

I built Iris, an offline Android visual assistant for blind and low-vision users.

The interaction is intentionally simple: point the phone camera at something, tap the screen, and Iris speaks what it sees in Brazilian Portuguese.

Iris has three modes:

Continuous Mode describes the scene in front of the user.
Question Mode lets the user ask a spoken question about the current camera image.
Reading Mode reads visible text aloud, such as a label, medicine box, sign, or package.

A fourth control, Repeat, replays the last description — useful for users who could not catch it all the first time.

The core constraint was not only "can Gemma 4 understand the image?" — the real question was whether this could still be useful when the camera is looking at private, everyday scenes and the user may not have a reliable network connection.

That led to the main technical decision: everything runs on the phone.

No server. No cloud API. No telemetry. No INTERNET permission in the Android manifest.

Demo

https://youtu.be/cdug6i_HEJM

The demo shows Iris running on a Galaxy S21 with airplane mode visible. The right side of the video is the actual phone screen; the left side explains what each mode is doing.

The video is not meant to hide the on-device latency. On a Galaxy S21, the first spoken sentence arrives in roughly 25–30 seconds after the tap. The wait is part of the point: Gemma 4 is doing the multimodal work locally, on the phone, with no help from a server.

Code

Repository:

https://github.com/juniormartinxo/iris

The project is a native Android app built with Kotlin, Jetpack Compose, CameraX, Android TTS/STT, and LiteRT-LM.

Why This App Needed To Be Offline

A visual assistant sees the user's world.

That can mean a medicine label, a document on a desk, a room at home, a person nearby, a screen, or an object the user is trying to identify. For this kind of app, "send the image to a server" is not a neutral implementation detail. It changes the privacy model of the product.

I wanted Iris to have a stronger boundary:

camera frames stay on the device;
speech recognition uses Android's on-device recognizer;
speech output uses Android Text-to-Speech;
Gemma 4 runs through LiteRT-LM locally;
the app does not request Internet access.

The Android manifest only asks for the permissions the app needs to see and hear:

<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />

There is no android.permission.INTERNET.

That means the app cannot silently fall back to a network call unless a future version explicitly changes the permission model.

How I Used Gemma 4

Iris uses Gemma 4 E2B as the primary model, packaged as a .litertlm bundle and loaded with LiteRT-LM on Android.

I chose E2B because the target device is a phone, not a workstation. The challenge prompt asks builders to be intentional about model selection, and for this project the priority was clear: local multimodal inference with the smallest model that could still make the experience meaningful.

The app can also look for an E4B bundle as a fallback, but the loading order prefers E2B:

val MODEL_CANDIDATES: List<Pair<String, String>> = listOf(
    "E2B" to "gemma-4-E2B-it.litertlm",
    "E4B" to "gemma-4-E4B-it.litertlm",
)

For the current demo, E2B is the right trade-off: it keeps the app viable on devices like the Galaxy S21 and A55 while still giving Iris native multimodal understanding.

The app sends Gemma 4 one camera frame plus a mode-specific prompt:

in Continuous Mode, the prompt asks for a short scene description focused on obstacles, relevant objects, visible text, and people;
in Question Mode, Android's on-device speech recognizer captures the user's question, then Gemma 4 answers using the current image;
in Reading Mode, the prompt asks Gemma 4 to read visible text from top to bottom and left to right.

All prompts ask for Brazilian Portuguese output because the product is designed for PT-BR users first.

Architecture

The runtime path is deliberately small:

CameraX preview
  -> capture current frame
  -> downsample image to a 512px longest edge
  -> run frame quality checks
  -> Gemma 4 E2B through LiteRT-LM
  -> sentence buffer
  -> Android Text-to-Speech

There are a few details in that pipeline that matter.

1. Frame quality checks before inference

On-device multimodal inference is expensive enough that Iris should not waste a run on a useless image.

Before calling Gemma 4, the app calculates a small set of image quality signals:

brightness;
luminance variance;
a simple blur score.

If the image is too dark, too bright, too empty, or too blurry, Iris speaks a direct instruction like:

"Imagem muito escura. Verifique a iluminação ou se há algo cobrindo a câmera."

That is better than waiting through a slow inference only to get a weak answer.

2. Sentence streaming into TTS

LiteRT-LM returns text chunks. Iris does not wait for the entire response before speaking.

A small SentenceBuffer collects chunks until it sees a sentence boundary, then sends each sentence to Android TTS. The user hears the first useful sentence as soon as possible, while the model can still finish the rest of the response.

For accessibility, this is not just a polish detail. Silence during a long local inference can feel like the app froze. Iris speaks "Aguarde." as a progress beacon every 15 seconds while inference is still running. The moment the first sentence arrives from the model, the loading overlay disappears and the description starts streaming into the screen — one sentence at a time — so visual and audio feedback stay in sync.

3. Modes are prompt engineering exposed as UI

I did not want one generic "describe" button to handle every situation.

Blind and low-vision users often know what they need:

"What is in front of me?"
"Is there a silver object here?"
"Read this medicine box."

The three modes let the UI choose the prompt shape before the model runs. This keeps the responses shorter, more predictable, and easier to listen to.

4. TalkBack-aware behavior

Iris is built around audio, but Android accessibility already has an audio layer: TalkBack.

When TalkBack is enabled, Iris avoids speaking over UI announcements. When TalkBack is not enabled, Iris uses its own TTS announcements for mode changes, loading states, errors, and tutorial flow.

Every primary control has a contentDescription, including:

Continuous Mode;
Question Mode;
Reading Mode;
Repeat.

This lets the same interface work for screen-reader users and for users who are not running TalkBack.

Performance on the Galaxy S21

Step	Time / size
Cold start to "Ready" (model load)	~10–30 s
Tap → first spoken word	~25–35 s
Tap → full response done	~35–50 s
Memory while idle (model loaded)	~3 GB
APK size (debug)	~99 MB
Model bundle (sideloaded `.litertlm`)	~2.59 GB

These are not best-in-class numbers. They are the cost of doing multimodal inference fully on-device on a 2021 phone. The UX is designed around making that wait legible, not invisible — that is what the progress beacon and the sentence streaming are for.

Numbers above are approximate, taken on a single Galaxy S21 unit. They will vary by device, by ambient thermal state, and by how much memory the rest of the system is using.

What Gemma 4 Unlocked

The important thing about Gemma 4 here is not only that it can caption an image.

It lets Iris treat visual assistance as a flexible language problem:

a scene can be summarized;
a user question can be grounded in the image;
visible text can be read in context;
the output can be constrained to short, spoken PT-BR sentences.

Without a multimodal model, this app would likely become a collection of separate systems: one detector, one OCR pipeline, one classifier, one rules engine, and a lot of glue code. That can be the right architecture for a mature product, but it is much heavier for a fast prototype.

Gemma 4 made it possible to build one coherent loop:

image + intent -> useful spoken answer

What Was Hard

The hardest part was not wiring the camera to the model. It was making the experience feel reliable enough for an audio-first user.

Some examples:

The app must tell the user when the model is still working.
A second tap should cancel or replace the previous flow cleanly.
If speech recognition is unavailable offline, the app should explain that instead of failing silently.
If the camera points at a blank wall, the model should not invent a detailed scene.
If the device is too hot, the app should refuse another expensive inference instead of making the phone worse.

Some other details would have been invisible in a tech demo but mattered for a real app: guarding the camera tap area against overlay-based tap-jacking, capping the crash log file size so a failure loop cannot fill the disk, synchronizing access to the speech recognizer so it cannot be torn down mid-utterance. Each one came from imagining what a confused or panicked user would experience.

Iris is still a prototype, but these details are the difference between a tech demo and something that starts to behave like a product.

Limitations

The current version has real constraints.

First, local inference on a Galaxy S21 can take a while. That is the cost of running a multimodal model offline on a phone-class device. The app is designed to keep the user informed during that wait, but latency is still the biggest UX limitation.

Second, Iris is not a navigation or safety-critical tool. It can describe what the camera sees, but it should not be used as the only source of truth for crossing streets, avoiding hazards, or making medical decisions.

Third, Reading Mode uses Gemma 4's multimodal ability rather than a dedicated OCR engine. That keeps the architecture simple and demonstrates what the model can do, but a production version might combine Gemma 4 with a specialized OCR pipeline for speed and fidelity.

Try It Yourself

The model is sideloaded because it is large. The app expects the LiteRT-LM bundle under the app's external files directory.

Short version:

./gradlew :app:assembleDebug

adb install -r app/build/outputs/apk/debug/iris-0.1.0-debug.apk

adb push gemma-4-E2B-it.litertlm \
  /sdcard/Android/data/com.iris/files/

Model source:

https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm

The README includes the full setup notes, including Android version, memory, storage, and offline PT-BR TTS/STT requirements.

What's Next

The next improvements I would make are:

test the same build across more Android devices;
improve latency with better model/runtime configuration;
add a more explicit first-run checklist for offline language packs;
explore a hybrid Reading Mode that uses dedicated OCR when speed matters;
keep the permission model strict: no Internet unless the product direction changes openly.

Acknowledgments

The Google AI Edge team for LiteRT-LM, which makes running Gemma 4 on Android tractable.
litert-community on Hugging Face for the .litertlm model bundles.
Anthropic Claude Code was used as a pair-programming assistant during development of the Android code, the UX logic, and parts of this article.

Closing

Iris is small, but it represents the kind of app I want to see more often: local-first, accessibility-first, and built for a real language community instead of assuming English by default.

Gemma 4 made the prototype possible because it brought multimodal understanding close enough to the device. LiteRT-LM made it possible to run that loop inside Android.

The result is simple:

The camera sees. Gemma 4 understands. Iris speaks.

And it does that without sending the image anywhere.

Color Contrast for Web Accessibility: WCAG AA vs AAA Explained

Thu, 14 May 2026 10:09:39 +0000

If you have ever squinted at a website trying to read light grey text on a white background, you have experienced poor color contrast. It is uncomfortable for everyone. For people with low vision, color blindness, or cognitive disabilities, it makes content completely inaccessible.

The Web Content Accessibility Guidelines (WCAG) give us a mathematical standard for color contrast, and every modern web developer should understand it.

What Is the Contrast Ratio?

The contrast ratio compares the relative luminance of two colors. Luminance is a measure of how much light a color emits — white is 1.0, black is 0.0.

The formula is:

ratio = (L1 + 0.05) / (L2 + 0.05)

Where L1 is the lighter color's luminance and L2 is the darker one's. Ratios range from 1:1 (no contrast, same color) to 21:1 (black on white, maximum contrast).

To get luminance from an RGB value, you first linearize each channel, then apply weights that reflect how the human eye perceives brightness:

`javascript function getLuminance(r, g, b) {

const [rs, gs, bs] = [r, g, b].map(c => {

c /= 255;

return c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4);

});

return 0.2126 rs + 0.7152 gs + 0.0722 * bs;

}

function contrastRatio(rgb1, rgb2) {

const l1 = getLuminance(...rgb1);

const l2 = getLuminance(...rgb2);

const lighter = Math.max(l1, l2);

const darker = Math.min(l1, l2);

return (lighter + 0.05) / (darker + 0.05);

}

WCAG Levels: AA vs AAA

WCAG defines two conformance levels for contrast:

WCAG AA — the minimum standard required by most accessibility laws (including ADA, EN 301 549, and Section 508 in the US):

Normal text (under 18pt or 14pt bold): 4.5:1 minimum
Large text (18pt+ or 14pt+ bold) and UI components: 3:1 minimum

WCAG AAA — the enhanced standard, recommended for critical text:

Normal text: 7:1 minimum
Large text: 4.5:1 minimum

Most teams aim for AA across the board and AAA for body copy on high-traffic pages.

Why the Green/Grey Traps Are So Common

Web designers often use brand colors without checking contrast. A company palette might include a medium-saturation green that looks vibrant in the style guide but fails AA when used as text on white.

Common failure patterns:

Light grey text on white backgrounds — a common UI pattern for secondary text that looks elegant but often fails at 2:1 or 3:1
Coloured text on coloured backgrounds — two medium-saturation colours in the same value range can clash at only 1.5:1
White text on mid-tone brand colours — a teal, orange, or green at 50% brightness barely reaches 3:1 against white

Fixing Contrast Without Losing Your Design

You do not usually need to replace your brand colors. Adjust lightness:

For text on white: darken the text color until it passes
For white text on a colored background: darken the background until it passes
For body copy: use black or near-black (#1a1a1a) on white — instant 19:1 ratio

In CSS, the color-mix() function (now well-supported) makes this easy:

`css / Start with your brand color /

--brand: #4a9a6f;

/ For text, darken it /

--text-primary: color-mix(in srgb, var(--brand) 60%, black);

/ For backgrounds, lighten it /

--bg-accent: color-mix(in srgb, var(--brand) 20%, white);

Testing Your Palette

You can check contrast ratios manually using the formula above, or use a browser-based tool. The SnappyTools Color Contrast Checker lets you enter two hex colors, shows the contrast ratio, and tells you instantly whether it passes WCAG AA and AAA for normal text, large text, and UI components. It runs entirely in the browser.

For systematic palette audits, use browser DevTools. In Chrome, opening any color in DevTools shows the contrast ratio inline and flags AA/AAA status with a warning icon.

Automated Testing in CI

Manual checking is not enough for large codebases. Add automated contrast checking to your CI pipeline:

axe-core — integrates with Jest, Cypress, and Playwright. Runs a full accessibility audit including contrast failures.
Storybook a11y addon — shows contrast issues per component during development
Lighthouse — checks contrast for rendered pages and reports failures in the accessibility audit section

A typical axe-core integration in Playwright:

`javascript import { checkA11y } from 'axe-playwright';

test('homepage passes contrast checks', async ({ page }) => {

await page.goto('/');

await checkA11y(page, null, {

runOnly: { type: 'tag', values: ['wcag2aa'] },

});

This catches regressions before they reach production.

Summary

Contrast ratio measures luminance difference between two colors (1:1 to 21:1)
WCAG AA: 4.5:1 for normal text, 3:1 for large text — required by most accessibility laws
WCAG AAA: 7:1 for normal text — recommended for body copy
The most common failures are light grey on white and brand colors without luminance adjustment
Fix by darkening text or darkening the background color — rarely need to change the hue
Automate with axe-core in CI to prevent regressions

Accessible color contrast is one of the cheapest accessibility wins available — it costs nothing to check and usually takes five minutes to fix.

Originally published at https://snappytools.app/color-contrast-checker/

Describe Image

Mon, 11 May 2026 09:34:59 +0000

I recently launched Describe Image, an AI image-to-text tool for turning images and short videos into clear, reusable written content.

The tool is built for creators, marketers, bloggers, website owners, e-commerce sellers, accessibility workflows, and anyone who needs to describe visual content quickly.

What it does

Describe Image can generate:

Detailed image descriptions
Brief image summaries
Alt text for accessibility
OCR text from screenshots and documents
Social media captions
SEO-friendly image descriptions
Product listing copy
Chart analysis
Document summaries
Image-to-prompt results

Why I built it

A lot of modern workflows start with an image, but the next step often needs text. A product photo may need a listing description. A screenshot may need OCR. A website image may need alt text. A chart may need a short explanation. A visual reference may need to become a prompt.

Describe Image is designed to make that process faster. Users can upload an image, choose the output type they need, and get a practical first draft in seconds.

Who it is for

The tool is useful for people who regularly work with visual content, including content creators, marketers, bloggers, e-commerce sellers, website owners, students, and teams working on accessibility or SEO.

The goal is not to replace human editing, but to reduce repetitive writing work and make images easier to understand, search, edit, and reuse.

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.

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.

Effective HTML Elements for Accessibility in Web Design

Tue, 24 Feb 2026 20:08:58 +0000

In the world of web design, ensuring accessibility is not just a best practice; it's a necessity. By leveraging the right HTML elements, developers can create web pages that are usable for everyone, including those with disabilities. Here are some key HTML features to focus on:

Semantic HTML: Use elements like <header>, <nav>, <article>, and <footer> to structure your content meaningfully. This helps screen readers interpret the page better.
Forms and Inputs: Properly label every form input using <label> tags. This improves the experience for users relying on assistive technologies.
Alt Text for Images: Always provide descriptive alt attributes for images using the alt attribute. This ensures that users who cannot see the image still understand its purpose.
ARIA Roles: When standard HTML cannot accommodate a specific requirement, consider using ARIA (Accessible Rich Internet Applications) roles to enhance assistive technology behavior. For instance, use role="navigation" to define navigation landmarks.
Headings Hierarchy: Maintain a clear heading structure using <h1> through <h6> tags. This not only aids navigation for screen reader users but also assists with SEO.

By incorporating these techniques, you're not just conforming to legal requirements; you're creating a more inclusive web. Testing with various tools like WAVE or Axe can help you identify accessibility issues in your HTML implementation.

Conclusion

Adopting accessible practices is imperative for the future of web design. Start with these HTML elements and continually look for opportunities to enhance accessibility in your projects. Your users will thank you, and so will search engines.

Happy coding!

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.

Building Truly Inclusive Interfaces: An Angular Developer's Guide to ARIA

Tue, 02 Dec 2025 19:09:55 +0000

Accessibility (often shortened to a11y) isn't just a compliance requirement—it's a critical aspect of modern software development. A well-built interface should be usable by everyone, regardless of disability or the assistive technologies they rely on.

In the world of Angular, achieving high accessibility standards, especially for complex interactive components, just got significantly easier with the introduction of Angular Aria.

What is ARIA and Why is it Essential?

ARIA (Accessible Rich Internet Applications) is a set of attributes that you can add to HTML elements. Its purpose is to define ways to make web content and web applications, especially those developed with JavaScript, more accessible to people with disabilities.

While standard HTML elements (like <button> and <input type="radio">) have built-in accessibility, many modern UI patterns (like complex menus, tabs, and grids) are built using generic elements (<div>, <span>). ARIA attributes provide the necessary semantic information to assistive technologies (like screen readers) that these generic elements lack.

However, implementing these W3C Accessibility Guidelines correctly—handling complex keyboard interactions, focus management, and dynamic ARIA attributes—can be a significant and specialized effort.

Introducing Angular Aria: Accessible Components, Your Way

Angular Aria is a collection of headless, accessible directives designed to simplify the implementation of common WAI-ARIA patterns.

The term "headless" is key here:

You provide the HTML structure, the CSS styling, and the business logic.
Angular Aria provides the accessibility implementation.

These directives handle all the tedious, error-prone aspects of a11y, including:

Keyboard Interactions: Ensuring users can navigate components (e.g., opening a menu with Enter, navigating options with arrow keys, closing with Escape).
ARIA Attributes: Automatically setting and updating necessary attributes like aria-expanded, aria-selected, and aria-label.
Focus Management: Moving focus logically between elements for seamless interaction.
Screen Reader Support: Providing clear announcements of a component's state and available options.

Installation:

npm install @angular/aria

What's Included in Angular Aria?

Angular Aria provides pre-built accessibility logic for a wide range of common UI patterns, organized into three categories:

1. Search and Selection

Component	Description
Autocomplete	Text input with filtered suggestions as the user types.
Listbox	Single or multi-select option lists with keyboard navigation.
Select	Single-selection dropdown pattern.
Multiselect	Multiple-selection dropdown pattern with a compact display.
Combobox	Primitive directive for coordinating a text input with a popup.

Component	Description
Menu	Dropdown menus that can include nested submenus and keyboard shortcuts.
Menubar	Horizontal navigation bar for persistent application menus.
Toolbar	Grouped sets of controls with logical keyboard navigation.

3. Content Organization

Component	Description
Accordion	Collapsible content panels (can expand individually or exclusively).
Tabs	Tabbed interfaces with automatic or manual activation modes.
Tree	Hierarchical lists with expand/collapse functionality.
Grid	Two-dimensional data display with cell-by-cell keyboard navigation.

When to Use Angular Aria (and When Not To)

Angular Aria is a powerful tool, but it's not meant to replace every other accessibility solution.

Use Angular Aria When...	Consider Alternatives When...
Building a Design System: Your team needs accessible implementations that match specific visual standards.	You Need Pre-Styled Components: Use Angular Material or similar libraries if you want components that look complete out-of-the-box.
Custom Branding is Required: The interface must match precise design specifications that pre-styled component libraries cannot easily accommodate.	Building Simple Forms: Native HTML controls like `<button>` and `<input type="checkbox">` offer built-in, reliable accessibility.
Creating Enterprise Component Libraries: You are creating reusable, WCAG-compliant components for multiple applications.	Rapid Prototyping: Pre-styled component libraries offer faster initial development time for validating concepts quickly.

By separating the accessibility logic (Angular Aria) from the visual presentation (your HTML/CSS), Angular empowers developers to build bespoke, beautiful, and completely inclusive components without becoming ARIA experts overnight.

Start exploring the directives—the Toolbar is an excellent place to begin—and transform your approach to web accessibility today!

Speed, Reach, Cost: The Triple Win of Web Standards on Blue Beanie Day

Sun, 30 Nov 2025 10:31:22 +0000

Sunday, November 30th 2025, marks the 18th annual Blue Beanie Day. Okaaaaay, why is this relevant for inclusion?

Blue Beanie Day reminds us to pay attention to web standards in order to create sites that load faster, reach more users, and cost less to maintain. Accessibility is part of these standards.

The web was designed with accessibility in mind.

Exactly 10 years ago, Tumblr user BlueBeanieDay posted:

It’s a thrilling time to create web content and experiences, as more new coders join our ranks, using more new tools and frameworks to create more new kinds of content, experience, and interactivity. But in this environment that moves faster than reason, it’s too easy for our community—and the breathless media that reports on it—to lose sight of vital basics.

Progressive enhancement and accessible, semantic markup aren’t optional extras. They’re the foundation of a web that works for all people, of whatever ability, on whatever devices they choose to access it.

All of the above still stands true today. Web design and development have become popular career paths, with many emerging self-taught talents. Being self-taught myself, I know the pros and cons.

Pro: With no degree or anything to show, you really have to prove your skills through your skills.
Con: You only learn what you choose to learn. Many things can slip in between the grooves of your keyboard like crumbs, so close yet always eluding your fingertips.

You don’t learn what you don’t know, and with a severe lack of web accessibility curriculum standardisation, accessibility is unfortunately most often part of this category.

Even formal education isn’t a guarantee that you will know the basics of accessibility. Luckily, an increasing number of teachers and boot camps make a conscious effort to include web accessibility in their curriculum, but that remains an individual effort.

So let’s take Blue Beanie Day as an occasion to master the basics. I know, I know, plain HTML5 is not as sexy as the latest release cutting-edge tech stack (unless your name is Manuel). But it’s important to understand (and honour) the blueprints today’s web is built on:

The World Wide Web Consortium (W3C), along with other groups and standards bodies, has established technologies for creating and interpreting web-based content. These technologies, which we call “web standards,” are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the Web.

Designing and building with these standards simplifies and lowers the cost of production, while delivering sites that are accessible to more people and more types of Internet devices. Sites developed along these lines will continue to function correctly as traditional desktop browsers evolve, and as new Internet devices come to market.

WaSP - The Web Standards Project

Web Standards are what keep the web usable, independent of browser and device. Not only now but for the next decades to come.

Digital accessibility is an integral part of web standards.

The web was built on the idea that anyone, on any device, should be able to read, navigate, and contribute.

One of the biggest players in Web Standards today is the World Wide Web Consortium (W3C). That abbreviation rings a bell, right? Maybe because they have published the Web Content Accessibility Guidelines (WCAG) since 1999. Now we are feverishly anticipating version 3.0, growing from the original 14 guidelines to 85 success criteria grouped into 13 guidelines.

Take the blue beanie as a reminder to start small, but think big.

Today, spend a few minutes checking one of your own pages with an accessibility tester (WAVE, axe dev tools, or Google Lighthouse). Fix the most obvious issues: missing image descriptions, hierarchical heading order, and sufficient colour contrast. Then share what you learned on social media with the hashtag #BlueBeanieDay. By turning a single day into a habit, we keep web standards alive for the next generation of developers and designers.

Blue Beanie Day Resources

Resources for Developers
WaSP Web Standards Project
Web Standards by W3C
Accessibility Fundamentals by W3C
Designing with Web Standards, the book that started it all.
The original Jeffrey Zeldman also has a handy dandy post on How to join Blue Beanie Day.
Blue Beanie Day on Tumblr: #a11y is code for “Love Your Neighbor”

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

AccessFix

Wed, 05 Nov 2025 01:00:25 +0000

A few months ago, I was reading through accessibility reports for one of my projects and realized how tedious and inconsistent most a11y tools feel — either too technical for non-specialists or too shallow for developers.

That’s when I started building AccessFix, a developer-first accessibility checker that makes finding (and fixing) accessibility issues as easy as running a linter.

The goal:
Make accessibility scanning fast, actionable, and part of every developer’s normal workflow — not an afterthought.

How It Works
AccessFix runs scans using axe-core, the industry-standard open-source accessibility engine.

You can:

Upload your HTML file
Paste a website link
Or connect your GitHub repository

Once scanned, AccessFix gives you:

A score (based on detected issues)
A downloadable report — written in plain English for quick fixes
An optional GitHub Pull Request — it auto-comments on lines with detected issues so your team can fix them inline

All runs happen in your browser or via GitHub integration — no setup needed.

Key Features:

axe-core Integration — industry-grade accessibility checks
Scoring System — quickly gauge overall accessibility health
Downloadable Reports — shareable summaries in plain English
GitHub PR Generation — automatic inline comments for issues
Multi-Input Scanning — upload files, enter URLs, or scan repos

(More features like CI/CD integration, AI integration, color analysis, and advanced scoring are coming soon!)

Sneak Peek

Demo video (30s) AccessFix Demo Video

How Others Can Get Involved

We’re looking for early testers and developers interested in shaping accessibility tools that actually fit into real workflows.

Feedback I’m Looking For

What would make you actually use AccessFix regularly?
Any feature you wish existed in accessibility tooling?

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.

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.

Hello World! Welcome to the Accessibility Group!

Wed, 24 Sep 2025 05:27:05 +0000

Hello World! Welcome to the Accessibility Group!

We’re excited to have you here! This is a space where you can share, learn, and connect with other developers who love Accessibility.

Start by saying hi!

Introduce yourself in the comments below—tell us your name, what you’re working on, or something fun about yourself. We’d love to get to know you!

Once you’ve said hi, you can:

Share your HTML tips or interesting projects.

Ask questions and get feedback from the community.

Comment on and support other members’ posts.

We’re happy you joined the Accessibility Group and can’t wait to see your contributions. Let’s make this a friendly and helpful place to learn together!

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 accessibility

When Should Delete Offer Undo?

When Is a Progress Bar Misleading?

Image SEO in 2026: Alt Text, Modern Formats and Fast Loading

Key takeaways

Can a Keyboard-Only User Finish Your App’s Main Task?

My GitHub Sponsors Is Live: Help Me Build Creative Tools Blind People Can Actually Use

Who I am

What I'm building

How you can help

AmazingPlugins

Your Repo Can Now Tell People It Cares About Accessibility

Why it matters

What we put in ours

Add one to your project

FOUC-Proof Retro Design Systems

The Pitfall of Retro Aesthetics on the Web

The Mathematics of Accessible Contrast

Eliminating FOUC with Synchronous Head Scripts

Maintaining a Single Source of Truth

What a 100 Accessibility Score Didn't Check

The baseline

What the 100 covers

Decorative icons

Landmarks

Checking it

What's still open

Your site looks AI-generated. Here's how to fix it

Why the AI look shows up so often

Pass one: brief the agent with references and reasons

Pass two: describe visitor jobs before visual direction

Pass three: treat the agent as a potential customer on the live URL

Pass four: run an accessibility check as a UX pass

What this ritual will not do

Ship the next page without the average

References

Audit the accessibility tree, not only the Lighthouse a11y score

What the accessibility tree exposes (roles, names, states)

Lighthouse accessibility score versus an accessibility tree audit

Money-page checklist: can an agent act from the tree alone?

JavaScript rendering gaps the accessibility tree makes obvious

Headings, landmarks, and accessible names agents actually receive

Put ARIA snapshots in CI so the tree cannot silently regress

Where WebMCP and agentic browsing monitoring sit beside the tree

FAQ

Does a green Lighthouse accessibility score mean the accessibility tree is agent-ready?

Is accessibility tree SEO a replacement for WCAG work?

Where should agencies start this week?

CTA

References

The Story Behind Accesstive: Web Accessibility. Done Right.

The Full Circle Philosophy Behind py-simple-wrap

Heading hierarchy is not a design trade-off

What heading hierarchy means in HTML (and what it is not)

Why teams treat headings as a visual problem

How broken heading levels hurt SEO and internal linking

What screen readers do when you skip from H2 to H4

Why LLMs and answer engines read headings differently than CSS

How to keep one H1 and logical H2/H3 without flattening the design

How to audit heading structure on a client template before the next deploy

Which accessibility fixes show up in Core Web Vitals dashboards?

Why do accessibility audits and Core Web Vitals dashboards tell different stories?

Which keyboard and interaction fixes move INP on monitoring dashboards?

Which focus and layout fixes show up as CLS improvements?

Focus rings that change layout on :focus

Focus moves that scroll unstable pages

Which accessibility improvements help LCP without changing the hero image?

Which accessibility fixes never appear on a Core Web Vitals dashboard?

How should agencies monitor accessibility-related fixes alongside Core Web Vitals?

Next step: tag one audit fix with the Core Web Vital it should move

WCAG Color Contrast: What Developers Need to Know About Accessibility

What WCAG says

How contrast ratio is calculated

Common contrast failures

Automating contrast checks

Iris: An Offline Visual Assistant in Brazilian Portuguese Powered by Gemma 4

What I Built

Demo

Code

Why This App Needed To Be Offline

Focus rings that change layout on `:focus`

Speed, Reach, Cost: The Triple Win of Web Standards on Blue Beanie Day