From e86582844743021504b0775318561c17855c08b3 Mon Sep 17 00:00:00 2001 From: Frederike Ramin Date: Tue, 11 Feb 2025 13:19:04 +0100 Subject: [PATCH 1/2] doc(adr): Add non-javascript support adr --- doc/adr/0021-users-without-javascript.md | 48 ++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 doc/adr/0021-users-without-javascript.md diff --git a/doc/adr/0021-users-without-javascript.md b/doc/adr/0021-users-without-javascript.md new file mode 100644 index 000000000..f5b1721f7 --- /dev/null +++ b/doc/adr/0021-users-without-javascript.md @@ -0,0 +1,48 @@ +# 21. Supporting Users Without JavaScript + +Date: 2025-02-11 + +## Status + +Accepted + +## Context + +Currently, our application is built with the principle that core functionality should be accessible and usable even without client-side JavaScript. +This aligns with our goal of ensuring a resilient and broadly accessible experience. + +We recognize that "non-JS users" aren't just those with JavaScript disabled, but also include users with slow connections, JavaScript errors, or while the JavaScript is still downloading ([Everyone has JavaScript, right?](https://www.kryogenix.org/code/browser/everyonehasjs.html)). +However, we are now encountering situations where specific features, like the upcoming upload component or the auto-suggest input, require JavaScript to work intuitively. + +Our approach needs to address the balance between rich interactive features (requiring JavaScript) and the core usability for all users. +The GOV.UK Service Manual provides guides on how to best approach this in the governmental area (see [here](https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices) and [here](https://www.gov.uk/service-manual/technology/using-progressive-enhancement)). + +Our framework Remix is built with progressive enhancement in mind, providing a functional experience even during JavaScript loading or failures. + +## Decision + +We will adopt a **Progressive Enhancement** strategy for all features. +This means: + +1. **Core Functionality First:** All essential features must be fully functional and accessible without JavaScript. This ensures that every user, regardless of their JavaScript capabilities, can accomplish the primary tasks the application is designed for. + +2. **Enhancement with JavaScript:** JavaScript will be used to _enhance_ the user experience where appropriate. This allows us to add interactive elements, richer interfaces, and improved performance for users with JavaScript enabled. Examples include the auto-suggest input, dynamic form validation, and advanced UI components. + +3. **Graceful Degradation:** If JavaScript fails to load or execute, the enhanced features should degrade gracefully, ensuring that the core functionality remains intact. This might mean a less visually appealing or less interactive experience, but it should never result in broken or inaccessible functionality. Components should be designed in isolation to minimize the impact of JavaScript failures. + +4. **Testing Strategy:** Our testing strategy will include both JavaScript-enabled and JavaScript-disabled scenarios. This will ensure that we are continuously validating the accessibility and functionality of our application for all users. + +## Consequences: + +- **Positive:** + + - Improved accessibility for users with disabilities, limited bandwidth, or JavaScript disabled/unavailable. + - Increased resilience to network issues and JavaScript errors. + - Simplified testing of core functionality. + - Alignment with best practices for web development. + +- **Negative:** + + - Increased development effort for implementing features in both a non-JS and JS version (though this is mitigated by focusing on core functionality first). + - Potential limitations on the complexity of interactive features in non-JS mode. + - Requires a consistent and disciplined approach to development and testing to ensure adherence to the progressive enhancement strategy. From 2aea1433e3e3294ff2a780e9788190d96305821d Mon Sep 17 00:00:00 2001 From: Frederike Ramin Date: Tue, 11 Feb 2025 18:21:34 +0100 Subject: [PATCH 2/2] doc(adr): Restructure and add base link --- doc/adr/0021-users-without-javascript.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/adr/0021-users-without-javascript.md b/doc/adr/0021-users-without-javascript.md index f5b1721f7..1541a0bfe 100644 --- a/doc/adr/0021-users-without-javascript.md +++ b/doc/adr/0021-users-without-javascript.md @@ -13,15 +13,13 @@ This aligns with our goal of ensuring a resilient and broadly accessible experie We recognize that "non-JS users" aren't just those with JavaScript disabled, but also include users with slow connections, JavaScript errors, or while the JavaScript is still downloading ([Everyone has JavaScript, right?](https://www.kryogenix.org/code/browser/everyonehasjs.html)). However, we are now encountering situations where specific features, like the upcoming upload component or the auto-suggest input, require JavaScript to work intuitively. - Our approach needs to address the balance between rich interactive features (requiring JavaScript) and the core usability for all users. -The GOV.UK Service Manual provides guides on how to best approach this in the governmental area (see [here](https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices) and [here](https://www.gov.uk/service-manual/technology/using-progressive-enhancement)). Our framework Remix is built with progressive enhancement in mind, providing a functional experience even during JavaScript loading or failures. ## Decision -We will adopt a **Progressive Enhancement** strategy for all features. +We will adopt a [**Progressive Enhancement**](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement) strategy for all features. This means: 1. **Core Functionality First:** All essential features must be fully functional and accessible without JavaScript. This ensures that every user, regardless of their JavaScript capabilities, can accomplish the primary tasks the application is designed for. @@ -32,6 +30,8 @@ This means: 4. **Testing Strategy:** Our testing strategy will include both JavaScript-enabled and JavaScript-disabled scenarios. This will ensure that we are continuously validating the accessibility and functionality of our application for all users. +This is also suggested by the GOV.UK Service Manual for the governmental area (see [here](https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices) and [here](https://www.gov.uk/service-manual/technology/using-progressive-enhancement)). + ## Consequences: - **Positive:**