How we work
Methodology
No team page names individual testers - this page, and the credentials and editorial policy pages linked below, are how we show our work instead.
Accessibility audits
- Scoping by page templates and user flows, so testing is representative rather than exhaustive-but-shallow.
- Automated scan (axe-core) to establish a baseline and catch machine-detectable issues quickly.
- Manual review against every WCAG 2.2 Level A and AA success criterion - automated tools alone catch only a portion of real issues.
- Assistive-technology testing: NVDA with Chrome, JAWS with Edge, VoiceOver on iOS and macOS, and TalkBack on Android.
- Severity rating for every finding, so your team can prioritize fixes by real user impact.
- A report mapped to WCAG 2.2, plus the relevant regulatory standard (ADA/Section 508, EN 301 549/EAA, IS 17802/GIGW, as applicable).
- A verification retest once remediation is complete.
Security testing
- Scoping and rules of engagement, agreed in writing before any testing begins.
- Threat modelling against your actual architecture, not a generic checklist.
- Testing against OWASP WSTG, OWASP ASVS, the OWASP Top 10 for LLM Applications (where AI/LLM components are in scope) and MITRE ATT&CK.
- Manual exploitation with proof-of-concept evidence - we don't report a finding we can't demonstrate.
- CVSS scoring for every finding, so severity is consistent and defensible.
- A report with reproduction steps and remediation guidance mapped to your codebase or infrastructure.
- A verification retest once remediation is complete.
See Credentials for the certifications held by the practice, and Editorial Policy for how our articles and guides are researched and reviewed.
Make it accessible.
Make it attack-ready.
Prove both before launch.
Bring us your app, audit deadline, or security concern. We'll map the fastest path to WCAG conformance, VAPT coverage, and regulator-ready evidence.
