Accessibility review of code.djangoproject.com

Just opening this early to plan for a mini accessibility audit of Trac as set up for Django.

## Context

This is in the context of [discussions on migrating away from Trac](https://forum.djangoproject.com/t/discuss-migrating-off-of-trac-onto-something-else/36253), though the audit findings will be very useful if we stayed on Trac too, as far as knowing what to fix and how we might want to adjust our contribution tools in the meantime.

## Audit requirements

### Standards

- [WCAG 2.2 AA](https://www.w3.org/TR/WCAG22/)
- Some AAA-level success criteria where relevant
- Some elements of [ATAG 2.0](https://www.w3.org/WAI/standards-guidelines/atag/) – for example reviewing whether it’s possible to create accessible content in Trac comments.

### Scope

Picked 5 pages to cover a good breadth of the Trac UI and represent a common contributor journey

- [Trac home](https://code.djangoproject.com/)
- Account creation
- GitHub login
- Listing: [View tickets](https://code.djangoproject.com/query)
- Wiki: [TracTickets](https://code.djangoproject.com/wiki/TracTickets)
- Form: [New ticket](https://code.djangoproject.com/newticket)

### Reporting

- Format similar to [djangoproject.com accessibility audit](https://github.com/django/djangoproject.com/issues/1381), with a single GitHub issue arranged in sections
- Accompanying video.
- [ATAG report tool](https://www.w3.org/WAI/atag/report-tool/)

### Testing methodology

Automated tasks:

- Accessibility Insights

Manual tasks:

- Screenshot-taking & visual review for tab order
- Manual keyboard navigation testing
- Manual 400% zoom testing
- Desktop screen readers: VoiceOver macOS
- Speech recognition: Voice Control
- Windows contrast themes

## Audit planning

- [x] Validate requirements & decide on approach
- [x] Confirm availability of relevant stakeholders / auditors
- [ ] Audit
- [ ] Report
- [ ] (Backlog curation)