How it works
A straightforward review process built around scope, testing, and follow-through.
Guidepost Accessibility starts with scope, then moves through manual testing, screen reader review, issue documentation, retesting, and public verification when that step is appropriate. Each stage is meant to make the next decision clearer.
What stays explicit
- Which flows and platforms are included
- Which supporting evidence was used
- What clients should do next after delivery
Step 1
Define the scope that matters
We identify the pages, flows, mobile screens, documents, or signing steps that matter most to your customers and staff.
Step 2
Run real testing
That includes manual review, screen reader testing, keyboard checks, and cross-platform review on Windows, macOS, iOS, and Android, with supporting browser evidence where it helps. The goal is a faithful read on real task completion, not a checkbox scan.
Step 3
Document issues for builders
Findings are written for designers, engineers, and product owners: what is broken, who it affects, how to reproduce it, and what good looks like.
Step 4
Support remediation and verification
We help teams retest fixes, answer implementation questions, and maintain an accurate public record of review scope when verification is appropriate.
Platform coverage
Testing is matched to the systems and browsers that matter to the scope.
Testing can include Windows, macOS, iOS, and Android, with Chrome, Edge, Firefox, and Safari where relevant.
Windows and macOS review for websites, portals, and desktop workflows where relevant
Applied where relevant to the requested scope so the review reflects the environments people actually use.
iOS and Android review for native apps and mobile web flows
Applied where relevant to the requested scope so the review reflects the environments people actually use.
Popular browser coverage across Chrome, Edge, Firefox, and Safari
Applied where relevant to the requested scope so the review reflects the environments people actually use.
Supporting browser-based structure, accessibility-tree, and keyboard-path evidence on approved web routes
Applied where relevant to the requested scope so the review reflects the environments people actually use.
Method
The review produces working materials, not just a one-time opinion.
A scope that names the important flows
We define which pages, screens, pathways, and platforms are in or out so the review stays accountable and useful.
Findings written for the people doing the work
Issues include impact, reproduction detail, expected behavior, and implementation guidance that supports design and engineering work.
A path to retest and public communication
Where appropriate, the work can continue through retests, ongoing support, and date-bound verification pages that stay honest about scope.
Prepare for scope
A better intake starts with the tasks, platforms, and timing that matter.
If accessibility work is new for your team, a short list of the customer or staff tasks that matter most is enough to begin the conversation.
Share the flows that matter most
Examples include sign-up, login, scheduling, checkout, billing, support, account settings, onboarding, and purchase flows.
Include all platforms involved
You can request one review that spans website, portal, documents, iOS, Android, or a combination when the user journey crosses surfaces.
Add timing or delivery context
Launch deadlines, redesign work, procurement requests, fix sprints, or known pain points help shape the right engagement size.