A
licenseB
qualityA
maintenanceEnables automated web accessibility scans for WCAG compliance using Playwright and Axe-core, providing visual and JSON reports with remediation guidance.
25
3,085 npm
56
MIT
Web Accessibility MCP Server
웹 접근성 MCP 서버
axe-core와 Puppeteer를 사용하여 웹 접근성 분석 기능을 제공하는 MCP(Model Context Protocol) 서버입니다.
특징
axe-core를 사용하여 모든 URL의 웹 접근성을 분석합니다.
색상 행렬을 사용하여 색맹(적색맹, 녹색맹, 청색맹)을 시뮬레이션합니다.
접근성 위반에 대한 자세한 보고
사용자 정의 사용자 에이전트 및 선택기 지원
문제 해결을 위한 디버그 로깅
WCAG 가이드라인을 기반으로 한 포괄적인 접근성 검사
Related MCP server: Cursor A11y MCP
필수 조건
Node.js(v14 이상)
엔피엠
설치
Smithery를 통해 설치
Smithery를 통해 Claude Desktop용 웹 접근성 MCP 서버를 자동으로 설치하려면:
지엑스피1
수동 설치
저장소를 복제합니다.
git clone [repository-url]
cd mcp-web-a11y종속성 설치:
npm install서버를 빌드하세요:
npm run build구성
MCP 설정 파일(일반적으로 ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json 에 위치)에 서버를 추가합니다.
{
"mcpServers": {
"web-a11y": {
"command": "node",
"args": ["/path/to/mcp-web-a11y/build/index.js"],
"disabled": false,
"autoApprove": [],
"env": {
"MCP_OUTPUT_DIR": "/path/to/output/directory"
}
}
}
}환경 변수
MCP_OUTPUT_DIR: 스크린샷 출력이 저장될 디렉토리simulate_colorblind도구에 필요합니다.지정하지 않으면 현재 작업 디렉토리를 기준으로 './output'이 기본값으로 사용됩니다.
MCP 설정에서 구성할 경우 절대 경로여야 합니다.
용법
이 서버는 웹 접근성을 분석하는 check_accessibility 와 색맹을 시뮬레이션하는 simulate_colorblind 두 가지 도구를 제공합니다.
도구: check_accessibility
axe-core를 사용하여 주어진 URL의 접근성을 확인합니다.
매개변수
url(필수): 분석할 URLwaitForSelector(선택 사항): 분석 전 기다릴 CSS 선택기userAgent(선택 사항): 요청에 대한 사용자 정의 사용자 에이전트 문자열
사용 예
<use_mcp_tool>
<server_name>mcp-web-a11y</server_name>
<tool_name>check_accessibility</tool_name>
<arguments>
{
"url": "https://example.com",
"waitForSelector": ".main-content",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
}
</arguments>
</use_mcp_tool>도구: simulate_colorblind
색상 행렬 변환을 사용하여 다양한 유형의 색맹 사용자에게 웹 페이지가 어떻게 표시되는지 시뮬레이션합니다.
색맹 유형
이 도구는 세 가지 유형의 색맹 시뮬레이션을 지원합니다.
적색맹 (적색맹) - 매트릭스 사용:
0.567, 0.433, 0 0.558, 0.442, 0 0, 0.242, 0.758녹색맹 (녹색맹) - 매트릭스 사용:
0.625, 0.375, 0 0.7, 0.3, 0 0, 0.3, 0.7삼 색맹 (청맹) - 매트릭스 사용:
0.95, 0.05, 0 0, 0.433, 0.567 0, 0.475, 0.525
매개변수
url(필수): 캡처할 URLtype(필수): 시뮬레이션할 색맹 유형('적색맹', '녹색맹' 또는 '청색맹')outputPath(선택 사항): 스크린샷 출력을 위한 사용자 지정 경로userAgent(선택 사항): 요청에 대한 사용자 정의 사용자 에이전트 문자열
사용 예
<use_mcp_tool>
<server_name>mcp-web-a11y</server_name>
<tool_name>simulate_colorblind</tool_name>
<arguments>
{
"url": "https://example.com",
"type": "deuteranopia",
"outputPath": "colorblind_simulation.png"
}
</arguments>
</use_mcp_tool>응답 형식
check_accessibility 응답
{
"url": "analyzed-url",
"timestamp": "ISO-timestamp",
"violations": [
{
"impact": "serious|critical|moderate|minor",
"description": "Description of the violation",
"help": "Help text explaining the issue",
"helpUrl": "URL to detailed documentation",
"nodes": [
{
"html": "HTML of the affected element",
"failureSummary": "Summary of what needs to be fixed"
}
]
}
],
"passes": 42,
"inapplicable": 45,
"incomplete": 3
}simulate_colorblind 응답
{
"url": "analyzed-url",
"type": "colorblind-type",
"outputPath": "path/to/screenshot.png",
"timestamp": "ISO-timestamp",
"message": "Screenshot saved with [type] simulation"
}오류 처리
서버에는 일반적인 시나리오에 대한 포괄적인 오류 처리 기능이 포함되어 있습니다.
네트워크 오류
잘못된 URL
시간 초과 문제
DNS 확인 문제
오류 응답에는 문제를 진단하는 데 도움이 되는 자세한 메시지가 포함됩니다.
개발
프로젝트 구조
mcp-web-a11y/
├── src/
│ └── index.ts # Main server implementation
├── build/ # Compiled JavaScript
├── output/ # Generated screenshots
├── package.json # Project dependencies and scripts
└── tsconfig.json # TypeScript configuration건물
npm run build이렇게 하면:
TypeScript를 JavaScript로 컴파일
출력 파일을 실행 가능하게 만들기
컴파일된 파일을
build디렉토리에 넣으세요
디버깅
서버에는 콘솔 출력에서 확인할 수 있는 자세한 디버그 로깅이 포함되어 있습니다. 여기에는 다음이 포함됩니다.
네트워크 요청 및 응답
페이지 로딩 상태
선택기 대기 상태
분석된 페이지의 모든 콘솔 메시지
색상 시뮬레이션 진행
일반적인 문제 및 솔루션
시간 초과 오류
코드에서 타임아웃 값을 늘리세요
네트워크 연결 확인
URL에 접근 가능한지 확인하세요
DNS 확인 오류
URL이 올바른지 확인하세요
네트워크 연결 확인
www 하위 도메인을 사용해 보세요
선택기를 찾을 수 없습니다
선택기가 페이지에 있는지 확인하세요
동적 콘텐츠가 로드될 때까지 기다리세요
올바른 선택기의 페이지 소스를 확인하세요
색상 시뮬레이션 문제
페이지의 색상이 지원되는 형식(RGB, RGBA 또는 HEX)으로 지정되었는지 확인하세요.
페이지에서 동적 색상 변경을 사용하는지 확인하세요(추가 대기 시간이 필요할 수 있음)
스크린샷 출력 디렉토리가 존재하고 쓰기 가능한지 확인하세요.
기여하다
저장소를 포크하세요
기능 브랜치 생성
변경 사항을 커밋하세요
지점으로 밀어 넣기
풀 리퀘스트 만들기
특허
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여되었습니다. 자세한 내용은 라이선스 파일을 참조하세요.
Available Tools
2 toolscheck_accessibilityC
Check web accessibility of a given URL using axe-core
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to analyze | |
| waitForSelector | No | Optional CSS selector to wait for before analysis | |
| userAgent | No | Optional user agent string to use for the request |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: it doesn't mention whether this is a read-only analysis, what the output format might be, potential rate limits, authentication requirements, or error conditions. For a tool that performs web analysis, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a tool with a clear, focused function and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations and no output schema, the description should provide more complete context for this accessibility checking tool. It doesn't explain what kind of results to expect, what accessibility standards are checked, whether the analysis is comprehensive or limited, or how the tool handles dynamic content. For a tool with 3 parameters and no structured output documentation, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so all parameters are documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('web accessibility of a given URL'), and mentions the technology used ('axe-core'). However, it doesn't explicitly differentiate from its sibling tool 'simulate_colorblind', which appears to be a related but distinct accessibility function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 its sibling 'simulate_colorblind' or other alternatives. It doesn't mention prerequisites, typical use cases, or exclusions, leaving the agent with no contextual usage information beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
simulate_colorblindC
Simulate how a webpage looks for colorblind users
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture | |
| type | Yes | Type of color blindness to simulate | |
| outputPath | No | Optional path to save the screenshot | |
| userAgent | No | Optional user agent string to use for the request |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool simulates colorblind views but doesn't describe how (e.g., generates a screenshot, modifies display, or returns data), what the output is (e.g., image file, visual report), or any behavioral traits like performance, rate limits, or side effects. This leaves significant gaps for an agent to understand the tool's operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Simulate how a webpage looks for colorblind users.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence earns its place by conveying essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output (e.g., what is returned or saved), behavioral context (e.g., how simulation works, any limitations), and usage guidelines. While the schema covers parameters well, the description doesn't compensate for missing annotations or output schema, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all four parameters (url, type, outputPath, userAgent) with details like enum values for 'type.' The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining the simulation process or output format. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Simulate how a webpage looks for colorblind users.' It specifies the action (simulate) and resource (webpage appearance for colorblind users), making it easy to understand. However, it doesn't explicitly differentiate from its sibling tool 'check_accessibility,' which might also involve accessibility testing, though the focus here is specifically on colorblind simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 doesn't mention the sibling tool 'check_accessibility' or any other tools, nor does it specify prerequisites, contexts, or exclusions. Usage is implied from the purpose but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- First observed
check_accessibility - First observed
simulate_colorblind
TDQS
B3.1/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one checks general web accessibility using axe-core, while the other specifically simulates colorblindness effects on a webpage. There is no overlap or ambiguity between them.
Naming Consistency5/5
Both tools follow a consistent verb_noun pattern (check_accessibility, simulate_colorblind) with clear, descriptive names. The naming style is uniform and predictable throughout the set.
Tool Count2/5
With only two tools, the server feels thin for a web accessibility domain. While the tools are useful, typical accessibility testing involves more operations like checking screen reader compatibility, keyboard navigation, or ARIA attributes, suggesting notable gaps in coverage.
Completeness2/5
The tool set is severely incomplete for web accessibility. It lacks core operations such as validating HTML structure, testing screen reader output, assessing keyboard accessibility, or generating accessibility reports, which are essential for comprehensive accessibility evaluation.
Maintenance
ActivityInactive
ResponsivenessNo issues
Related MCP Connectors
Deterministic axe-core accessibility scans (WCAG 2.1 AA, EN 301 549, PDF/UA) via your account.
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.
Accessibility and WCAG data for your own websites: fix lists, live checks, and fix validation.
Related MCP Servers
- AlicenseBqualityDmaintenanceProvides accessibility testing capabilities through CLI, helping identify accessibility issues in web applications using axe-core and Puppeteer.12MIT
- FlicenseBqualityDmaintenanceEnables AI agents to perform comprehensive accessibility audits on websites using Playwright and axe-core against WCAG standards. Provides detailed compliance reports with violation summaries and remediation guidance across multiple browsers.3-
- FlicenseNot gradedqualityDmaintenancePerforms automated web accessibility audits following WCAG standards using axe-core and Puppeteer, generating detailed reports in Spanish with recommended solutions and code examples.-