What we are aiming for, what we know is broken, and what we have not tested yet. This page is deliberately specific: a statement that claims more than we have measured is worse than none.
Our target is WCAG 2.1 Level AA.
Current status: does not conform. BGPScout does not currently meet WCAG 2.1 AA. The barriers listed below are known and unresolved.
Last assessed 2026-09-01, by self-assessment. Three passes back this page, and each one sees things the others cannot.
1. Every page template was read by a scanner. Across 125 templates it finds 350 markup-level problems: 163 form controls with no accessible name, 104 relying on placeholder text alone, 74 pages with no top-level heading, and 9 data tables with no header cells. Three earlier findings are now at zero - pages not declaring their language, mouse-only click handlers, and icon-only buttons with no label - and the last of those is now checked automatically on every build.
2. An automated scan ran in a real browser, across seven public pages, in both the dark and light colour schemes. This is the pass we had been deferring to, and running it changed what this page can honestly say.
3. A keyboard traversal walked every focusable control on those same seven pages - 191 stops in total - checking that each one visibly changes appearance when it receives focus, and that focus is never trapped.
The browser pass found 13 failures the earlier scans could not see: seven contrast failures in the dark colour scheme and six in the light one - the two schemes fail on different elements, so neither run alone would have found them all - plus four of the seven pages scrolling sideways at a 320-pixel window width. Both are barriers below, with numbers. The keyboard traversal found none: all 191 focus stops showed a visible indicator, and nothing trapped focus.
A correction, because the previous version of this page was reassuring and wrong. It said an automated scan had found no violations. Re-run today, that scan still reports zero problems on the seven pages where the browser finds thirteen - it runs without a browser, so it cannot compute a colour or measure a dimension. It was blind to exactly these failures and reported that blindness as a clean result.
We have not done any screen-reader testing, and we have not scanned the signed-in application at all - that needs a logged-in session, which our audit tooling is currently not permitted to create. It is the larger part of the site and where all 350 template problems above are found. Assume it is worse than the public pages, not better.
We are publishing this before the audit is complete rather than after, because the barriers we already know about are worth telling you about now.
These are confirmed, not suspected. Each names the issue we are tracking it under, so you can quote it back at us.
Measured 2026-09-01, in a browser. In the dark colour scheme our primary call-to-action button - the one that says Log in or Get started, on both the home page and the pricing page - paints near-white text on an amber fill at a contrast ratio of 1.74 to 1. The standard requires 4.5 to 1. This is the worst result anywhere on the site, it is above the fold on our two most-visited pages, and it is the first thing a visitor with low vision meets.
Two more in the same theme: a blue category tag on the home page reaches 4.27 to 1. In the light colour scheme the button is fine but a green tag reaches 4.44 to 1, and three links on the pricing page are marked out from the text around them by colour alone, with no underline - so if you cannot distinguish those hues, they do not read as links at all.
A further 31 pieces of text sit on gradients or on decorative layers, where the tool cannot compute a single ratio because the background changes across the element. Those are unresolved, not passing. Gradient-backed text is a common place for a contrast failure to hide, and we have not yet checked them by hand.
Measured 2026-09-01. Content is supposed to reflow into a 320-pixel-wide window without forcing horizontal scrolling. The pricing page needs 768 pixels before it stops scrolling sideways; the home page needs 640; the data sources page needs 560; the French version of this page needs 400. Sign-in, registration and this page in English are the three that pass.
In practice that means the pricing page scrolls horizontally on every phone held upright, which is the hardest reading mode to work around if you also rely on large text or magnification.
74 templates have no top-level heading, so jumping through headings - a primary way to navigate with a screen reader - has no entry point for the page topic.
163 form controls across 46 templates have no accessible name; a further 104 rely on placeholder text, which disappears as soon as you type and is not a dependable label. Affected fields are mostly filters and search boxes inside the application.
Sixteen pages of the signed-in application let you click anywhere on a row to open its detail page - a click handler delegated from the document to every [data-href] row, platform-wide. It listens for click and auxclick only; there is no keydown handler and the row carries no tabindex, so the row itself is unreachable and unactivatable without a pointing device. Where a row also has a real link inside it, that link works with a keyboard - the row-level shortcut just does not.
The ASN detail page's Location Map and the IXP/facility maps are interactive Mapbox canvases with nothing else nearby presenting the same information - no table, no text summary of what the map shows. We consider this the most serious barrier on the platform.
One exception, worth stating precisely rather than folding into the same blanket claim: the IP-density heatmap at /prospect/ip-density does have a server-rendered "Top ASNs" table alongside it, with proper th/thead markup, that answers substantially the same question (which networks are dense in this area) without depending on the map at all. It is a ranked summary, not a pixel-for-pixel equivalent of the heatmap, but it is a real, keyboard- and screen-reader-reachable alternative - and claiming otherwise would have been exactly the kind of unmeasured overstatement this page exists to avoid.
These are specific, cited exceptions to "does not conform" above - not evidence of broader conformance, and not a reason to relax the status at the top of this page.
The platform's own replacement for the browser's native popup dialogs (window.BGPSDialogs, used everywhere on the platform that needs one) traps focus inside the open dialog, restores focus to whatever opened it on close, is dismissible with Escape, and carries aria-modal, aria-labelledby and aria-describedby. This is a real, working implementation of WCAG's focus-management and keyboard-trap requirements for one interactive component - not a claim about every interactive component on the site.
A build-time check scans every icon-only button, link and close control on every page and fails the build if one has no text alternative. Re-run 2026-09-01: 1,122 such controls found across 125 pages, 220 carrying an explicit label, none unlabelled. This does not mean every control on the platform is well-named - text-labelled controls and the 163 bare form fields listed above are a separate, larger problem this check does not look at - only that the specific unlabelled-glyph failure is now caught before it ships.
A prefers-reduced-motion: reduce rule in the portal stylesheet collapses transition and animation durations to near-zero across the entire signed-in application. The public marketing pages, including this one, do not have an equivalent rule yet - a gap, not a false claim, since the barrier list above is about the application, not this page's own animations (it has none).
Measured 2026-09-01, in a browser. Pressing Tab through the home, pricing, sign-in, registration, data sources and both accessibility pages produced 191 focus stops, and on every single one the control changed appearance when it took focus. Focus never became stuck: on every page it kept advancing and eventually left the document, so there is no keyboard trap on any of them.
Two limits worth stating. This says the indicator appears; it does not yet say the indicator is bright enough against what is behind it, which is a separate requirement we have not checked. And it covers the seven public pages - the signed-in application has not been walked at all.
The seven CDN-provider badge colours used across the ASN detail and CDN pages are checked against the WCAG relative-luminance formula, per pair, with the ratios and pass/fail recorded in docs/colour-rules.md - all seven currently pass 4.5:1. This is one colour system on two pages, not a site-wide contrast audit; the "not tested" list below still applies to everything else.
Being honest about the gaps matters as much as listing the barriers. None of the following has been assessed:
Until that testing happens, assume there are barriers beyond the ones listed above.
If something on BGPScout blocks you, please tell us - including things not listed above. Email [email protected].
We aim to respond within 5 business days, and we will tell you whether we can fix it, when, and what to do in the meantime. If you need data you cannot reach through the interface, say so - we can often supply it directly, and our API and MCP server expose the same data in a form that does not depend on the visual interface at all.
This statement covers bgpscout.io, including the public marketing pages and the logged-in application.
Prepared 2026-07-30. Fully re-measured 2026-09-01, when a browser became available on the machine that runs our checks: that pass added colour contrast, reflow and keyboard traversal, which had all been listed as untested until then. We will review it again when the signed-in application has been scanned and a screen-reader walkthrough has been done, and at least annually thereafter. A French translation is available at /accessibility/fr.
BGPScout is operated by Hive Data Center Inc., Montreal, Quebec, Canada.