Loading...
An accessibility audit tells you what needs to change. Working out how those findings relate to the actual codebase — including where several findings depend on the same implementation change — and then making the agreed changes is separate work. This service starts from formal findings prepared by an external accessibility review provider, establishes what can reasonably be estimated, and carries out the agreed frontend work through two separately contracted services.
Accessibility review and audit work is carried out by external providers — specialist audit firms, accessibility consultancies, and review services. Sola Studio does not provide that. What tends to be missing is the step after: findings are shared, and the development team is left to identify the relevant implementation areas, understand where several findings point to the same underlying change, and account for constraints the report could not see.
That gap is where this service sits. It is split into two independently contracted services because they handle different work. Scoping Confirmation identifies the proposed implementation scope, estimated effort, constraints, dependencies, and assumptions based on the codebase as it actually is. Remediation carries out the agreed implementation work. Implementation cannot be reliably quoted before that scoping work takes place, which is why the order does not vary.
Findings come from outside. Sola Studio picks up from there.
Carried out by an external accessibility review provider — not by Sola Studio.
Formal findings from an external accessibility review provider are the required starting point. This may be an audit report or review results produced by a specialist accessibility firm, consultancy, or review service, whether commissioned by you directly or supplied through a partner. Where existing findings turn out to be insufficient for implementation scoping, additional or updated external review is needed rather than review work by Sola Studio.
Relate the external findings to the actual codebase — and receive a Remediation Estimate in Google Sheets.
The codebase, staging environment, and target components are reviewed alongside the external findings to identify the relevant implementation areas, estimate the effort involved, and confirm constraints, dependencies, assumptions, and items requiring further confirmation. Related findings may be grouped where they depend on the same component or implementation change. A Remediation Estimate is shared in Google Sheets for the portions that can reasonably be estimated at that point.
Frontend implementation of the agreed findings — forms, focus behaviour, keyboard operation, semantic HTML, ARIA, and component states.
Working from the Remediation Estimate, the agreed findings are addressed through frontend implementation within a confirmed scope. Changes are shared through the workflow that fits your development process, along with notes on what was changed, what was checked, and what remains.
What needs to be in place before starting.
Formal findings from an external review provider
An audit report or review results prepared by an external accessibility review provider. This is the entry point for the service, and it is required — Sola Studio does not carry out accessibility review, so findings are always brought in from outside.
Automated results and internal issue lists need a different starting point
Automated check output, internally compiled issue lists, developer tickets, or individual user reports cannot be used as the starting point by themselves. If formal external findings are not yet in place, arranging an external accessibility review is the step before this one.
Scoping Confirmation comes before Remediation
Remediation always follows Scoping Confirmation. Receiving a Remediation Estimate does not commit you to proceeding.
Sola Studio works on the implementation side of accessibility — relating external findings to real interface behaviour and implementation areas, establishing an estimate grounded in the codebase, and carrying the agreed changes through to working code.
Yoko Shiina
UX Consultant & Frontend Engineer
Findings read against the codebase, not just the report
A finding describes a barrier. What it takes to remove that barrier depends on component structure, state handling, library behaviour, and dependencies the report had no access to. Scoping starts from the code as it actually is.
Implementation judgment where checklists stop being useful
Error message association, focus movement, keyboard completion of a flow, whether a required or disabled state is actually conveyed — these need a decision in context, not a rule applied. Frontend implementation experience is what makes those decisions practical.
Scoping and implementation handled by the same person
What was understood while identifying implementation scope, effort, and constraints carries directly into the implementation work, without a handoff in between. Constraints noticed during scoping are already known when the agreed changes are implemented.
IAAP CPACC
Accessibility knowledge is connected to practical frontend review, remediation, and site-improvement work.
“Her keen eye for design and user experience, combined with her frontend skills, made her a key contributor to our projects.”
S.R.N., Reference Letter
“Yoko is an avid learner who surpasses every challenge she encounters. Her React skills allowed her to build highly functional, responsive apps in no time—and her attitude enriched every team she joined.”
A.L., LinkedIn & Reference Letter
Do you carry out the accessibility audit as well?
No. Accessibility review and audit work is carried out by external providers, and Sola Studio does not offer it. This service begins from formal findings prepared by an external accessibility review provider — whether you commissioned them directly or they came through a partner.
We have automated check results and an internal issue list. Is that enough to start?
Not on their own. Automated output, internally compiled issue lists, developer tickets, and individual user reports do not carry the interpretation needed as a starting point for implementation scoping. Producing that interpretation is review work. If formal external findings are not yet in place, that is the step to arrange first.
Why is Scoping Confirmation a separate paid service?
Because implementation scope cannot be estimated from findings alone. Library and framework constraints, third-party widgets, state management, and how the existing code is organised all affect what a given fix actually requires — and none of that is visible in an audit report. Assessing it takes real work on the codebase, so it is scoped, contracted, and paid for as its own service rather than absorbed into an implementation quote built on assumptions.
Can we go straight to Remediation if our findings are detailed?
No. Scoping Confirmation always comes first, with no exception for detailed findings or familiar codebases. The detail in a report describes the interface; it does not describe what the implementation will involve.
Do we have to proceed to Remediation after Scoping Confirmation?
No. The Remediation Estimate in Google Sheets is the shared output of Scoping Confirmation. Proceeding to Remediation is a separate decision with its own scope confirmation, contract, and payment. The Scoping Confirmation fee covers the scoping work and is not credited toward Remediation.
Do we need an NDA in place before sharing our audit report?
A non-disclosure agreement is required for this service. It is signed after payment, before codebase and staging access is shared. If you have questions about the process, feel free to get in touch.
Can this support EAA-related accessibility work?
It can address the practical implementation side. For EU-facing projects, EAA and EN 301 549 form part of the background context, and UK private-sector work is approached with WCAG 2.2 as the practical reference. What the service does not provide is legal advice, formal compliance determination, conformance assessment, or certification.
Is this a formal accessibility audit?
No. This is implementation-scoping and frontend remediation work with defined boundaries. It does not produce WCAG conformance declarations, EAA compliance confirmation, EN 301 549 conformity assessment, VPAT / ACR documentation, or public-sector compliance evidence. Where any of those are needed, they should be arranged with a specialist provider.
Here is a selection of projects I've worked on throughout my career.
An open-source tool for quickly checking WCAG AA / AAA contrast results across Tailwind CSS palettes, custom hex values, and foreground and background combinations. It brings color lookup and contrast checking into one lightweight interface designed around everyday frontend work.
A web app designed and developed for people preparing for interviews in a language other than their first language. Users can import their own questions and answers from a CSV file and practise them in multiple modes without creating an account or storing the content on a server. The implementation also covers keyboard interaction, motion preferences, and announcements for dynamic updates.
Share the audit or review results you already have, along with a short description of the pages, forms, or flows involved.
Nothing is payable until the fee is confirmed.
