Skip to content
Pandus
Pandus SDK documentation

Live barriers and what to fix first

How the Pandus SDK detects barriers in real visits, joins them with scanner findings, ranks what to fix first, confirms fixes and sends a weekly digest.

Updated:

A scanner shows what is broken in the code. The SDK shows where real visitors run into it and how many of them. Together they give an order of work based on real traffic, and after a fix the system checks by itself that the signal is gone.

How barriers are detected

Each detector watches the page in the visitor's browser and reports the page, a stable selector and the WCAG success criterion. It never sends text, field values, a session id or a client id. Signals are summed per page view in the browser and on our server per page template and element, so /product/123 and /product/456 count as one template.

Signal How it is noticed WCAG
Focus trap Tab and Shift+Tab circle in a few elements, Esc does not get out, the mouse was not used 2.1.2
Lost focus After an action (a dialog closed, an element removed) focus is on the page body 2.4.3
Invisible focus The focused element looks the same as without focus 2.4.7, 2.4.11
Focus under an overlay A sticky header or banner covers the focused element 2.4.11
Focus order jump The next focus jumps against the visual flow 2.4.3
Control without semantics A click on an element with a pointer cursor but no role, no tabindex and no name 4.1.2, 2.1.1
Focus inside hidden content Focus inside a part with aria-hidden 4.1.2
Unannounced form errors Invalid fields without aria-invalid or a linked message; repeated failed sends 3.3.1, 3.3.3
Reflow and zoom Sideways scrolling at 320 CSS px or when zoomed; cut-off text 1.4.10, 1.4.4
Autoplay Video or audio with sound starts without an action 1.4.2
Live axe axe-core on a sample of real page states, see Browser extension and live axe by rule
Barrier reports The “Report a barrier” form, linked to the page and its signals —

Rage and dead clicks are shown next to the barriers as a hint, without a WCAG criterion. A skip link that visitors use is counted as a positive signal.

One list of what to fix

What to fix joins problems from four sources: the scanner, live visitors, the extension and barrier reports. Each problem shows badges of its sources. A scanner finding and a live signal on the same page or template, selector and WCAG criterion become one problem with the badge “confirmed by real visitors: N sessions in 7 days”.

Filter by status, page, WCAG criterion, severity and assignee; change many problems at once.

Priority

Priority = severity weight × share of affected sessions × page traffic × confirmation factor (scanner and visitors together) × barrier reports factor. A barrier on the step before a key event ranks higher. The top of the list shows the expected effect, for example “affects about 12 % of visits to the cart page”. The rules and the rule cards choose the advice; no AI is involved.

The problem card

  • What it is and why it matters for the business, from the rule card in seven languages.
  • Where it happens: pages and templates with their traffic.
  • Evidence: the screenshot and selector from the scanner, the chart of live signals, recordings with this barrier, a heatmap excerpt, messages from visitors.
  • How to fix it on Shopify, WooCommerce, PrestaShop, Shoptet and in code.
  • Status, assignee and team comments.
  • Check the fix: the scanner checks again and live traffic is watched. Show on the site opens the page in the extension with the element highlighted.

Statuses

Open → in progress → fixed → confirmed when the live signal stays below the threshold for the set number of days, or returned when it comes back. A problem can be hidden with a reason.

Health index

A score from 0 to 100 from the scanner and live barriers, in the site header, with the formula one click away and a trend.

Live barriers screen

Signals by type and page with trends, the keyboard map (how far people get with Tab and where they stop) and display preferences in aggregate only, when at least 20 sessions stand behind them.

Barrier reports

The public “Report a barrier” form asks in steps, in plain words, with an optional screenshot. In the dashboard reports have statuses (new, in progress, solved, spam), link to problems and recordings of the page, and you can answer a visitor who left an e-mail and agreed to it, or add a barrier by hand.

Digest and alerts

Once a week, by e-mail and Telegram: new barriers, what was confirmed fixed and spikes. A sudden rise of a signal sends an alert at once; the threshold is in the settings.

The Pandus SDK and the scanner are automated checks, not a full audit, and not legal advice. The SDK changes nothing on your site and does not determine which visitors use assistive technology.