원클릭으로 Manus에서 모든 스킬 실행

시작하기

website-accessibility-check

스타167

포크11

업데이트2026년 3월 11일 21:54

Run a focused accessibility pass for website changes (WCAG 2.1 AA-oriented).

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

oocx

oocx/tfplan2md

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Skill Instructions

Purpose

Provide a focused, repeatable accessibility checklist for changes to Eleventy-authored website pages and shared UI building blocks.

Hard Rules

Must

For any changed page/component, confirm semantic structure and a sensible heading hierarchy.
Ensure interactive elements are keyboard reachable and have visible focus.
Ensure images/icons that convey meaning have appropriate alt text (decorative images should not add noise).
Ensure links have descriptive text (avoid “click here”).
For any forms/inputs, ensure there are labels (or equivalent accessible names).
Run scripts/website-verify.sh --all and fix failures before claiming done.
When shared authored sources change (_includes, _data, styles, site-assets, or examples), validate at least one representative consuming page in the rendered website/dist/ output.

Must Not

Do not claim “done” if basic keyboard navigation is broken.
Do not introduce new UI patterns without considering accessibility impact.

Quick Checklist (per changed page)

Structure: one clear h1, no heading level jumps where avoidable
Landmarks: use semantic elements (header, nav, main, footer) where appropriate
Keyboard: tab order is logical; focus is visible; no traps
Images: meaningful images have alt; decorative images don’t distract screen readers
Links: text is descriptive and unique enough in context
Color/contrast: avoid low-contrast text and “color-only” meaning

Suggested Workflow (VS Code)

Open the changed page via the VS Code preview server (http://127.0.0.1:3000/website/dist/), then use the browser/* tools or the website-devtools skill to inspect DOM, focus order, and console state.
Use keyboard only (Tab/Shift+Tab/Enter/Space) to navigate key flows.
Spot-check headings and landmark structure in the DOM.
If shared components or layouts changed, repeat the checks on multiple pages that use them.
If available, use the website-devtools skill to validate focus states, responsive behavior, and console errors.

이 저장소의 다른 Skills

같은 저장소

pre-pr-checklist

oocx/tfplan2md

Minimum-requirements checklist for any change — code or docs-only. Run this before every PR creation or push to avoid CI failures on the first attempt.

2026-05-20167

generate-release-screenshots

oocx/tfplan2md

Generate PNG screenshots for release notes using the repository's HtmlRenderer and ScreenshotGenerator tools. Use when asked to add screenshots to release notes or documentation.

2026-05-16167

next-issue-number

oocx/tfplan2md

Determine the next available issue number across all change types (feature, fix, workflow) by checking both local docs and remote branches, then reserve it by pushing an empty branch.

2026-03-17167

update-workflow-diagram

oocx/tfplan2md

Convert the mermaid diagram in docs/agents.md to a blueprint-styled SVG for the website. Use when the workflow diagram in agents.md is updated and needs to be reflected on the website.

2026-03-11167

website-create-examples

oocx/tfplan2md

Create and update interactive examples for the Eleventy website using page entrypoints and src/examples fragments.

2026-03-11167

website-devtools

oocx/tfplan2md

Use browser tools to inspect rendering and troubleshoot website issues with the Maintainer.

2026-03-11167

Skill Instructions

Purpose

Provide a focused, repeatable accessibility checklist for changes to Eleventy-authored website pages and shared UI building blocks.

Hard Rules

Must

For any changed page/component, confirm semantic structure and a sensible heading hierarchy.

Ensure interactive elements are keyboard reachable and have visible focus.

Ensure images/icons that convey meaning have appropriate alt text (decorative images should not add noise).

Ensure links have descriptive text (avoid “click here”).

For any forms/inputs, ensure there are labels (or equivalent accessible names).

Run scripts/website-verify.sh --all and fix failures before claiming done.

When shared authored sources change (_includes, _data, styles, site-assets, or examples), validate at least one representative consuming page in the rendered website/dist/ output.

Must Not

Do not claim “done” if basic keyboard navigation is broken.

Do not introduce new UI patterns without considering accessibility impact.

Quick Checklist (per changed page)

Structure: one clear h1, no heading level jumps where avoidable

Landmarks: use semantic elements (header, nav, main, footer) where appropriate

Keyboard: tab order is logical; focus is visible; no traps

Images: meaningful images have alt; decorative images don’t distract screen readers

Links: text is descriptive and unique enough in context

Color/contrast: avoid low-contrast text and “color-only” meaning

Suggested Workflow (VS Code)

Open the changed page via the VS Code preview server (http://127.0.0.1:3000/website/dist/), then use the browser/* tools or the website-devtools skill to inspect DOM, focus order, and console state.

Use keyboard only (Tab/Shift+Tab/Enter/Space) to navigate key flows.

Spot-check headings and landmark structure in the DOM.

If shared components or layouts changed, repeat the checks on multiple pages that use them.

If available, use the website-devtools skill to validate focus states, responsive behavior, and console errors.

name	website-accessibility-check
description	Run a focused accessibility pass for website changes (WCAG 2.1 AA-oriented).