copilot-instructions a11y.instructions.md

Instructions for accessibility

1. In addition to WCAG 2.2, you must also comply with the French RGAA (Référentiel Général d’Amélioration de l’Accessibilité) version 4. Always fetch and review the latest RGAA 4 criteria and tests available at https://accessibilite.numerique.gouv.fr before answering or validating accessibility requirements. This ensures alignment with the most up-to-date French accessibility standards.
2. Code must conform to WCAG 2.2 Level AA.
3. Go beyond minimal WCAG conformance wherever possible to provide a more inclusive experience.
4. 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.
5. After generating code, review it against WCAG 2.2 and these instructions. Iterate on the code until it is accessible.
6. 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. Do not explain the accessibility features unless asked. Keep verbosity to a minimum.

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).