Datakoot › Accessibility

Accessibility Conformance Report

Datakoot conforms to WCAG 2.1 Level AA, which is a superset of the WCAG 2.0 Level A and AA criteria incorporated by reference into the Revised Section 508 Standards (36 CFR Part 1194). This page is the full report: every applicable criterion, what we found, and how we tested it. Where something had to be fixed to get here, it says so and gives the date.

For procurement officers. This is a vendor self-assessment in the VPAT® 2.5 structure, published as a web page so it stays current. If your file needs it as a signed document on the ITI template, email hello@datakoot.com and you will have it the same week. Nothing in it will differ from what is on this page.

FieldValue
ProductDatakoot — datakoot.com website and product documentation
VersionSite as deployed 3 October 2026
Report date3 October 2026
VendorDatakoot — hello@datakoot.com
Standards appliedWCAG 2.1 Level A and AA (W3C Recommendation)
Revised Section 508 Standards, 36 CFR Part 1194, Appendix A, Chapters 3–6
Evaluation methodsAutomated testing with axe-core 4.13.0 driven through Chromium against the WCAG 2.0/2.1 A and AA rule sets, re-run on 3 October 2026 at two viewports — 1280 px and 320 px, because several defects appear only at the narrow one. Plus scripted behavioural testing of keyboard operation, focus, reflow, text resize and text spacing; direct computation of contrast ratios from the source colour values; and manual code inspection. All 35 pages were tested at both widths, not a sample. The run is also repeated at several sampling delays (0 ms, 80 ms, 200 ms and 500 ms after the DOM is ready), because an automated checker that samples a page mid-animation can read a colour that never actually settles on screen. That is not a hypothetical: until 3 September 2026 the site faded revealed sections in over 0.7 s, and a checker sampling inside that window measured section labels at 4.18–4.49:1 rather than their resting 5.68:1. The fade was removed and those sections now slide into place at full opacity, so the measured value no longer depends on when the checker looks. Latest result: 0 violations on all 35 pages at both viewports, at every sampling delay.
Independent auditNone. This is a vendor self-assessment, which the Section 508 program permits and which carries less weight than a third-party review. Said plainly so you can weigh it.

How to read the conformance column

Supports
The functionality meets the criterion without known defects.
Partially Supports
Some functionality meets the criterion. The remark says what does not.
Does Not Support
The majority of the functionality does not meet the criterion.
Not Applicable
The criterion is not relevant to this product. The remark says why.
Not Evaluated
Not tested. Used only where stated; nothing on this page is claimed on the strength of an assumption.

Table 1 — WCAG 2.1 Level A

30 criteria: 22 Supports, 8 Not Applicable, 0 Partially Supports, 0 Does Not Support.

CriterionConformanceRemarks and explanations
1.1.1
Non-text Content
SupportsAll 179 inline SVG icons are decorative and carry aria-hidden="true", so assistive technology skips them rather than announcing 156 unnamed graphics. No <img> element on the site lacks an alt attribute. No non-text content conveys information on its own.
1.2.1
Audio-only and Video-only (Prerecorded)
Not ApplicableThe site contains no audio or video. Checked across all 35 pages: zero audio, video, object, embed or iframe elements.
1.2.2
Captions (Prerecorded)
Not ApplicableNo synchronised media.
1.2.3
Audio Description or Media Alternative (Prerecorded)
Not ApplicableNo synchronised media.
1.3.1
Info and Relationships
SupportsHeadings nest without skipping a level on all 35 pages. Lists use real list markup, tables use <th> with correct scope, and the terminal examples are wrapped in role="group" with an accessible name so the code and its label stay associated. axe rules list, listitem, th-has-data-cells, td-headers-attr and definition-list pass.
1.3.2
Meaningful Sequence
SupportsNo element on any page uses CSS order, reversed flex direction or direction: rtl, so the DOM order is the reading order.
1.3.3
Sensory Characteristics
SupportsNo instruction on the site depends on shape, colour, size or screen position. Verified by text scan of all 35 pages for phrasing such as “the button on the right” or “click the green box”: no matches.
1.4.1
Use of Color
SupportsFixed 30 August 2026. Two links inside prose on the home page were distinguished from the surrounding text by colour alone. They are now underlined. Every remaining in-content link is either underlined or carries a non-colour cue; the copy controls, which previously confirmed success by turning blue, now also announce it. Also fixed 3 September 2026: links inside table cells were not covered by the underline rule, so the contact address in the vendor table above was distinguished by colour alone. The rule now covers td, th and dd.
1.4.2
Audio Control
Not ApplicableNo audio plays automatically or at all.
2.1.1
Keyboard
SupportsFixed 3 September 2026. A 320 px scan found that 14 pages contained a region that scrolls but could not be reached by keyboard — 46 response samples on the server pages, 14 table wrappers and 2 command blocks. A mouse user could drag them sideways to read the rest; a keyboard user could not reach them. All now carry tabindex="0" with role="group" and a label. Every control is a native <a> or <button>. Tested by keyboard rather than by inspection: the copy buttons, the FAQ disclosures, the mobile menu and the motion toggle each operate on both Enter and Space, and 45 sequential Tab stops were walked on the home page.
2.1.2
No Keyboard Trap
SupportsFocus was driven forward 60 stops and back 60 stops on the home page and moved freely throughout. No component captures focus.
2.1.4
Character Key Shortcuts
SupportsThe site defines no keyboard shortcuts. Its only script registers zero keydown, keypress or keyup handlers.
2.2.1
Timing Adjustable
Not ApplicableNo time limit is imposed anywhere on the site. Sessions do not expire because there are no sessions.
2.2.2
Pause, Stop, Hide
SupportsFixed 30 August 2026. Two background layers drift indefinitely behind the content. prefers-reduced-motion was already honoured, but that is an operating-system setting rather than a mechanism on the page, which is what this criterion asks for. A Reduce motion button now appears in the footer of all 35 pages. It stops every animation and transition, reports its state through aria-pressed, and is remembered between visits.
2.3.1
Three Flashes or Below Threshold
SupportsNothing on the site flashes. The only indefinite animations are two background translations of 26 and 44 seconds. No animation anywhere runs faster than 3 Hz.
2.4.1
Bypass Blocks
SupportsFixed 3 September 2026. The first Tab stop on every page is now a working “Skip to content” link targeting the <main> landmark. Until that date only the home page carried one; the other 32 pages did not, and an earlier version of this report claimed otherwise. The link is present on all 35 pages and precedes the header in source order on every one of them.
2.4.2
Page Titled
SupportsEvery one of the 35 pages has a unique, descriptive <title>.
2.4.3
Focus Order
SupportsFocus order follows visual order. No element on any page carries a positive tabindex — verified, count is zero across all 35 pages.
2.4.4
Link Purpose (In Context)
SupportsNo link on the site reads “here”, “click here”, “read more”, “more”, “link” or “this”. Verified across all 35 pages.
2.5.1
Pointer Gestures
SupportsEvery interaction is a single click or tap. There is no path-based gesture, drag, pinch or multipoint input anywhere.
2.5.2
Pointer Cancellation
SupportsEvery handler is bound to the click event, never to mousedown, so activation happens on the up-event and can be aborted by moving off the target before releasing.
2.5.3
Label in Name
SupportsNo control has an accessible name that omits its visible text. The only aria-label attributes on the site are on landmarks and on icon-only controls that have no visible text to conflict with.
2.5.4
Motion Actuation
Not ApplicableNo feature responds to device motion or orientation.
3.1.1
Language of Page
Supportslang="en" is declared on all 35 pages and is a valid language tag.
3.2.1
On Focus
SupportsReceiving focus changes nothing but the focus indicator. No focus event navigates, submits or opens anything.
3.2.2
On Input
SupportsRe-tested 3 September 2026 after the contact form was added. No field on the contact form submits, navigates or changes context when it receives focus or when its value changes; the form is submitted only by activating the Send button. The motion toggle is a button that changes decorative motion, not context, and never moves focus or navigates.
3.3.1
Error Identification
SupportsChanged from Not Applicable on 3 September 2026, when the contact form was added. Each field that fails validation is described in text next to the field, is given aria-invalid="true", and is linked to its message through aria-describedby, so the error is announced with the field rather than only shown in colour. A summary message is also written into a polite role="status" region above the form, and focus moves to the first field in error. The server applies the same rules as the browser and returns the same field names, so a submission that bypasses the client script is identified the same way. Checkout and account management are operated by Polar; see the component table.
3.3.2
Labels or Instructions
SupportsChanged from Not Applicable on 3 September 2026, when the contact form was added. Every visible field on the contact form has a real <label> bound with for. Required fields are marked in the label and carry the required attribute, so the requirement reaches assistive technology as well as sighted users. Instructions that are not obvious from the label — where the reply will be sent, and the remaining character budget — are associated with their field through aria-describedby. The one unlabelled-looking field is a spam honeypot: it is inside an aria-hidden="true" container and removed from the focus order, so no real user or assistive technology encounters it. The contact form is the only form on the site; the other 34 pages contain zero input, select, textarea or form elements.
4.1.1
Parsing
SupportsMarkup parses without duplicate IDs or improper nesting; axe rule duplicate-id-aria passes. Noted for completeness: W3C removed this criterion by errata in 2023 and it is treated as always satisfied for content parsed by modern browsers.
4.1.2
Name, Role, Value
SupportsZero unnamed links or buttons across all 35 pages. The mobile menu maintains aria-expanded and aria-controls, the FAQ disclosures maintain aria-expanded, and the motion toggle maintains aria-pressed. Every contact-form control is a native input, select, textarea or button with a bound label, and reports its invalid state through aria-invalid. Fourteen ARIA-related axe rules pass with no violations.

Table 2 — WCAG 2.1 Level AA

20 criteria: 14 Supports, 6 Not Applicable, 0 Partially Supports, 0 Does Not Support.

CriterionConformanceRemarks and explanations
1.2.4
Captions (Live)
Not ApplicableNo live media.
1.2.5
Audio Description (Prerecorded)
Not ApplicableNo synchronised media.
1.3.4
Orientation
SupportsNo page locks orientation. Layout reflows in both portrait and landscape.
1.3.5
Identify Input Purpose
SupportsChanged from Not Applicable on 3 September 2026, when the contact form was added. The three fields that collect information about the user carry the correct autocomplete tokens from the WCAG input-purpose list: name, email and organization. The topic and message fields ask about the enquiry, not about the person, so no token applies to them.
1.4.3
Contrast (Minimum)
SupportsEvery text colour was computed against the backgrounds it is used on rather than sampled from a screenshot. Body text 16.81:1, secondary 9.20:1, tertiary 7.24:1, link blue 5.82:1, cyan 10.37:1, green 9.74:1, amber 10.49:1 against the page background. The lowest ratio anywhere on the site is link blue on the raised card background at 4.64:1, above the 4.5:1 threshold. The full table is below.
1.4.4
Resize Text
SupportsTested at 200% root font size on a 640 px viewport across four page types. No horizontal scrolling, no clipping, no loss of function.
1.4.5
Images of Text
SupportsAll text is live text. The only images on the site are the logo mark and the Open Graph share images used by social previews, neither of which carries information the page does not also state in text.
1.4.10
Reflow
SupportsFixed 30 August and 3 September 2026. Tested at a 320 px viewport on every page, not a sample. On 30 August, three of the then 31 pages failed: two server pages whose extension button could not fit its label on one line, and one guide with an unbroken URL in a paragraph. On 3 September the two pages added that day, /government and /security, failed too — their tables carry a 560 px minimum width and had not been placed in the horizontal-scroll container the other tables use. All five causes are fixed. All 35 pages now reflow with no horizontal scrolling of the page; wide tables scroll inside their own container.
1.4.11
Non-text Contrast (AA)
The contact form shipped with field borders at 1.85:1 against the field fill, below the 3:1 required for a user-interface component boundary. axe-core does not check component boundaries, so this was found by computing the ratio by hand, not by the automated run. Border colour changed; now 3.50:1.
1.4.3
Contrast (Minimum) (AA)
Revealed sections faded in over 0.7 s, so an automated checker sampling inside that window measured section labels at 4.18–4.49:1 — a real, if brief, sub-threshold state, and a result that changed from run to run. The opacity transition was removed; sections now slide in at full opacity and measure their resting 5.68:1 at every sampling delay.
3.3.1, 3.3.2, 3.3.3, 1.3.5
Form criteria
Four criteria were reported as Not Applicable because the site had no form. Adding the contact form made them applicable. Each has been re-tested and now reads Supports, with the evidence in Tables 1 and 2.
1.4.11
Non-text Contrast
SupportsThe keyboard focus ring is cyan at 10.37:1 against the page background and 9.34:1 against the card background. The primary button is 5.82:1. Fixed 3 September 2026. The contact form first shipped with its field borders drawn in the site’s general line colour, which measures 1.85:1 against the field fill — below the 3:1 this criterion requires for the boundary of a user-interface component, and not something axe-core checks. The form controls now use a dedicated border colour measuring 3.50:1 against the field fill and 3.66:1 against the page, rising to 5.72:1 on hover; the invalid state is 7.76:1 and the select indicator is 6.92:1. Other controls whose boundary is lower-contrast are identified by their visible text label, which meets the text threshold.
1.4.12
Text Spacing
SupportsTested with the criterion's own override values — line height 1.5×, letter spacing 0.12em, word spacing 0.16em, paragraph spacing 2em — across five page types. No clipping and no horizontal scrolling. axe rule avoid-inline-spacing passes.
1.4.13
Content on Hover or Focus
Not ApplicableNo tooltips, popovers or hover-revealed content. Verified: zero title attributes and zero role="tooltip" elements across all 35 pages.
2.4.5
Multiple Ways
SupportsPrimary navigation on every page, a footer with four link columns, a guides index, and a published sitemap.xml.
2.4.6
Headings and Labels
SupportsOne <h1> per page, no empty headings, and no skipped heading levels on any of the 35 pages.
2.4.7
Focus Visible
SupportsA 3 px cyan outline with a 3 px offset. Verified on all 45 focusable elements of the home page, and on pricing and a server page, by pressing Tab and reading the computed style — not by assuming the rule applies. Worth recording: an earlier run of this test appeared to show five controls with no ring; the test was sampling the style mid-transition, and the ring is present on every control once the 200 ms transition settles.
3.1.2
Language of Parts
SupportsAll content is in English. No passage on any page is in another language.
3.2.3
Consistent Navigation
SupportsThe primary navigation contains the same five items in the same order on all 35 pages, and the footer repeats its links in the same order throughout.
3.2.4
Consistent Identification
SupportsFixed 30 August 2026. The link to the guides index was labelled “Docs” on the home page and the nine server pages and “Guides” on the other 21 — the same destination under two names, which is what this criterion prohibits. Now “Guides” everywhere; the site has exactly one navigation signature.
3.3.3
Error Suggestion
SupportsChanged from Not Applicable on 3 September 2026, when the contact form was added. Every validation message says what to do rather than only that something is wrong — for example the message field asks for at least 20 characters, and the rate-limit and timing responses say to email hello@datakoot.com directly or to wait and resend. No error is reported as a bare code.
3.3.4
Error Prevention (Legal, Financial, Data)
Not ApplicableThe site itself takes no legal, financial or data-modifying action. Sending the contact form creates no account, no obligation and no charge, and does not modify data the sender controls, so it is not a transaction this criterion governs. Purchase is handled entirely by Polar, which is listed separately in the component table.
4.1.3
Status Messages
SupportsFixed 30 August 2026. The copy buttons changed their own label to “Copied” and the inline copy links changed colour, with no live region anywhere on the site — a screen-reader user received no confirmation that anything had happened. A polite role="status" region is now present on all 35 pages and both copy paths announce through it. The contact form has its own polite role="status" region: sending, success and failure are announced without moving focus, and the confirmation that replaces the form is itself a status region that receives focus.

Table 3 — Section 508 Chapter 3: Functional Performance Criteria

These describe what a person must be able to do, independent of any technical checklist. Where the answer rests on structure rather than on observed use, it says so.

Functional performance criterionConformanceRemarks and explanations
302.1
Without Vision
Partially SupportsAll content is text or is marked decorative, headings and landmarks are correct, and every control has a name and a role. No testing with a screen reader has been performed, so this is asserted from structure rather than from use.
302.2
With Limited Vision
SupportsText resizes to 200% and reflows at 320 px with no loss of content or function. All text exceeds 4.5:1 contrast; most exceeds 9:1.
302.3
Without Perception of Color
SupportsNo information is conveyed by colour alone. In-content links are underlined and copy confirmations are announced as text, not signalled only by a colour change.
302.4
Without Hearing
Not ApplicableThe site produces no sound.
302.5
With Limited Hearing
Not ApplicableThe site produces no sound.
302.6
Without Speech
Not ApplicableNo feature requires speech input.
302.7
With Limited Manipulation
SupportsEverything is operable from the keyboard alone. No gesture, drag or timed interaction exists anywhere on the site.
302.8
With Limited Reach and Strength
SupportsNo sustained physical action is required. Every target is a single click or a single key press.
302.9
With Limited Language, Cognitive, and Learning Abilities
SupportsPlain language, consistent navigation on every page, no time limits, and — as of this report — a control to stop background motion.

Table 4 — Section 508 Chapter 4: Hardware

Not applicable in full. Datakoot supplies no hardware. Chapter 4 does not apply to any part of this offering.

Table 5 — Section 508 Chapter 5: Software

Chapter 5 — SoftwareConformanceRemarks and explanations
501.1
Scope — Software
Not ApplicableDatakoot ships no installed software as part of this offering. The website is evaluated against Chapter 5 by way of WCAG 2.1 AA above. The nine Chrome extensions are software and are listed as not evaluated in the component table.
502
Interoperability with Assistive Technology
Partially SupportsThe website is standard HTML with correct ARIA and exposes name, role, state and value through the browser's accessibility tree. Not verified against a specific assistive technology; see Known limitations.
503
Applications
SupportsEvaluated as web content under WCAG 2.1 AA. User preferences for colour, contrast, font type and size are inherited from the browser and are not overridden.
504
Authoring Tools
Not ApplicableDatakoot is not an authoring tool. It produces no content on a user's behalf.

Table 6 — Section 508 Chapter 6: Support Documentation and Services

Chapter 6 — Support documentation and servicesConformanceRemarks and explanations
602.2
Accessibility and Compatibility Features
SupportsDocumentation is published as web pages on this site and is covered by the WCAG 2.1 AA evaluation above. This report itself states which accessibility features exist and how they were tested.
602.3
Electronic Support Documentation
SupportsAll documentation — the guides, the pricing page, the privacy policy and the terms — is HTML on datakoot.com and conforms as described above. No documentation is delivered as PDF or as an image.
602.4
Alternate Formats for Non-Electronic Support Documentation
Not ApplicableNo printed or non-electronic documentation is provided.
603.2
Information on Accessibility and Compatibility Features
SupportsSupport is by email at hello@datakoot.com. Questions about accessibility receive the same channel and the same person as any other support question.
603.3
Accommodation of Communication Needs
SupportsSupport is by email, which does not require speech or hearing. If another channel is needed, ask and it will be arranged.

Contrast measurements

Contrast was computed from the source colour values using the WCAG relative-luminance formula rather than sampled from a screenshot, because a screenshot of a page with a translucent animated background does not reliably tell you which pixel is the real background.

ColourUsed forOn page backgroundOn cardOn raised card
#eef3fbBody text16.81:115.13:113.39:1
#a8b7cdSecondary text9.20:18.28:17.33:1
#94a2b8Tertiary text, captions7.24:16.52:15.77:1
#4f8cffLinks, primary button5.82:15.24:14.64:1
#5a6f8fContact-form field borders3.66:13.30:12.92:1
#26d3eeFocus ring, accents10.37:19.34:18.26:1
#34d399Success accents9.74:18.77:17.76:1
#ecba62Notice accents10.49:19.44:18.36:1

The threshold is 4.5:1 for normal text and 3:1 for large text and user-interface components. The lowest text ratio anywhere on the site is 4.64:1. The lowest user-interface ratio is the contact-form field border at 3.50:1 against the field’s own fill, which is the surface it is actually drawn against; the 2.92:1 figure in the raised-card column is listed for completeness — no form field is placed on a raised card.

What was tested, and how

Automated

axe-core 4.13.0 through Chromium against 14 pages covering every template on the site: home, pricing, onboarding, the guides index, a guide article, four of the nine server pages, terms, privacy, this page, the post-purchase page and the 404 page. Result: 0 violations, with 321 rule-checks passing and 15 distinct WCAG tags exercised.

Automated tools catch a minority of accessibility barriers. A clean axe run is a floor, not a finding. Everything below is the part the automated pass could not decide.

Scripted behavioural testing

  • Keyboard operation. 45 sequential Tab stops walked on the home page. Every control activated with both Enter and Space, and the result of each activation read back from the page rather than assumed. Focus driven 60 stops forward and 60 back to confirm there is no trap.
  • Focus visibility. The computed outline read on every focusable element after the focus transition settles. All show a 3 px cyan ring at 10.37:1.
  • Reflow. Every page loaded at a 320 px viewport and checked for horizontal scrolling. Three failed on 30 August and two more on 3 September; all five causes were fixed and all 33 now pass.
  • Text resize. Root font size set to 200 per cent on a 640 px viewport across four page types.
  • Text spacing. The criterion's own override values injected as a stylesheet across five page types, then every text element checked for clipping.
  • Mobile navigation. Menu opened at 390 px on all 35 pages, with aria-expanded and the resulting position verified each time.
  • Structure and content scans. Heading order, empty headings, positive tabindex, vague link text, sensory-only instructions, title attributes, unnamed controls, exposed decorative graphics and navigation consistency, all checked across all 35 pages.

What we found and fixed

Six defects were found and fixed on 30 August 2026 while preparing this report, and further defects on 3 September 2026. They are listed because a conformance report that only reports success is not worth reading.

CriterionWhat was wrong
1.4.1 Use of Color (A)Two links inside prose on the home page were distinguished from the surrounding text by colour alone. Underlined.
4.1.3 Status Messages (AA)The copy buttons changed their own label to “Copied” and the inline copy links changed colour, with no live region anywhere on the site — a screen-reader user got no confirmation at all. A polite role="status" region is now on every page.
2.2.2 Pause, Stop, Hide (A)The background animates indefinitely. prefers-reduced-motion was honoured, but the criterion asks for a mechanism on the page. Added the Reduce motion control in the footer.
1.1.1 Non-text Content (A)115 of the 156 decorative icons the site then had were exposed to assistive technology as unnamed graphics. All are now hidden from it.
3.2.4 Consistent Identification (AA)The link to the guides index was labelled “Docs” on ten pages and “Guides” on the other 21 — one destination, two names. Standardised.
1.4.10 Reflow (AA)Three pages scrolled horizontally at 320 px. Found only because that round tested all 33 pages then on the site instead of a sample of eleven.

Components outside this report

ComponentStatusNotes
MCP API endpointsNot applicableMachine-to-machine JSON-RPC over HTTP. No user interface and no human-perceivable content, so WCAG has nothing to attach to.
Chrome extensions (nine)Not evaluatedEach has a browser popup interface. They have not been formally tested and are not claimed as conforming. If an extension is part of what you are buying, say so and it will be tested and reported before you commit.
Billing and account portalThird partyOperated by Polar. Their conformance is theirs to state, not ours. This is also why criteria 3.3.1, 3.3.3 and 3.3.4 are marked not applicable to the Datakoot site itself.
Per-server landing pagesPartially evaluatedServed from the API subdomains and normally redirected to the equivalent page on datakoot.com. Not separately audited.

Known limitations

We would rather tell you these than have you find them.

  • No assistive-technology testing has been performed. The site has not been driven with JAWS, NVDA, VoiceOver or Dragon. Everything above is asserted from automated testing, scripted behavioural testing and code inspection. This is the single biggest gap in this report, and it is why 302.1 and 502 are marked Partially Supports rather than Supports.
  • No third-party audit has been commissioned. This is a self-assessment.
  • The nine Chrome extensions are untested.
  • One axe rule returns “needs review” on every page rather than pass or fail — colour contrast over the animated background. It was resolved by computing the ratios directly, which is the table above.

Legal basis and scope

Section 508 of the Rehabilitation Act (29 U.S.C. §794d) binds federal agencies in what they procure, develop, maintain and use. It does not directly bind private companies; the obligation reaches a vendor through the terms of a contract. The Revised 508 Standards incorporate WCAG 2.0 Level A and AA by reference. We target WCAG 2.1 AA, a strict superset, because agency solicitations commonly ask for it.

VPAT® is a registered trademark of the Information Technology Industry Council. This report follows the structure of the VPAT 2.5 Revised Section 508 edition; it is not published on the ITI template, and is available in that form on request.

Found a barrier?

Email hello@datakoot.com with the page and what went wrong. It reaches the person who builds the site, not a queue. Accessibility defects are treated as functional defects, not feature requests, and this page is updated when one is fixed.