Prompts as a Skill: Driving Accessibility Outcomes with GitHub Copilot Chat

Large Language Models (LLMs) generate varied output based on their training data. To align those results with specific, high-quality standards, developers need to guide the model through prompt engineering—the practice of structuring inputs to elicit targeted outputs. While default prompts can yield generic suggestions, carefully crafted instructions transform the tool into a specialized expert.

GitHub Copilot Chat provides a direct interface to this capability within the editor. It draws on the same contextual signals as code completion, including open files, comments, and surrounding code. But its chat interface allows for explicit, ad-hoc instructions that go well beyond what auto-completion can infer. This makes it possible to target non-functional requirements—areas where LLMs often produce plausible but technically weak output—such as accessibility.

Rather than relying on implicit behavior, you can establish a persistent, high-standard baseline for all accessibility-related responses. This empowers Copilot Chat to act not merely as a code generator, but as a knowledgeable coach that verifies its own output against recognized standards.

Establishing an Accessibility Baseline

Copy this prompt into GitHub Copilot Chat for Visual Studio Code to set a rigorous standard for accessibility discussions:

"I need to learn about accessibility and need to write code that conforms with the WCAG 2.1 level A and AA success criteria defined at https://www.w3.org/TR/WCAG21/. I want you to be my accessibility coach, a subject-matter expert that makes me think and account for all accessibility requirements and usability enhancements. When you answer questions about accessibility please use reputable sources such as w3.org, webaim.org, developer.mozilla.org, and https://www.ibm.com/able/. When possible, please provide links and references for additional learning. When you suggest code please use semantic HTML, ensure it is operable using the keyboard, follow WCAG 2.1 sufficient techniques, and follow the ARIA Authoring Practices Guide and related design patterns. Do you understand these instructions?"

This foundational prompt can be reused across projects.

What the Prompt Articulates

The prompt functions as a specification for the interaction. It is structured around five distinct principles:

  • Context — It anchors the conversation to a specific, measurable target: WCAG 2.1 Level A and AA success criteria.
  • Role Definition — It assigns a clear persona—"accessibility coach"—which sets expectations for the type and depth of feedback.
  • Source Quality — It constrains answers to authoritative references (e.g., w3.org, webaim.org, MDN), minimizing the risk of hallucinated or outdated best practices.
  • Feedback Loop — It asks for citations and links, enabling validation and further self-directed learning.
  • Code Constraints — It dictates tangible, verifiable requirements for any code generated: semantic HTML, keyboard operability, WCAG sufficient techniques, and adherence to the ARIA Authoring Practices Guide.

These guardrails work together to narrow the model’s output space from generic information to targeted, actionable guidance.

Querying for Compliance

Since prompts are conversational, you can verify that the defined scope remains intact for the duration of the session. This check-and-balance is a key part of treating Copilot Chat as a team member whose work should be reviewed rather than blindly accepted.

Query input: Are you still using the instructions I provided?

GitHub Copilot response: Yes, I am still adhering to the instructions you provided. I will continue to assist you in learning about accessibility and writing code that conforms with the WCAG 2.1 level A and AA success criteria. I will use reputable sources for references and additional learning, and ensure that the code suggestions I provide use semantic HTML, are operable using the keyboard, follow WCAG 2.1 sufficient techniques, and follow the ARIA Authoring Practices Guide and related design patterns.

Reconfirming the scope ensures the model has not lost its directive during a longer exchange. Consider your role as a lead developer asking a junior colleague to demonstrate that they have understood the task before solving the next problem. The responsibility for accuracy rests with you; the prompt is the primary tool for enforcing that standard.

Putting the Foundation Prompt to Work

Note: The following examples were tested in a brand new workspace without any source code or files to reference. Running the same prompts in an existing codebase may produce different output because GitHub Copilot can draw on context from open tabs and project files. LLM results are also non-deterministic.

Testing for accessibility issues

Query: How can I test for web accessibility?

Copilot's response outlined four complementary testing approaches:

  1. Manual testing: Navigate the site using only a keyboard, inspect color contrast, and resize text to 200% to confirm readability.
  2. Automated testing: Tools such as WAVE, Axe, and Lighthouse can catch a range of issues against established rulesets.
  3. Screen reader testing: Verify the experience with tools like NVDA, JAWS, or VoiceOver.
  4. User testing: Include people with disabilities in testing to surface practical obstacles that tools miss.

Copilot was also careful to note that no single method catches everything and pointed to references from WebAIM, Mozilla, and IBM.

HTML tables

Query: What are some best practices for creating accessible tables in HTML?

Copilot's answer emphasized using native structural elements to give screen readers the information they need:

  • Use <th> for headers and the scope attribute to indicate whether a header applies to a row or column:
<table>
<tr>
<th scope="col">Header 1</th>
<th scope="col">Header 2</th>
</tr>
<tr>
<td>Data 1</td>
<td>Data 2</td>
</tr>
</table>
  • Add a <caption> so all users get a quick overview of the table's purpose:
<table>
<caption>Overview of sales</caption>
<!-- rest of the table -->
</table>
  • Organize content with <thead>, <tbody>, and <tfoot> to group sections semantically. The suggested markup looks like this:
<table>
<thead> <!-- header group -->
<tbody> <!-- body group -->
<tfoot> <!-- footer group -->
</table>
  • Avoid complex layouts with heavy rowspan/colspan usage when possible; if necessary, expand cell content or use the title attribute for clarity.
  • Ensure the table is meaningful without CSS applied.
  • For multi-level headers, wire data cells to their headers with aria-labelledby.

Forms

Query: What are some best practices for creating accessible forms in HTML?

The generated guidance covered the fundamentals:

  • Associate every control with a corresponding <label> element so screen readers announce the input's purpose:
<label for="name">Name:</label>
<input id="name" name="name" type="text" />
  • Group related controls in a <fieldset> with a descriptive <legend>:
<fieldset>
<legend>Choose your favorite pet:</legend>
<input type="radio" id="dog" name="pet">
<label for="dog">Dog</label><br>
<input type="radio" id="cat" name="pet">
<label for="cat">Cat</label><br>
</fieldset>
  • Give clear error feedback, tying messages back to the input with aria-describedby:
<input type="text" id="name" name="name" aria-describedby="nameError">
<span id="nameError">Please enter your name.</span>
  • Pick correct input type values (email, number, date, etc.) so mobile browsers surface the appropriate keyboard.
  • Keep all controls fully operable by keyboard.
  • Add ARIA roles and properties only where the interaction model demands them.

Keyboard support

Query: What are some best practices for creating proper keyboard support in HTML?

Copilot's answer centered on keeping native behavior intact and providing obvious feedback:

  1. Logical tab order: Structure HTML to match visual reading order; avoid positive tabindex values that override the natural flow.
  2. Visible focus indication: Style the :focus state with CSS so keyboard users always know where they are:
button:focus, a:focus {
outline: 2px solid blue;
}
  1. Skip links: Add a link near the top of the page that jumps to main content, revealing itself on focus:
<a href="#maincontent">Skip to main content</a>
  1. Semantic interactive elements first: Native links, buttons, and form controls come with keyboard behavior built in.
  2. Custom widget support: For dropdowns, dialogs, and other custom components, implement key handlers for Enter, Space, Escape, and arrow keys; the WAI-ARIA Authoring Practices Guide covers the expected patterns.
  3. No keyboard traps: Confirm users can tab into and out of every part of the page.

ARIA roles

Query: What are some best practices around using proper ARIA roles in HTML?

Copilot's core advice was that ARIA is a fallback, not a first choice:

  • Prefer a plain <button> over a <div role="button">; native elements carry the required semantics and behavior automatically.
  • Don't repurpose ARIA to change what an element means, such as adding role="button" to an <a> tag.
  • When ARIA is required, pick the correct role from the spec and supply any mandatory states or properties. A checkbox, for instance, needs aria-checked:
<div role="checkbox" aria-checked="false">Check me</div>
  • Connect descriptive text to controls with aria-labelledby and aria-describedby:
<button aria-describedby="info">More Info</button>
<div id="info">Clicking this button will open more information.</div>
  • After adding ARIA, verify the result with an actual screen reader.

Assessing Copilot's Guidance

The answers were broadly sound, but several points deserve closer reading. On tables, Copilot presented <tfoot> as part of a standard structure; that element is meant to hold column-summary rows, and a table that doesn't summarize columns doesn't need one. For forms, the reply raised the importance of <label> and showed the correct for attribute wiring in its code, but never explained that the attribute value must match the input's id. The keyboard-support answer mentioned semantic elements' built-in behavior, yet stopped short of extra measures such as checking the final tab order, simulating keyboard-only workflows, or avoiding overrides of default keyboard behavior.

Any of these gaps can be closed by follow-up questions. Ask Copilot to drill deeper on a specific topic, request more external references, and then verify the cited documentation. Treat the chat output as you would code from another developer: it requires review before it becomes the basis for your work.

Boundaries of the Approach

A good foundational prompt makes GitHub Copilot Chat a more useful accessibility resource, but generated answers and code will not always meet full accessibility standards. The right frame is to act as the lead engineer reviewing suggestions from a well-informed but junior teammate. Concretely, that means verifying every recommendation, passing generated code through your normal review, security, and quality gates, and bringing in a qualified accessibility expert to test the results. The prompts are a reference material and starting point, not a substitute for expert judgment or standard QA processes.

Further Reading