Observação
- Os exemplos nesta biblioteca são para servir de inspiração. Ajuste-os para serem mais específicos para seus projetos, linguagens e processos de equipe.
- Para exemplos de instruções personalizadas com contribuição da comunidade para linguagens e cenários específicos, confira o repositório de Personalizações Incríveis do GitHub Copilot.
- Você pode aplicar instruções personalizadas em diferentes escopos, dependendo da plataforma ou do IDE em que você está criando. Para obter mais informações, confira "Sobre como personalizar as respostas do GitHub Copilot Chat".
O exemplo a seguir mostra um arquivo accessibility.instructions.md
específico de caminho que se aplica somente a arquivos HTML em seu repositório e orienta o GitHub Copilot a gerar HTML acessível e inclusivo que siga as diretrizes WCAG. Para obter mais informações sobre arquivos de instruções específicas do caminho, consulte Como adicionar instruções personalizadas de repositório no GitHub Copilot.
--- 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.
---
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.
Leitura adicional
- Sobre como personalizar as respostas do GitHub Copilot Chat – Visão geral da personalização de resposta no GitHub Copilot
- Configurar instruções personalizadas no GitHub Copilot: como configurar instruções personalizadas
- Personalizações incríveis do GitHub Copilot – repositório de instruções personalizadas com a contribuição da comunidade e outras personalizações para linguagens e cenários específicos