Find accessibility barriers. Fix them at the source. Verify the result.

Access Audit Lab is an independent accessibility practice. We run manual accessibility testing, then either guide your team through the fixes or implement the technical remediation ourselves — code-level fixes and retesting for websites and web applications.

  1. Find the real barriers

    Manual and screen reader testing finds what automated scans miss.

  2. Fix at the source

    Code-level remediation and direct implementation support, within scope.

  3. Verify by retest

    Retesting confirms what is resolved and what remains.

Value proposition

Scans read markup. People use interfaces.

Automated tools are part of the process. The audit is the evidence that appears when someone operates the interface.

Automated tools are fast and repeatable, and we use them in every audit. But many of the barriers that stop people appear only when someone operates the interface.

That is where most of our testing time goes.

Where each method produces evidence
AreaAutomated toolsManual & assistive technology
Names, labels and alt attributesUsually detectedChecked for meaning
Contrast of static textUsually detectedIncludes hover, focus and overlays
Keyboard operationPartlyTested end to end
Focus order and focus managementGenerally not detectableTested
What screen readers announceGenerally not detectableTested with agreed pairings
Dynamic content and status messagesPartlyTested
Form errors and recoveryPartlyTested
Zoom, reflow and text spacingPartlyTested at 320 CSS px and 400%

Sample finding

What a finding looks like.

Each issue follows a repeatable structure: finding, evidence, impact, fix and verify.

AAL / FINDING 024

  • Open
  • Priority: High

Keyboard focus escapes the checkout dialog.

Affected users
Keyboard and screen reader users
Component
Checkout → Payment details dialog
Criterion
2.4.3 Focus Order (Level A)
Test method
Keyboard; NVDA + Firefox; VoiceOver + Safari
  1. Evidence

    1. Open checkout and activate “Edit payment details”.
    2. Tab past “Save card”.
    3. Focus moves behind the dialog.
    4. Closing the dialog returns focus to the top of the page.
  2. Impact

    Users can move into background content without realizing the dialog is still open, then lose their place when it closes.

  3. Fix

    Move focus into the dialog on open, keep focus inside while open, support Escape, and return focus to the trigger on close.

  4. Verify

    Retest pending

    Passes when Tab and Shift+Tab stay inside the dialog and focus returns to the trigger.

Illustrative finding. Real reports reference your components and environments.

Methodology

One method, five verbs.

Each step produces something that can be inspected.

  1. Test

    Define the sample and evaluate it with automated, manual and assistive technology testing.

  2. Find

    Isolate each barrier to a component, state and reproducible condition.

  3. Explain

    Document affected users, impact, criteria and evidence in plain technical language.

  4. Fix

    Provide remediation guidance grouped by root cause so teams can correct the source.

  5. Verify

    Retest fixes against original evidence and record what is resolved or still open.

How we work

Two ways to work with us

Choose audit-only guidance, or audit plus hands-on remediation. Accessibility stays the specialization either way.

  • Audit only

    We identify, document and prioritize accessibility barriers and provide actionable, code-level remediation guidance your team can implement.

  • Audit + remediation

    We identify the barriers, then provide direct implementation support or code-level fixes within the agreed scope, and retest the affected experience where technically possible.

Services

Assess. Document. Fix. Maintain.

Assess

Document

  • VPAT® / ACR Support

    Testing and Accessibility Conformance Reports for procurement.

  • Section 508

    For vendors and organizations working with U.S. federal agencies.

Fix and maintain

All services

Deliverables

The report is the product.

A summary for stakeholders, priorities for product managers, and the detail designers, developers and QA need to act.

Accessibility Audit ReportPage 2

Customer portal

WCAG 2.2 Level AA · Sign-in, dashboard, billing, settings

Executive summary

The portal works with a mouse, but several core tasks are difficult or impossible by keyboard and with a screen reader.

Remediation notes

  1. Rebuild the shared dialog on native <dialog>.
  2. Associate errors and hints with form fields.
  3. Restore visible focus across navigation.
Summary page (illustrative)

Finding inventoryPage 6

Sample finding inventory
IDFindingCriterionStatus
014Focus indicator removed on navigation2.4.7Resolved
021Required fields shown by color only1.4.1Reviewed
024Focus escapes checkout dialog2.4.3Retest
031Filter result count not announced4.1.3Open
Inventory page (illustrative)
Executive summary
Overall state and where to start.
Finding inventory
Stable IDs, priority, location.
Criterion mapping
Each finding tied to WCAG.
Remediation notes
Code-level fixes, by root cause.
Verification status
Open, reviewed, retest, resolved.

Standards

Five terms. Five different things.

Often used interchangeably, they affect what you test against and what you can document.

WCAG
Technical guidelines · W3C Testable success criteria at Levels A, AA and AAA. Our default target is WCAG 2.2 Level AA.
ADA
U.S. civil rights law Prohibits discrimination on the basis of disability. It is not a technical standard.
Section 508
U.S. federal ICT requirements Applies to technology federal agencies develop, buy or use.
VPAT®
Reporting template · ITI A blank template published by the Information Technology Industry Council.
ACR
Completed report A completed VPAT for one product version. It documents conformance; it does not certify it.

Standards explained

Selected industries

Selected industries

  • SaaS & technology
  • Government vendors
  • Education
  • Nonprofits
  • Ecommerce
  • Professional services
  • Agencies

The standards are shared. The workflows are not. We scope testing around what your users need to do.

Testing by industry

Questions

Before you ask

More answers on the accessibility audit page.

Is automated accessibility testing enough?

No. Automated tools reliably detect a subset of issues. They generally cannot judge whether focus order makes sense, whether a custom component works with a screen reader, or whether alt text is meaningful.

Do you test with screen readers?

Yes, in every full audit. Browser and screen reader pairings are agreed during scoping.

Which WCAG version do you test against?

WCAG 2.2 Level AA by default, unless a contract, regulation or procurement process requires another target.

Do you guarantee ADA compliance?

No. Access Audit Lab evaluates technical accessibility against an agreed standard and does not provide legal advice.

Audit, fix, verify.

Tell us about your website or application, the scope and your accessibility goals. We'll recommend an approach — audit only, or audit plus remediation — and send a written proposal.

Request an Accessibility Review

Or email hello@accessauditlab.com