Independent accessibility assurance for software vendors
SaaS, platforms, enterprise software and mobile applications. Accessibility increasingly decides whether a product clears procurement, so vendors need evidence that does not rest solely on their own assertion. We work alongside your product, engineering, design and QA teams, not instead of them.
Why does accessibility matter for a software vendor?
A product can be sold into many markets, but accessibility requirements increasingly arrive through customer expectations, enterprise procurement, government procurement and contractual terms. Buyers who carry their own accessibility obligations push those obligations down to the products they deploy, which means accessibility affects whether a product is suitable for procurement at all. ExceedAbility provides the independent product audit, the VPAT or Accessibility Conformance Report and the remediation support that turn an accessibility claim into evidence.
Who this covers
Organisations whose product is the thing being assessed, rather than organisations who bought someone else's.
- SaaS vendors
- Enterprise software
- Platform providers
- Mobile app developers
- B2B software
- B2C applications
- Digital product companies
- Government technology suppliers
- Financial technology vendors
- Health and education technology
- Systems integrators
- Digital agencies and delivery partners
The commercial reality
Most vendors do not encounter accessibility as a regulation. They encounter it as a question in a tender, a clause in a contract, a line in a security and compliance questionnaire, or a customer asking for a VPAT two weeks before renewal.
-
Procurement is where it bites
Australian government agencies bound by the Digital Experience Policy push their obligations to suppliers. Tenders ask for an independent audit, a VPAT or Accessibility Conformance Report and a remediation plan for the specific product being bought. Vendors who arrive with the evidence progress. Vendors who improvise lose to one who did not.
-
One product, many obligations
The same codebase may be sold to an Australian agency, an enterprise buyer, a European customer and a US institution. WCAG 2.2 AA, EN 301 549 and Section 508 overlap substantially, so one well scoped audit programme can produce evidence for all three rather than three separate scrambles.
-
Self assessment has a credibility ceiling
A vendor completed VPAT is a starting point, and experienced evaluators know it. Where a claim is contested, the question becomes who tested it, against what, and can the finding be reproduced. Independent evidence answers that in one line.
-
Your customers inherit your defects
When an agency or a bank deploys your product, your accessibility position becomes part of theirs. Buyers increasingly understand this, which is why product level evidence is now requested rather than a corporate statement.
-
Cost of late discovery
An accessibility defect in a shared component costs a fraction to fix at design time compared to after it has shipped to every customer and been embedded in integrations, training material and support scripts.
-
Product quality, not just compliance
Keyboard operability, meaningful focus management, robust labelling and predictable state changes are the same disciplines that make a product testable, automatable and usable under load. Accessibility work tends to improve product quality generally.
Where accessibility lives in the product lifecycle
We can participate at any of these stages. Independent assessment is the one that cannot sensibly be done by the delivery team itself.
-
Design
Patterns, components, colour and interaction decisions made once and inherited everywhere.
-
Build
Semantics, keyboard support, focus management and assistive technology behaviour in the component library.
-
Internal testing
Automated checks in the pipeline, plus manual keyboard and screen reader passes by your own QA team.
-
Independent assessment
An objective WCAG 2.2 audit by specialists outside the delivery team, with reproducible evidence.
-
Remediation
Severity ranked findings with code level fixes, prioritised so shared components are fixed first.
-
Verification
A retest that confirms what has actually been fixed, and an honest conformance report.
-
Ongoing improvement
Release gates, training, and reassessment as the product changes, so the position does not decay.
Where product teams most often get caught
Design system components
One inaccessible dropdown, tab set or data grid, reused four hundred times. Also the fastest thing to fix, because one correction repairs the whole product.
Complex widgets
Data grids, tree views, drag and drop, rich text editors, charts and canvas rendered visualisations, where a keyboard and screen reader path has to be designed rather than inherited.
Single page frameworks
Route changes that never move focus or announce the new view, and live regions that either say nothing or say everything.
Customer configuration
Themes, white labelling and customer authored content that can undo the accessibility of an otherwise sound product.
Native and hybrid apps
Custom controls with no accessible name, gesture only interactions, and dynamic type or display size settings that break the layout.
Generated output
Exports, reports, invoices and emails your product produces. A conformant interface that emits an untagged PDF has moved the problem, not solved it.
What we assess
Vendors are usually assessed on more than the main interface. Admin consoles, mobile clients, onboarding documentation and generated exports all form part of what a buyer evaluates, and all of them can be tested.
Websites
Public sites, campaign sites and content estates assessed against WCAG 2.2, with prioritised findings, code level fixes and a retest once the corrections land.
Web applications
Transactional interfaces, authenticated portals, dashboards and enterprise systems, including the custom components and single page frameworks that automated tools cannot judge.
Mobile applications
Native and hybrid applications tested with the platform screen readers and interaction settings your customers actually use, not emulated approximations.
Documents
PDF, Word, PowerPoint, Excel and InDesign remediated to WCAG 2.2 AA and PDF/UA, at volume, plus Easy Read, large print, audio and braille where an alternative format is the right answer.
Design and development
Accessibility input before the build, so decisions about patterns, components and journeys are made once. Design reviews, delivery advice and accessibility written into your definition of done.
Self service and tools
Free checks and references your own team can run today. Useful for triage and for building internal capability, and a sensible first pass before an independent assessment.
Build, test, assure: we are the third layer, not a replacement for the first two
This is not a claim that your developers cannot be trusted. Good product teams build accessibility in and test it continuously, and the best vendors we work with were already doing both before they called us.
Independent assurance adds something structurally different: an objective assessment from specialists who did not make the build decisions, using real assistive technology, reported in a form a customer, an evaluation panel or a board can rely on. It makes internal testing sharper by showing the team what it is missing, and it gives your accessibility claim a backing that is not simply your own word.
Build
Designers, developers, content authors and suppliers build accessibility into the work as it is created.
- Accessible design patterns and component libraries
- Semantic markup, keyboard support and assistive technology behaviour
- Authoring standards for content and documents
Test
Delivery teams test throughout the cycle so problems surface early, while they are cheap to fix.
- Automated checks in the pipeline and in the browser
- Manual keyboard and screen reader checks by the team
- Accessibility in the definition of done and release gates
Assure
An independent specialist gives an objective view of conformance, usability and residual risk.
- Independent WCAG 2.2 assessment with reproducible evidence
- Testing with real assistive technology, not automation alone
- Conformance reporting for procurement, risk and executive audiences
What independent evidence changes commercially
An evaluator reading a vendor completed conformance report is asking three questions: who tested this, against what, and can I reproduce the finding. Independent assessment answers all three at once, and it lets you state partial support and known issues honestly without that reading as weakness. An overstated report fails at the first serious evaluation, and it fails expensively.
We work alongside your product, engineering, design and QA teams throughout. Findings arrive with the code level fix attached, we walk the report through with the people who will do the work, and we retest to verify. The goal is a product your customers can deploy with confidence and a team that needs us less next time.
How ExceedAbility helps
Senior led and on shore, with a written fixed price scope before any commitment. Audits run against staging or production with read only access, so the disruption to your team is minimal.
Independent product audits
WCAG 2.2 AA assessment of web apps, native apps and platforms, with severity ranked findings, code level fixes and a retest once remediation lands.
Product audits →VPAT and conformance reports
The procurement evidence buyers ask for, covering WCAG 2.2, EN 301 549 and Section 508, built from a real audit rather than optimism.
VPAT and ACR →Component and framework remediation
Hands on help with the parts that repeat: design system components, custom widgets, single page routing and focus management.
Web remediation →Assistive technology user testing
Testing with people who use screen readers, magnification, switch access and voice control, on the tasks your product exists to support.
User testing →Engineering and design training
Practical, role based sessions for developers, designers, testers and product managers, so the same class of defect stops arriving.
Training programs →Accessibility in the product process
Accessibility written into the roadmap, the definition of done and the release gate, so conformance is maintained between assessments rather than rebuilt before each tender.
Product management support →Give your team the means to test earlier
The cheapest defect is the one your own engineers catch before it ships. These references and free checks need no account and no procurement.
Common questions from product and engineering teams
Plain answers to what software vendors ask us most often.
What accessibility evidence do buyers ask software vendors for?
An independent WCAG 2.2 AA audit of the specific product being supplied, a VPAT or Accessibility Conformance Report reporting conformance criterion by criterion, a remediation plan for known issues with dates, and a public accessibility statement. Australian ICT procurement also references AS EN 301 549. A generic platform claim rarely survives evaluation, because the evidence has to cover the product actually being bought.
Does independent assessment replace our engineering and QA teams?
No, and it should not. Your designers and engineers build accessibility in, your QA team tests it continuously, and independent assessment is a third layer that provides an objective view of conformance and residual risk from outside the delivery team. It makes internal testing more effective by showing the team what it is missing, and it gives customers evidence that does not rest solely on your own assertion.
How disruptive is an audit to a product team?
Minimal. Audits run against staging or production with read only access. A focused product audit typically takes three to six weeks, findings arrive severity ranked with code level fixes, and we walk the report through with the team so remediation lands in the next sprint rather than a distant backlog.
Can you produce a VPAT for our product?
Yes. We produce independent, evidence based VPAT and Accessibility Conformance Reports covering WCAG 2.2, EN 301 549 and Section 508, built from an actual audit rather than a self assessment. The report states the position honestly, including partial support and known issues, because a report that overstates conformance fails at the first serious evaluation.
Is an audit a legal certification of compliance?
No. An audit is an expert conformance assessment against a defined standard, at a point in time, with reproducible evidence. It is the strongest form of proof commonly available and it is what procurement teams ask for, but it is not a legal certification and we do not present it as one. Anyone offering certified compliance for a digital product is worth questioning closely.
Our product is white labelled and heavily configured by customers. What can be assessed?
We assess the product in a defined, representative configuration and state that scope explicitly in the report, then note where customer configuration can affect the result. That is the honest position, and it is more useful to a buyer than a blanket claim. Where it matters, we can also assess a specific customer deployment.
Need conformance evidence that holds up?
Tell us the product, the market and the deadline. We will come back with a written scope, an effort estimate and a realistic date.
Book a Discovery Call Request an Accessibility Audit