Skip to content

Languages

HTML5

The foundation everything else stands on — semantic, accessible, standards-compliant markup, done properly by people who treat it as craft rather than an afterthought.

Overview

HTML5 is two things wearing one name. It is the modern semantic markup language — the elements you use to describe a document’s structure and meaning — and it is the browser platform those elements unlock: the canvas and SVG for graphics, native audio and video without plugins, form controls with built-in validation, and a family of JavaScript APIs for storage, offline behaviour, geolocation, drag-and-drop and web components. Calling it a “version” is slightly misleading. HTML5 is really a living standard that has been evolving continuously since the label was coined, and the browser platform underneath it has grown far beyond the original specification. When people say HTML5, they usually mean “the modern web, done with current elements and APIs” rather than a fixed release you can pin to a date.

The part that matters most, and that the industry most often neglects, is semantic markup: choosing header, nav, main, article, section, aside and footer because they describe what the content is, not merely how it should look. A div can hold anything; a nav announces navigation to a screen reader, a search engine and any future maintainer alike. Get the structure right and accessibility, SEO and long-term maintainability come substantially for free. Get it wrong — a page built from anonymous divs and spans wired up with JavaScript — and you spend the rest of the project bolting those qualities back on at ten times the cost, usually imperfectly.

We treat HTML as the load-bearing layer of the front end, because it is. Every React component, every Next.js page, every Vue template ultimately renders down to HTML that a browser parses and an assistive technology reads. A framework does not exempt you from getting the markup right; it just puts more distance between you and the output, which is exactly why so many framework-heavy apps ship inaccessible, unsemantic HTML nobody looked at. Our angle is unfashionably simple: build the foundation properly first. Semantic, accessible, performant, standards-compliant markup underpins everything else, and it is the cheapest quality to build in at the start and the most expensive to retrofit at the end.

Best for — Any team that wants the foundation of their website or web app to be semantic, accessible and standards-compliant from the first line — whether that is a fast content site in plain HTML or the markup discipline underneath a modern framework build.

Why teams choose HTML5

  • Accessibility built in, not bolted on

    Correct semantic markup makes a page usable by screen readers, keyboard users and assistive technology by default, before a single ARIA attribute is added. Getting header, nav, main, headings and landmarks right does more for real accessibility than any amount of retrofitted patching, and it is dramatically cheaper to do at the start than to reverse-engineer under a compliance deadline.

  • Search engines that understand your page

    Semantic HTML tells a crawler what your content is — what the main content is versus navigation and boilerplate, what the headings hierarchy means, what is an article. That structural clarity, combined with clean, fast-loading markup, is foundational SEO that no amount of keyword tactics substitutes for. Search engines reward pages they can parse and understand.

  • A foundation that outlives frameworks

    HTML is the most stable technology on the web. Markup written to the standard a decade ago still renders correctly today, and markup written now will still render in a decade. Frameworks come and go; the semantic foundation underneath them, if it is built properly, survives every rewrite and migration you will do on top of it.

Why businesses choose HTML5

  • It is the one layer of your product you cannot opt out of, so building it well is the highest-return decision you can make about the front end.
  • Accessibility and SEO — two things every business claims to want — are largely downstream of semantic HTML done correctly, rather than separate workstreams to buy later.
  • A properly structured foundation makes every subsequent change cheaper: new features, redesigns and framework migrations all sit more easily on markup that already means something.
  • It future-proofs by default. Standards-based HTML is the most durable code you will write, insulated from the churn that affects everything layered above it.

What we build with HTML5

The capabilities this technology is genuinely strong at — and what we most often build with it.

  • Semantic structural elements

    header, nav, main, article, section, aside and footer describe the shape of a document so that browsers, assistive technology and search engines all understand it the same way. We use them deliberately — one main per page, a sensible landmark structure, a heading hierarchy that actually nests — because this structure is the skeleton every other quality hangs off.

  • Accessibility and ARIA, used correctly

    Native HTML elements carry accessibility semantics for free; ARIA exists to fill the gaps, not to replace them. The first rule of ARIA is to prefer a real element over a faked one — a button, not a div with a role. We build to WCAG, test with real screen readers and keyboards, and treat ARIA as a scalpel for genuinely custom widgets rather than a sticking plaster over bad markup.

  • Native forms and validation

    HTML5 form controls — email, number, date, range and the rest — plus required, pattern and constraint validation give you input handling, error states and accessibility that work before a line of JavaScript runs. We lean on the platform for the baseline and enhance with JavaScript only where the native behaviour genuinely falls short, which keeps forms robust and usable even when scripts fail.

  • Canvas and SVG graphics

    The canvas element gives you a scriptable pixel surface for dynamic, high-throughput graphics — visualisations, games, image manipulation — while SVG gives you resolution-independent, accessible, DOM-addressable vector graphics for icons, charts and diagrams. They solve different problems, and we choose between them on the merits rather than by habit.

  • Native audio and video

    The audio and video elements play media directly in the browser with no plugin, with captions and text tracks for accessibility and a JavaScript API for custom controls. We wire up media that degrades gracefully, respects bandwidth and remains operable by keyboard and screen reader, rather than shipping an inaccessible custom player.

  • The platform APIs HTML5 unlocked

    Beyond markup, HTML5 brought a platform: service workers and offline caching, local and session storage, geolocation, drag-and-drop, and web components for framework-agnostic reusable elements. We reach for these where they earn their place, always with progressive enhancement so the core experience works when a given API is unavailable.

Use cases

  • Accessible, standards-compliant content sites

    Marketing sites, documentation and publications where semantic markup, a clean heading structure and fast-loading pages do the heavy lifting for both accessibility and SEO. These are the cases where plain HTML with disciplined CSS beats a framework on speed, robustness and cost, and we build them that way.

  • The markup foundation under a framework app

    When the product is a React or Next.js application, the HTML it renders still has to be semantic and accessible. We own that layer explicitly — component structure that outputs correct landmarks and headings, forms that use native controls, interactive widgets that meet WCAG — so the app is usable by everyone rather than only by a mouse-using sighted person.

  • Accessibility remediation and audits

    Existing sites that fail WCAG or fall over with a screen reader, where the fix is fundamentally about the HTML underneath: replacing div soup with real elements, correcting heading order, adding labels and landmarks, and making custom widgets operable by keyboard. This is unglamorous work with an outsized effect on real users and on legal exposure.

  • Progressive web foundations

    Sites that use the HTML5 platform — service workers for offline resilience, storage for state, native media — while remaining fully functional when those APIs are absent. Built as progressive enhancement, the core content and interaction work everywhere, and capable browsers get the richer experience on top.

When HTML5 is the right choice

  • Right for every website and web application, without exception — HTML is not optional. The only real choice is whether the markup underneath your product is semantic and accessible or an accidental mess of divs, and that choice is made whether you think about it or not.
  • Right, in its plain form, for content-driven sites — marketing pages, documentation, blogs, brochureware — where well-structured HTML with a little CSS and minimal JavaScript is faster, cheaper and more robust than reaching for a framework.
  • Right as the deliberate foundation of any framework build: getting the semantic structure and accessibility correct at the HTML level is what makes a React or Next.js app usable by everyone and legible to search engines, rather than a black box that happens to render.
  • Wrong as a complete answer to a rich, stateful application. HTML describes structure; it does not style itself or make itself interactive. Anything beyond a document needs CSS for presentation and JavaScript for behaviour, and a genuinely app-like interface wants a framework built on top of HTML, not HTML alone.
  • Wrong to treat as a solved, trivial layer you can leave to a junior or generate and forget. Accessibility and semantic correctness are easy to get subtly, invisibly wrong, and the cost of getting them wrong lands on real users and, increasingly, on legal compliance.

HTML5: pros and cons

Strengths

  • Universal and permanent — every browser on every device parses HTML, and backwards compatibility is close to sacred, so correct markup does not rot.
  • Semantic elements deliver accessibility and SEO largely for free when used correctly, turning two expensive concerns into a by-product of doing the structure right.
  • The browser platform gives you a great deal natively — form validation, audio and video, canvas and SVG graphics, offline storage — without plugins or heavy dependencies.
  • It is the cheapest quality layer to get right early and the highest-leverage: everything above it, in any framework, inherits the foundation you lay.

Trade-offs

  • HTML alone is not an application. It describes structure and nothing more — you need CSS to style it and JavaScript to make it interactive — so “just HTML” is only ever the base of a larger stack.
  • “HTML5” is a moving target, not a fixed version. It is an evolving living standard, and the browser platform APIs bundled under the name vary in support and maturity, so you cannot assume a feature works everywhere.
  • Support for newer platform APIs is uneven across browsers and versions, which means progressive enhancement and feature detection are not optional if you use the cutting edge.
  • Accessibility is genuinely easy to get wrong. Valid HTML can still be unusable — a wrong heading order, a missing label, a div pretending to be a button — and without deliberate discipline and testing, teams ship inaccessible pages while believing they have not.

How we structure HTML for the long term

We start with the document, not the design. Before any styling, we decide the semantic structure of a page — what is the main content, what is navigation, what is complementary, how the headings nest — because that structure is the contract every other layer depends on. A page has exactly one main, a coherent landmark map, and a heading hierarchy that a screen-reader user could navigate by alone. This is deliberately old-fashioned: it is the discipline of writing HTML that means something, which is precisely what gets skipped when teams jump straight to components and CSS.

In a framework context the same principles apply, one level of indirection removed. We design components so that their rendered output is correct — a component called Card should not emit a nest of divs where an article belongs, and a component called Button should render a button. Because the framework hides the HTML, we make reviewing the actual rendered markup part of the work rather than trusting that it came out right. The output is what the browser and the screen reader see, and the output is what we hold to standard.

We build with progressive enhancement as the default posture: a baseline of semantic HTML that works with no JavaScript and no advanced APIs, then CSS for presentation, then JavaScript and platform APIs layered on for capable environments. This is not nostalgia — it is what makes a site resilient when a script fails to load, an API is unsupported, or a user is on assistive technology the developers never tested. The foundation works; everything above it is an enhancement.

Markup as a performance lever

HTML is the first thing a browser receives and the thing that gates everything else, so its size and structure directly affect how fast a page becomes usable. Lean, semantic markup parses faster and describes the page in fewer bytes than div soup carrying styling hooks and framework scaffolding. We keep the document tree shallow and meaningful, because a bloated DOM is slow to parse, slow to style and slow to script, and no amount of downstream optimisation fully recovers from it.

The platform gives real performance wins when the markup uses it. Responsive images with srcset and sizes, the loading attribute for lazy-loading below-the-fold media, width and height to reserve layout space and prevent shift, and native form controls that avoid shipping JavaScript to reimplement what the browser already does — these are markup-level decisions with measurable effects on Core Web Vitals. We treat them as standard, not as an optimisation pass bolted on at the end.

Because HTML is the base layer, getting it right pays off in every framework above it. Server-rendered HTML that is correct and complete gives a fast, meaningful first paint before any JavaScript hydrates; markup that is wrong forces the client to do work the server should have done. The fastest interaction is the one the platform handles natively, and the most reliable performance budget is the one that starts with disciplined markup.

The security surface of the front end

HTML is a declarative document format, not a program, so it does not have the injection surface of a server language — but the moment you inject dynamic content into a page, cross-site scripting becomes the dominant risk. Any user-controlled data written into the DOM as markup rather than text is a potential script-execution hole. We treat every dynamic insertion point as untrusted, escape content by default, and are extremely wary of anything that sets raw HTML, because that is where XSS lives.

The platform offers real defences that live at the markup and header level, and we use them. A Content Security Policy constrains what scripts and resources a page may load and blunts whole classes of injection. The rel="noopener" relationship closes the reverse-tabnabbing hole on links that open new tabs. The sandbox attribute constrains what an embedded iframe can do. Form controls should submit over HTTPS, and sensitive fields should not autofill or cache carelessly. These are small, specific, standards-based mitigations that add up.

We are also honest about the boundary: nothing enforced only in the browser is a security control, because the client is fully under the user’s power. HTML5 validation improves the experience and catches honest mistakes, but every constraint must be re-checked on the server, which cannot be bypassed. Client-side validation is a courtesy to the user, never a guarantee to the system.

Markup that scales with the team and the product

HTML’s scalability is less about traffic — static markup is trivially cacheable and serveable at the edge — and more about how a codebase holds up as it grows and as people who did not write it have to change it. Semantic markup scales here because it is self-documenting: a maintainer opening a file sees article, nav and main and immediately understands the intent, where a wall of nested divs communicates nothing and has to be reverse-engineered every time.

In component-based systems the foundation scales through consistency. When accessibility and semantics are built into shared components — the button that is always a real button, the field that always carries a label, the dialog that always manages focus — every team consuming those components inherits correctness for free, and the standard is enforced once rather than re-litigated on every page. This is how a large product stays accessible: not by auditing thousands of pages, but by making the reusable pieces correct.

Static, well-structured HTML is also the most operationally scalable output on the web. It can be pre-rendered, cached indefinitely and served from a CDN with essentially no per-request cost, which is exactly why content sites and the static shells of applications should lean on it. The more of your product that reduces to cacheable HTML, the cheaper and more resilient it is to run.

HTML5 integrations & ecosystem

The technologies we most often pair with it — each links to how we work with it.

How we deliver HTML properly

We work structure-first. On any page or component the semantic markup is designed before the styling, because the structure is the thing everything else depends on and the thing that is most expensive to change late. We settle the landmarks, the heading hierarchy and the choice of elements up front, and we treat the rendered HTML — not the source template, not the component tree — as the artefact that has to be correct, since that is what the browser and assistive technology actually consume.

Accessibility is part of the definition of done, not a phase at the end. We build to WCAG as we go, prefer native elements over ARIA-patched ones, and test with real keyboards and real screen readers rather than trusting an automated checker alone — automated tools catch perhaps a third of accessibility issues, and the ones they miss are often the ones that matter most. Progressive enhancement is our default: a working semantic baseline first, then presentation and behaviour layered on, so the product degrades gracefully rather than collapsing when a script or an API is unavailable.

Because we operate what we build, we live with the consequences of these choices — the support burden of an inaccessible form, the SEO cost of unparseable markup, the migration pain of a foundation that meant nothing. That is why we treat the unglamorous foundation as the part most worth getting right, and why we are willing to be the ones who actually read the rendered HTML.

The service behind it

Delivered throughCustom Software Development

What we build with HTML5

The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves — including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

Industries we use HTML5 in

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

Also in Languages

Why teams choose us for HTML5

  • We treat the foundation as craft

    Most teams skip past HTML to get to the framework and the design, and it shows in the inaccessible, unsemantic markup they ship. We do the opposite. We think semantic, accessible, standards-compliant markup is the highest-leverage layer of the front end, and we give it the attention it deserves rather than the attention it usually gets.

  • Accessibility we actually test, not claim

    We build to WCAG and verify it with real screen readers and keyboards, because valid HTML can still be unusable and automated checkers miss the issues that matter most. Accessibility is a discipline we practise deliberately, not a badge we assert, and we will tell you plainly where a design or a deadline is putting it at risk.

  • Senior-led and honest about scope

    A senior engineer owns the markup and accessibility decisions on your project. We are candid that HTML alone is not an application, that some platform APIs are not universally supported, and that accessibility is real work rather than a free by-product — because setting that expectation honestly is how the foundation actually gets built right.

Typical timeline

  1. 01

    Assessment

    We review the content, the design and any existing markup, agree the accessibility target — usually a specific WCAG level — and settle the semantic structure and heading hierarchy before anything is built.

  2. 02

    Foundation

    We build the semantic HTML skeleton: landmarks, headings, native forms and media, and the base document that works with no CSS and no JavaScript, so the foundation is correct before presentation and behaviour go on top.

  3. 03

    Enhancement

    We layer on styling and interactivity as progressive enhancement, wiring in platform APIs and any framework components so that their rendered output stays semantic and accessible rather than drifting from the standard.

  4. 04

    Validation

    We test against real keyboards and screen readers, validate the markup, check Core Web Vitals, and confirm WCAG conformance — the acceptance step where we prove the foundation is actually as accessible and standards-compliant as intended.

How pricing works

  • Front-end and markup work is priced as part of the engagement it belongs to — a new build, a content site, or the foundation layer of a framework application — rather than as a separate line, because the semantic and accessible markup is not an add-on to the front end, it is the front end.
  • The largest cost driver is accessibility scope: meeting a specific WCAG conformance level, supporting a defined set of assistive technologies, and testing against them is real, careful work, and we would rather scope it honestly than imply it comes for nothing.
  • Remediation of an existing site is priced by the state of what is already there. A codebase of div soup and faked controls costs more to make accessible than one built on a reasonable semantic base, and we assess before we quote so the number reflects the actual work.

Hire HTML5 engineers

Need HTML5 capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.

Hire HTML5 engineers

Common questions

Is HTML5 a version I should be targeting, or just the current web?

Practically, it is the current web. HTML5 began as a specific specification, but it has become a living standard that evolves continuously, and the browser platform bundled under the name has grown well beyond the original document. So when we say we build in HTML5, we mean we use current semantic elements and platform features to the standard as it stands now — not that we are pinning to a fixed release. The useful question is not “which version” but “are we using the right elements and APIs correctly, with sensible fallbacks”.

If our app is built in React, does semantic HTML still matter?

It matters just as much, arguably more. Every React component renders down to HTML, and that HTML is what the browser and the screen reader actually consume. A framework does not make markup semantic or accessible on your behalf; it puts distance between you and the output, which is precisely why so many framework apps ship inaccessible HTML nobody reviewed. We design components so their rendered markup is correct, and we review the actual output rather than assuming it came out right.

Why do you make such a point of accessibility?

Because it is easy to get wrong, expensive to retrofit, and it lands on real people. Valid HTML can still be unusable with a screen reader or a keyboard, and automated accessibility checkers catch only a fraction of the problems — the rest need a person testing with the actual tools. It is also increasingly a legal requirement. Getting the semantic structure right from the start makes accessibility largely a by-product; leaving it to the end makes it a costly, imperfect scramble. We would rather build it in.

Can you just build us a fast site in plain HTML instead of a framework?

Often that is exactly the right call, and we will recommend it when it is. For a marketing site, documentation or a blog, well-structured HTML with disciplined CSS and minimal JavaScript is faster, cheaper and more robust than a framework, and it scales beautifully because it is trivially cacheable. We reach for a framework when the interface is genuinely stateful and interactive enough to justify it — and we will tell you honestly which side of that line your project falls on rather than defaulting to the heavier tool.

Do the newer HTML5 platform APIs work in every browser?

Not uniformly — support for the newer platform APIs, such as service workers, certain form input types and some web component features, varies across browsers and versions. That is why we build with progressive enhancement and feature detection rather than assuming a feature is present: the core experience works everywhere on a semantic baseline, and capable browsers get the enhanced behaviour on top. It means a missing or unsupported API degrades gracefully instead of breaking the page, which is the only responsible way to use the cutting edge of the platform.

Building on HTML5?

A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.

Prefer to book a call?Or email [email protected]

Two fields required. We reply to real enquiries — no list, no sequence.