Web Accessibility Checker for Current Browser Pages
Check the page currently open in your browser with DevCheck, including localhost, staging and signed-in screens. Scan for machine-detectable issues, inspect affected elements, and test the task with a keyboard before re-testing fixes.
Why use a browser-based web accessibility checker?
An open menu or a form error can change both the content and the task. DevCheck checks the state open in your browser without requiring a public URL. Other pages and interaction states still need separate checks.
Check local and staging pages
Run accessibility checks before a page is public, including localhost and staging URLs, without sending the page to an external URL scanner.
Inspect authenticated and interactive states
Check login-only pages, user flows, form states, dialogs, and dynamic content after they appear in the browser.
Locate elements that need fixing
Use axe-core to find machine-detectable issues and map results back to page elements so fixes can be made and re-tested.
Add visual context checks
Use color vision, text spacing, visual field loss, presbyopia, myopia, and cataract simulations to review readability and visual risk before a formal audit.
Optional: review text and image descriptions
Optional AI reviews descriptive link names, language marking and image alternatives in sampled content, not link destinations. Samples are sent to Google Gemini; human confirmation is still needed. Do not enable it on pages containing confidential or unauthorized content.
How to check a webpage with DevCheck
Start with local scans and review tools; no public URL or AI is required. Test only pages you are authorized to use, and use a controlled environment for tasks that send orders or messages.
- Step 1
Install the browser extension (Chrome/Edge or Firefox).
- Step 2
Open the public page, local build, staging page, or authenticated flow you want to inspect.
- Step 3
In DevCheck, choose Scan → Scan this page.
- Step 4
Review issue types, impact, related rule clues, and affected elements.
- Step 5
Complete the main task using the keyboard and use Review to inspect structure and focus. After fixing an issue, rescan the same state. AI is optional and is not needed for this starting workflow.
Accessibility checkers cannot replace a complete manual audit
DevCheck helps people reviewing pages find common machine-detectable issues faster, but automated checks cannot certify full WCAG, ADA, or legal compliance. Formal review still requires manual inspection, keyboard testing, assistive technology testing, and contextual judgment.
Try one check: find a button without a name
No code needed: open the practice page, scan it with DevCheck, find the button without a name, then apply the fix on the page and scan again. The practice page is fictional demo content, and AI is not needed.
Open the DevCheck practice page
Needs manual review is not the same as a confirmed error. No findings does not mean the page conforms to WCAG. If an element cannot be located, return to the same page state and rescan; protected frames and closed shadow roots may remain unavailable. Use Copy summary for a handoff, and review its contents before sharing.
Want to try it on your own test page? See the HTML example
Put the first HTML snippet on a test page you can edit, such as a localhost development page. The button does not add data.
Before: only an icon hidden from assistive technology
<button type="button"><span aria-hidden="true">＋</span></button>- Open the test page and DevCheck, then choose Scan → Scan this page. Do not use a browser settings page or an extension store page.
- Find the button-name rule in the results and inspect the listed element. Activate its element entry to try highlighting it on the page. Here, the name is missing because aria-hidden excludes the button’s only content.
- Confirm the button’s purpose, then use the version with visible text below. Do not add a name such as “button” merely to silence the finding.
- Reload the edited page and scan the same state again. This button should no longer produce a button-name finding. Still check keyboard access and operation, and the name announced by a screen reader. A working product also needs a test of the actual add-contact flow.
After: visible text explains the purpose
<button type="button">Add contact</button>Pre-release accessibility check workflow
Start with the review scope, then choose checks for automation, keyboard access, names, images, and visual states as your page needs. Record fixes and retest them. Review PDF files separately only when they are part of the task.
- Step 1. Start with the page and release scope
How to test website accessibility before launch
Decide whether the review covers a public page, local build, staging page, authenticated flow, interactive state, or PDF.
- Step 2. Run the first automated check
What automated accessibility checks can and cannot find
Use scan results to find machine-detectable issues while keeping the parts that still need human judgment visible.
- Step 3. Review keyboard and focus path
How to check keyboard focus path
Check whether focus can move, whether the order makes sense, whether focus gets trapped, and whether the path matches the page context.
- Step 4. Review accessible names
How to implement accessible names
Check whether buttons, links, form controls, and interactive components expose understandable names.
- Step 5. Review image alternatives
How to write meaningful image alt text
Review alt text based on the image purpose in context, not only what appears visually.
- Step 6. Review color, states, and readability
Color contrast checks before release
Review text, focus, error, and selected states, distinguishing essential icons and boundaries from decoration and genuinely inactive-control exceptions.
- Step 7. If PDFs are in scope, inspect structure signals
PDF accessibility structure checks
Review language, tags, images, links, forms, bookmarks, and page consistency signals.
- Step 8. Turn findings into a remediation plan
Web accessibility remediation plan
Organize next steps by user task, impact scope, owner, repair level, and re-test method.
Who should use this web accessibility checker?
Developers and agency teams
Before handoff or acceptance testing, find common issues on staging and signed-in views; when an audit report arrives, reproduce and re-test each item in the same state.
QA and testing
Add accessibility checks to pre-release and regression testing workflows.
PMs, content, and operations
Inspect the screen where a barrier was reported, record the affected element and task, and discuss next steps with the person making the fix.
Design and product
Review color, readability, visual conditions, and potential interaction difficulty during design review.
What would you like to check next?
Accesserty DevCheck
Explore the available checks, learn what stays on your device, and install DevCheck.
Check a PDF document
For a file rather than a webpage, see how the local PDF structure check works and what it cannot establish.
Understand WCAG check results
Understand success criteria and severity in your results, identify what needs human review, and re-test after a fix.
Color Contrast Checks Before Release
Use this guide when the question is whether text, states, focus indicators, icons, and component boundaries remain clear before release.
Frequently asked questions
Check whether it can inspect your pages and interaction states, identify affected elements, explain its coverage, and let you record results and retest. Also check data transmission, usage limits, and conditions for optional features. Neither free nor paid means every evaluation is covered; complete tasks still need human review.
Yes. DevCheck is a browser-based accessibility checker for people reviewing public pages, local builds, staging pages, authenticated views, focus paths, AI semantic quality, and PDF structure signals.
Public-URL tools are useful for starting with public pages. DevCheck runs in your current browser state, making local builds, staging pages, authenticated flows, open menus, and form errors available to inspect. Other tools may also support these contexts through authorized testing or browser automation; choose by actual capability, not category alone.
Yes. Because DevCheck runs in the browser, it is suited for localhost, staging, internal test pages, and pages that are not public yet.
Yes. If you can open the state in your browser, you can run DevCheck there. This is a key difference from many online URL checkers.
DevCheck can support preliminary accessibility checks for pages and documents, but it is not a legal certification tool and does not guarantee ADA, WCAG, or regulatory compliance.