Avon and Somerset Police limits reliance on client side JavaScript as a conscious design choice. We do this to keep services accessible and reliable, and to make sure people can complete important tasks even when scripts do not run. As a public sector organisation, we are required to meet accessibility standards; how we meet them can be tested, evidenced and audited, so the way we build services needs to hold up under review, not only in principle.
Progressive enhancement means building the page so that HTML carries the core experience, then adding CSS for presentation and JavaScript for helpful behaviour where it is appropriate. Users should still be able to use the service when styling or scripting is missing, blocked or fails.
Developers may use JavaScript as part of development, for example for backend logic, integrations, and the tools used to build, test and release applications. That does not contradict the approach described here.
What this page addresses is client side JavaScript. That means script sent to the user’s browser to control interface behaviour. We are careful about how much essential user facing behaviour depends on that browser layer, because every user brings their own device, network, settings and extensions. That is separate from whether we use JavaScript in development.
HTML is comparatively fault tolerant by design: browsers can often still make sense of the page when markup is imperfect or includes unfamiliar elements. CSS is also partly fault tolerant, for example when individual declarations are not supported (though unsupported selectors can cause larger blocks of CSS to be skipped).
JavaScript is different. If a script hits an error, uses syntax that the browser does not support, or calls an API that is not available, execution can stop for that script (and sometimes for other scripts on the page that depend on it). Unlike HTML and CSS, there is no safe “ignore this line and carry on” behaviour for the running script as a whole. That is why depending on JavaScript for essential steps is risky for users and for the organisation.
JavaScript may not be available to every user, on every device, on every visit. Common reasons include:
Some people also use older or lower powered devices, or very slow connections, where heavy client side work performs poorly even when scripts do run. We plan for those situations rather than assuming ideal conditions.
When essential journeys are implemented only in JavaScript:
Single page applications, where navigation within a service is handled by JavaScript instead of the browser, are widely associated with accessibility and usability problems (for example context changes, focus, and use of the back and forward buttons). We avoid building our services that way.
Assistive technologies and keyboard users rely on a predictable document: semantic HTML, logical focus order, and native controls where possible. When critical behaviour is moved into custom JavaScript widgets:
Requiring JavaScript for core tasks therefore tends to increase the accessibility burden and the testing surface, while still leaving users exposed if the script layer fails. Our preference is to deliver the core journey in HTML (and server side processing where applicable), and to use JavaScript to enhance that baseline.
We apply the same standard for public, staff, partner and mixed audiences. How much we rely on client side JavaScript is a product and development choice, not something we dial up or down because a service is internal or external. Being internal is not grounds for heavy client side JavaScript where the core journey could still be HTML first. The ASP Digital Design System and frontend library are written for that single bar, including while the site and patterns are primarily used inside the team.
Who the end user is should not determine whether heavy client side script is acceptable, for example treating internal use as an informal exemption. Colleagues using internal systems face the same accessibility and reliability realities as anyone else, including assistive technology, situational needs, and corporate networks, VPNs, locked down browsers and extensions.
Our accessibility expectations for WCAG level AA are set out on our WCAG accessibility compliance page. We have also written related expectations into our Definition of done.