CivicBinder's fulfillment lane stopped after repeated network failures because Node was choosing DNS addresses in an unstable order. Commit ad21608 fixed the failure by setting IPv4-first resolution before the helper's network calls. The live CivicBinder page shows what that work produces: a scan, a document inventory, policy and statement text, and a dated remediation plan.
CivicBinder
Accessibility evaluation
The main page describes an automated WCAG 2.1 AA evaluation covering up to 150 pages and 100 PDFs, with findings ranked by severity.
The evaluation turns scan results into findings that can be explained and handed to the person responsible for repairs.
Document inventory
The binder outline includes a document inventory covering every PDF on the site and its accessibility status.
The inventory keeps documents inside the same dated scope as the page scan, so the binder records what was checked rather than only describing the website generally.
png)
Accessibility Policy
The live binder outline includes an Accessibility Policy prepared for adoption by the governing body.
The policy gives the entity a document it can take through its regular meeting process instead of leaving the scan as a standalone technical report.
Accessibility Statement
The binder includes an Accessibility Statement ready to publish, with a feedback mechanism.
The statement turns the findings into public-facing text and gives visitors a route for reporting accessibility problems.
png)
Remediation plan
The binder outline includes a dated, phased remediation plan described as vendor-executable.
The plan orders repairs by severity and gives the work a schedule tied to the scan and the entity's applicable Title II date.
Pages evaluated
The binder includes an appendix listing the pages and documents in scope, along with the scan date.
That appendix limits the claim to the material CivicBinder actually evaluated, which makes the resulting record specific to the site state captured by the scan.
Fulfillment network helper
The commit named ad21608 changed ops/fulfill/services.mjs after the fulfillment lane exited with the same failure code repeatedly. The commit message identifies unstable DNS address ordering as the cause.
import { readFileSync, writeFileSync, existsSync, chmodSync } from 'node:fs';
import { execFileSync } from 'node:child_process';
+import { setDefaultResultOrder } from 'node:dns';
import { join, dirname } from 'node:path';
import { fileURLToPath } from 'node:url';
export const HERE = dirname(fileURLToPath(import.meta.url));
+setDefaultResultOrder('ipv4first');
const ENV_CACHE = join(HERE, '.env');
The fix sets Node's default DNS result order before the helper reaches its network calls. I kept the change at the helper boundary, where the failure occurred, and left the fulfillment operations around it unchanged.
Top comments (0)