diff --git a/apps/www/app/content/best-practices/en/accessibility/disabled-states.mdx b/apps/www/app/content/best-practices/en/accessibility/disabled-states.mdx
new file mode 100644
index 0000000000..b7d6bbeded
--- /dev/null
+++ b/apps/www/app/content/best-practices/en/accessibility/disabled-states.mdx
@@ -0,0 +1,99 @@
+---
+title: Disabled states
+description: Why disabled states are challenging, and how to avoid them
+date: 2025-07-18
+author: Nav
+category: Accessibility
+published: true
+---
+
+Disabled states can be difficult for users to perceive and understand, which is why we recommend avoiding them in your solution. In this article, we look at technical details and alternative approaches. In cases where using disabled states is still relevant, we suggest harm-reducing measures.
+
+
+## What does WCAG say about disabled states?
+WCAG does not prohibit the use of disabled states. However, it is often the way such states are designed and implemented that leads to WCAG violations.
+
+What WCAG actually says is that “inactive components” are exempt from contrast requirements (1.4.3 and 1.4.11)... without defining what “inactive components” means. W3C’s “Understanding” articles, which are non-normative, clarify that disabled components do not need to meet contrast requirements.
+
+That said, all meaningful content on the page must be available to everyone. If your disabled component does not add meaning, it is probably best not to show it at all.
+
+
+## Why are disabled states problematic?
+
+Disabled states can be difficult to perceive. They are usually designed with low colour contrast and rely on a colour change as the only graphical means of communicating the state. This can be problematic not only for people with visual impairments, but also for those in bright surroundings or with poor-quality screens.
+
+If disabled elements have the same level of contrast as active ones, users may think they are interactive. They might try to click them, without receiving any response or explanation, and become stuck without understanding why. The reason an element is disabled is usually implicit, we do not explain why it is disabled. The user must guess, and they may guess wrong.
+
+In some cases, the user may not even notice when an element becomes active. For example, if activation occurs after filling in something higher up in a form and the button is out of sight, the user may not realise that the button has suddenly become available.
+
+Disabled states also do not receive keyboard focus, meaning screen reader and braille display users may miss them entirely.
+
+## Common use cases
+
+Designers mainly use disabled states in three situations:
+
+- To show that an option is not relevant at the moment, but may become relevant later.
+- To show that a form has not been correctly or fully completed.
+- To show that an element cannot be changed (“read only”).
+
+## Alternative solutions
+Fortunately, there are alternatives to using disabled states.
+
+### Form validation
+Considering using a disabled submit button as a form of validation? Instead, validate inline as usual, keep the button active, and show an error message when the user tries to submit the form.
+
+### Irrelevant choices
+If a choice is not relevant, it is usually better to remove the option altogether rather than disable it. You may also wish to provide the user with information about why the option is not available.
+
+### Read-only content
+Use plain text rather than disabling read-only input fields, optionally with additional information explaining why the content cannot be changed.
+
+## HTML and ARIA attributes
+HTML offers several ways to indicate that something is non-interactive, each with slightly different behaviour.
+
+### `disabled`
+
+Form elements with `disabled` are completely inactive. They cannot be focused with keyboard or mouse: they are skipped in the tab order, and the user cannot click them (no `onClick` event is fired). Browsers often change their appearance automatically. A disabled form field is also not submitted when the form is posted.
+
+If you set `disabled` on a ``, all controls within the group are disabled, except for the `` content.
+
+### `aria-disabled="true"`
+You can use `aria-disabled="true"` when an element does not support the built-in `disabled` attribute. Screen readers will announce the element as “dimmed” or “disabled”, helping the user understand that the function exists but is not currently available. Applying `aria-disabled="true"` to a grouping (e.g. ` ` or `role="radiogroup"`) tells assistive technologies that the whole group is disabled.
+
+As with other ARIA attributes, only the semantics change, not the behaviour: the element can still receive focus via keyboard or mouse. You therefore need to prevent the action or provide clear feedback if the user tries to activate it. The benefit is that keyboard and screen reader users discover the function; the drawback is that they may still attempt to use it, so you must handle this in code.
+
+### `readonly`
+`readonly` only applies to input types where the value can be changed by the user, i.e. `textarea` and text inputs (text, search, email, etc.). It cannot be used on a radio group or fieldset. Fields with `readonly` remain in the tab order, and users can copy content but not change it. Data in `readonly` fields is submitted with the form.
+
+Input fields with `readonly` receive no default styling that distinguishes them from regular editable fields. This can be confusing if users do not understand why they cannot change the content. If you choose to use `readonly`, make sure to style the field differently from normal text fields and explain why the content cannot be changed.
+
+### `aria-readonly="true"`
+For form elements other than text inputs and `textarea`, you can use `aria-readonly="true"`. This attribute is most relevant for custom components, when you want to communicate to assistive technologies that the element is read-only. `aria-readonly="true"` can be applied to a group, though support is inconsistent.
+
+As with all ARIA attributes, `aria-readonly` only changes semantics, not functionality. You must ensure that users cannot change the values of elements marked with `aria-readonly`.
+
+### CSS `pointer-events: none`
+Developers are sometimes tempted to “disable” an element visually using CSS, for example by adding a semi-transparent overlay or by setting `pointer-events: none` to block mouse clicks. The element remains keyboard focusable and will be perceived as active by screen readers.
+
+## Harm reduction
+When you must display a disabled control, make it both visible and clear.
+
+Ensure the component can be perceived and understood by everyone, including people with visual impairments, assistive technology users, those on devices with poor screens, those in bright environments, as well as people with limited digital skills or cognitive impairments. The state should stand out from active elements without fading into the background. You may add an icon, pattern, or other indicator. At the same time, the element should still look like a control, otherwise nobody will know the function exists.
+
+Always explain why the control is disabled, and what is required to enable it. Place the explanation directly in the interface, not only on hover, so that everyone gets the information regardless of device or assistive technology. This prevents guesswork and avoids users trying to use something that cannot be used.
+
+Ultimately, our main recommendation remains: avoid disabled states whenever possible, by designing the solution so that users do not encounter a blocked path without explanation.
+
+
+
+Denne artikkelen ble opprinnelig publisert på [aksel.nav.no](https://aksel.nav.no/god-praksis/artikler/deaktiverte-tilstander), skrevet av Sarah Brodwall. Den er gjengitt her med tillatelse og tilpasset for bruk i Designsystemet.
+
+
+
+## Hva sier WCAG om deaktiverte tilstander?
+
+WCAG forbyr ikke bruk av deaktiverte tilstander. Derimot er det ofte måten slike tilstander designes og implementeres på som bryter WCAG.
+
+Det WCAG faktisk sier er at «inaktive komponenter» er unntatt fra kontrastkravene (1.4.3 og 1.4.11)...uten å definere hva «inaktive komponenter» betyr. W3Cs «Understanding»-artikler, som ikke er normative, presiserer at deaktiverte komponenter ikke trenger å oppfylle kontrastkravene.
+
+Når det er sagt, skal alt meningsbærende innhold på siden være tilgjengelig for alle. Hvis den deaktiverte komponenten din ikke tilfører mening, er det trolig best å ikke vise den i det hele tatt.
+
+## Hvorfor er deaktiverte tilstander problematiske?
+
+Deaktiverte tilstander kan være vanskelig å oppfatte. De er vanligvis designet med lav fargekontrast og med en endring i farge som det eneste grafiske virkemiddelet for å kommunisere tilstanden. Dette kan være problematisk ikke bare for folk som er svaksynte, men også folk som sitter i lysrike omgivelser eller som har dårlig skjerm.
+
+Hvis deaktiverte elementer har like høy kontrast som aktive, kan brukeren tro at de faktisk kan brukes. Da prøver de å klikke, uten å få respons eller forklaring, og kan bli stående fast uten å skjønne hvorfor. Grunnen til at et element er deaktivert er vanligvis implisitt—vi forklarer ikke hvorfor elementet er deaktivert. Brukeren må gjette, det kan hende at de gjetter feil.
+
+I noen tilfeller kan brukeren heller ikke få med seg når elementet blir aktivt. For eksempel, hvis aktiveringen skjer etter at brukeren har fylt ut noe lengre oppe på skjemaet og knappen er utenfor synsfeltet, risikerer man at brukeren ikke legger merke til at knappen plutselig ble tilgjengelig.
+
+Deaktiverte tilstander mottar heller ikke tastaturfokus, og leselist- og skjermleserbrukere kan gå glipp av dem.
+
+## Vanlige bruksområder
+
+Designere bruker deaktiverte tilstander hovedsakelig i tre forskjellige situasjoner:
+
+- For å vise at et valg ikke er relevant per det tidspunktet, men kan bli relevant i fremtiden.
+- For å vise at et skjema ikke er utfylt riktig eller ikke er ferdig utfylt ennå.
+- For å vise at et element ikke kan endres («read only»).
+
+## Alternative løsninger
+Heldigvis så finnes det alternativer til bruk av deaktiverte tilstander.
+
+### Skjemavalidering
+Vurderer du å bruke en deaktivert submit-knapp som en form for skjemavalidering? Du bør heller validere inline som vanlig, la knappen forbli aktiv og vise en feilmelding når brukeren prøver å sende inn skjemaet.
+
+### Ikke-aktuelle valg
+Hvis et valg ikke er relevant, bør du helst fjerne valget fremfor å deaktivere det. Tilby gjerne brukeren informasjon om hvorfor valget ikke er tilgjengelig.
+
+### Skrivebeskyttet innhold
+Bruk vanlig tekst fremfor å deaktivere skrivebeskyttede inputfelter, eventuelt med tilleggsinformasjon som forteller hvorfor informasjonen ikke kan endres.
+
+
+
+
+
+ Bruksområde
+
+
+ Problem med disabled
+
+
+ Anbefalt løsning
+
+
+
+
+
+
+ Skjemavalidering
+
+
+ Brukeren får ikke sendt inn skjema og vet ikke hvorfor
+
+
+ La knappen være aktiv, vis feilmelding
+
+
+
+
+ Ikke-aktuelle valg
+
+
+ Lav kontrast eller uklart hvorfor valget ikke fungerer
+
+
+ Fjern valget, gi forklaring
+
+
+
+
+ Skrivebeskyttet innhold
+
+
+ Brukeren forstår ikke hvorfor feltet ikke kan endres
+
+
+ Bruk tekst eller readonly med tydelig styling og forklaring
+
+
+
+
+
+## HTML- og ARIA-attributter
+HTML tilbyr ulike måter å markere at noe er ikke-interaktivt, og de har litt forskjellig oppførsel.
+
+### `disabled`
+
+Skjemaelementer med `disabled` blir helt inaktive. De kan ikke fokuseres med tastatur eller mus: de kommer ikke med i tabrekkefølgen, og brukeren kan ikke klikke på dem (dvs. det blir ingen `onClick`-event utløst). Nettleseren endrer ofte utseendet automatisk. Et deaktivert skjemafelt blir heller ikke sendt med når skjemaet postes.
+
+Setter du `disabled` på et ``, blir alle kontrollene inni grupperingen deaktivert, bortsett fra innholdet i ``-elementet.
+
+### `aria-disabled="true"`
+Det er mulig å bruke `aria-disabled="true"` når et element ikke støtter det innebygde `disabled`-attributtet. Skjermlesere vil da lese opp elementet som «dimmet» eller «deaktivert», slik at brukeren skjønner at funksjonen finnes, men ikke er tilgjengelig akkurat nå. `aria-disabled="true"` på en gruppering (for eksempel ` ` eller `role="radiogroup"`) gir hjelpemiddelteknologi beskjed om at hele gruppen er deaktivert.
+
+Akkurat som med andre ARIA-attributteter er det bare semantikken som endres, ikke oppførselen: elementet kan fortsatt få fokus via tastatur og mus. Derfor må du selv stoppe handlingen eller gi klar tilbakemelding hvis brukeren prøver å aktivere elementet. Fordelen er at tastatur- og skjermleserbrukere oppdager funksjonen; ulempen er at de fortsatt kan forsøke å klikke, så du må håndtere dette i koden.
+
+### `readonly`
+`readonly` er bare relevant for inputtyper som har en value som kan endres av brukeren, dvs. `textarea` og tekstfelter (text, search, email, osv.). Attributtet kan derfor ikke brukes på en radiogruppe eller fieldset. Felter med `readonly`-attributtet kommer i tabrekkefølgen, og brukere kan kopiere innholdet men ikke endre det. Informasjon i `readonly`-felter kommer med når skjemaet sendes inn.
+
+Inputfelter med `readonly`-attributtet får ingen default styling som skiller dem ut fra vanlige, redigerbare felter. Dette kan være svært forvirrende for folk hvis de ikke skjønner hvorfor de ikke kan endre innholdet i feltet. Hvis du velger å bruke readonly, sørg for at du styler feltet annerledes fra vanlige tekstfelter og forklarer for folk hvorfor innholdet ikke kan endres.
+
+### `aria-readonly="true"`
+For andre skjemaelementer enn tekstfelter og `textarea` kan du bruke `aria-readonly="true"`. Attributtet er mest relevant for custom komponenter, når du ønsker å kommunisere til hjelpemidler at elementet er skrivebeskyttet. `aria-readonly="true"` kan settes på en gruppe, men støtten er ujevn.
+
+Ta i betraktning at som med all ARIA, er det bare semantikken som blir endret av `aria-readonly`, ikke funksjonaliteten. Det vil si at du selv må sørge for at brukere ikke kan endre verdien til elementene `aria-readonly` brukes på.
+
+### CSS `pointer-events: none`
+Utviklere fristes noen ganger til å "deaktivere" et element rent visuelt via CSS, for eksempel ved å legge et semi-transparent lag over eller sette pointer-events: none for å blokkere museklikk. Elementet forblir fokuserbart med tastatur og vil bli oppfattet som aktivt av skjermlesere.
+
+## Skadereduksjon
+Når du likevel må vise en deaktivert kontroll, gjør den både synlig og tydelig.
+
+Sørg for at komponenten kan oppfattes og forstås av alle, inkludert folk som er svaksynte og de som bruker hjelpemiddelteknologi, folk som bruker enheter med dårlig skjerm og de som sitter i omgivelser med sterk lys, i tillegg til folk som ikke er datakyndige og folk med kognitiv funksjonsnedsettelse. Tilstanden skal skille seg fra aktive elementer uten å forsvinne i bakgrunnen. Legg gjerne til et ikon, mønster eller annen måte å markere tilstanden på. Samtidig må elementet fortsatt se ut som en kontroll, ellers vet ingen at funksjonen finnes.
+
+Fortell alltid hvorfor kontrollen er deaktivert, og hva som trengs for å aktivere den. Plasser forklaringen rett i grensesnittet, ikke kun på hover, så alle får informasjonen uansett enhet eller hjelpemiddel. Da slipper brukeren å gjette, og du unngår at noen forsøker å bruke noe som ikke kan brukes.
+
+Uansett, vårt overordnede råd står ved lag: unngå deaktiverte tilstander der det er mulig, ved heller å designe løsningen slik at brukeren slipper å møte en veg sperret uten forklaring.
+
+
+