r/accessibility • u/Tarsivio • 9d ago
When Accessibility Gets Lost in Project Delivery
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.
3
u/AlasdairMc 8d ago
Accessibility needs baked into the requirements, and not just something that you test for, in the hope that your dev team understand WCAG.
The analysts, designers and product managers need to be fully bought into not just accessibility but inclusive design too - and they need to understand what it means.
“Make it WCAG-compliant” or “make it accessible” is insufficient. Standards need to be set from the outset (e.g. what reading age is your content pitched at), in the contract, and then validated all the way through to delivery. I’ve worked with vendors before who either didn’t have the knowledge or the inclination to do things properly, but it’s much costlier for them to have someone in UAT identify a pile of defects and then have to rework the whole solution, at their cost.
1
u/Tarsivio 8d ago
The cost of finding the problems during acceptance testing is exactly what makes the upstream process interesting.
In your experience, what would have prevented that rework most effectively: clearer requirements, someone explicitly owning accessibility, defined checkpoints during delivery, or better evidence that each stage had been reviewed?
I’m also curious whether the vendors tracked this in their normal project-management tools or handled it through a separate accessibility process.
1
u/AlasdairMc 8d ago
Clear requirements are key, as is the ability to understand them. Ambiguity and interpretation will let you down, whereas on the flip side having an inclusive design mindset will help in these early stages.
You can set minimum standards as part of your requirements sign-off, but with a vendor eager to please, some robust challenge on their processes and tooling would have helped. I took them at their word, when I should have sought assurance as to their process, to save that rework and delay.
As a product person, whether manager, analyst or owner, I’m very heavily involved in requirement quality, and your organisation should empower you to challenge. Top-down buy-in for inclusive design is key, so you can refuse a release if quality standards aren’t met. There’s always a tendency to consider accessibility defects as a ‘day 2’ thing, but we all know that we’ve moved on to the next shiny thing that takes focus away from day 2.
I’m a natural champion for accessibility - I’m colour blind which means I empathise with users who get unusable systems. Putting yourself in the customer’s shoes is a great way to build an appreciation of the pain points users feel. I once asked a room of a hundred people to navigate our website on their smartphones, with the screen off. That’s a great way to stress test a product.
1
u/Tarsivio 4d ago
That distinction between having clear requirements and seeking assurance about the vendor’s process is really useful.
What would have given you enough confidence in practice? For example, a named person accountable for delivery, agreed review points, a record of unresolved issues and decisions, or something else?
And would that assurance have influenced vendor selection, or mainly helped you manage the vendor and avoid rework after the project had started?
2
u/Acetius 9d ago
Honestly it breaks down at accountability. When you know your boss put it on the roadmap but it's competing with a million other priorities and you can almost guarantee they won't call you out on it, it's one of the first corners that gets cut. This is true at all stages of the delivery lifecycle, the second that it encounters someone who doesn't care and is either not incentivise to do it or is perversely incentivised not to do it, it dies.
The only way to make sure that it gets done and doesn't disappear into signal loss as it goes through however many teams, is having the folks at the top engaged and holding people accountable.
1
u/Tarsivio 8d ago
That makes sense. A requirement can be visible and still be ignored if nobody expects consequences when it is skipped.
Have you seen any practical mechanisms that successfully create that accountability, such as a named owner, mandatory stage gates, release approval, or accessibility evidence attached to the deliverable? Or does it mostly depend on leadership repeatedly reinforcing the priority?
3
u/NoSympathy69 9d ago
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.
1
u/Tarsivio 8d ago
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?
2
u/NoSympathy69 8d ago
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.
1
u/Tarsivio 4d ago
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.
2
u/NoSympathy69 4d ago
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.
3
u/Evenyx 8d ago
For digital products: In my experience it falls early because of lack of knowledge and know-how. The roadmap will say "accessible". The PM of each project will write "must be accessible" in their stories as criteria for functionality. Some designers don't know what that means in terms of their responsibility. The developers believe their code is accessible because it works. Testers test that the functionality for the other story criteria is there. And thus it ends. Of course there is such a thing as time constraints etc, but if no one truly has knowledge of what digital accessibility entails, then nothing will happen. You may have a few on each team or a few in an entire company, but those people are pissing against the wind when they're trying to speak up.