Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@accessibility-mcp-server Check https://example.com for accessibility issues"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-Server for Web Accessibility Checks (WCAG 2.1/2.2)
Gives AI agents the ability to check websites for accessibility issues, validate ARIA attributes, check color contrast ratios, and generate full accessibility reports — without any API key.
WCAG 2.1 AA Compliance Checks — Automated checks for 10+ WCAG success criteria
Color Contrast Analyzer — Calculates contrast ratios and WCAG AA/AAA pass/fail
ARIA Validator — Checks ARIA roles and attributes for correctness
Heading Structure Analyzer — Validates heading hierarchy (H1→H2→H3...)
Image Alt Text Checker — Finds images missing alt attributes
Form Label Validator — Ensures all form inputs have accessible labels
Full A11y Report — Comprehensive report with accessibility score (0-100)
WCAG Rule Reference — Browse all WCAG 2.1 A/AA/AAA rules
No API Key Required — Works with any public website
Related MCP server: Accessibility MCP Server
Tool | Description |
| Full WCAG 2.1 AA check for any URL |
| Calculate contrast ratio between two colors |
| Validate ARIA attributes in HTML snippet |
| Analyze heading hierarchy on a page |
| Check all images for alt text |
| Check all form inputs for labels |
| Comprehensive accessibility report with score |
| List all WCAG 2.1 rules for a given level |
pip install accessibility-mcp-serverAdd to your claude_desktop_config.json:
{
"mcpServers": {
"accessibility": {
"command": "accessibility-mcp-server"
}
}
}"Check https://example.com for accessibility issues"
"What is the contrast ratio between #333333 and #ffffff?"
"Generate a full accessibility report for https://mysite.com"
"Check if the images on https://example.com have alt text"
"Validate the ARIA in this HTML: <div role='buttn'>Click</div>"
"List all WCAG 2.1 AA rules"
Criterion | Level | Check |
1.1.1 Non-text Content | A | Images without alt text |
1.3.1 Info and Relationships | A | Heading hierarchy, landmark regions |
1.4.3 Contrast (Minimum) | AA | Color contrast ratio calculator |
2.4.1 Bypass Blocks | A | Skip links and landmarks |
2.4.2 Page Titled | A | Missing or empty page titles |
2.4.4 Link Purpose | A | Generic link text detection |
3.1.1 Language of Page | A | Missing lang attribute |
3.3.2 Labels or Instructions | A | Form inputs without labels |
4.1.1 Parsing | A | Duplicate IDs |
4.1.2 Name, Role, Value | A | ARIA validation, unlabeled buttons |
Python 3.10+ with FastMCP
httpx for async HTTP requests
BeautifulSoup4 + lxml for HTML parsing
WCAG formulas implemented directly (relative luminance, contrast ratio)
MIT — Free for personal and commercial use.
Built by AiAgentKarl | Part of the AI Agent Tools ecosystem
Prueft den Farbkontrast zwischen Vordergrund- und Hintergrundfarbe nach WCAG 2.1.
Args: foreground: Vordergrundfarbe als Hex (#RRGGBB oder #RGB), z.B. '#000000' background: Hintergrundfarbe als Hex (#RRGGBB oder #RGB), z.B. '#ffffff' font_size_pt: Schriftgroesse in Punkt (Standard: 12pt) bold: True wenn Fettschrift
Returns: Kontrastverhältnis, WCAG-Level und Empfehlungen
| Name | Required | Description | Default |
|---|---|---|---|
| foreground | Yes | ||
| background | Yes | ||
| font_size_pt | No | ||
| bold | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only lists return values but omits error handling, prerequisites (e.g., valid hex format), or side effects. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with Args and Returns sections. Every sentence is informative and front-loaded. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple checking tool with an output schema, the description covers the key inputs and outputs. However, it lacks guidance on error cases or edge conditions (e.g., invalid colors). Completeness is high but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no parameter descriptions), so the description compensates by explaining each parameter with examples and defaults (e.g., '#000000' for foreground). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks color contrast per WCAG 2.1, specifying the verb and resource. It distinguishes from sibling tools like check_heading_structure or check_form_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied by the tool's purpose, but alternatives are not mentioned. Sibling tools are listed but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prueft alle Formular-Elemente einer Webseite auf zugaengliche Labels (WCAG 3.3.2).
Args: url: Zu pruefende URL
Returns: Alle Formular-Elemente mit Label-Status
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the basic check. It does not state limitations (e.g., static pages, invisible elements) or dependencies (e.g., JavaScript execution), leaving the agent with minimal understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the essential purpose. The Args/Returns structure is clear. However, the Returns section is vague ('all form elements with label status'), missing detail that could have been included concisely. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter and existing output schema, the description provides only the high-level purpose and return type. It lacks details about detection methodology, what constitutes an accessible label, handling of dynamic content, or edge cases. This leaves the agent underinformed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'url' lacks description in the input schema (0% coverage). The description adds only 'URL to test' in the Args section, which is tautological and adds no meaning beyond the parameter name and type. The tool fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool checks all form elements for accessible labels per WCAG 3.3.2, with a specific verb (checks) and resource (form elements). It clearly distinguishes from sibling tools that focus on other aspects like color contrast or heading structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks explicit when-to-use, when-not-to-use, or mention of specific conditions like dynamic content or required JavaScript.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analysiert die Ueberschriften-Hierarchie einer Webseite nach WCAG 1.3.1.
Prueft: H1-Einzigartigkeit, keine Hierarchie-Spruenge, leere Ueberschriften.
Args: url: Zu pruefende URL
Returns: Ueberschriften-Baum und alle gefundenen Probleme
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions three specific checks and a returned tree+problems, but lacks details on how the page is fetched, performance, error handling, or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs: first states purpose and checks, second lists Args and Returns. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and key checks. With an output schema present, it doesn't need to detail return structure. Could mention prerequisites or error behavior, but overall adequate for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage for the 'url' parameter. The description adds 'Zu pruefende URL' (URL to test), which provides basic meaning but no format or constraints, doing the minimum to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes heading hierarchy per WCAG 1.3.1, listing specific checks (H1 uniqueness, no jumps, empty headings). This differentiates it from sibling tools like check_color_contrast or check_form_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not or alternative recommendations. While the description implies use for heading structure validation, it does not guide the agent on when to prefer this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prueft alle Bilder einer Webseite auf Alt-Text (WCAG 1.1.1).
Args: url: Zu pruefende URL
Returns: Alle Bilder mit Alt-Text-Status
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool 'checks' images for alt text without disclosing any behavioral traits such as network requests, rate limits, or what constitutes a check (e.g., does it parse the page asynchronously?). This is insufficient for a tool with no built-in safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and direct, with separate lines for Args and Returns. No unnecessary words. However, the absence of any explanatory detail beyond the basics slightly reduces the score from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the tool does not need to detail return values. However, the description lacks information about the depth of the check, edge cases (e.g., images without alt attribute vs empty alt), or whether it follows the page's redirects. It is minimally complete for a simple tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (url), and the description repeats its name and a generic phrase ('Zu pruefende URL') which adds no meaning beyond the input schema. With 0% schema description coverage, the description fails to provide any additional context about the expected format or constraints of the URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks all images on a webpage for alt text, referencing WCAG 1.1.1. It is specific about the verb (prueft) and resource (Bilder einer Webseite) and distinguishes from sibling tools that focus on other accessibility checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like check_color_contrast or check_heading_structure. While the name and context hint at its specific purpose, there is no guidance on prerequisites or situations where it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuehrt automatische WCAG 2.1 AA Accessibility-Checks fuer eine URL durch.
Prueft: Bildtextalternativen, Seitentitel, Sprach-Attribut, Ueberschriften-Hierarchie, Formular-Labels, Link-Texte, ARIA-Grundregeln, doppelte IDs.
Args: url: Zu pruefende URL (z.B. 'https://example.com')
Returns: Liste aller gefundenen Probleme nach WCAG-Kriterium sortiert
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the tool as performing checks, which implies read-only behavior, but it does not explicitly confirm non-destructiveness or mention any potential side effects, rate limits, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a front-loaded purpose, a bullet list of checks, and clear Args/Returns sections. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema for return values, the description adequately covers input and behavior. It could be improved by noting it covers multiple rules comprehensively, but it is largely complete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for the 'url' parameter. The description compensates fully by explaining 'URL to test' and providing an example format ('https://example.com'), adding clear semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs automatic WCAG 2.1 AA accessibility checks for a URL, listing specific checks like image alt texts, headings, etc. It distinguishes from sibling tools that are more specific (e.g., check_color_contrast) by being comprehensive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for a full accessibility check but does not explicitly state when to use it vs. sibling tools. No guidance on exclusions or alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erstellt einen vollstaendigen Accessibility-Bericht fuer eine URL. Kombiniert alle Checks: URL-Accessibility, Bilder, Formulare, Ueberschriften.
Args: url: Zu pruefende URL
Returns: Vollstaendiger A11y-Bericht mit Gesamt-Score und Empfehlungen
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool creates a report, but does not mention any side effects, required permissions, rate limits, or data handling. As a tool that fetches a URL and runs multiple checks, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It includes a bullet list of combined checks. However, the language mix (German with some English) might be slightly confusing, and the args/returns section is redundant with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values in detail. It mentions the report includes a total score and recommendations, adding some value. However, without annotations, more behavioral context (e.g., that it fetches a live URL, might be slow) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for the 'url' parameter. The description adds a brief 'URL to be tested' in the args section, but does not provide format examples, constraints, or valid URL patterns. More detail is needed to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a complete accessibility report for a URL, and explicitly mentions that it combines all checks (URL accessibility, images, forms, headings), distinguishing it from the sibling tools which focus on individual checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for comprehensive accessibility auditing, while sibling tools are for specific checks. However, it does not explicitly state when to prefer this tool over others, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet alle WCAG 2.1 Regeln fuer das angegebene Konformitaetslevel.
Args: level: Konformitaetslevel -- 'A', 'AA' oder 'AAA' (Standard: 'AA')
Returns: Liste aller relevanten WCAG-Regeln mit Beschreibung
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | AA |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, external dependencies, or performance considerations. The tool is likely read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences plus structured Args/Returns. Every part is necessary and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal), the description does not need to detail return values. It covers the essential purpose and parameter. However, it could mention that the rules follow the WCAG 2.1 standard and lack prerequisites or error handling information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no enum or description in schema). The description compensates by explaining the 'level' parameter with acceptable values 'A', 'AA', 'AAA' and default 'AA', adding significant meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists WCAG 2.1 rules for a given conformance level, using specific verbs ('Listet') and resource ('WCAG 2.1 Regeln'). It distinguishes itself from sibling tools (e.g., check_color_contrast) which perform specific checks, not listing rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to fetch WCAG rules by level, but does not provide explicit guidance on when not to use or mention alternative tools. Sibling tools are not referenced, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validiert ARIA-Attribute in einem HTML-Snippet.
Prueft: aria-* Attribute auf gueltigen Werten, role-Attribute auf bekannte Werte, required ARIA-Attribute fuer bestimmte Rollen.
Args: html_snippet: HTML-Code-Snippet (kein vollstaendiges Dokument noetig)
Returns: Liste der ARIA-Probleme mit WCAG-Referenz
| Name | Required | Description | Default |
|---|---|---|---|
| html_snippet | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It declares what is checked but does not disclose behavioral traits such as whether it modifies input or requires authentication. The read-only nature is implied but not explicit, and no side effects are noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, beginning with a clear one-sentence purpose, followed by bullet points of checks, then args and returns sections. Every sentence adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and an existing output schema, the description covers the key aspects: purpose, input, and output format. It does not address limitations or edge cases, but for a simple validation tool, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, yet the description adds meaningful context: it clarifies that html_snippet expects an HTML snippet (not a full document) and provides a German explanation. This compensation justifies a score above baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it validates ARIA attributes in HTML snippets, specifying three checks (aria-* values, role values, required ARIA for roles). This clearly distinguishes it from sibling tools like check_color_contrast or check_heading_structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ARIA validation but does not explicitly state when to use it versus alternatives like check_form_labels. No exclusions or prerequisites are provided, leaving the agent without clear guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_color_contrastcheck_form_labelscheck_heading_structurecheck_images_altcheck_url_accessibilitygenerate_a11y_reportlist_wcag_rulesvalidate_ariaEach tool targets a distinct aspect of accessibility testing (color contrast, form labels, headings, images, etc.), but check_url_accessibility overlaps with several individual checks (images, headings, forms). Despite this, descriptions clearly distinguish between comprehensive and focused checks, so confusion is limited.
Most tools use the verb_noun pattern with 'check_', but there are exceptions: generate_a11y_report, list_wcag_rules, and validate_aria. While names are clear, the mix of verbs and a few underscores with abbreviations (a11y) breaks full consistency.
With 8 tools, the server covers core accessibility checks, a combined scan, rule reference, and ARIA validation. The count is well-scoped for an automated accessibility testing tool, neither too sparse nor too bloated.
The set includes essential WCAG checks like color contrast, headings, images, forms, and ARIA, plus a report generator and rule list. However, it lacks checks for keyboard navigation, focus order, or more advanced dynamic content, which are minor gaps for an automated audit.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Scan URLs for WCAG 2.1 violations, generate AI fixes, and produce VPAT 2.5 compliance reports.
Accessibility pre-checks (WCAG/BFSG) in a real browser + statement drafts. Pay per call.
Deterministic axe-core accessibility scans (WCAG 2.1 AA, EN 301 549, PDF/UA) via your account.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/accessibility-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
