
New York Times
Making Accessibility a habit, Not a Checklist
As Accessibility Lead for my team at The New York Times, I led a company-wide initiative, running workshops, conducting audits, and helping build a culture of accessibility and inclusive design.
ROLE
Accessibility Lead
TEAM
Live Storytelling
SKILLS
Workshops
Audits
Facilitation
Inclusive Design Squad
TIMELINE
10 months
OVERVIEW
Leading Accessibility at The New York Times
Being appointed Accessibility Lead as a Product Design Intern meant taking ownership of something that most interns don't touch: organizational culture change.
My job wasn't just to audit components; it was to build the knowledge, processes, and materials that would make accessibility a default part of how the Live News team and the broader company designed, long after I left.
REACH
4+
Seniority level taught, from product design interns to principal designers
STANDARD
WCAG
Compliance ensured across existing and launching features
INITIATIVES
3
Initiatives ran in parallel; workshops, audits, and the Inclusive Design Squad
WORKSHOPS
Helping designers identify accessibility gaps in their own work
The workshops were hands-on: not just "what is accessibility" but "how do you check your own work right now." The goal was to help designers develop an intuition for accessibility, not just a checklist to run before shipping.

Workshop where we prioritized which accessibility concerns to tackle first.
📚
Assessing your own work
Training designers to check contrast, touch targets, focus order, and legibility directly in Figma.
🛠️
Building the habit
The goal wasn’t compliance, it was fluency. Accessibility became embedded in designers’ workflows.
AUDIT
Every feature audited, existing and launching
Audits weren't just documentation; they were a gate. I worked with cross-functional teams to ensure that accessibility was reviewed before any new feature shipped, reducing legal risk and improving the experience for all users.

Screenshots from previous audits across existing and launching features at the Times.
🚀
Evaluating Pre-launch
New features were evaluated before launch, not after. Accessibility became a requirement, not an afterthought.
⚖️
Legal Risk Mitigation
Accessibility isn’t just ethical, it’s a legal requirement. The audits I led reduced the company's exposure.
🤝
Auditing across teams
My impact extended beyond Live News. I was auditing products across teams to ensure compliance.
📑
Documentation for future designers
Findings were added to the shared handbook, so designers could build on past decisions.
INCLUSIVE DESIGN SQUAD
Building accessibility culture, beyond my own team
The Inclusive Design Squad is a small team of designers committed to building shared knowledge, resources, and practices around accessibility. As an active member, my work extended beyond my immediate team into the broader design organization.

The Accessibility Handbook lived in Notion where anyone could access and review it.
📖
Best Practice Handbook
Created shared documentation giving any NYT designer a clear reference for accessibility.
🕐
Accessibility Office Hours
Held open sessions where designers could get real-time feedback.
🌐
Team onboarding
Introduced teams to inclusive design thinking, shifting from compliance to better design.
IMPACT
The work that outlasts the internship
The impact of this work isn’t measured in any single audit or workshop. It’s in the features that shipped accessibly, the designers who now think inclusively by default, and the infrastructure that will continue to shape how The New York Times designs long after I’ve left.
LASTING CHANGE
Culture Shift
The biggest outcome was behavioral: designers started proactively raising accessibility questions during design reviews, rather than waiting to be audited.
LEGAL RISK REDUCTION
Risk
WCAG compliance reduces legal exposure and demonstrates commitment to inclusive design.
INSTITUTIONAL KNOWLEDGE
Handbook
Handbooks and design system standards that outlast the internship are the most scalable form of design impact.
TAKEAWAYS
What leading accessibility work actually taught me
01
Accessibility is a systems issue, not a checklist
Accessible components alone don’t make an accessible product. How elements combine, the order they’re read by a screen reader, contrast on dynamic backgrounds; these are systems-level concerns. Accessibility must be built into the architecture, not added afterward.
02
Culture change requires more than one person
The most lasting impact was shared language. When designers naturally flagged issues or added accessibility notes, that signaled a shift. Individual practice scales slowly; culture scales fast.
