https://aaardvarkaccessibility.com/

AAArdvark, Los Angeles, CA (2026)

06/04/2026

Ever had an accessibility issue flagged, gone looking for the element on your page, and just couldn't find it?

There's a good chance it was hiding inside an iframe or a shadow DOM. Both are ways of nesting one part of a page inside another: an embedded form, a third-party widget, a video player, a web component someone dropped in. The element is really there, but it lives in its own little world, so searching the page the normal way doesn't turn it up.

That's one of the most frustrating parts of fixing accessibility issues. You can see the problem in the report, but you can't see where it actually is.

AAArdvark now shows you. When an issue sits inside an iframe or the shadow root of a component, the issue card says so, right above the code, so you know exactly where to look before you start digging.

It's a small piece of context, but it saves the part of the job nobody enjoys: hunting for an element you already know is broken.

You can't fix what you can't find. Try it with a free account at https://a20y.com, no credit card required.

[Image description: Heading "Iframes and shadow DOM." Below it, a screenshot of a complex app titled "Operations Dashboard" with a left navigation menu, data cards, a chart, and a list of recent alerts. A highlighted strip near the bottom, marked with arrows, shows an AAArdvark issue card banner reading "Inside iframe: -container > div > div > div > iframe" directly above a code block beginning with "". The AAArdvark logo and a20y.com appear at the bottom.]

06/03/2026

Your accessibility scanner gave you a perfect score. So you're done, right?

Not quite. Automated scanners are fast and useful, but they only catch a fraction of the accessibility issues real people run into. A clean scan can still hide a broken keyboard experience, a confusing screen reader flow, or a form nobody can actually complete.

In this session, Natalie MacLees runs a site through multiple scanners, gets the green checkmarks, and then tests the same page with keyboard navigation and a screen reader to reveal everything the tools missed: focus order, dynamic content, meaningless labels, decorative-vs-informative images, and voice control breakage.

You'll leave knowing where automated testing genuinely helps, what it can't see, and a simple workflow for catching the issues that matter before you call anything done.

Bring your questions. We'll be testing live.

06/02/2026

A11y Tip of the Week: End your alt text with a period.

It sounds like a tiny detail, but it changes how an image description sounds out loud. Many screen readers don't pause between an image's alt text and whatever comes next on the page. Without punctuation, the description runs straight into the following heading or sentence, and the listener loses track of where the image ended.

A period at the end creates a natural pause. It signals that the description is finished before the screen reader moves on.

One more habit worth building: write alt text as a real phrase or sentence, then close it with a period. "Golden retriever asleep on a blue couch." reads better out loud than a string of comma-separated keywords.

Here's the catch: no automated checker will flag a missing period. It's the kind of detail you only notice when you actually listen to your own pages. Turn on a screen reader, tab to an image, and hear where the description ends.

[Image description: Heading "End alt text with a period." On a dark navy background, an audio bubble with a speaker icon shows what a screen reader announces when there's no pause between an image and the text after it: "Golden retriever puppy sound asleep in a bed our adoptable puppies." Below the bubble, a photo of a golden retriever puppy asleep on a bed sits beside a section headed "Our Adoptable Puppies." A caption reads: "Without a period alt text runs together with text content that comes after the image."]

05/27/2026

We just shipped 40+ new accessibility issue guidance entries in two weeks.

Most accessibility scanners (axe, IBM Equal Access, HTMLCS, Lighthouse) hand you a list of rule IDs and a one-line description. Something like "aria_required_parent" or "H91.Select.Value." If you're not already deep in WCAG, that's not actionable. You know something failed. You don't know what it is, who it affects, or how to fix it.

That gap is where accessibility work falls apart. Teams either ignore the warnings, paper over them with "we'll handle it later," or burn an hour Googling each one.

So we've been steadily closing it. Every failure that comes back from our scanners gets a plain-language guidance page inside AAArdvark:

• What the rule actually checks
• Who it impacts and why
• The exact pattern that triggers it
• How to fix it (with a code example when it helps)
• A link out to the underlying WCAG criterion for people who want to go deeper

This month we filled in guidance for 19 new IBM, Axe, and HTMLCS rules. Form labels, ARIA roles, table headers, language attributes, fieldset structure, hover persistence, status messages - the long tail of stuff that scanners flag but never explain.

This is the work that doesn't make a launch announcement. It just quietly makes a scan report 10x more useful the next time someone runs one.

If you've been frustrated by accessibility tools that give you a rule name and walk away, AAArdvark is worth a look. The free plan lets you run scans on your own sites and see the guidance in context.

a20y.com

05/26/2026

A11y Tip of the Week: click the label. Did the input focus?

If your site has any kind of form, here's a 30-second test that needs no DevTools, no scanner, and no a11y experience. Click on the visible text of a form label. Watch what happens.

Three possible outcomes:

• You click the label and the input gets focus (or the checkbox toggles). That's a properly associated label. Pass.
• You click the label and nothing happens. The label and input aren't actually connected - they just look like they are. Fail.
• You click and your cursor lands inside the label, selecting text. Same problem. Fail.

When a label isn't programmatically associated with its input, two things break at once:

• The clickable hit area shrinks to just the visible input. For a checkbox, that's about 16 by 16 pixels - hard to hit on touch, brutal for motor-impaired users.
• Screen readers can't connect the label to the field. The user hears "edit, blank" with no idea what to type.

The fix is almost always one line of HTML. Match the label's "for" attribute to the input's id. Or wrap the input inside the label tag - no id needed.

Placeholders are not labels. A div styled to look like a label is not a label. The browser needs the actual relationship to do its job.

This is the tip we'd hand to a non-developer who wants to spot-check their own forms today. It catches a real, common, fixable failure - and it works on everything from a contact form to a signup flow to a checkout.

[Image description: Title text reads "Click the label." Below, an illustration of a form with a checkbox and the label text "I agree to the terms." A cursor hovers over the label text with an arrow pointing to the now-checked checkbox.]

05/26/2026

A11y Tip of the Week: click the label. Did the input focus?

If your site has any kind of form, here's a 30-second test that needs no DevTools, no scanner, and no a11y experience. Click on the visible text of a form label. Watch what happens.

Three possible outcomes:

• You click the label and the input gets focus (or the checkbox toggles). That's a properly associated label. Pass.
• You click the label and nothing happens. The label and input aren't actually connected - they just look like they are. Fail.
• You click and your cursor lands inside the label, selecting text. Same problem. Fail.

When a label isn't programmatically associated with its input, two things break at once:

• The clickable hit area shrinks to just the visible input. For a checkbox, that's about 16 by 16 pixels - hard to hit on touch, brutal for motor-impaired users.
• Screen readers can't connect the label to the field. The user hears "edit, blank" with no idea what to type.

The fix is almost always one line of HTML. Match the label's "for" attribute to the input's id. Or wrap the input inside the label tag - no id needed.

Placeholders are not labels. A div styled to look like a label is not a label. The browser needs the actual relationship to do its job.

This is the tip we'd hand to a non-developer who wants to spot-check their own forms today. It catches a real, common, fixable failure - and it works on everything from a contact form to a signup flow to a checkout.

[Image description: Title text reads "Click the label." Below, an illustration of a form with a checkbox and the label text "I agree to the terms." A cursor hovers over the label text with an arrow pointing to the now-checked checkbox.]

05/21/2026

It's GAAD (Global Accessibility Awareness Day). Here are three things any team can ship today to mark it on your own site:

1. Make sure every interactive element has a visible focus style. The default browser outline isn't pretty, but invisible focus is worse. If your CSS includes outline: none anywhere, replace it with something visible - a clear border, a stronger outline, anything keyboard users can actually see.

2. Audit alt text on your three most-visited pages. Empty alt for purely decorative images. Real, descriptive alt for anything that carries meaning. Skip generic placeholders like "image" or filenames - if the alt text doesn't tell a non-sighted user what the image communicates, it isn't doing its job.

3. Run a free scan of your site to see what else is hiding. AAArdvark's free plan checks the whole thing - WCAG failures, color contrast, missing labels, keyboard issues - and gives you a punch list to work from. No credit card, no demo call.

Get started: https://bit.ly/46QW1gD

GAAD is one day a year. What you ship today can help your users every day after.

05/20/2026

Most people think of accessibility as something for disabled users. That framing isn't wrong, but it isn't the whole picture. Accessibility helps every user, often in ways most teams never think to design for.

This Thursday is Global Accessibility Awareness Day. To mark the occasion, AAArdvark founder Natalie MacLees walks through a different way to talk about accessibility: not as a niche concern for a small group of users, but as a feature that pays back across permanent, temporary, and situational disability. Captions in a noisy bar. Voice control while you're cooking dinner. Keyboard navigation when the trackpad finally gives up. The same patterns over and over.

We'll cover:

• The story behind Global Accessibility Awareness Day, and why it still matters in 2026
• The Persona Spectrum: how permanent, temporary, and situational disability all need the same things from your site
• The curb cut effect, and why features built for disabled users so often become features everyone uses
• Live demos of captions, voice control, screen readers, and keyboard navigation in everyday scenarios
• What this perspective changes about how you design, build, and test
• Three things you can do this week to mark GAAD on your own site

This stream is for anyone who builds, designs, writes for, or owns a website. No code or accessibility background required. If you're a developer who wants a sharper way to make the case for accessibility on your team, you'll get plenty out of it. If you're a designer, content person, or business owner who's heard "accessibility" but never quite known where to start, this is the one for you.

05/20/2026

Most people picture accessibility as something for disabled users. That picture isn't wrong, but it isn't the whole story. Accessibility helps everyone, often in ways most teams never think to design for.

Tomorrow is Global Accessibility Awareness Day. Today at 1pm PT, AAArdvark founder Natalie MacLees is going live to walk through a different way to talk about accessibility: not as a niche concern, but as a feature that pays back across permanent, temporary, and situational disability. Captions in a noisy bar. Voice control while cooking dinner. Keyboard navigation when the trackpad finally gives up.

She'll cover:

• The story behind Global Accessibility Awareness Day, and why it still matters in 2026
• The Persona Spectrum, and how the same accessibility need shows up in unexpected places
• The curb cut effect, with live demos of features built for disabled users that everyone now uses
• What this perspective changes about how you design, build, and test
• Three things you can do this week to mark GAAD on your own site

This one is for anyone who builds, designs, writes for, or owns a website. No code or accessibility background required. Bring your questions for live Q&A throughout.

https://bit.ly/4uVok85

AAArdvark

06/04/2026

06/03/2026

06/02/2026

05/27/2026

05/26/2026

05/26/2026

05/21/2026

05/20/2026

05/20/2026

Address

Website

Alerts

Contact The Business

Shortcuts

Share

Category