The Core Philosophy of Semantic HTML in Public Infrastructure
The technical implications of this choice are profound. When a developer uses a semantic <button> element, the browser automatically provides built-in features: it is focusable via the keyboard, it responds to the ‘Enter’ and ‘Space’ keys, and it communicates its role to screen readers. James Gordon, Senior Frontend Developer at the Department for Work and Pensions, points out a common pitfall in modern development: the "faux-link." This occurs when an image or a generic element is given a JavaScript click event to mimic a link. While it may look correct to a sighted user, it remains invisible or confusing to a screen reader unless significant manual coding is added to fix it. Gordon argues that starting with semantic tags like <a> ensures that assistive technology can interpret the code as intended, reducing the risk of failure across different devices.
Michael Cheung of NHS England further notes that semantic HTML provides "accessibility for free." By utilizing the correct document structure—including <header>, <nav>, <main>, and <footer>—developers create a predictable environment for users of speech recognition software and screen readers. This standardization is not merely a technical preference; it is a necessity for services like the NHS, where users may be accessing critical health information under stress or with temporary impairments.
The Evolution of Web Standards and Government Compliance
The push for better frontend practices is set against a backdrop of evolving regulatory requirements. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 mandated that all public sector websites meet the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards. In recent years, this has been updated to include WCAG 2.2, which introduces new criteria regarding focus appearance, dragging movements, and target sizes.
To meet these rigorous standards, government departments have moved away from relying on automated "accessibility overlays" or third-party plugins. Instead, the focus has shifted to the development phase. David Biddle, a Frontend Developer at GDS, explains that accessibility must be considered during the initial design stage. By planning how a feature should work for users of different assistive technologies before a single line of code is written, teams avoid the "accessibility debt" that occurs when developers try to "bolt on" fixes to a finished product.
Holly Blues, a Frontend Developer at DWP Digital, notes that this responsibility is shared across the entire project team. From Product Owners to Quality Assurance testers, accessibility is treated as a core requirement of the "Definition of Done." This cultural shift is supported by the GOV.UK Design System, a library of rigorously tested components that ensure consistency across the thousands of services provided by the UK government. These components are designed with accessibility at their core, allowing developers to focus on the unique aspects of their specific service while knowing the foundational elements are compliant.
Technical Strategies for Dynamic and Interactive Content
One of the most significant challenges in modern frontend development is making dynamic content—such as modals, carousels, and complex forms—accessible. These elements often change state without a page reload, which can be disorienting for users who cannot see the visual changes.
Dilwoar Hussain highlights the use of ARIA (Accessible Rich Internet Applications) attributes as a vital tool for managing these interactions. For collapsible elements like accordions, Hussain utilizes the aria-expanded attribute. When a user toggles a section, the code updates from aria-expanded="false" to aria-expanded="true", prompting the screen reader to announce the change to the user. Additionally, the aria-controls attribute creates a programmatic link between a button and the content it reveals, ensuring that the relationship is clear to assistive software.
The approach to these complex elements is often guided by "progressive enhancement." This development strategy ensures that the core functionality of a website works even if JavaScript fails to load or is not supported. For example, an accordion might default to an "always open" state in the absence of JavaScript, ensuring the information remains reachable. James Gordon emphasizes that the only way to verify these implementations is through "prodigious manual testing." While automated tools can catch roughly 30% to 40% of accessibility issues, manual testing with screen readers like NVDA, JAWS, or VoiceOver remains the gold standard for ensuring a seamless user experience.
Supporting Data and the Cost of Digital Exclusion
The importance of these technical choices is underscored by economic and social data. According to the Office for National Statistics (ONS), approximately 6.7 million people in the UK have never used the internet or have not used it in the last three months, a group often referred to as the "digitally excluded." For those who are online but live with disabilities, poorly coded websites create a "digital divide" that prevents access to essential services like Universal Credit, passport renewals, or health appointments.
Research by the GDS suggests that fixing accessibility issues during the design and development phase is significantly more cost-effective than retrofitting a live service. It is estimated that remediating a bug after a product has launched can cost up to 100 times more than addressing it during the initial requirements phase. Furthermore, accessible design often results in better search engine optimization (SEO) and faster load times, benefiting the general population and reducing the infrastructure costs for government departments.
Michael Cheung mentions that NHS England manages an "Accessibility Lab" equipped with various devices and assistive technologies. This facility allows developers to witness firsthand how their code interacts with braille displays, switch controls, and different screen reader versions. This empirical approach moves accessibility from a checklist of rules to a human-centered design practice.
Broader Impact on the Future of Frontend Development
The insights shared by these developers reflect a broader trend in the global tech industry toward "Inclusive Design." By prioritizing semantic integrity and keyboard navigation, the UK government is setting a benchmark for the private sector. The reliance on the GOV.UK Design System has already seen adoption by other governments and organizations worldwide, proving that high-quality, accessible code is a scalable solution for complex digital ecosystems.
David Biddle concludes that the ultimate goal is to make the technology invisible. When a website is built correctly with semantic HTML, the user can focus on the task at hand—whether that is applying for a driving license or checking a medical record—without the interface itself becoming an obstacle. The browser’s inbuilt tools, such as the "Accessibility Tree" in DevTools, are increasingly being used by developers to inspect what assistive technologies see, further integrating accessibility into the daily workflow of the modern frontend engineer.
As digital services become the primary interface between the state and the citizen, the work of frontend developers in ensuring "accessibility by default" is no longer a niche specialty but a fundamental requirement of public service. The Unlocking Accessibility series serves as both a technical guide and a call to action for the developer community to maintain the semantic standards that keep the web open to everyone. Through the continued use of well-tested patterns, manual testing, and a commitment to progressive enhancement, the UK government aims to ensure that no citizen is left behind in the digital age.
