Measuring Ourselves GitHub’s Accessibility Scorecard
summary
GitHub builds an accessibility scorecard (rolled into Fundamentals in fall 2022 after a six‑month effort) that scores services on audit progress, static analysis, and dynamic analysis. It uses the service catalog, SLAs, GitHub issue labels (severity 1–4 with timelines like 35 days for sev‑1), lint rule parsing across repos, and Playwright + axe scans via an internal test framework. Early results: axe mentions up 11×, audit issue engagement +23%, and monthly closures +14%.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 0:49Barriers to Accessibility
- 2:55Accessibility Scorecard
- 4:42Accessibility Scorecard Objectives
- 5:39Audit Progress
- 10:21Introduce Accessibility
- 14:03Dynamic Analysis
- 17:21Early Results
- 19:21Thank you
- 19:43What did it take to get accessibility added to your fundamentals
- 20:56How did you define severity
- 22:21How did you identify nondescriptive link text
- 23:51How did you handle false positives
- 25:42Recommendations for HTML winter
- 27:21Severity setting for noncritical issues
- 28:21Wrap up
- 29:23Native apps
- 30:56Testing
- 32:46Audits
- 34:13Severity
- 35:34Learning
- 36:50Audit Issues
- 38:01User Feedback
- 38:43Accessibility Prior to GitHub
- 40:48Accessibility Audit Frequency
related talks
43mHow to make your application accessible (and keep it that way!)
05mGitHub Accessibility Scanner
11mOpen Source Accessibility
43mHow to make your application accessible (and keep it that way!)
45mAccessible by default
33mHow to make your application accessible (and keep it that way!)
19mAutomated Techniques for Measuring Trustworthiness of Open Source Code and Communities
43mHow to Use AI to Build Accessible Products