Case study: V/Line component system

I am the sole frontend specialist on the rebuild of the V/Line website in Kentico Xperience. I built a library of 45+ components and multiple page templates, all to WCAG 2.2 AA. The site is not public yet, so this case study has no screenshots or code, but I am happy to walk through it in person.

The challenge

The system had to work for three groups at once. Users needed accessible, consistent pages. Backend developers needed to implement components in the CMS without guessing how they should behave. Content editors needed building blocks they could rely on.

An automated table of contents

The business needed a table of contents for long pages, but there was no design for it. I gathered the requirements with stakeholders, then designed a solution that kept the backend work small. The backend developers created one simple template, and my JavaScript does the rest:

  1. An editor publishes a page with h2 headings.
  2. The script finds each h2 and gives it an id.
  3. It builds a linked table of contents at the top of the page, inside a nav landmark, so screen reader users can find and use it.

Editors get a table of contents on every long page with no extra work.

Handing off to backend developers

Every component has a contract: its props, variants, states and the data it expects. I documented each one in Pattern Lab, so the flow works like this:

  1. Figma design
  2. Component built and documented in Pattern Lab
  3. Contract defined: props, variants, states, data
  4. Assets compiled for the CMS
  5. Collaborate with Backend developers on Razor(.cshtml) implementation in Kentico

This meant the backend team could build pages without coming back to me to ask how a component should behave.

Complex patterns

Beyond the foundations (buttons, inputs, typography), I built navigation with search and typeahead, a media playlist that announces changes to screen readers, a keyboard-operable carousel with no autoplay, and a shared dialog pattern used by a status-driven Traffic Light Tool.

Accessibility

I automated accessibility testing with axe and BrowserStack, and worked with testers on audits. Results went back into the component documentation so the standard stayed consistent. Where the usual approach fell short, I went through the specs to find an accessible solution for the edge case.

Working with the team

Agile ceremonies including frontend estimation, story planning and technical spikes, and collaborating and mentoring other developers, BAs and content editors on using the system.

What I learned

The table of contents changed how I judge a solution. I now ask what it will cost to maintain, as well as what it will cost to build.

The obvious option was two widgets: one for the links and one for each section. Editors would have had to add both to the page, give them matching unique ids, and repeat that for every section without creating duplicates. That is ongoing work for editors and ongoing maintenance for developers. The template approach removes all of it. Editors assign the template and write their h2 headings, and everything else is handled.

I apply the same thinking to third-party libraries. Before adding a package, I check whether the platform can already do the job. Fewer moving parts means less rework later.

Stack: Kentico Xperience, Pattern Lab, Handlebars, Tailwind CSS, Alpine.js, Vite, axe, BrowserStack, Figma