Image courtesy of Government Digital Services.
Our Unlocking Accessibility series focuses on asking various professions or teams specific questions about digital accessibility.
In the next instalment of this series, we asked frontend developers from various government departments and public sector organisations about the importance of semantic HTML, how they ensure accessibility from the start without over-relying on additional tools or plugins, and their approach to making dynamic content accessible for keyboard and screen reader users.
Traditionally, frontend developers design, build, and improve websites, ensuring they are accessible to all users, including those with disabilities.
Question 1 - What is 'semantic HTML,' and why is it important for accessibility?
Dilwoar Hussain, Lead Frontend Developer, Ministry of Housing, Communities and Local Government
Websites use special building blocks called HTML. HTML has two types of elements: generic ones like <div> and <span>, and specific ones like <img>, <nav>, and <button>. Using specific elements correctly is called semantic HTML.
Choosing the right elements helps computers and screen readers understand the page structure. For example, a <button> should be a button, not just text. This ensures assistive technologies can properly navigate the page. Using the correct tags also helps search engines and makes websites better for everyone.
James Gordon, Senior Frontend Developer, Department for Work and Pensions
When is a link not a link? When it’s an image with a javascript click event that mimics the behaviour of a link. To most users, it works fine, the creator even added some visual cues to indicate it’s clickable, but to a screen reader or other assistive tech, that’s reading the underlying HTML, it’s just an image. To make it ‘accessible’ you could add alt text to the image so screen readers can read out a description of a clickable link, you could add a role tag to indicate it’s a link, or you could just use the semantic html for a link <a>. The issue with not using semantic html is you can’t be 100% sure the assistive tech that is being used on your site is going to interpret your code as intended.
The current state of modern web development is a hangover of shoring up the gaps in HTMLs interactivity with JS and, in doing so, losing the meaning of the underlying HTML. By writing your HTML semantically and enhancing it later with JS as desired you can serve a more diverse user group from the start of development instead of at the end.
Michael Cheung, Senior Front-end Developer, NHS England
Semantic HTML means using the right HTML elements for their intended purpose or meaning. For example, use the <a> element for links, or the <header>, <nav>, <main> or <footer> elements to structure a page instead of generic elements like <span> and <div>.
Using semantic HTML gives you accessibility for free. It helps assistive technologies to understand the type of content it comes across, making it easier to navigate and interact with when using screen readers, speech recognition software or a keyboard. This benefits everyone.
Holly Blues, Front-end Developer, Department for Work and Pensions Digital
Semantic HTML describes the content of a web page in a meaningful way by using HTML tags such as a <header> or <footer> to describe page content, rather than using non-descriptive tags such as a <div> or <span>.
These semantically named elements imply both the structure and content of the page which aids keyboard navigation for screen reader users.
David Biddle, Frontend Developer, Government Digital Services
Semantic HTML is made up of HTML elements with meaning attached to them - so your tags describe the meaning of your document rather than just the way it looks. Most HTML elements have some meaning attached.
The information this provides about the document can help users of assistive technologies use the page. For example, the <ul> and <li> elements allow screen readers to tell the user that a particular bit of text is a part of a list, or the <button> element makes it easy for a user of voice control software to interact by saying 'Click the button'.
Question 2 - How do you make sure your code is accessible from the start, without relying too much on extra tools or plugins?
Dilwoar Hussain, Lead Frontend Developer, Ministry of Housing, Communities and Local Government
Making a page accessible is more challenging if you don’t consider accessibility from the start. That’s why I follow best practices early on. I use clear headings, meaningful alt text, and ensure colour contrast meets WCAG standards. I also test with a keyboard and screen reader during development.
I work with designers and content writers early to flag potential issues that could impact users. Using well-tested patterns, like the GOV.UK Design System, helps ensure accessibility. This lets me focus on creating the best user experience while knowing each component meets high accessibility standards.
James Gordon, Senior Frontend Developer, Department for Work and Pensions
Keep it simple stupid, is a principle I code by. It starts with working with designers to ensure we aren’t creating something untenable, then implementing it in the simplest way possible with semantic html. Sticking to well tested patterns developed by experts, such as the GDS and DWP design systems helps us know we are starting on the right foot too.
Michael Cheung, Senior Front-end Developer, NHS England
I try keeping things as simple as possible. That always starts with hand-coding semantic HTML and using the appropriate HTML elements. I’ll have an idea of how the code should be but will often reference official HTML specifications and accessibility guidelines to ensure, for example, correct use of attributes and behaviours.
Making use of a browser’s inbuilt tools is very helpful. For example, looking at the accessibility tree within DevTools to see what assistive technologies see, zooming in and resizing text, or just using the keyboard to navigate, are all simple ways of testing code without relying on anything else.
Holly Blues, Front-end Developer, Department for Work and Pensions Digital
As a team we're all responsible for accessibility so from the Product Owner to Quality Assurance, and everyone in-between. This helps to keep accessibility at the forefront of our processes. The Government Design System components have been developed to give us a good starting point for creating accessible websites, with research and accessibility considered during their creation. This gives us a great start and provides consistent user journeys across our services, another win for accessible design and development. Before development starts we're looking out for components or features that might usually rely on client-side JavaScript and cause accessibility issues, such as filtering or paging controls, to see if there is an accessible pattern or component we can re-use.
David Biddle, Frontend Developer, Government Digital Services
I find it helpful to think about the accessibility as early as possible - for example the design stage think about how the feature should work in different assistive technologies and what you expect the service to be like for different users.
I'd then think about that when marking up the structure of the HTML, using the right semantic elements will provide a lot of cues to assistive technology, and browsers will provide some useful behaviour as well - for example, interactive elements will be focusable by default.
Question 3 - How do you approach making dynamic content (like modals, carousels, and forms) and interactive elements (like buttons and forms) accessible for keyboard and screen reader users?
Dilwoar Hussain, Lead Frontend Developer, Ministry of Housing, Communities and Local Government
I make pop-ups and buttons accessible by using proper HTML, ARIA attributes, and keyboard-friendly functionality. Collapsible elements, like dropdowns and accordions, are a great example since they let users expand and hide content as needed.
For collapsible elements, I ensure they can be controlled entirely with a keyboard. Users should be able to navigate to the trigger button with the Tab key and use Enter or Space to toggle the section. I use aria-expanded="true" when the content is visible and aria-expanded="false" when it is hidden. This lets screen readers announce whether the section is open or closed, providing clear feedback. I also use aria-controls to link the button to the content it affects, so assistive technologies can describe the relationship accurately.
A critical approach to accessibility is progressive enhancement, a development technique that ensures core functionality works in all situations, with additional features enhancing the experience when supported by the browser. This is particularly important for accessibility when JavaScript is unavailable. For collapsible elements, the non-JavaScript version typically displays all content while hiding interactive controls like buttons. This ensures that users can still access the information even if scripts do not load.
The GOV.UK Accordion component is a well-tested example of an accessible collapsible element, designed to work smoothly for both keyboard and screen reader users.
James Gordon, Senior Frontend Developer, Department for Work and Pensions
When creating something new it’s important to start with the simplest version, one with little to no javascript enhancements. This enables you to write as much of it as semantic as possible. Making interactive content accessible requires analysing all the times the content changes or wrestles control away from the user and flagging it up with aria live events as appropriate.
The only real way to know if what you have done will work is doing a prodigious amount of manual testing across different devices and technologies.
Michael Cheung, Senior Front-end Developer, NHS England
Rather than starting from scratch, I’ll check the NHS design system to see if it has what I need. It contains styles, components, and patterns that we use in the NHS and have been tested for accessibility.
If it isn’t in our design system, I’ll check someone else’s like those from other government departments. Another resource is the WAI Aria Authoring Practices Guide which has many accessible examples.
I’ll adapt what I find to my requirements and then test in our Accessibility Lab, which I help manage. It has a range of devices and assistive technology for testing.
Holly Blues, Front-end Developer, Department for Work and Pensions Digital
During development we keep the Document Object Model (DOM) in mind. The HTML has a hierarchy, so we ensure our code uses semantic HTML and follows the correct ordering. It's also important to produce clean HTML that the browser understands and can render without errors, for example by ensuring HTML tags are opened and closed.
Any dynamic content would have to adhere to the WCAG 2.2 accessibility standards. Using a combination of semantic html and appropriate ARIA attributes, we would ensure that keyboard or screen reader navigation would clearly highlight and focus on the navigable element and make announcements whenever the content changes.
David Biddle, Frontend Developer, Government Digital Services
I'd start by seeing if I can use a semantic element to get some of the functionality I'm looking for - for example, if I was working on a modal I'd look to use <dialog>. I'd also check whether the feature I was building was a pattern with an ARIA widget role - such as a list of tabs.
I'd ensure that any interactive elements were properly labelled, and that any interactions involving a mouse were also possible with a keyboard - including any click events, but also making sure that the user could navigate around and that their focus is clearly visible at all times.
Read more of our Unlocking Accessibility series.
If you enjoyed reading our Unlocking Accessibility series and would like to contribute to future posts you can reach us at accessibility-in-government-blog@digital.cabinet-office.gov.uk or, if you work in government, on the UK Government Digital Slack.
Please leave a comment if you are a frontend developer or just interested in the field and would like to give your thoughts on the questions above.
Leave a comment