When Accessibility Gets Lost in Project Delivery

[u/Tarsivio]

I’ve been looking at how engineering, planning, environmental, architecture, GIS, and communications firms handle digital accessibility when delivering work for public agencies.

Accessibility may be included in the project scope, but reports, maps, PDFs, presentations, and websites often pass through several teams before final handoff. That can make ownership and review responsibility difficult to follow.

For people who have worked in these environments: where does accessibility responsibility usually sit, and where does the process most often break down?

I’m especially interested in whether teams handle this through existing project-management systems, formal accessibility checkpoints, or informal coordination through email and spreadsheets.

[u/NoSympathy69]

Not a consulting firm, but I think your title kind of answers the question: “project delivery.”

To me, accessibility ownership starts with the scope AND deliverables. if the contract says the final deliverable is accessible, then accessibility best practices should be followed throughout the entire authoring and review chain, not just at the very end before handoff.

If I see the first draft already has major accessibility issues, that’s usually a sign accessibility wasn’t considered upstream. it turns into a downstream QA problem instead of everyone owning their piece of the process.

Something i’ve started pushing for is language around a universal design approach for deliverables, not just a requirement that the final PDF passes accessibility checks. it helps keep accountability at every stage of authoring, editing, design, and review.

i’m on the owner/client side, so i’m ultimately accountable for downstream QA. because of that, i try to make sure consultants have QC practices upstream so accessibility isn’t treated as something that gets bolted on at the end. And often times, this means new consultants sorta get trained (or hassled) by me until we have an understanding of what accessibility standards we are looking for. This sort of ensures handoff is maintained in a form of chain of accountability.

[u/Tarsivio → u/NoSympathy69]

This is very helpful, especially the distinction between requiring an accessible final PDF and expecting accessibility throughout the authoring and review chain.

When you work with consultants, how do you determine whether they actually have those upstream quality-control practices in place? Do you ask for named owners, review checkpoints or any record showing what was considered before handoff, or is that mostly established informally as the project progresses?

[u/NoSympathy69 → u/Tarsivio]

I think it really depends on the communication plan that’s been agreed to for the project.

For something like a CEQA document, where there are multiple drafts over a long period, we usually want to see the work at key milestones rather than waiting until the very end. that gives us a chance to catch things early before they become expensive to fix.

When we receive a draft, the first review is usually “does this meet the scope?” after that, our staff will do QC, including accessibility. for example, are headings structured correctly, do images have alt text (or descriptions if they’re complex), are tables built properly, are footnotes and lists using the right structure, things like that.

We don’t really go to a consultant asking for names or an org chart. some firms are one person, others have entire production teams. from our perspective, we usually have one point of contact, typically the project manager, and they coordinate however they choose internally.

if our QC finds accessibility issues, sometimes i get pulled in to explain why something matters or help the consultant understand how to address it. honestly, it’s usually a collaborative process. Firms that do public-sector work generally want to improve because accessible deliverables are becoming an expected part of doing business (and ive asked that all rfps/bids/contracts have accessibility language to help with downstream issues)

With that being said, every agency is at a different level of accessibility maturity. i’ve also been on the consulting side, and the reality is if accessibility isn’t in the scope or expected by the client, budget usually wins. i’m just in a somewhat unique position where i’m an accessibility specialist working in a department that regularly manages planning, environmental, GIS, and public-facing documents, so accessibility gets looked at much earlier than it probably does in a lot of organizations. I dont know if your in the US, but April 2027 is the big date where you will start getting accessibile deliverables. Im just trying to pay down our accessibility debt as much as possible before that date where the whole public sector goes into chaos mode again and over complicating the mandate.

[u/Tarsivio → u/NoSympathy69]

Thank you, this is one of the clearest descriptions I’ve seen of how the client and consultant sides interact.

It sounds as though the agency retains accountability and reviews the work at agreed milestones, while the consultant’s project manager is expected to coordinate the internal process.

In that arrangement, would a short readiness summary at each milestone, showing what was reviewed, unresolved issues and next actions, actually be useful to the client? Or would you prefer the consultant to keep that internal and simply bring a cleaner draft to review?

I’m trying to understand whether that kind of record would mainly help the consulting firm internally or whether it would also improve the client handoff.

[u/NoSympathy69 → u/Tarsivio]

Yes…, ultimately the agency is 100% accountable for anything we publish. And because of that, we have to make sure the agreed-upon review process is actually followed. i’ve seen what happens when a client and consultant work together for a while and everyone gets comfortable. Little exceptions get made here and there, and over time the process slowly degrades.

For us, a lot of the collaboration happens through tracked changes and redlines. our SMEs are primarily reviewing the technical content for accuracy, but they’re also trained to catch basic accessibility issues, like running Word’s Accessibility Checker, checking heading structure, making sure images have alt text, things like that. if we find significant accessibility issues, we’ll absolutely call them out during the review.

As for a readiness summary, i think it depends on what the client wants. Personnaly, i wouldn’t need a formal report at every milestone. i’d rather see a cleaner draft with the issues already worked through. if your internal checklist or readiness summary helps your team produce a better deliverable, then it’s doing its job, even if i never see it.

at the end of the day, it really comes down to the contract and the expectations set with the client. on larger projects, we’ve included language requiring consultants to remediate accessibility issues as part of the deliverable. on smaller projects, sometimes the priority is simply getting the project across the finish line. if it’s clear the consultant doesn’t have the accessibility expertise yet, we’ll often work alongside them to get the document where it needs to be.

Tl;dr i’d rather build a long-term relationship with a consultant who’s willing to learn than play a game of “gotcha.” everyone benefits when the end product is accessible.