Every few months someone proposes a new standard so AI agents can interact with websites. WebMCP, llms.txt, agent metadata layers.
The accessibility tree already solves this. Labels, roles, states, actions, input formats, validation feedback, it's all there. A screen reader user and an AI agent need the exact same information. If your site works for one, it works for the other.
If you find something an agent can't do through the accessibility layer, you've found something a disabled person's assistive technology can't do either. So fix accessibility. Don't build a parallel system.
I filed an issue on the W3C WebMCP repo asking for a concrete use case that (1) can't be handled by the accessibility tree, (2) isn't better served by a backend API, and (3) wouldn't also benefit assistive technology if added to the accessibility layer.
For the copyright thing, I understand that there's legit ongoing debate around all this AI-assisted coding and copyrightability.
In this case of zpdf, while Claude Code did a lot of the heavy lifting on implementation, there was a real effort in architecture decisions, iterative prompting/refinement, debugging, testing, benchmarking.
My intent is zero restrictions: use it, fork it, sell it, whatever. WTFPL captures that spirit perfectly for me. It's as permissive as legally possible while being upfront about not caring.
The goal is just to make a useful tool freely available.
- Memory-mapped file I/O (no read syscalls)
- Zero-copy parsing where possible
- SIMD-accelerated string search for finding PDF structures
- Parallel extraction across pages using Zig's thread pool
- Streaming output (no intermediate allocations for extracted text)
What it handles:
- XRef tables and streams (PDF 1.5+)
- Incremental PDF updates (/Prev chain)
- FlateDecode, ASCII85, LZW, RunLength decompression
- Font encodings: WinAnsi, MacRoman, ToUnicode CMap
- CID fonts (Type0, Identity-H/V, UTF-16BE with surrogate pairs)