Free Tools to Build a More Accessible Web: ArcStone’s 2026 Accessibility Toolkit

This Thursday is Global Accessibility Awareness Day. Rather than writing another post about why accessibility matters (you already know), I want to share something practical: a collection of free tools my team and I use every day to build accessible websites.

At ArcStone, accessibility has been core to how we work for over a decade. We’re a certified B Corp, and we take seriously the idea that the web should work for everyone. That conviction eventually led us to build Insi, our own accessibility scanning platform, because we kept running into the same problem: the existing tools either didn’t catch real issues or cost more than our nonprofit and government clients could justify. Building Insi taught us a lot about what works, what doesn’t, and where the gaps are in the accessibility workflow.

The tools in this toolkit grew out of that same frustration. We built them because we needed them — for client projects, for internal QA, for translating vendor documentation into something a real person could understand. They’ve been tested on real websites for real organizations, and they work.

A note about AI and accessibility. Several of these tools are AI-powered prompts. I want to be clear-eyed about that. Accessibility is fundamentally about people. It exists because real humans with real disabilities need the web to work for them. No AI tool replaces the lived experience of a person navigating your site with a screen reader, a switch device, or a keyboard. Manual testing by real people is always the final word.

What AI is genuinely good at is accelerating the tedious, repeatable parts of accessibility work — converting PDFs to semantic HTML, translating dense VPAT documents into plain language, generating color contrast references from brand guides. These are tasks that used to take hours and often just didn’t get done because nobody had the time. AI makes them fast enough that they actually happen. The quality still needs human review, but the first draft is no longer the bottleneck.

Every tool in this toolkit is free. No signup, no email gate, no sales pitch. Download the ZIP, use what’s helpful, ignore what’s not.

Insi Accessibility Tool Discount

ArcStone’s spinoff company Insi, is also celebrating GAAD with a special offer. Insi is offering a discount on its accessibility scanning platform. Through the end of May, new customers get 25% off their first year. If you’re a nonprofit, that doubles to 50% off. Insi uses virtual browser technology to scan your website the way a real user experiences it — catching accessibility issues that traditional code-only scanners miss. If you’ve been meaning to get a handle on your site’s accessibility, this is a good time. Request your discount code at insihub.com.

What’s Included In The Toolkit

Accessibility-Informed Analytics

One question I hear constantly from clients: “How many people with disabilities are visiting our site?” It’s a fair question, but the honest answer is more nuanced than most people expect.

Screen readers, switch devices, and voice control software deliberately hide themselves from websites. This is a privacy protection, not a limitation. If sites could detect specific assistive technologies, it would create a vector for discrimination — serving different content, blocking access, or profiling disabled users. Browsers have actively closed detection methods the disability community flagged as surveillance risks.

But there are signals you can observe. Operating system preferences like reduced motion, high contrast, and inverted colors are set deliberately by users and exposed to websites through CSS media queries. Browser zoom levels above 100% are detectable. And interaction patterns — whether someone navigates entirely with a keyboard versus a mouse — can be observed behaviorally.

I built a free Google Tag Manager script that detects these signals and pushes them into Google Analytics 4 as custom events. It tracks seven signals across two tiers: OS-level preferences (reduced motion, high contrast, dark mode, inverted colors) and behavioral patterns (keyboard-only navigation, browser zoom, text scaling). A summary event fires once per session rolling everything up into a single data point for easy reporting.

What makes this useful is connecting the data to your accessibility work. If 15% of your visitors navigate primarily with keyboard, and your site has keyboard trap issues, you now have evidence that real users are affected. It turns accessibility from an abstract compliance exercise into something grounded in actual visitor behavior.

The script, setup guide, and GA4 configuration instructions are all free. Setup takes about 30 minutes if you already have GTM and GA4 running. I’m calling the approach “Accessibility-Informed Analytics” because that’s what it is — aggregate behavioral data that informs your accessibility priorities without identifying or profiling individual assistive technology users.

Accessibility Statement — Third-Party Vendor Content Generator

If you manage a website, you almost certainly use third-party tools: payment processors, event registration widgets, chat tools, video players, donation platforms, map embeds. Each one introduces accessibility considerations you don’t fully control, and most accessibility statements either ignore these vendors entirely or wave them away with “we’re working with our vendors to improve.”

That’s not good enough. Someone using a screen reader deserves to know that the event registration widget on your site has known keyboard navigation issues before they spend 10 minutes trying to complete a form that won’t cooperate.

The W3C actually has guidance for this. Their conformance provisions allow for “statements of partial conformance due to third-party content” — meaning you can acknowledge that your site would conform to WCAG except for specific vendor content you don’t control. But translating a vendor’s VPAT (Voluntary Product Accessibility Template) into plain-language disclosure that actually helps people is tedious, technical work that rarely gets done.

This prompt automates that translation. You feed it three things: the vendor’s VPAT or accessibility documentation, the URLs on your site where that vendor’s product appears, and your existing accessibility statement (so it can match your tone and voice). It generates a self-contained section you can drop directly into your accessibility statement that explains what the vendor’s product does, where users will encounter it, what accessibility barriers they may experience described in plain language, and how to get help.

It handles edge cases too — vendors with no documentation at all, outdated VPATs that reference old WCAG versions, products that are only accessed via outbound links versus embedded on your pages, and vague vendor claims that can’t be verified.

The goal is honest transparency for the people who need it most: someone using assistive technology who’s about to interact with a vendor widget on your site and needs to know what to expect.

WCAG 2.2 AA Color Contrast Guide Generator

Brand guides are designed for print. The web has different rules. That signature orange that looks gorgeous on a poster might produce a 2.8:1 contrast ratio against white — well below the 4.5:1 minimum WCAG requires for body text. Most teams don’t discover this until an accessibility audit flags it, and by then the color is baked into every page of the site.

This prompt turns any brand guide PDF into a complete, interactive color contrast reference. Attach your brand guide to Claude or ChatGPT, paste the prompt, and it generates a single self-contained HTML file — no dependencies, no internet connection required, works from your desktop — with six tabbed sections covering every color combination’s WCAG compliance status.

You get a quick reference showing which brand colors pass for normal text, which are restricted to large text and UI components only, and which fail entirely. Full tables showing every color on white, on black, and on every other brand color. A heat-mapped matrix of every possible combination. And a recommendations tab with specific guidance: which colors are safe for body text, which backgrounds need white versus black text, and which pairings to avoid.

The technical detail that matters: the prompt specifies truncation instead of rounding for contrast ratios, matching industry tools like WebAIM’s Contrast Checker. A raw ratio of 4.5384 becomes 4.53, not 4.54. This sounds minor, but it’s the difference between a color that barely passes and one that doesn’t, and auditors will catch it.

Hand the generated HTML file to your designers, developers, and content editors. Everyone works from the same reference. No more guessing whether that heading color is accessible.

PDF to Accessible HTML Converter

PDFs are one of the biggest accessibility liabilities on most websites. A screen reader can technically read a tagged PDF, but the experience ranges from frustrating to unusable depending on how the document was created. Untagged PDFs — which is most of them — are essentially invisible to assistive technology.

The best solution is providing the content as HTML directly on the page. But if your site has dozens or hundreds of PDFs (meeting minutes, policy documents, event schedules, reports), manually converting each one is a project nobody has time for.

This prompt handles the conversion. Feed it a CSV with PDF titles and URLs, and it returns clean, semantic HTML for each document — proper heading hierarchy starting at H2 (since your page already has an H1), accessible table markup with scope attributes and captions, descriptive link text, ordered and unordered lists, and no inline styles or CSS classes. The output is a fragment designed to drop directly into your CMS.

The prompt handles the judgment calls that make PDF-to-HTML conversion tricky. Multi-column print layouts get linearized into logical reading order. Data tables get proper structure. Infographics with embedded text get converted to structured content. “Click here” links get rewritten to be descriptive. And heading hierarchy gets inferred from the document’s visual structure, since most PDFs don’t have semantic headings to begin with.

This is particularly useful for government and nonprofit websites facing ADA Title II compliance deadlines. If you’ve got a document library full of board minutes, public notices, and program guides in PDF format, this prompt gives you a fast path to making that content accessible.

Website Accessibility QA Checklist

Most accessibility failures aren’t caused by developers who don’t care. They’re caused by teams that don’t have a structured way to check their work at the right point in the project.

A developer can build a perfectly semantic form, but if the designer didn’t spec visible focus states, keyboard users still can’t see where they are. A content author can write great alt text, but if the heading hierarchy is broken at the template level, screen reader users can’t navigate the page. Accessibility is a team sport, and different checks belong to different people at different stages.

This spreadsheet organizes WCAG 2.2 AA requirements into four project stages: wireframe and design, frontend development, content authoring, and QA testing. Each item has a status dropdown, a priority level, a responsible role, a direct link to the relevant WCAG Understanding document, and a plain-language explanation of why it matters and who it affects.

It’s designed to be practical, not exhaustive. The ~65 items cover the issues that actually show up on real projects: missing form labels, broken heading hierarchy, insufficient color contrast, keyboard traps, absent alt text, missing captions. It includes the newer WCAG 2.2 criteria too, like minimum target size and focus appearance, that many older checklists miss.

Drop it into your project management workflow. Hand the Design tab items to your designer during wireframes. Hand the Development items to your frontend team during build. Hand the Content items to whoever’s entering copy. Run the QA section before launch. That’s it.

One Last Thing

Accessibility isn’t a checklist you complete and forget. It’s an ongoing commitment to making sure the things you build work for the widest possible range of people. These tools make that work faster and more consistent, but they don’t replace paying attention, testing with real users, and caring about the outcome.

If you use any of these tools on a project, I’d genuinely like to hear about it. What worked, what didn’t, what you’d add. This toolkit is a living thing — we’ll keep updating it as we learn.

Happy GAAD.

Download ArcStone’s 2026 Web Accessibility Toolkit

Warmly, Nick