docs: update pattern documentation and add date and time article

apps/www/app/content/patterns/en/button-placement-and-order.mdx

@@ -1,7 +1,7 @@
 ---
 title: Button placement and order
 sidebar_title: Button placement
-category: Upcoming
+category: Upcoming patterns
 description: How can we create a more predictable and inclusive experience by standardizing button placement and order?
 partners: Digdir, Nav, Skatteetaten ++
 search_terms: placement, order

apps/www/app/content/patterns/en/consent-banner.mdx

@@ -0,0 +1,29 @@
+---
+title: Consent banner
+sidebar_title: Consent banner
+category: Upcoming patterns
+description: How can we ensure a holistic and accessible approach to managing consent for cookies and tracking technologies?
+partners: Digdir, Nav, Skatteetaten ++
+search_terms: consent banner, cookie banner, cookies, consent, privacy
+date: 2026-02-16
+order: 75
+---
+
+A consent banner should give users genuine control over their own data. At the same time, it must be clear, understandable and accessible to everyone. Today, this is handled differently across public services, both in terms of language, design, equal presentation of choices and technical implementation.
+
+A shared pattern for consent banners can contribute to:
+
+- A more consistent and recognisable user experience  
+- Equal presentation of choices, without manipulative design  
+- Improved accessibility and inclusive design  
+- Clearer distinction between necessary and optional technologies  
+- A shared understanding of recommended interaction and behaviour  
+
+<Card
+  data-color='warning'
+  variant="tinted"
+>
+**Work in progress** \
+A cross-agency working group is developing common guidelines and recommendations for this topic during spring 2026. We greatly appreciate input from anyone with relevant experience, insights or results from user testing. You are welcome to contribute in the related [GitHub discussion thread](https://github.com/digdir/designsystemet/discussions/1671).
+
+</Card>

apps/www/app/content/patterns/en/date-and-time.mdx

@@ -0,0 +1,109 @@
+---
+title: Ask users for date and time
+sidebar_title: Date and time
+category: Ask users for...
+description: Asking users for date and time is often solved in a more complicated way than necessary. In many situations, standard input fields are both faster to use and easier to understand than custom-built date pickers.
+partners: Digdir, Brønnøysundregistrene
+date: 2026-02-18
+order: 10
+---
+
+How you ask users for date and time should be based on the information you actually need. Some dates are easy to remember, such as a date of birth, while others must be read from documents or cards. In some situations, an approximate date is sufficient, or a date relative to today. In other cases, users need to choose a date or time from a predefined set of options.
+
+Avoid making the task more complicated than necessary. Custom-built date pickers often result in lower accessibility and more friction than simple text fields. They can be difficult to use with a keyboard, provide poor support for screen readers, and require unnecessary navigation when the user already knows the date.
+
+## Known dates
+
+When asking for well-known dates, such as a date of birth or wedding date, simple text inputs work well. Users already know the answer and often prefer to type it directly, rather than navigating through a calendar.
+
+Consider splitting the date into separate fields for day, month and year. This makes it easier to enter the date correctly and provides better support for assistive technologies. When asking users to enter a date exactly as it appears on a bank card, passport or other document, the fields should match the format shown in that document. This makes it easier to transfer the date accurately and reduces the risk of errors.
+
+<Story story="KnownDates" />
+
+In the example above, we use `inputmode="numeric"` to provide a numeric keyboard on mobile phones and tablets. We deliberately avoid using `type="number"` for day, month and year fields. `type="number"` is designed for numeric values that can be incremented or decremented, and introduces functionality such as spin buttons and automatic validation that is not always appropriate for dates. It can also create [accessibility issues (mozilla.org)](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/number#accessibility), including problems for screen reader users and unintended value changes.
+
+## Date from a predefined set of options
+
+If you know that users need to choose a date or time from a limited set of options, for example available appointments in the coming week, it may be more efficient to present these as ready-made choices.
+
+When the number of options is very limited, such as a few dates or times, [`Radio`](/en/components/docs/radio/overview) can be a good choice. It allows users to quickly select an option without having to type anything.
+
+<Story story="PredefinedOptions1EN" />
+
+### Let users narrow down the options
+
+When the number of options increases, a [`Select`](/en/components/docs/select/overview) can be useful to narrow down the list. Users can choose preferred weeks, days or time ranges, and then see the available options based on that selection.
+
+Note: The example below is not connected to an actual data source. It illustrates how users can narrow down the options before seeing the available appointments.
+
+<Story story="PredefinedOptions2EN" />
+
+You should only show options that have available appointments, and avoid disabling weeks without availability, as this may create confusion. Explain in advance that only weeks with available times are shown, so users understand why some weeks are not available to select.
+
+## Specific date in the near future or past
+
+In some cases, when users need to choose a specific date close to today, visual support can be helpful. An [`Input`](/en/components/docs/input/overview) with `type="date"` allows users to either enter the date directly or use the browser's built-in date picker. This often provides a good balance between flexibility and support.
+
+Support varies between browsers and devices in terms of functionality, appearance and interaction, but the solution is often more accessible and robust than custom-built alternatives.
+
+<Story story="NearFuturePastEN" />
+
+Be aware that `type="date"` is controlled by the user's operating system and regional settings, not by the language of the website. This can result in the date being displayed in a format the user does not expect. Consider whether additional clarity is needed, for example by displaying the selected date in plain text with the month written out in words, or by otherwise asking the user to confirm the date before it is saved.
+
+## Start and end date
+
+When users need to provide a period, the start date and end date should be clearly shown together. Use two separate fields and make it clear which date is which.
+
+Place the fields in a logical order and validate that the end date is not earlier than the start date. If the dates depend on each other, error messages should explain what is wrong and how the user can correct it.
+
+<Story story="StartEndDateEN" />
+
+## Time - start and end
+
+When users need to provide a time interval, such as opening hours or the duration of a meeting, an [`Input`](/en/components/docs/input/overview) with `type="time"` can be used. It allows users to enter the time directly, while the browser provides additional support.
+
+Use separate fields for start and end time, and display them clearly together.
+
+<Story story="StartEndTimeEN" />
+
+## Approximate date
+
+If users only need to provide month and year, they should be able to do exactly that. This is particularly relevant when the event took place a long time ago and users may not know the exact date.
+
+For example, you can allow users to enter an approximate date in a free text field, or provide separate fields for month and year only, as shown in the example below.
+
+<Story story="ApproximateDateEN" />
+
+## Date relative to another date
+
+In some situations, it is more natural to ask for dates relative to another date, for example when setting up a reminder. In these cases, it may be better to use a [`Select`](/en/components/docs/select/overview) to offer options such as “tomorrow”, “in 3 days” or “1 day before”. If the day of the week is important for the task, it should also be clearly displayed.
+
+<Story story="RelativeDateEN" />
+
+## Summary
+
+Start with the need and choose the solution that allows users to complete the task as quickly as possible. Standard text fields are often more accessible and faster to use than advanced date pickers.
+
+- Show ready-made options when the alternatives are limited  
+- Let users type when the answer is known  
+- Only ask for as precise a date and time as the situation requires  
+- Use built-in browser support rather than custom-built solutions  
+
+## Sources and relevant information
+
+- [Who needs a JavaScript date picker? (dbushell.com)](https://pikaday.dbushell.com/)
+- [Maybe You Don't Need a Date Picker (adrianroselli.com)](https://adrianroselli.com/2019/07/maybe-you-dont-need-a-date-picker.html)
+- [Ask users for dates (gov.uk)](https://design-system.service.gov.uk/patterns/dates/)
+
+<Contributors
+  authors={[
+    'Marianne Røsvik (Digdir)',
+    'Ole Martin Tangen Vad (Brønnøysundregistrene)',
+    'Roy Halvor Frimanslund (Brønnøysundregistrene)',
+    'Lasse Febakke Straum (Digdir)',
+    'Frank Dahle (Digdir)',
+    'Tobias Barsnes (Digdir)',
+    'Oddbjørn Øvernes (Digdir)',
+    'Michael Marszalek (Digdir)',
+  ]}
+/>