Web Development
Front-end development, fast and accessible
Front-end development is where design becomes a real, working site, and where speed and accessibility are won or lost. We build with semantic HTML, minimal JavaScript and performance budgets, so pages load fast and every user can use them.
Who it is for: Businesses and design teams who need a build that matches the design exactly, loads quickly on mobile, and does not fall apart in six months.
Everything in this service
- Pixel-accurate builds from your designs
- Semantic HTML that crawlers and screen readers can parse
- Core Web Vitals passing on mobile as a requirement
- WCAG accessibility built in, keyboard and screen reader tested
- Clean, documented code your next developer will thank us for
What to expect
- Pages that pass Core Web Vitals on real phones
- A site every user can use, whatever their ability
- Code that stays cheap to change
How front-end development actually works
Semantic HTML: the cheapest accessibility and structure you can buy
Semantic HTML means using the element that describes what the thing is, rather than wrapping everything in generic containers and adding classes. A button element for a button, a list for a list, headings in order, landmark elements for the header, main content and footer.
It matters because meaning is what assistive technology and machine readers work from. A screen reader user can jump between headings, skip to the main content, or list every link on the page, but only if those structures exist in the markup. A generic container styled to look like a button is not focusable by keyboard, does not respond to the space bar, and is not announced as a button. Recreating all of that behaviour with extra code is possible and is almost always done incompletely. The native element gives it to you for free.
The same structure helps machines that parse pages for content. Heading hierarchy indicates what the page is about and how its sections relate. Lists and tables mark up content that is genuinely a list or a table. None of this is a ranking trick, it is simply the difference between a document with structure and a wall of boxes. It costs nothing at build time and it is expensive to retrofit, which is why we treat it as the default rather than an enhancement.
- Use the native element first, add code only when nothing fits
- Keep one main heading per page and do not skip heading levels
- Mark up header, main content, and footer as landmarks
- Never rebuild a button or a link out of generic containers
- Write form labels that are properly associated with their inputs
Progressive enhancement in practice
Progressive enhancement means the page works with HTML and CSS alone, and JavaScript improves it. The opposite approach, where nothing works until the script loads and runs, has more failure modes than people expect.
JavaScript fails for ordinary reasons: a flaky mobile connection, a request that times out, a corporate proxy that blocks a domain, a browser extension that interferes, one script error that halts everything after it. When the page depends entirely on JavaScript, any of those produces a blank screen. When the page is built up in layers, the same failure produces a plainer page that still works.
In practice this means a form that submits to a server endpoint and is then enhanced with client-side validation, links that are real links with real addresses and are then intercepted for faster transitions, and content that is present in the markup and then progressively made interactive. It is not an argument against JavaScript. It is an argument about ordering: build the thing that works, then improve it.
- Forms should submit and work before any script is involved
- Links need real addresses, not click handlers on generic elements
- Content that matters belongs in the markup, not fetched after load
- One script error should not be able to take out the whole page
- Test with slow connections and blocked third-party domains
Server-rendered content and AI crawlers: what the evidence says
Search engines and AI systems read your pages by fetching them, and what they get depends on whether they run JavaScript. Content present in the HTML response is available to everything. Content that only appears after JavaScript executes is available only to systems that execute it.
The best available evidence on the AI side comes from a large study of AI crawler traffic in late 2024. It found that the crawlers for several major AI systems, including GPTBot, ClaudeBot and PerplexityBot, fetch JavaScript files but do not execute them. We should be careful with how much weight that carries. It is one study, it has not been replicated, and the picture is not uniform: Gemini and AppleBot do render JavaScript. Crawler behaviour also changes over time without announcement. So treat it as the best evidence currently available rather than a settled fact.
Even with that caution, the practical conclusion is easy, because the cost of acting on it is close to zero. Server-render the content that matters. If your headline, your main copy, your prices and your key answers are in the raw HTML, you are covered whether a given crawler renders or not. If they are assembled in the browser, you are dependent on behaviour you cannot observe and that nobody publishes. There is no meaningful downside to server rendering, and it happens to be faster for users too.
- Put headline, main copy, prices and key answers in the raw HTML
- Check by viewing source or fetching the page with JavaScript disabled
- Client-side rendering is fine for interactive features, not for core content
- Do not hide primary content behind tabs that load their contents on click
- Static generation or server rendering is the safest default for content pages
Bundle discipline: every kilobyte is charged to the user
JavaScript is the most expensive thing on a typical page, and not only because of download size. The browser has to parse it, compile it and execute it, and on a mid-range phone that work takes far longer than the download did. A file that arrives quickly on office broadband can still block the interface for a noticeable period on the device most of your visitors are using.
The bloat usually arrives one reasonable decision at a time. A library for date formatting, another for one small animation, a component library where three components are used, an analytics tag, a chat widget, a heatmap tool. Each is justifiable alone. Together they are the reason the page takes seconds to become usable.
Discipline means setting a budget before the build, checking what actually ships, and asking of each dependency whether the problem is worth its weight. Modern platform features cover much of what libraries were once needed for. Splitting code so a page only loads what it needs, and deferring anything not required for the first view, deals with most of the rest. And third-party scripts need the hardest scrutiny, because they are outside your control, they can slow down or change without warning, and they are frequently added by marketing tools without anyone measuring the cost.
- Agree a JavaScript budget before writing code and enforce it in the build
- Audit dependencies, a small utility rarely justifies a large library
- Split code by route so pages load only what they use
- Defer anything not needed for the first meaningful view
- Review third-party tags regularly, they accumulate and nobody owns them
Testing on real devices, not just a resized browser window
A narrow browser window on a fast laptop is not a phone. It has a different processor, a different network, a different input method, and browser behaviour that differs in ways a responsive preview never shows.
Real device testing catches a specific class of problems. Touch targets that are comfortable with a mouse pointer and fiddly with a thumb. Hover states that carry information a touch user never sees. Fixed elements that behave oddly when the mobile browser bar hides and reappears. Form inputs that trigger a zoom because the font size is below the threshold. Scroll behaviour that stutters on real hardware and looks fine in a simulator. Colours and contrast in daylight rather than in a dark office.
You do not need a device lab. One mid-range Android phone and one older iPhone, on a real mobile connection rather than office wifi, catch most of it. The mid-range Android matters most, because performance problems appear there first and that is where a large share of visitors are. Add keyboard-only testing on desktop and a pass with a screen reader, and you have covered the failures that are otherwise found by users.
- Keep one mid-range Android and one older iPhone for real testing
- Test on mobile data, not on office wifi
- Check touch target size and anything that depends on hover
- Do a keyboard-only pass, then a screen reader pass, on every key flow
- Look at the site outdoors, contrast problems are obvious in daylight
Code that stays cheap to change
The cost of a site is not the build, it is everything after. Front-end code gets edited by people who did not write it, often a year later and under time pressure. Whether that is a small job or a rewrite depends on choices made now.
The choices that help are unglamorous. Consistent structure, so a developer can guess where something lives. Styling that follows one approach rather than four layered on top of each other. Values defined once and referenced, rather than repeated. Components that do one thing. Dependencies chosen for being maintained and widely used rather than for being new. A readme that explains how to run the project, how to deploy, and which decisions were deliberate.
The single biggest factor is dependency restraint. Every package is something that will need updating, may introduce a vulnerability, and may be abandoned. A build with few, well-chosen dependencies can sit for a year and update cleanly. A build with a hundred of them needs constant attention just to stay where it is, and that attention gets billed to you or, more often, skipped until something breaks.
- One styling approach, applied consistently
- Define values once and reference them everywhere
- Prefer fewer, well-maintained dependencies over many convenient ones
- Write the readme for the developer who inherits this in a year
- Handle over full source and deployment access as standard
A clear path, step by step
- 01
Review the designs
We flag anything that will be slow, inaccessible or fragile before building it.
- 02
Build
Semantic markup, mobile-first CSS and only the JavaScript the page truly needs.
- 03
Test
Real devices, keyboard-only use, screen readers and performance budgets, not just a desktop browser.
- 04
Ship and measure
Launch, then verify field data confirms what the lab tests promised.
Why choose us for this
Performance budgets set before the build, not measured after
Accessibility tested with a keyboard and screen reader, not assumed
We match the design to the pixel and say so when a design choice will cost speed
Common questions
Which frameworks do you build with?
Static-first frameworks like Astro for content sites, React or similar where real interactivity earns its weight. The default is less JavaScript, because every script costs the user load time.
Why does semantic HTML matter?
It is how search engines, AI crawlers and screen readers understand your page. Proper headings, landmarks and structure improve rankings and accessibility at zero extra cost. Skipping it is pure loss.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase