The Core Philosophy of Semantic HTML
At the heart of the discussion is the concept of semantic HTML, which refers to the use of HTML elements that convey the meaning and structure of the content rather than just its visual appearance. Dilwoar Hussain, Lead Frontend Developer at MHCLG, explains that while generic elements like <div> and <span> serve as versatile containers, they offer no information to assistive technologies. In contrast, semantic tags such as <img>, <nav>, and <button> provide immediate context to browsers and screen readers. When a developer uses a <button> element, the browser automatically grants it keyboard focusability and announces it as a button to users with visual impairments. If a developer instead uses a <div> styled to look like a button, they must manually add complex JavaScript and ARIA (Accessible Rich Internet Applications) roles to achieve the same level of functionality—a process that is prone to error.
The importance of this distinction cannot be overstated in the context of the UK’s aging population and the increasing reliance on digital-first services. According to data from the World Health Organization and the UK’s Department for Work and Pensions, approximately 16 million people in the UK—nearly 24% of the population—live with some form of disability. For these millions of citizens, the difference between a semantic link and a non-semantic image with a click event is the difference between accessing a service independently and being entirely excluded from the digital landscape.
James Gordon, Senior Frontend Developer at the DWP, notes that modern web development often suffers from a "hangover" of over-relying on JavaScript to fill gaps in HTML interactivity. This reliance frequently leads to the loss of the underlying HTML’s meaning. By prioritizing semantic code, developers ensure that assistive technologies can interpret the site’s intent with 100% certainty, a level of reliability that custom-built JavaScript components rarely achieve.
The Chronology of Web Accessibility Standards
To understand the current emphasis on semantic HTML, one must look at the evolution of web standards. The World Wide Web Consortium (W3C) first published the Web Content Accessibility Guidelines (WCAG) 1.0 in 1999. Since then, the standards have evolved through WCAG 2.0 (2008) and 2.1 (2018), culminating in the current WCAG 2.2 standard, which introduced new criteria for focus appearance, target size, and redundant entry.
The UK government’s commitment to these standards was codified in the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. This legislation requires all public sector websites and apps to be accessible to everyone, regardless of their ability. The timeline of this regulation saw a phased implementation: new websites had to be compliant by September 2019, existing websites by September 2020, and mobile applications by June 2021. The ongoing "Unlocking Accessibility" series serves as a continuous internal audit and knowledge-sharing platform to ensure these legal and moral obligations are met across the vast ecosystem of government digital services.
The "Shift-Left" Approach to Accessible Development
A recurring theme among the developers is the rejection of "accessibility overlays" or third-party plugins as a primary solution. Instead, the consensus favors an integrated approach where accessibility is considered during the design and initial coding phases. Michael Cheung, Senior Front-end Developer at NHS England, emphasizes that using semantic HTML provides "accessibility for free." By hand-coding elements and referencing official W3C specifications, developers can leverage the browser’s built-in accessibility tree—a data structure that translates the DOM (Document Object Model) into a format that screen readers can understand.
This "shift-left" strategy involves:
- Early Collaboration: Developers working with designers and content writers to identify potential barriers before a single line of code is written.
- Use of Design Systems: Utilizing pre-tested, accessible components from the GOV.UK Design System or the NHS Design System.
- Manual Testing: Moving beyond automated tools to test sites using only keyboards, screen readers (such as NVDA or VoiceOver), and browser zoom functionality.
Holly Blues of DWP Digital highlights that the entire team—from Product Owners to Quality Assurance testers—shares responsibility for accessibility. This holistic approach ensures that features like filtering or paging controls, which typically rely on client-side JavaScript, are built using accessible patterns that do not alienate users who may have JavaScript disabled or who rely on specific assistive hardware.
Technical Strategies for Dynamic Content
As websites become more interactive, the challenge of maintaining accessibility increases. Dynamic content—such as modals, carousels, and accordions—presents significant hurdles for keyboard and screen reader users. David Biddle, a Frontend Developer at GDS, points out that new HTML elements like <dialog> are now available to handle modals natively, providing better focus management and keyboard interaction than custom-built solutions.
For elements like accordions (collapsible sections), Dilwoar Hussain advocates for the use of the aria-expanded attribute. This attribute tells a screen reader whether a section is open or closed, providing vital feedback that a visual user would get through a change in an icon or animation. Furthermore, the use of aria-controls links the trigger button to the content it affects, creating a clear relationship within the accessibility tree.
Another critical technique discussed is "progressive enhancement." This philosophy dictates that the core functionality of a website should work for everyone, regardless of their browser’s capabilities. For an accordion, the progressively enhanced version might display all content by default if JavaScript fails to load, ensuring that the information remains reachable even if the interactive "collapse" feature does not function.
Supporting Data and the Cost of Inaccessibility
The drive for accessible frontend code is supported by compelling economic and social data. A study by the "Click-Away Pound" survey found that 71% of disabled customers with access needs will leave a website that they find difficult to use. In the UK, the combined spending power of disabled people and their families—often referred to as the "Purple Pound"—is estimated at £274 billion per year.
For the government, the cost of retrofitting accessibility into an existing, poorly coded site is significantly higher than building it correctly from the start. Industry estimates suggest that fixing an accessibility bug during the maintenance phase can be up to 30 times more expensive than addressing it during the initial design and development phase. By focusing on semantic HTML and robust frontend practices, government departments are not only fulfilling a legal mandate but also practicing prudent fiscal management.
Official Responses and Internal Governance
The UK government has established several bodies and frameworks to oversee these efforts. The Government Digital Service (GDS) plays a central role, maintaining the GOV.UK Design System, which serves as the "gold standard" for accessible web components. Michael Cheung notes that when a component is not available in the NHS design system, he looks to the GDS or the WAI-ARIA Authoring Practices Guide for established, accessible patterns.
Internal governance is further bolstered by facilities like the NHS Accessibility Lab, where developers can test their code on a wide range of devices and assistive technologies. This manual testing is viewed as the only way to truly verify that a service works for all users. The "Unlocking Accessibility" series itself is an official response to the need for transparency and continuous improvement within the civil service, encouraging developers to share "prodigious amounts of manual testing" results and best practices.
Broader Impact and Future Implications
The impact of these frontend development practices extends beyond the immediate user experience. Semantic HTML significantly improves Search Engine Optimization (SEO), as search engine crawlers use the same semantic cues as screen readers to index and rank content. A well-structured page with clear headings (<h1> through <h6>) and meaningful links is easier for both Google and a screen reader user to navigate.
Looking forward, the evolution of digital services will likely see an increased focus on "cognitive accessibility"—designing for users with neurodivergence, learning disabilities, or temporary cognitive impairments caused by stress or illness. The developers featured in the GDS report suggest that the simplicity and predictability of semantic HTML provide a stable foundation for these future challenges.
As the UK continues its digital transformation, the insights shared by these frontend developers underscore a fundamental truth of the modern web: accessibility is not a feature to be added, but a quality to be baked into the very syntax of the code. Through the disciplined use of semantic HTML, the rejection of "quick-fix" tools, and a commitment to manual testing, the public sector is setting a global benchmark for how to build a digital world that excludes no one.
The "Unlocking Accessibility" series remains an open dialogue, with GDS inviting further contributions from developers across the government to refine these standards. As web technologies continue to advance, the core principle remains the same: the most sophisticated code is the code that everyone can use.
