Unlocking Accessibility Frontend Developers Discuss Semantic HTML and Accessible Code

The Government Digital Service (GDS) has released the latest installment of its Unlocking Accessibility series, a strategic initiative designed to demystify digital inclusion by gathering expert insights from various technical professions across the United Kingdom’s public sector. This latest chapter focuses on the foundational role of frontend developers in creating a barrier-free digital environment. Experts from the Ministry of Housing, Communities and Local Government (MHCLG), the Department for Work and Pensions (DWP), NHS England, and GDS itself have contributed to a comprehensive dialogue regarding the technical pillars of accessibility: semantic HTML, proactive development strategies, and the management of complex dynamic content.

The publication of these insights comes at a critical time for the UK public sector. Under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, all public sector digital services are legally required to meet the Web Content Accessibility Guidelines (WCAG) 2.2 AA standard. As of 2024, approximately 16 million people in the UK—nearly 24% of the population—report having a disability. This demographic reality places an immense responsibility on frontend developers to ensure that the "digital front door" of government remains open to everyone, regardless of their physical or cognitive abilities.

The Foundation of Digital Inclusion: Semantic HTML

At the heart of the discussion is the concept of semantic HTML, the practice of using web elements for their intended meaning rather than their visual appearance. Dilwoar Hussain, Lead Frontend Developer at MHCLG, defines semantic HTML as the use of specific "building blocks" like <nav>, <button>, and <img /> rather than generic containers like <div> and <span>. According to Hussain, this distinction is vital because it allows computers and assistive technologies—such as screen readers—to interpret the structure and intent of a webpage automatically.

The consensus among the experts is that semantic code provides "accessibility for free." Michael Cheung, Senior Frontend Developer at NHS England, emphasizes that by utilizing the correct elements from the start, developers reduce the need for complex workarounds. He notes that semantic tags like <header>, <main>, and <footer> provide an inherent roadmap for users who navigate via keyboard or speech recognition software.

However, the industry faces a significant challenge: the "hangover" of modern web development. James Gordon, Senior Frontend Developer at the DWP, observes that a decade of JavaScript-heavy development has led many creators to mimic native browser behavior using non-semantic code. A common example is an image with a JavaScript "click" event that functions as a link. While this may look correct to a sighted user, it is often invisible or confusing to a screen reader. Gordon argues that the most robust way to ensure a link works for everyone is to use the semantic <a> tag, which carries centuries of standardized browser behavior and accessibility metadata.

Proactive Strategies and the Role of Design Systems

The Unlocking Accessibility series highlights a shift in the development lifecycle from "reactive" to "proactive" accessibility. Traditionally, accessibility was often treated as an audit-based task completed at the end of a project. The modern approach, advocated by Holly Blues of DWP Digital and David Biddle of GDS, integrates accessibility into the earliest design phases.

A central tool in this proactive approach is the use of established design systems. The GOV.UK Design System and the NHS Design System serve as central repositories of pre-tested, accessible components. These systems allow developers to implement complex features—such as accordions, checkboxes, and error summaries—knowing they have already undergone rigorous user research with people who have access needs.

Holly Blues notes that at DWP Digital, the entire team—from Product Owners to Quality Assurance testers—is held responsible for accessibility. This collective ownership prevents the "siloing" of inclusion tasks. By identifying potential hurdles, such as complex filtering or paging controls, before development begins, teams can select accessible patterns rather than trying to "fix" inaccessible ones later. This proactive stance is not just a matter of ethics; it is a matter of efficiency. Industry data suggests that fixing an accessibility bug during the design phase can be up to 100 times cheaper than fixing it after a product has been launched.

Navigating the Complexity of Dynamic Content

One of the most technically demanding aspects of frontend development is making dynamic, interactive elements accessible. Features such as modals (pop-up windows), carousels, and live-updating forms often "wrestle control" away from the user, which can be disorienting for those using screen readers or keyboard navigation.

Unlocking Accessibility: Frontend developers discuss semantic HTML and accessible code

Dilwoar Hussain points to the importance of ARIA (Accessible Rich Internet Applications) attributes in these scenarios. When building collapsible elements like accordions, Hussain utilizes aria-expanded and aria-controls to provide real-time feedback to assistive technology. When a user clicks a button to expand a section, the screen reader must immediately announce that the section is now open. Without these attributes, a visually impaired user might click a button and have no way of knowing that new content has appeared on the screen.

Furthermore, the experts advocate for "Progressive Enhancement." This development philosophy dictates that a website’s core functionality should work with the simplest possible HTML before adding layers of CSS and JavaScript. David Biddle highlights the importance of the <dialog> element for modals, which provides built-in focus management—a feature that previously required dozens of lines of complex JavaScript to prevent "keyboard traps" where a user becomes stuck inside a pop-up.

The Importance of Manual Testing and the Accessibility Tree

While automated tools and plugins are common in the industry, the contributors to the GDS series caution against over-reliance on them. Michael Cheung recommends that developers utilize the "accessibility tree" found within browser developer tools. This view shows exactly what information the browser is passing to assistive technology, revealing gaps that automated scanners might miss.

James Gordon stresses that "prodigious amounts of manual testing" across different devices and screen readers (such as NVDA, JAWS, and VoiceOver) remain the gold standard. This sentiment reflects a broader industry understanding that while an automated tool can check if an image has an "alt" tag, it cannot determine if the description is actually meaningful or helpful to the user.

Analysis: The Broader Impact on Public Trust

The insights shared by these frontend developers underscore a fundamental shift in how government digital services are built. In an era where essential services—from Universal Credit applications to NHS appointment bookings—are primarily digital, accessibility is synonymous with equity.

The move toward semantic-first development and the utilization of shared design systems has several long-term implications:

  1. Sustainability: Semantic HTML is more "future-proof." As new devices and browsers emerge, they are built to understand standard HTML tags, ensuring that government services remain functional for years without constant rebuilding.
  2. Performance: Semantic code is generally lighter and faster to load. This benefits users with limited data plans or slow internet connections, further reducing the "digital divide."
  3. Search Engine Optimization (SEO): Many of the same structures that help screen readers—such as proper heading hierarchies and descriptive links—also help search engines index content, making it easier for citizens to find the information they need.
  4. Legal and Financial Risk Mitigation: By embedding accessibility into the frontend workflow, departments reduce the risk of legal challenges and the high costs associated with emergency remediation.

Conclusion and Future Outlook

The Unlocking Accessibility series serves as a reminder that digital accessibility is not a "feature" to be added, but a fundamental requirement of modern engineering. The testimonies from MHCLG, DWP, and the NHS highlight a sophisticated community of practice within the UK government that prioritizes the user experience of the most vulnerable citizens.

As web technologies continue to evolve—with the rise of AI-driven interfaces and increasingly complex web applications—the principles of semantic HTML and progressive enhancement remain the most reliable safeguards against digital exclusion. The Government Digital Service continues to encourage developers across the public and private sectors to contribute to this ongoing dialogue, ensuring that the digital world remains a space where everyone, regardless of ability, can participate fully.

For those working in the field, the message is clear: accessibility is a team sport that begins with the very first line of code. By returning to the basics of meaningful HTML and embracing rigorous manual testing, developers can unlock the full potential of the web for every user.

Leave a Reply

Your email address will not be published. Required fields are marked *