Accessibility from an engineering perspective
How SGDS builds accessibility into its engineering systems, from automated testing with Oobee to documentation and shared responsibility.
Accessibility as a national priority
Improving accessibility for persons with disabilities (PWDs) is a key priority under the Enabling Masterplan 2030. One of the goals is to enhance access to information and services for PWDs. As a design infrastructure and the building blocks of web applications, SGDS has a strong commitment to accessibility to ensure that all users, regardless of ability and device, have undeterred access to the websites and applications that are built with it.
Built into our systems, not an afterthought
Accessibility is built into our systems, not an afterthought. Starting from development phase, we take every possible permutation of usage in a component and run them through Oobee, a software tester that runs accessibility tests, optimised for screen readers.
Accessibility is built into our systems, not an afterthought. Starting from development phase, we take every possible permutation of usage in a component and run them through Oobee, a software tester that runs accessibility tests, optimised for screen readers.
Based on the test results of Oobee, we modify and recommend the accessible way of using the components. For example, certain components require the ariaLabel property to be forwarded down to the web component's shadow DOM element in order to pass accessibility testing. Every component we build passes the accessibility testing pipeline before it is published.
We then ensure our code documentation in Storybook and agent skills are compliant with the best recommendation by default.
Our components are rendered on this site, where we also run Oobee accessibility testing to verify that it works for end users.
How our architecture enforces it
The advantage of web components is the strictness of the shadow DOM. While users of other light DOM libraries like ShadCN or Mantine can freely modify a component's HTML semantics and ARIA attributes, the shadow DOM keeps these internals secure. This makes it straightforward for us to control accessibility within the shadow DOM.
However, we acknowledge that patterns in the light DOM are subjected to user modifications. While we cannot gate how developers use the component externally, we are dedicated to extend the accessibility testing to patterns, templates, and blocks. This includes covering various forms of component usage patterns as part of our roadmap.
For a deeper look at the engineering trade-offs behind our accessibility decisions, see our architecture decision record on declarative aria labels.
It takes two hands to clap
Using SGDS's building blocks does not magically make your entire application accessible. A website is made up of more than just components. For example, using the correct semantic HTML is crucial for accessibility but outside the control of the design system — such as when a developer places a div inside a list instead of using proper li elements.
It takes the joint responsibility and commitment of the design system and its users to ensure web pages are accessible.
An open invitation
We are aware that we may not get it right every time for every user, so we invite everyone to participate in this ongoing effort by submitting accessibility improvements via GitHub issues if you encounter them with SGDS.
Published July 2026
Singapore Government Design System
The Singapore Government Design System was developed to empower teams in creating fast, accessible and mobile-friendly digital services.