Open
Description
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, 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
- Some AAA-level success criteria where relevant
- Possibly some elements of ATAG 2.0 – 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
- Account creation
- Listing: View tickets
- Wiki: TracTickets
- Form: New ticket
Reporting
I’m planning to use a similar format to my djangoproject.com accessibility audit, with a single GitHub issue arranged in sections, and an accompanying video. This will be focused on reporting the problems as they appear, rather than proposing solutions.
Testing methodology
Automated tasks:
- Accessibility Insights
- Pa11y
Manual tasks:
- Screenshot-taking & visual review for tab order
- Manual keyboard navigation testing
- Manual touch navigation testing
- Manual 400% zoom testing
- Desktop screen readers: VoiceOver macOS
- Speech recognition: Voice Control
- Magnification with Apple Zoom
- Windows contrast themes
Audit planning
- Validate requirements & decide on approach
- Confirm availability of relevant stakeholders / auditors
- Audit
- Report
- (Backlog curation)
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Todo