Study: AudioEye detects up to 2.5x more issues than other tools
Get ReportBuilding an Accessibility Program Without a Dedicated Team
Can one person run an accessibility program? Yes, when they own accountability and sequencing, and a platform supplies the expert testing and fix work. Below: the five stages of accessibility maturity, the outsource split, role-by-role guidance, and a 90-day plan.
Author: Missy Jensen, Senior Content Strategist: AI Search and Discovery
Published: 09/08/2026
)
Accessibility landed on your desk. Maybe it came from a customer complaint, or maybe your legal team forwarded a demand letter. Or your manager just said, “Can you own this?” and moved on with their day.
Every guide you found assumed a dedicated accessibility team, a governance committee, and an engineering queue that exists to fix issues. None of which is coming.
One person can run a digital accessibility program when they own accountability and sequencing. Testing and actual fixing are different kinds of work, and no amount of effort turns one person into a testing team. Below, we'll cover what you can build on your own, what you have to hand off, and how to put both into practice.
Can One Person Run an Accessibility Program?
Yes, and dozens of companies are doing so right now with one person’s name on it. Most of them started the way you did, after a complaint or a demand letter brought accessibility to the top of your priority list.
What makes a one-person program work is a narrower definition of the job. When accessibility falls on you, the instinct is to think you now have to become the person who finds and fixes the issues. That's the version that isn't possible on your own. You can make some progress solo, but you'll hit a ceiling well before your site is actually accessible, and that ceiling isn't about how hard you work.
The actual job is smaller than the one you were picturing. You're accountable for the program and decide what happens and in what order. You're the person who knows which pages matter to the business, which release is coming, and who to go to when something has to change. That isn't accessibility expertise. It's context about your company, and you already have it.
The expertise is what gets supplied. Finding the issues a scan can't detect, verifying that a checkout flow works for someone using a screen reader, engineering the harder fixes, producing the documentation enterprise customers ask for: that work comes from an accessibility partner, not you. The bottom line: one person can run a digital accessibility program when they own accountability and sequencing, and a partner does the testing and fix work.
The difference becomes clear once you see how these programs actually develop.
The Five Stages of Accessibility Maturity
Most people inheriting accessibility have no idea whether they're behind, and there's no obvious way to tell. The accessibility maturity model below gives you a read: five stages from unaware to integrated, and most mid-market companies begin at stage two, after a complaint or a demand letter.
Find your row, then look at the one under it.
Getting from stage two to stage three is the move that matters. Naming an owner is free. Continuous automated scanning isn't, and without it, you're guessing at the size of the problem. This is where programs either get a platform or sit at stage two for years.
After that, it's cadence: testing on a schedule, fixes tracked to closure, and documentation kept current. Stage five is where accessibility becomes someone else's step too, and most mid-market companies don't need to be there yet.
What to Outsource and What to Own Internally
An accessibility program owner keeps four things in-house: accountability for the program, prioritization against the roadmap, vendor management, and policy, including the public accessibility statement. Everything that requires specialized testing skills gets outsourced or supplied through a platform instead.
This split works because of how the two kinds of work actually get done.
Automated scanning covers volume and catches common issues on every page in seconds. Expert testing covers judgment: the criteria that ask whether alt text actually describes an image or whether a keyboard user can complete a task, and that no automated tool can detect on its own.
Combining the two is how AudioEye detects 2.5 times as many accessibility issues as other tools. Neither automation nor expert testing on its own can reach that number.
That’s the line an accessibility program should hold: keep the decisions, hand off the technical work.
If you’re deciding between hiring a specialist or engaging an outside partner for the testing side, check out our page on what an expert audit actually includes.
What Each Role Needs to Know When Nobody is an Accessibility Expert
Nobody on a small team needs to become an accessibility expert. Each role needs a short, specific list of what to watch for in their own work, and nothing more.
Marketer
A marketer supporting an accessibility program needs to know alt text, link text, heading order, and color contrast.
In practice, that means writing alt text that conveys what an image shows, writing link text that makes sense out of context rather than ‘click here,’ keeping heading levels in order, and checking contrast on landing pages, email templates, and ad creative. That’s the whole list. Your marketers don’t need to know the full list of WCAG criteria, run audits, or interpret a scan report. And asking them will cost you their attention on the four things that matter.
Developers
A developer supporting an accessibility program needs to know semantic HTML, keyboard operability, and how to read a fix ticket. As marketers, they do not need to know the full set of WCAG 2.1 Level AA criteria.
The practical version is: use native semantic elements before reaching for ARIA, make every interactive element keyboard operable, manage focus deliberately in modals and dynamic content, and be able to action a fix ticket without someone translating it first. Expert auditing and assistive technology testing aren't their job. Those come from your platform, and a developer who can implement a well-written fix is worth more to the program than one who can half-run an audit.
Designers
A designer supporting an accessibility program needs to know about color contrast ratios, target sizes, and not to encode meaning in color alone.
Most of this gets solved once in the design system rather than page by page: contrast minimums baked into the palette, touch targets sized adequately, a visible focus state designed on purpose rather than left to the developer, and no information carried by color itself. Designers don’t need to test with screen readers or understand how fixes are implemented. They need to stop new issues from entering the site, which is the cheapest accessibility work there is.
Content Editors
A content editor supporting an accessibility program needs to know document structure, descriptive links, captions, and table headers.
Day-to-day, that’s structuring pages with real headings rather than bolded text, writing links that describe where they go, captioning videos, and properly marking up table headers in the CMS. Nothing here is technical, and none of it requires touching the codebase. It’s mostly a matter of using the CMS the way it was built to be used, which is why this role tends to show the fastest improvement once someone explains it.
)
Your First 90 Days
A working digital accessibility program takes about 90 days to stand up, and the order matters as much as the actions themselves.
Days 1 to 30
The first 30 days are about naming and knowing, not fixing. Name the accessibility program owner in writing, so the role has an actual person attached to it. Run an automated baseline scan across the site, because every later decision depends on knowing the current state. Inventory the ten highest-traffic templates, and flag the highest-risk flows first: checkout, forms, and login. Brief leadership on what the scan found before day 30 ends, so budget conversations start early instead of late.
Start here: Run a free accessibility scan to see where your site stands today.
Days 31 to 60
With a baseline in place, days 31 to 60 shift from knowing to fixing. Select and onboard a platform that combines automated fixes with expert testing. Testing waits until now on purpose: the baseline scan is what tells you which templates need it most. Get expert expert testing scheduled on your highest-traffic templates. Open a tracked fix backlog so nothing found gets lost between departments. Run one 30-minute training session each for marketing and development, using the role breakdown above.
Days 61 to 90
The last 30 days turn the work into a program instead of a project. Publish a public accessibility statement that names your commitment and how users can report an issue. Set a monitoring and reporting cadence that the accessibility program owner can sustain on their own; monthly is realistic for most mid-market teams. Add an accessibility check to your design and release workflow, even a lightweight one. Agree to a quarterly review with leadership so the program has a standing checkpoint rather than relying on memory.
What a One-Person Accessibility Program Owner Needs from an Accessibility Platform
A one-person accessibility program owner should require a platform that combines automation with expert testing, continuous monitoring, and documentation support, so that no in-house testing capability is needed.
Here’s what those look like as requirements you can ask a vendor:
Automated detection and fixes, running continuously rather than on request
Expert testing performed by professionals and individuals with disabilities
Continuous monitoring instead of point-in-time assessment, because your site changes frequently
Documentation and VPAT support, since procurement and enterprise customers will ask
Legal response support, so a demand letter does not become your problem alone
Reporting you can hand to leadership without translating it first
Those six are the shortlist, and the gaps are what to interrogate. If a vendor covers the first two but not monitoring, you're buying an audit, which describes your site on one day. If it covers monitoring but not expert testing, you’re buying a scanner, which describes the parts of your site that a machine can evaluate. Either one leaves you holding work you can’t do alone.
For evaluating specific tools against these requirements, see our list of top web accessibility testing tools.
)
What This Looks Like in Practice
Mid-market companies with a working accessibility program aren't the ones with the largest budgets. They're the ones where a single person got named, got a baseline, and stopped trying to do the expert work themselves.
The pattern is consistent. Someone in marketing or IT takes the program, onboards a platform in the first month, and gets automated coverage running before they've read a single WCAG success criterion. Expert testing follows on the highest-traffic templates, turning a long issue list into a short, ordered one. After that, the job is maintenance, and the owner spends their time prioritizing instead of discovering.
That’s what AudioEye supplies: powerful automation, expert testing from certified professionals using assistive technology, Active Monitoring that doesn’t stop when an audit ends, and documentation you don’t have to produce yourself. You keep the accountability; you don’t have to supply the expertise.
Ready to see what AudioEye looks like in action? Talk to an expert.
Curious how accessible your existing site is? Use our free Website Accessibility Checker to find out.
Frequently Asked Questions
Share Article
)
)
)