Skip to main content
Glama
kinti

a11y-toolkit

by kinti
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

a11y-toolkit: Infinite-scroll audit

a11y_scroll
Read-onlyIdempotent

Audit infinite-scroll and paginated feeds for WCAG failures: verify focus survives re-renders, new content is announced, and the feed ends. Returns scored JSON findings.

Instructions

Infinite-scroll accessibility audit — the documented disaster nobody automates (Deque guidance + ARIA APG Feed pattern; criteria 2.4.3, 4.1.3, 2.2.2). Real scrolling batches in Chromium with a live-region observer: does the focused element SURVIVE each batch (re-render destroys it — the documented failure)? Is new content ANNOUNCED (aria-live/status receives text, role=feed)? Does the feed END or offer a load-more alternative (footer reachability)? APG feed pattern as positive signal. Honest guard: if no standard items are detected (login walls, non-standard markup) the unfounded signals are skipped with a note. Requires local Playwright. — For paginated feeds only; general page audit is a11y_audit_url/dom. Returns JSON: {mode, url, score, findings [{criterion, severity, signal, issue, remediation}], summary} — same shape as the audits.

Input Schema

NameRequiredDescriptionDefault
urlYesFeed URL to audit (best on feeds you own or can authenticate into)
langNoOutput language (default en)
auth_stateNoPath to a Playwright storage_state JSON (exported session) to audit an authenticated feed
max_batchesNoscroll batches (5 default)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.14.0
    • addedInput schema / properties / max_batches
      Added value: +{
+  "description": "scroll batches (5 default)",
+  "type": "integer"
+}
    • removedInput schema / properties / max_tandas
      Removed value: -{
-  "description": "scroll batches (5 default)",
-  "type": "integer"
-}
  2. Changed1 schema field changedv5.6.0
    • removedInput schema / browser
      Removed value: -{
-  "description": "Browser engine (auto = detect the first available)",
-  "enum": [
-    "auto",
-    "chromium",
-    "firefox",
-    "webkit",
-    "chrome",
-    "msedge"
-  ],
-  "type": "string"
-}
  3. Changed4 schema fields changedv4.0.0
    • addedInput schema / browser
      Added value: +{
+  "description": "Browser engine (auto = detect the first available)",
+  "enum": [
+    "auto",
+    "chromium",
+    "firefox",
+    "webkit",
+    "chrome",
+    "msedge"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / auth_state
      Added value: +{
+  "description": "Path to a Playwright storage_state JSON (exported session) to audit an authenticated feed",
+  "type": "string"
+}
    • addedInput schema / properties / lang / description
      Added value: +"Output language (default en)"
    • addedInput schema / properties / url / description
      Added value: +"Feed URL to audit (best on feeds you own or can authenticate into)"
  4. Addedv3.3.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only/idempotent/non-destructive, but the description adds substantive behavior the agent cannot infer: real scrolling batches in a live browser, a live-region observer, a per-batch focus-survival test, and an explicit degradation guard that skips unfounded signals. It also discloses the return payload shape inline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and dense with useful specifics, and the alternative-tool routing comes before the return-shape note. Some flourish ("the documented disaster nobody automates") and embedded criteria lists cost a little density, but nothing is redundant with structured fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description responsibly describes the returned JSON (mode, url, score, findings, summary) and the finding fields. Minor gap: the score scale and severity taxonomy are not defined, leaving an agent unsure how to read a low score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all four parameters are already documented; the baseline would be 3. The description still adds meaning by framing max_batches as real scroll batches in a browser (implying runtime cost) and by advising to audit feeds you own or can authenticate into, which motivates the auth_state parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource — an infinite-scroll accessibility audit with real Chromium scrolling — and enumerates the three concrete checks (focus survival, live-region announcement, feed termination). It explicitly demarcates itself from a11y_audit_url/a11y_audit_dom, so an agent can route correctly without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit usage boundary ("For paginated feeds only; general page audit is a11y_audit_url/dom") and a prerequisite ("Requires local Playwright"). It also states a when-not condition via the honest guard for login walls / non-standard markup, so the agent knows when results will be degraded.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools