F6S is a global platform that connects founders, startups, and entrepreneurs with resources and funding. With the EU Web Accessibility Directive approaching, making the platform accessible became a legal requirement.
I led the accessibility audit and redesign effort, working with engineers to prioritize fixes, address recurring issues, and introduce practices to prevent future regressions.
GOALS
Making F6S platform to be WCAG 2.2 compliant
ROLE
Product owner/designer - Accessibility audit, redesign, dev specs, creating new process and documentation
KEY RESULTS
90% of pages now pass WCAG 2.2 standard
New accessibilty handoff, design documentation, and testing process
Problem
The platform was built without accessibility in mind, and fixing it meant retrofitting.
F6S was developed before accessibility was a priority. The issues ranged from missing semantic structure to poor keyboard navigation, and some pages didn’t work on mobile at all.
Two challenges stood out:
The scale. The audit would surface hundreds of issues, possibly close to a thousand across 100+ pages. Fixing all of them wasn’t realistic with team size and timeline.
The legacy code. Every fix had to work within an existing codebase and across inconsistent browser behavior.
So the question wasn’t only what’s broken? It was:
What do we fix first, and how do we stop it from breaking again?
Audit & prioritization
I couldn’t fix everything, so I decided what mattered most.
Choosing where to start. I mapped all 100+ pages and ranked them by traffic and importance to users, so the first fixes would reach the most people.
Running the audit. I used Accessibility Insights for Web to run automated and manual tests against about 20 key checks. Automated tools miss a lot, so the manual pass mattered.
The pattern. Past a few hundred issues, I noticed many were the same bug repeating wherever a component was used. I proposed fixing at the component level instead: repair it once, and every page using it is fixed. It meant slower first results. I made that tradeoff explicit with the engineers, trading speed now for fixes that scale and stay fixed.
Matching effort to impact. Fixes ranged from small (adding ARIA attributes, landmarks, headings) to large (full redesigns). I looked for solutions that gave the best accessibility gain for the least engineering cost.
The fix
Some issues were as simple as color contrast. Others needed more than a patch.
Most issues could be fixed in place. Some couldn’t. The Pipeline page was unusable on mobile, so I redesigned it instead of layering fixes on a broken layout.
Working with engineering. I worked with front-end developers and QA throughout implementation. Legacy code and browser inconsistencies meant some fixes needed several rounds of testing, and a few needed workarounds.
Validating like a real user. Passing an audit doesn’t prove a page is usable. I tested key user flows myself using a screen reader and keyboard navigation.
Future proofing
Fixing today’s pages doesn’t help if tomorrow’s features break them again.
To keep accessibility from regressing, I changed how the team works at three points:
Annotated handoffs. Every design now goes to developers with annotated components and accessibility guidelines, so engineers don’t have to guess at behavior like focus order or labels.
New accessibility section in the design system. Accessibility guidance now lives alongside the components themselves, so designers apply it by default.
Accessibility in the QA process. I wrote accessibility checks into the testing guidelines and documented the process so anyone on the team can follow it.
Impact
90% of pages now pass, and accessibility is part of how we ship.
Beyond the numbers, F6S is better prepared for the EU Web Accessibility Directive, and the team now has the habits to keep new work accessible.
90%
of audited pages pass WCAG 2.2 standard
490+
Aria attributes specified for developers
3
new A11y practices: handoffs, design system , and QA
Reflection
What I learned
Accessibility is a prioritization problem as much as a design problem.
With hundreds of issues, the hard part wasn’t finding them but deciding which to fix, and being clear about what we weren’t fixing yet.
Passing an audit isn’t the same as being usable.
Automated and manual checks catch a lot. Using the product with a screen reader and keyboard showed me what compliance can’t.
Process outlasts heroics.
The audit fixed the past. Creating a new process for handoff, design system, and QA changes protect the future.
What’s next
Testing with real users, including people with disabilities, to confirm these solutions work in real-world conditions.