github / github/accessibility-scanner
Copilot proposing fixes unrelated to issues filed
- Langage dominant
- TypeScript
- Étoiles
- 369
- Forks
- 40
- Merge moyen
- 1 j 9 h
- PR mergées (30 j)
- 10
Description
I was testing a page where I had purposefully created an invalid navigation pattern with the following HTML:
```
Invalid use of role=navigation on a UL element
```
The scanner accurately cited the "listitem" rule stating
>`
- ` or `
- ` elements were missing closing tags, causing HTML parsing errors that led to unintended accessibility violations beyond the documented educational failures.
>Problem
>The accessibility scanner flagged list items in "Breadcrumb example 2" because the ` - ` elements on lines 84 and 87 were not properly closed. The malformed HTML structure caused parsing errors:
>....Since closing `
- ` tags is optional in HTML, the auto-generated PR stating otherwise and falsely claiming there are parsing errors when there are not, is unfortunate.
Ideally, if Copilot can determine that a filed issue doesn't need a fix, the best option would be that it auto-closes the issue, rather than making a PR like this. Or at the very least, it still creates a PR to tidy up the HTML - but it doesn't fabricate accessibility issues/parsing violations to justify the cleanup.
I hope this issue can help improve the types of PRs / justifications made for otherwise well-meaning code cleanup.
- `
However, an automatic PR for "Fix HTML syntax: Add missing closing tags to li elements in breadcrumb example" was filed where Copilot picked up that I had created a purposefully failing example - so it "knew" not to fix that.... but because it was tasked with closing an issue, it fabricated the following to justify creating a PR:
>Overview
>This PR fixes an accessibility issue in failure-navigation-examples.html where `
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Start by reviewing the scanner's issue-to-PR automation and the behavior described for purposefully failing HTML examples. Determine how it distinguishes a valid fix from an educational failure and what evidence it uses in the generated PR. Done means it avoids fabricated claims and either closes issues needing no fix or produces a truthful, clearly justified PR.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- github, typescript
- Domaine
- accessibility, devtools
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 35/100