No es un checkbox. Es la lente con la que leo cada componente: qué anuncia un screen reader, qué pasa sin color, qué pasa solo con teclado. Lo demuestro con código mergeable en los repos más exigentes del ecosistema.
11 de agosto de 2026. Cada PR revisado contra la API de GitHub, no de memoria.
Más allá de los tres repos detallados arriba, contribuciones de accesibilidad mergeables en todo el ecosistema open source.
No es "agregar atributos". Es un proceso con criterio técnico y validación empírica.
En astryx #4298 el problema no era "falta un label" — era que el status perdía significado para screen readers al componerse (parent-reads-child, issue #4777).
WCAG 2.1 SC 1.4.1 (use of color), 1.4.11 (non-text contrast), 2.1.1 (keyboard). Cada fix cita su criterio.
Prop explícita > default por variante > none. Nunca romper la semántica del sistema (lección del PR #4703: filled ≠ selected).
Tests de locale override, tests de keyboard nav, verificación con screen readers (VoiceOver/NVDA) cuando el fix lo amerita.
Changesets, i18n catalog, comentarios que explican la decisión, no solo el cambio.
Código real, revisado por maintainers reales, en repos que usan millones de personas. No es un curso ni un proyecto propio — es contribución a los estándares del ecosistema.
Estos PRs están mergeables, no mergeados — esperando review de maintainers. Y eso es exactamente el punto: el trabajo está hecho, validado técnicamente, y a un review de distancia de estar en producción.
El 11 de agosto de 2026, un PR en el design system de Facebook quedó aprobado por code-owner y otro (fix de CI) quedó mergeable — los más cerca que estuve de un merge en un repo de esa escala.
Fullstack React/TS · Especialista en accesibilidad · Buscando rol donde la accesibilidad sea central