The Strategic Importance of Semantic HTML
At the heart of the discussion is the concept of "semantic HTML"—the practice of using web elements that describe their function and meaning rather than merely their visual appearance. For the developers representing the Ministry of Housing, Communities and Local Government (MHCLG), the Department for Work and Pensions (DWP), and NHS England, semantic code is not merely a technical preference but a legal and ethical necessity.
Dilwoar Hussain, Lead Frontend Developer at the MHCLG, defines semantic HTML as the use of specific building blocks. While generic elements like <div> and <span> offer no information to assistive technologies, specific elements such as <nav>, <button>, and <header> provide a structural map that computers and screen readers can interpret. This structural clarity is essential for users who rely on non-visual navigation. When a developer uses a <button> element, the browser automatically provides keyboard focusability and announces the element’s role to a screen reader. Conversely, if a developer mimics a button using a <div> and JavaScript, they must manually rebuild those features, often resulting in "broken" experiences for users with visual or motor impairments.
James Gordon, Senior Frontend Developer at the DWP, highlights a common pitfall in modern web development: the over-reliance on JavaScript click events on non-interactive elements. Gordon notes that while a custom-styled image might look like a link to a sighted user, it remains an unclickable mystery to a screen reader unless semantic tags like <a> are used. This "hangover" from earlier eras of web development, where HTML was less capable, continues to pose a challenge to modern accessibility audits.
A Chronology of UK Digital Accessibility Standards
The current focus on accessible frontend development is the result of a decade-long evolution in UK digital policy. The timeline of this transformation underscores the transition from voluntary guidelines to mandatory compliance:
- 2011: The launch of the Government Digital Service (GDS) marked a shift toward "digital by default" services, with accessibility listed as a core design principle.
- 2018: The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations were introduced, requiring all public sector websites to meet Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards.
- 2020: All public sector websites were required to publish an accessibility statement, detailing any non-compliant areas and providing a roadmap for remediation.
- 2023-2024: The transition to WCAG 2.2 began, introducing new criteria for focus appearance, target size, and redundant entry, placing greater pressure on frontend developers to refine their code.
This chronological progression has shifted the responsibility of accessibility from a "final check" performed by Quality Assurance (QA) teams to a "shift-left" approach where accessibility is integrated into the initial coding phase.
Data-Driven Justification for Accessible Design
The necessity for high-standard semantic HTML is supported by staggering data regarding web usability. According to the 2024 "WebAIM Million" report, an annual accessibility analysis of the top one million homepages globally, 95.9% of homepages had detectable WCAG 2 failures. The most common issues—low contrast text, missing alt text for images, and empty links—are almost entirely preventable through the use of semantic HTML and basic CSS standards.
In the UK context, data from the charity Scope indicates that the "Purple Pound"—the spending power of disabled people and their families—is estimated at £274 billion per year. For the public sector, the stakes are even higher. Accessibility failures in government services do not just represent lost revenue; they represent a denial of essential services, such as healthcare, housing benefits, and voting information.
Proactive Implementation and the "Shift-Left" Methodology
A recurring theme among the developers is the rejection of accessibility as an "add-on." Instead, they advocate for a "shift-left" methodology, where accessibility is considered during the design and initial markup stages. Michael Cheung, Senior Front-end Developer at NHS England, emphasizes that using semantic HTML provides "accessibility for free." By utilizing the browser’s native elements, developers inherit built-in behaviors that would otherwise require complex, bug-prone code to replicate.
To ensure compliance without over-relying on automated plugins—which can often miss up to 60% of accessibility errors—developers are increasingly turning to the "Accessibility Tree." This is a subset of the browser’s Document Object Model (DOM) that contains only the information relevant to assistive technology. By inspecting the accessibility tree in browser DevTools, developers can see exactly what a screen reader will announce, allowing for real-time adjustments during the build process.
Holly Blues of DWP Digital notes that the use of centralized design systems, such as the GOV.UK Design System and the NHS Design System, has revolutionized this process. These systems provide pre-tested, accessible components (like accordions, checkboxes, and buttons) that have already undergone rigorous user testing with people who have access needs. This consistency ensures that a user navigating a benefits application on a DWP site experiences the same interaction patterns as they would when booking an appointment on an NHS portal.
Managing Dynamic Content and Interactive Elements
As web applications become more interactive, the challenge of maintaining accessibility increases. Dynamic content—such as modals (pop-up windows), carousels, and live-updating forms—can be disorienting for keyboard and screen reader users if not handled with precision.
The developers outlined a technical strategy for these elements:
- Focus Management: When a modal or "pop-up" opens, the user’s keyboard focus must be programmatically moved inside the modal and "trapped" there until the modal is closed. This prevents a keyboard user from accidentally navigating to the content hidden behind the pop-up.
- ARIA Attributes: While the mantra of accessibility is "No ARIA is better than bad ARIA," attributes like
aria-expandedandaria-liveare essential for dynamic content. For instance, an accordion (a collapsible content section) usesaria-expanded="true"or"false"to inform a screen reader user whether the content is currently visible. - Progressive Enhancement: Dilwoar Hussain highlights this technique as a fail-safe. It involves building the core functionality of a site using only HTML and CSS first. JavaScript is then added as a "layer" of enhancement. If the JavaScript fails to load—or if a user is using an older device—the site remains functional and accessible in its simplest form.
David Biddle of GDS points to the <dialog> element as a prime example of how HTML is evolving to solve these problems natively. The <dialog> tag provides built-in modal functionality, including focus management and backdrop rendering, reducing the need for custom, often inaccessible, JavaScript solutions.
Institutional Responses and Broader Implications
The collaborative nature of this discussion reflects a broader institutional response within the UK government. By sharing knowledge across departments—from the Ministry of Housing to the NHS—the public sector is creating a unified standard for digital excellence. This cross-pollination of ideas ensures that "accessibility" is not a siloed department but a core competency required of every frontend developer.
The implications of this shift extend beyond the UK. The GDS model of accessible, user-centered design has been exported globally, influencing digital service units in the United States, Canada, and Australia. As the world moves toward more digitized governance, the "semantic first" approach championed by these developers serves as a critical defense against digital exclusion.
In conclusion, the insights from the "Unlocking Accessibility" series suggest that the future of the web lies in its past—returning to the meaningful, structural roots of HTML. By prioritizing semantic code, engaging in manual testing, and utilizing robust design systems, frontend developers are doing more than just passing audits; they are ensuring that the digital world remains an open and equitable space for every citizen, regardless of how they interact with their screen. As Michael Cheung of the NHS aptly summarized, "This benefits everyone." Factual, semantic, and simple code is not just better for accessibility; it is better for SEO, better for performance, and better for the long-term sustainability of the web.