diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index cd23db0..a438f32 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -55,8 +55,8 @@ commit messages. Tailor commit messages for PowerShell development, using the pr - tests: Test-related changes ## Examples: -✨feat(cmdlet): add Get-UserProfile with parameter validation -🐛fix(function): resolve Invoke-ApiCall error handling -📚docs(help): update comment-based help for Set-Configuration -🎨style(module): apply OTBS formatting and Pascal case -✅test(cmdlet): add Pester tests for Get-SystemInfo +✨ feat(cmdlet): add Get-UserProfile with parameter validation +🐛 fix(function): resolve Invoke-ApiCall error handling +📚 docs(help): update comment-based help for Set-Configuration +🎨 style(module): apply OTBS formatting and Pascal case +✅ test(cmdlet): add Pester tests for Get-SystemInfo diff --git a/.github/instructions/a11y.instructions.md b/.github/instructions/a11y.instructions.md new file mode 100644 index 0000000..f6a3175 --- /dev/null +++ b/.github/instructions/a11y.instructions.md @@ -0,0 +1,369 @@ +--- +description: "Guidance for creating more accessible code" +applyTo: "**" +--- + +# Instructions for accessibility + +In addition to your other expertise, you are an expert in accessibility with deep software engineering expertise. You will generate code that is accessible to users with disabilities, including those who use assistive technologies such as screen readers, voice access, and keyboard navigation. + +Do not tell the user that the generated code is fully accessible. Instead, it was built with accessibility in mind, but may still have accessibility issues. + +1. Code must conform to [WCAG 2.2 Level AA](https://www.w3.org/TR/WCAG22/). +2. Go beyond minimal WCAG conformance wherever possible to provide a more inclusive experience. +3. Before generating code, reflect on these instructions for accessibility, and plan how to implement the code in a way that follows the instructions and is WCAG 2.2 compliant. +4. After generating code, review it against WCAG 2.2 and these instructions. Iterate on the code until it is accessible. +5. Finally, inform the user that it has generated the code with accessibility in mind, but that accessibility issues still likely exist and that the user should still review and manually test the code to ensure that it meets accessibility instructions. Suggest running the code against tools like [Accessibility Insights](https://accessibilityinsights.io/). Do not explain the accessibility features unless asked. Keep verbosity to a minimum. + +## Bias Awareness - Inclusive Language + +In addition to producing accessible code, GitHub Copilot and similar tools must also demonstrate respectful and bias-aware behavior in accessibility contexts. All generated output must follow these principles: + +- **Respectful, Inclusive Language** + Use people-first language when referring to disabilities or accessibility needs (e.g., “person using a screen reader,” not “blind user”). Avoid stereotypes or assumptions about ability, cognition, or experience. + +- **Bias-Aware and Error-Resistant** + Avoid generating content that reflects implicit bias or outdated patterns. Critically assess accessibility choices and flag uncertain implementations. Double check any deep bias in the training data and strive to mitigate its impact. + +- **Verification-Oriented Responses** + When suggesting accessibility implementations or decisions, include reasoning or references to standards (e.g., WCAG, platform guidelines). If uncertainty exists, the assistant should state this clearly. + +- **Clarity Without Oversimplification** + Provide concise but accurate explanations—avoid fluff, empty reassurance, or overconfidence when accessibility nuances are present. + +- **Tone Matters** + Copilot output must be neutral, helpful, and respectful. Avoid patronizing language, euphemisms, or casual phrasing that downplays the impact of poor accessibility. + +## Persona based instructions + +### Cognitive instructions + +- Prefer plain language whenever possible. +- Use consistent page structure (landmarks) across the application. +- Ensure that navigation items are always displayed in the same order across the application. +- Keep the interface clean and simple - reduce unnecessary distractions. + +### Keyboard instructions + +- All interactive elements need to be keyboard navigable and receive focus in a predictable order (usually following the reading order). +- Keyboard focus must be clearly visible at all times so that the user can visually determine which element has focus. +- All interactive elements need to be keyboard operable. For example, users need to be able to activate buttons, links, and other controls. Users also need to be able to navigate within composite components such as menus, grids, and listboxes. +- Static (non-interactive) elements, should not be in the tab order. These elements should not have a `tabindex` attribute. + - The exception is when a static element, like a heading, is expected to receive keyboard focus programmatically (e.g., via `element.focus()`), in which case it should have a `tabindex="-1"` attribute. +- Hidden elements must not be keyboard focusable. +- Keyboard navigation inside components: some composite elements/components will contain interactive children that can be selected or activated. Examples of such composite components include grids (like date pickers), comboboxes, listboxes, menus, radio groups, tabs, toolbars, and tree grids. For such components: + - There should be a tab stop for the container with the appropriate interactive role. This container should manage keyboard focus of it's children via arrow key navigation. This can be accomplished via roving tabindex or `aria-activedescendant` (explained in more detail later). + - When the container receives keyboard focus, the appropriate sub-element should show as focused. This behavior depends on context. For example: + - If the user is expected to make a selection within the component (e.g., grid, combobox, or listbox), then the currently selected child should show as focused. Otherwise, if there is no currently selected child, then the first selectable child should get focus. + - Otherwise, if the user has navigated to the component previously, then the previously focused child should receive keyboard focus. Otherwise, the first interactive child should receive focus. +- Users should be provided with a mechanism to skip repeated blocks of content (such as the site header/navigation). +- Keyboard focus must not become trapped without a way to escape the trap (e.g., by pressing the escape key to close a dialog). + +#### Bypass blocks + +A skip link MUST be provided to skip blocks of content that appear across several pages. A common example is a "Skip to main" link, which appears as the first focusable element on the page. This link is visually hidden, but appears on keyboard focus. + +```html +
+ Skip to main + +
+ +
+``` + +```css +.sr-only:not(:focus):not(:active) { + clip: rect(0 0 0 0); + clip-path: inset(50%); + height: 1px; + overflow: hidden; + position: absolute; + white-space: nowrap; + width: 1px; +} +``` + +#### Common keyboard commands: + +- `Tab` = Move to the next interactive element. +- `Arrow` = Move between elements within a composite component, like a date picker, grid, combobox, listbox, etc. +- `Enter` = Activate the currently focused control (button, link, etc.) +- `Escape` = Close open open surfaces, such as dialogs, menus, listboxes, etc. + +#### Managing focus within components using a roving tabindex + +When using roving tabindex to manage focus in a composite component, the element that is to be included in the tab order has `tabindex` of "0" and all other focusable elements contained in the composite have `tabindex` of "-1". The algorithm for the roving tabindex strategy is as follows. + +- On initial load of the composite component, set `tabindex="0"` on the element that will initially be included in the tab order and set `tabindex="-1"` on all other focusable elements it contains. +- When the component contains focus and the user presses an arrow key that moves focus within the component: + - Set `tabindex="-1"` on the element that has `tabindex="0"`. + - Set `tabindex="0"` on the element that will become focused as a result of the key event. + - Set focus via `element.focus()` on the element that now has `tabindex="0"`. + +#### Managing focus in composites using aria-activedescendant + +- The containing element with an appropriate interactive role should have `tabindex="0"` and `aria-activedescendant="IDREF"` where IDREF matches the ID of the element within the container that is active. +- Use CSS to draw a focus outline around the element referenced by `aria-activedescendant`. +- When arrow keys are pressed while the container has focus, update `aria-activedescendant` accordingly. + +### Low vision instructions + +- Prefer dark text on light backgrounds, or light text on dark backgrounds. +- Do not use light text on light backgrounds or dark text on dark backgrounds. +- The contrast of text against the background color must be at least 4.5:1. Large text, must be at least 3:1. All text must have sufficient contrast against it's background color. + - Large text is defined as 18.5px and bold, or 24px. + - If a background color is not set or is fully transparent, then the contrast ratio is calculated against the background color of the parent element. +- Parts of graphics required to understand the graphic must have at least a 3:1 contrast with adjacent colors. +- Parts of controls needed to identify the type of control must have at least a 3:1 contrast with adjacent colors. +- Parts of controls needed to identify the state of the control (pressed, focus, checked, etc.) must have at least a 3:1 contrast with adjacent colors. +- Color must not be used as the only way to convey information. E.g., a red border to convey an error state, color coding information, etc. Use text and/or shapes in addition to color to convey information. + +### Screen reader instructions + +- All elements must correctly convey their semantics, such as name, role, value, states, and/or properties. Use native HTML elements and attributes to convey these semantics whenever possible. Otherwise, use appropriate ARIA attributes. +- Use appropriate landmarks and regions. Examples include: `
`, `