# 접근성 감사자

포괄적인 웹 접근성 테스트 및 규정 준수에 대한 지침입니다.

> \[!NOTE]
>
> * 이 라이브러리의 예시는 영감을 얻기 위한 것입니다. 프로젝트, 언어, 팀 프로세스에 더 구체적으로 맞게 조정하는 것이 좋습니다.
> * 특정 언어 및 시나리오에 대한 사용자 지정 지침의 커뮤니티 기여 예시는 [우수한 GitHub Copilot 사용자 지정](https://github.com/github/awesome-copilot/blob/main/docs/README.instructions.md) 리포지토리를 참조하세요.
> * 사용자 지정 지침을 만드는 플랫폼 또는 IDE에 따라 다양한 범위에서 사용자 지정 지침을 적용할 수 있습니다. 자세한 내용은 "[GitHub Copilot 응답을 사용자 지정하는 방법에 대한 정보](/ko/copilot/concepts/prompting/response-customization)"을(를) 참조하세요.

다음 예제에서는 리포지토리의 HTML 파일에만 적용되는 경로별 `accessibility.instructions.md` 파일과 WCAG 지침을 따르는 액세스 가능한 포괄 HTML을 생성하는 지침을 GitHub Copilot 보여 줍니다. 경로 지정 지침 파일에 대한 자세한 내용은 [GitHub Copilot 대한 리포지토리 사용자 지정 지침 추가](/ko/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions#creating-path-specific-custom-instructions)을(를) 참조하세요.

````text copy
---
applyTo: **/*.html
---

When generating code, ensure accessibility compliance by following these priorities:

## Semantic HTML First
- Use proper semantic elements: `<nav>`, `<main>`, `<section>`, `<article>`, `<header>`, `<footer>`
- Structure headings sequentially (h1 → h2 → h3, never skip levels)
- Use one `<h1>` per page with descriptive heading text

## Essential ARIA Requirements
- Add `alt` text to all images
- Label form inputs with `<label>` or `aria-label`
- Ensure interactive elements have accessible names
- Use `aria-expanded` for collapsible content
- Add `role`, `aria-labelledby`, and `aria-describedby` when semantic HTML isn't sufficient

## Keyboard Navigation
- All interactive elements must be keyboard accessible
- Provide visible focus indicators (minimum 2px outline)
- Include skip links: `<a href="#main">Skip to main content</a>`
- Use logical tab order that matches visual layout

## Color and Contrast
- Ensure 4.5:1 contrast ratio for normal text, 3:1 for large text
- Don't rely solely on color to convey information

## Quick Test Questions
- Can you navigate the entire interface using only Tab/Shift+Tab/Enter?
- Are all images and icons properly described?
- Can screen reader users understand the content and functionality?

## Screen Reader Compatibility

**Provide descriptive text for all non-text content:**
- Images: Use alt text that describes function, not just appearance
  - Good: `alt="Submit form"`
  - Avoid: `alt="Blue button"`
- Form inputs: Associate every input with a `<label>` element
- Links: Use descriptive link text
  - Good: "Download the accessibility report (PDF, 2MB)"
  - Avoid: "Click here" or "Read more"

**Announce dynamic content updates:**
- Use `aria-live="polite"` for status updates
- Use `aria-live="assertive"` for urgent notifications
- Update screen reader users when content changes without page reload

---

## Color and Contrast Requirements

**Meet these specific contrast ratios:**
- Normal text (under 18pt): Minimum 4.5:1 contrast ratio
- Large text (18pt+ or 14pt+ bold): Minimum 3:1 contrast ratio
- UI components and graphics: Minimum 3:1 contrast ratio

**Provide multiple visual cues:**
- Use color + icon + text for status indicators
- Add patterns or textures to distinguish chart elements
- Include text labels on graphs and data visualizations

---

## Testing Integration Steps

**Include these automated checks:**
1. Run axe-core accessibility scanner in CI/CD pipeline
2. Test with lighthouse accessibility audit
3. Validate HTML markup for semantic correctness

**Perform these manual tests:**
1. Navigate entire interface using only Tab and arrow keys
2. Test with screen reader (NVDA on Windows, VoiceOver on Mac)
3. Verify 200% zoom doesn't break layout or hide content
4. Check color contrast with tools like WebAIM Color Contrast Checker

---

## Form Design Standards

**Create accessible form experiences:**
- Place labels above or to the left of form fields
- Group related fields with `<fieldset>` and `<legend>`
- Display validation errors immediately after the field with `aria-describedby`
- Use `aria-required="true"` for required fields
- Provide clear instructions before users start filling out forms

**Error message format:**
```html
<input aria-describedby="email-error" aria-invalid="true">
<div id="email-error">Please enter a valid email address</div>
```

---

**Code Generation Rule:** Always include accessibility comments explaining ARIA attributes and semantic choices. Test code with keyboard navigation before suggesting it's complete.

````

## 추가 참고 자료

* [GitHub Copilot 응답을 사용자 지정하는 방법에 대한 정보](/ko/copilot/concepts/prompting/response-customization) - GitHub Copilot의 응답 사용자 지정 개요
* [에 대한 사용자 지정 지침 추가 Copilot](/ko/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions) - 사용자 지정 지침을 구성하는 방법
* [멋진 GitHub Copilot 사용자 지정](https://github.com/github/awesome-copilot/blob/main/README.md) - 특정 언어 및 시나리오의 커뮤니티 기여 사용자 지정 지침 및 기타 사용자 지정 리포지토리