Every Accessible.org accessibility audit is a 100% manual evaluation. A DHS Trusted Tester certified auditor evaluates your digital asset against the Web Content Accessibility Guidelines (WCAG). Then a professional who is blind or visually impaired will test your asset with a screen reader before the audit report is delivered.
Manual evaluation is a calling card and pillar of Accessible.org. Every time anyone gets an audit from us, they are getting an excellent, meticulous, and manual service.
| Key Point | What It Means |
|---|---|
| Who conducts the audit | Every auditor is DHS Trusted Tester certified and must pass our own internal test before working on client audits. |
| How issues are found | By a human using screen readers, keyboard navigation, visual inspection, color contrast analysis, and code inspection. We only use an automated scan as a review. |
| Where scans fit | An automated scan is run on web assets only after the manual evaluation. It checks that nothing automation can flag was missed. |
| Who reviews the work | A professional who is blind or visually impaired tests your asset with a screen reader before the report goes out. |
| What gets audited | Websites, web apps, mobile apps, platforms, learning management systems (lms), and software. |
| Environments | Websites and web apps are audited on desktop and mobile unless the client chooses desktop only. Software is desktop. Mobile apps are mobile. |
| After the audit | Issues are tracked, fixed, and manually validated in Accessibility Tracker, then documented with a VPAT/ACR, conformance statement, or certification. |
What does 100% manual evaluation mean?
Manual evaluation means a human technical accessibility expert personally audits every page or screen in scope. Manual evaluation consists of diverse methodologies including screen reader testing and keyboard testing.
Every issue in the report was found by a person using a screen reader, a keyboard, a contrast analyzer, browser zoom, visual inspection, audible inspection, or code inspection.
By definition, accessibility audits must be 100% human manual evaluation.
Where does an automated scan fit in?
We run an automated scan on web assets after the manual evaluation is finished, never before. The scan serves one purpose: confirming that every issue automation can correctly flag already appears in our report. If the scan catches something the auditor did not document, the auditor investigates it. If it is a real issue, it is added.
The scan is a review layer. It is not a source of findings, and its results are never copied into the report. The evaluation is manual from start to finish.
Who conducts Accessible.org audits?
Accessible.org audits are conducted by certified DHS Trusted Testers. Before joining our team, each auditor must also show prior audit experience, demonstrable technical expertise, and a longstanding interest in accessibility. Auditors are then tested internally before they are eligible to work on a client audit.
What is DHS Trusted Tester certification?
The Trusted Tester program is run by the U.S. Department of Homeland Security. It trains testers in a standardized, manual test process for evaluating web content against Section 508 and WCAG. Completing the program typically takes one to two months. To become certified, a candidate must score 85 or above on the certification exam.
Certification matters because it means every auditor follows a consistent, documented methodology. Two auditors evaluating the same page apply the same test steps. The report holds up when a developer, attorney, or procurement officer reads it.
Who reviews the audit before it is delivered?
Our review process includes professionals who are blind or visually impaired and use screen readers natively. Before an audit report is delivered, a native screen reader user navigates and uses the digital asset with their own assistive technology. This testing acts as a second filter and review to ensure all issues are included the technical audit.
This is not user testing sold as an audit. It is a quality assurance layer inside the audit itself. The auditor’s screen reader testing and the tester’s native screen reader use are two separate evaluations (technical and practical). Clients receive multiple layers of screen reader testing on every audit.
What evaluation methodologies are used in every audit?
An audit is only as good as its methodologies. We use several, because each one surfaces a different category of WCAG issue. Here is what a full evaluation includes.
Screen Reader Testing
The auditor navigates every page or screen in scope with a screen reader. For desktop websites, this is NVDA on Chrome and Windows, with JAWS added when the client’s environment calls for it. Mobile web is tested with VoiceOver on Safari and iOS. Mobile apps are tested with VoiceOver on iOS and TalkBack on Android.
Screen reader testing identifies issues such as:
- Missing or unhelpful text alternatives for images (WCAG 1.1.1)
- Controls without an accessible name, role, or value (WCAG 4.1.2)
- Headings and landmarks that do not reflect the page structure
- State changes and dynamic content that are never announced
- Reading order that does not match the visual order
Keyboard Testing
The auditor sets the mouse aside and operates the entire asset with the keyboard alone. Every link, button, menu, form field, modal, and custom widget must be reachable and usable. Keyboard testing exposes keyboard traps (WCAG 2.1.2), illogical focus order (WCAG 2.4.3), and missing visible focus indicators (WCAG 2.4.7).
On mobile apps, keyboard testing uses an external keyboard and switch control. Many users with motor disabilities depend on these input methods rather than touch.
Visual Inspection and Color Contrast Analysis
The auditor visually reviews every page or screen for issues that assistive technology cannot reveal. This includes color contrast, information conveyed by color alone, text spacing, and the visibility of focus indicators. Color contrast is measured with our own color contrast analyzer. Every text and interactive element is checked against the WCAG 2.1 AA minimum ratios.
Code Inspection
Some issues only show up in the code. The auditor examines the HTML, ARIA attributes, CSS, and JavaScript behind each component. This confirms that what the screen reader announced matches what the code actually says. Code inspection also documents the exact element and markup for each issue, so developers can locate it quickly.
Zoom and Reflow Testing
For websites and web apps, the auditor tests browser zoom at 200% and 400%. Content must remain readable and usable without horizontal scrolling or overlapping elements (WCAG 1.4.4 and 1.4.10). On mobile apps, this translates to testing with the operating system’s larger text settings and high contrast modes.
How are websites and web apps audited?
Websites and web apps, including Shopify stores and other ecommerce platforms, are audited in both desktop and mobile environments by default. The desktop environment is NVDA, Chrome, and Windows on a PC. The mobile environment is VoiceOver, Safari, and iOS on an iPhone. Android and macOS environments can be added.
The only exception is a desktop-only experience. If your web app is used exclusively on desktop, you can limit the audit to that environment. That decision is always up to the client. It is settled during scoping, along with the WCAG version and the list of pages in scope.
Each page in scope receives the full methodology described above in every environment being audited. A responsive site can behave very differently at mobile widths. Mobile findings are documented separately with their own testing environment noted.
How are mobile apps audited?
Mobile app audits follow the same 100% manual standard, with methodologies adapted to the platform. Scoping defines the WCAG version, the platforms (iOS, Android, or both), and the screens to be evaluated.
The evaluation then includes:
- Screen reader testing with VoiceOver on iOS and TalkBack on Android
- Keyboard testing with an external keyboard and switch control
- Visual inspection, including color contrast, text scaling, and touch target size
- Touch and gesture testing for gesture alternatives, motion-based actions, and timeouts
Touch and gesture testing is unique to mobile. The auditor checks that complex gestures such as swipes and pinches have simple alternatives (WCAG 2.5.1). Actions triggered by device motion must be able to be turned off (WCAG 2.5.4). Drag-and-drop interactions must be completable another way.
How is software audited?
Platforms, learning management systems, and other software are audited with the same manual methodologies. Web-based software is evaluated like a web app. Non-web software is evaluated using WCAG as applied to non-web documents and software (WCAG2ICT). This W3C guidance explains how each success criterion applies outside a browser.
Scoping is especially important for software. Rather than every screen, we often recommend a representative sample of screens, workflows, and component types. The goal is complete coverage of the interface patterns your users encounter, without auditing hundreds of near-identical screens.
What makes the audit report reliable?
An audit is only useful if the people fixing the issues can rely on it. Our reports are built so that a developer with no accessibility background can locate and fix each issue without guessing.
Every issue in the report includes:
- A plain description of the issue and who it affects
- The URL or screen and the specific element location
- The testing environment where the issue was found
- The applicable WCAG success criterion
- The related code
- A screenshot or clip
- A remediation recommendation
Before delivery, the report passes through internal quality assurance, the automated scan review for web assets, and the native screen reader review described above. That layered process is why our audits are thorough enough to support a VPAT/ACR, a conformance statement, or certification.
What happens after the audit?
Finding the issues is the first step. Fixing and validating them is where tracking matters. Most clients upload the audit report to Accessibility Tracker, our project platform, and use it to track each issue from open to fixed to validated.
The workflow looks like this:
- Your team fixes issues and marks them complete in Tracker
- Our auditors validate each fix or explain what is still incomplete
- Tracker tracks progress across all assets and team members
- Once every issue is validated, we issue documentation such as a VPAT/ACR, conformance statement, or certification
This matters for legal compliance as much as for access. Your obligation may come from the ADA, Section 508, or the European Accessibility Act (EAA). Either way, the documentation trail from audit to validation is what demonstrates WCAG 2.1 AA conformance.
Frequently asked questions
Are Accessible.org audits really 100% manual?
Yes. Every issue is found by a human auditor using screen readers, keyboard navigation, visual inspection, and code inspection. An automated scan is run only afterward, as a check that nothing automation can flag was missed.
Which screen readers are used during an audit?
NVDA and JAWS on Windows, VoiceOver on iOS and macOS, and TalkBack on Android, depending on the environments in scope. Separately, a reviewer who is blind or visually impaired uses their own screen reader to review the asset before the report is delivered.
Do you audit the mobile version of a website?
Yes. Websites and web apps are audited on desktop and mobile unless the client chooses a desktop-only audit for a desktop-only experience.
What does DHS Trusted Tester certification require?
The program takes about one to two months to complete, and candidates must score 85 or above on the certification exam. Every auditor on our team holds this certification.
Can I audit against WCAG 2.2 AA instead of WCAG 2.1 AA?
Yes. The WCAG version is set during scoping. WCAG 2.1 AA remains the most requested standard, but WCAG 2.2 AA audits use the same methodologies.
Actionable takeaways
- Ask any audit provider whether their audits are 100% manual and which methodologies they use. If they cannot list them, keep looking.
- Decide during scoping whether your website needs desktop and mobile environments. Most do.
- For mobile apps, confirm the audit covers VoiceOver, TalkBack, external keyboard, and touch and gesture testing.
- Ask who reviews the report before delivery and whether native screen reader users are part of the process.
- Plan for tracking before the report arrives so fixes and validation can start immediately.
Audit Service
Would you like an audit quote?
We’d be happy to help. Contact us to receive a quote within 24 hours.
