A few weeks ago, my friend Melissa Milloway told me she had vibe coded a PDF in Claude and was curious about recommendations for quick accessibility checks – just to see how it performed. She knew the typical things to check for, but didn’t know how much to trust the tool she was using or whether there were any particular accessibility checkers she should try.
With the growing popularity of vibe coding, I decided it was time to pressure test it with my own accessibility workflow. Inspired by Mel’s example, I decided to create a simple one-pager for a nonprofit leadership conference. In this blog post, I’ll share what I learned.
TL;DR Automated accessibility checkers don't replace real testing with assistive technology (AT) such as screen readers and magnifiers, preferably by someone who's a natural user of AT. Also, AI will confidently tell you that something passes an accessibility check when it doesn't.
Monday: First Prompt
1:29PM – I give Claude our existing source information, visual style guidelines, and ask it to create a one pager with WCAG (Web Content Accessibility Guidelines) 2.2 AA conformance.
I spent about three painful hours of prompting to adjust the copy and formatting over and over again. Even though I know exactly what I wanted at a code level for the HTML and CSS, the process of making these adjustments is much slower in a prompt-based interface. It feels like standing over someone’s shoulder and telling them what to do rather than just doing it myself.
4:41 PM – I realize that Claude has gone off the rails when making decisions about other adjustments, so I have to force accessibility back on track again. My goal is for this accessible PDF to be available at the conference in print with a digital version on my website, so I carefully check font size and type, readability, color, and contrast.
6:13 PM – Something unexpected happens. Claude decides to inject code to change color and contrast, but only when the PDF is printed. The digital version remains the same.
6:34 PM – After two hours of unsuccessfully trying to get the HTML converted to a printed PDF with the correct margins, color, and contrast, I stop and call it a day.
Tuesday: Try Again
10:57 AM – I beg Claude to help me make this PDF print correctly. No matter what I tell it to do or how I adjust the print settings, it loses a footer, prints with a gap on the edge of the page, or a number of other quirky issues.
11:08 AM – I give up again and revert it back.
Wednesday: Last Chance
1:00 PM – I have some feedback on wording and format and I’m bracing myself. At this point, I’m tempted to pull what I have into another authoring environment, but I decide to stick with it. I give Claude some prompting to continue tweaking the printed version.
2:51 PM – After nearly three hours of adjusting padding in different areas of the document, I’m finally getting a viable printed version. Also, at some point along the way, the issues I’d been having on print mysteriously disappear. I have no idea how it fixed itself and it couldn’t tell me.
Results
First, I print the full color one-pager for the conference and it looks decent enough. Are there still things I’d change? Yes.
Am I done dealing with vibe coding? Also, yes.
Next, I load the digital version of the PDF to our website. Remember that Claude created two versions of the PDF: one that was supposed to be optimized for print and one for digital use.
Time spent: Approximately 8 hours, excluding print time (design layout and accessibility only; we already had the style and content)
Water used: Based on estimates for intensive AI vibe coding sessions, 8 hours of prompting Claude to generate a one-pager could consume approximately 4 to 18 gallons of water. Reference: Hidden Costs of AI: Practical Steps to Reduce Energy and Water Use
Review – Digital Accessibility Checker
Claude promised that the digital version of the one pager passed WCAG 2.2 AA with no issues. WAVE gave the digital version of the one pager a 10 out of 10.
Review – Human
The source HTML version that Claude created was okay. It was missing alt text for the logo and some of the headings were not tagged properly. Reading order was correct. Unfortunately, the HTML version wasn’t what I needed. I needed an accessible PDF to use in both print and digital formats.
✅ The printed PDF met acceptable accessibility standards. It was high contrast and when printed and the text size was acceptable.
❌ Digital accessibility of the PDF is mediocre at best. The Build Capable logo doesn’t have alt text. There are missing heading tags and some of the heading tags break one heading into multiple headings (each word is tagged as it’s own heading). The reading order is not retained in the accessible PDF version. These would all be easy for me to fix if I could edit the code myself, but Claude just wasn’t getting it done.
Here’s a VoiceOver (Mac) screen reader demo comparison, starting with the source HTML version and ending with the digital PDF.
This activity demonstrates that Claude falls short when it comes to putting a human in control of the design. I found vibe coding a simple design very frustrating and ended with an output that I needed to edit in a different tool where I could really control the look and accessibility functionality.
The opportunity for AI in the design space, I believe, will be focused, AI-supported authoring environments that can quickly provide initial structure, but give the human direct control of editing the elements. I’m certainly not convinced that a chat-based authoring environment alone is an efficient, effective way to do this work – especially not for experienced design professionals. It may get you started with a fast first draft, but cross your fingers that it’s one you can work with.