diff --git a/README.md b/README.md
index 316984c71..960bce677 100644
--- a/README.md
+++ b/README.md
@@ -262,7 +262,7 @@ Currently, the [Intro to Storybook tutorial](https://storybook.js.org/tutorials/
 |              | Spanish          | ❌      |
 |              | Portuguese       | ❌      |
 |              | Japanese         | ❌      |
-| Svelte       | English          | ❌      |
+| Svelte       | English          | ✅      |
 |              | Spanish          | ❌      |
 
 ---
diff --git a/content/intro-to-storybook/index.md b/content/intro-to-storybook/index.md
index 48c0f7678..058fabd68 100644
--- a/content/intro-to-storybook/index.md
+++ b/content/intro-to-storybook/index.md
@@ -16,6 +16,7 @@ toc:
     'screen',
     'deploy',
     'test',
+    'accessibility-testing',
     'using-addons',
     'conclusion',
     'contribute',
diff --git a/content/intro-to-storybook/svelte/en/accessibility-testing.md b/content/intro-to-storybook/svelte/en/accessibility-testing.md
new file mode 100644
index 000000000..c5f4c0af2
--- /dev/null
+++ b/content/intro-to-storybook/svelte/en/accessibility-testing.md
@@ -0,0 +1,75 @@
+---
+title: 'Accessibility tests'
+tocTitle: 'Accessibility Testing'
+description: 'Learn how to integrate accessibility tests into your workflow'
+---
+
+So far, we've been focused on building our UI components with a strong emphasis on functionality and visual testing, adding complexity as we go. But we've not yet addressed an important aspect of UI development: accessibility.
+
+## Why Accessibility (A11y)?
+
+Accessibility ensures that all users can interact effectively with our components regardless of their abilities. This includes users with visual, auditory, motor, or cognitive impairments. Accessibility is not only the right thing to do, but it's increasingly mandated based on legal requirements and industry standards. Given these requirements, we must test our components for accessibility issues early and often.
+
+## Catch accessibility issues with Storybook
+
+Storybook provides an [Accessibility addon](https://storybook.js.org/addons/@storybook/addon-a11y) (A11y) that helps you test the accessibility of your components. Built on top of [axe-core](https://github.com/dequelabs/axe-core), it can catch up to [57% of WCAG issues](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/).
+
+Let's see how it works! Run the following command to install the addon:
+
+```shell
+yarn exec storybook add @storybook/addon-a11y
+```
+
+<div class="aside">
+
+💡 Storybook's `add` command automates the addon's installation and configuration. See the [official documentation](https://storybook.js.org/docs/api/cli-options) to learn more about the other available commands.
+
+</div>
+
+Restart your Storybook to see the new addon enabled in the UI.
+
+![Task accessibility issue in Storybook](/intro-to-storybook/accessibility-issue-task-non-react-9-0.png)
+
+Cycling through our stories, we can see that the addon found an accessibility issue with one of our test states. The [**Color contrast**](https://dequeuniversity.com/rules/axe/4.10/color-contrast?application=axeAPI) violation essentially means there isn't enough contrast between the task title and the background. We can quickly fix it by changing the text color to a darker gray in our application's CSS (located in `src/index.css`).
+
+```diff:title=src/index.css
+.list-item.TASK_ARCHIVED input[type="text"] {
+- color: #a0aec0;
++ color: #4a5568;
+ text-decoration: line-through;
+}
+```
+
+That's it. We've taken the first step to ensure our UI remains accessible. However, our job isn't finished yet. Maintaining an accessible UI is an ongoing process, and we should monitor our UI for any new accessibility issues to prevent regressions from being introduced as our app evolves and our UIs gain complexity.
+
+## Accessibility tests with Chromatic
+
+With Storybook's accessibility addon, we can test and get instant feedback on accessibility issues during development. However, keeping track of accessibility issues can be challenging, and prioritizing which issues to address first may require a dedicated effort. This is where Chromatic can help us. As we've already seen, it helped us [visually test](/intro-to-storybook/svelte/en/test/) our components to prevent regressions. We'll use its [accessibility testing feature](https://www.chromatic.com/docs/accessibility) to ensure our UI remains accessible and we don't accidentally introduce new violations.
+
+### Enable accessibility tests
+
+Go to your Chromatic project and navigate to the **Manage** page. Click the **Enable** button to activate accessibility tests for your project.
+
+![Chromatic accessibility tests enabled](/intro-to-storybook/chromatic-a11y-tests-enabled.png)
+
+### Run accessibility tests
+
+Now that we've enabled accessibility testing and fixed the color contrast issue in our CSS, let's push our changes to trigger a new Chromatic build.
+
+```shell:clipboard=false
+git add .
+git commit -m "Fix color contrast accessibility violation"
+git push
+```
+
+When Chromatic runs, it establishes the [accessibility baselines](https://www.chromatic.com/docs/accessibility/#what-is-an-accessibility-baseline) as the starting point against which future tests will compare their results. This allows us to prioritize, address, and fix accessibility issues more effectively without introducing new regressions.
+
+<!--
+
+TODO: Follow up with Design for an updated asset
+ - Needs a React and non-React version to ensure parity with the tutorial
+ -->
+
+![Chromatic build with accessibility tests](/intro-to-storybook/chromatic-build-a11y-tests.png)
+
+We've now successfully built a workflow that ensures our UI remains accessible at each stage of development. Storybook will help us catch accessibility issues during development, while Chromatic keeps track of accessibility regressions, making it easier to fix them incrementally over time.
diff --git a/content/intro-to-storybook/svelte/en/composite-component.md b/content/intro-to-storybook/svelte/en/composite-component.md
index 97b84fcb7..d9c58c10f 100644
--- a/content/intro-to-storybook/svelte/en/composite-component.md
+++ b/content/intro-to-storybook/svelte/en/composite-component.md
@@ -18,42 +18,59 @@ Since `Task` data can be sent asynchronously, we **also** need a loading state t
 
 ## Get set up
 
-A composite component isn’t much different from the basic components it contains. Create a `TaskList` component, an auxiliary component to help us display the correct markup, and an accompanying story file: `src/components/TaskList.svelte`, `src/components/MarginDecorator.svelte`, and `src/components/TaskList.stories.js`.
+A composite component isn’t much different from the basic components it contains. Create a `TaskList` component, an auxiliary component to help us display the correct markup, and an accompanying story file: `src/lib/components/TaskList.svelte`, `src/lib/components/MarginDecorator.svelte`, and `src/lib/components/TaskList.stories.svelte`.
 
 Start with a rough implementation of the `TaskList`. You’ll need to import the `Task` component from earlier and pass in the attributes and actions as inputs.
 
-```html:title=src/components/TaskList.svelte
-<script>
+```html:title=src/lib/components/TaskList.svelte
+<script lang="ts">
+  import type { TaskData } from '../../types';
+
   import Task from './Task.svelte';
 
-  /* Sets the loading state */
-  export let loading = false;
+  interface Props {
+    /** Checks if it's in loading state */
+    loading?: boolean;
+    /** The list of tasks */
+    tasks: TaskData[];
+    /** Event to change the task to pinned */
+    onPinTask: (id: string) => void;
+    /** Event to change the task to archived */
+    onArchiveTask: (id: string) => void;
+  }
 
-  /* Defines a list of tasks */
-  export let tasks = [];
+  const {
+    loading = false,
+    tasks = [],
+    onPinTask,
+    onArchiveTask,
+  }: Props = $props();
 
-  /* Reactive declaration (computed prop in other frameworks) */
-  $: noTasks = tasks.length === 0;
-  $: emptyTasks = noTasks && !loading;
+  const noTasks = $derived(tasks.length === 0);
 </script>
 
 {#if loading}
   <div class="list-items">loading</div>
 {/if}
-{#if emptyTasks}
+
+{#if !loading && noTasks}
   <div class="list-items">empty</div>
 {/if}
+
 {#each tasks as task}
-  <Task {task} on:onPinTask on:onArchiveTask />
+  <Task {task} {onPinTask} {onArchiveTask} />
 {/each}
-
 ```
 
 Next, create `MarginDecorator` with the following inside:
 
-```html:title=src/components/MarginDecorator.svelte
+```html:title=src/lib/components/MarginDecorator.svelte
+<script>
+  let { children } = $props();
+</script>
+
 <div>
-  <slot />
+  {@render children()}
 </div>
 
 <style>
@@ -65,74 +82,73 @@ Next, create `MarginDecorator` with the following inside:
 
 Finally, create `Tasklist`’s test states in the story file.
 
-```js:title=src/components/TaskList.stories.js
-import TaskList from './TaskList.svelte';
+```html:title=src/lib/components/TaskList.stories.svelte
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
 
-import MarginDecorator from './MarginDecorator.svelte';
+  import TaskList from './TaskList.svelte';
+  import MarginDecorator from './MarginDecorator.svelte';
 
-import * as TaskStories from './Task.stories';
+  import * as TaskStories from './Task.stories.svelte';
 
-export default {
-  component: TaskList,
-  title: 'TaskList',
-  tags: ['autodocs'],
-  //👇 The auxiliary component will be added as a decorator to help show the UI correctly
-  decorators: [() => MarginDecorator],
-  render: (args) => ({
-    Component: TaskList,
-    props: args,
-    on: {
-      ...TaskStories.actionsData,
-    },
-  }),
-};
+  export const TaskListData = [
+    { ...TaskStories.TaskData, id: '1', title: 'Task 1' },
+    { ...TaskStories.TaskData, id: '2', title: 'Task 2' },
+    { ...TaskStories.TaskData, id: '3', title: 'Task 3' },
+    { ...TaskStories.TaskData, id: '4', title: 'Task 4' },
+    { ...TaskStories.TaskData, id: '5', title: 'Task 5' },
+    { ...TaskStories.TaskData, id: '6', title: 'Task 6' },
+  ];
 
-export const Default = {
-  args: {
-    // Shaping the stories through args composition.
-    // The data was inherited from the Default story in task.stories.js.
-    tasks: [
-      { ...TaskStories.Default.args.task, id: '1', title: 'Task 1' },
-      { ...TaskStories.Default.args.task, id: '2', title: 'Task 2' },
-      { ...TaskStories.Default.args.task, id: '3', title: 'Task 3' },
-      { ...TaskStories.Default.args.task, id: '4', title: 'Task 4' },
-      { ...TaskStories.Default.args.task, id: '5', title: 'Task 5' },
-      { ...TaskStories.Default.args.task, id: '6', title: 'Task 6' },
-    ],
-  },
-};
+  const { Story } = defineMeta({
+    component: TaskList,
+    title: 'TaskList',
+    tags: ['autodocs'],
+    excludeStories: /.*Data$/,
+    decorators: [() => MarginDecorator],
+    args: {
+      ...TaskStories.TaskData.events,
+    },
+  });
+</script>
 
-export const WithPinnedTasks = {
-  args: {
-    // Shaping the stories through args composition.
-    // Inherited data coming from the Default story.
+<Story
+  name="Default"
+  args={{
+    tasks: TaskListData,
+     loading: false,
+  }}
+/>
+<Story
+  name="WithPinnedTasks"
+  args={{
     tasks: [
-      ...Default.args.tasks.slice(0, 5),
+      ...TaskListData.slice(0, 5),
       { id: '6', title: 'Task 6 (pinned)', state: 'TASK_PINNED' },
     ],
-  },
-};
+  }}
+/>
 
-export const Loading = {
-  args: {
+<Story
+  name="Loading"
+  args={{
     tasks: [],
     loading: true,
-  },
-};
-
-export const Empty = {
-  args: {
-    // Shaping the stories through args composition.
-    // Inherited data coming from the Loading story.
-    ...Loading.args,
+  }}
+/>
+
+<Story
+  name="Empty"
+  args={{
+    tasks: TaskListData.slice(0, 0),
     loading: false,
-  },
-};
+  }}
+/>
 ```
 
 <div class="aside">
 
-[**Decorators**](https://storybook.js.org/docs/writing-stories/decorators) are a way to provide arbitrary wrappers to stories. In this case we’re using a decorator `key` on the default export to add styling around the rendered component. They can also be used to add other context to components.
+[**Decorators**](https://storybook.js.org/docs/writing-stories/decorators) are a way to provide arbitrary wrappers to stories. In this case, we're using Svelte's CSF's `decorators` property to add styling around the rendered component. They can also be used to add other context to components.
 
 </div>
 
@@ -142,7 +158,7 @@ Now check Storybook for the new `TaskList` stories.
 
 <video autoPlay muted playsInline loop>
   <source
-    src="/intro-to-storybook/inprogress-tasklist-states-7-0.mp4"
+    src="/intro-to-storybook/inprogress-tasklist-states-9-0.mp4"
     type="video/mp4"
   />
 </video>
@@ -155,9 +171,9 @@ For the loading edge case, we will create a new component that will display the
 
 Create a new file called `LoadingRow.svelte` and inside add the following markup:
 
-```html:title=src/components/LoadingRow.svelte
+```html:title=src/lib/components/LoadingRow.svelte
 <div class="loading-item">
-  <span class="glow-checkbox" />
+  <span class="glow-checkbox"></span>
   <span class="glow-text">
     <span>Loading</span>
     <span>cool</span>
@@ -168,28 +184,40 @@ Create a new file called `LoadingRow.svelte` and inside add the following markup
 
 And update `TaskList.svelte` to the following:
 
-```html:title=src/components/TaskList.svelte
-<script>
+```html:title=src/lib/components/TaskList.svelte
+<script lang="ts">
+  import type { TaskData } from '../../types';
+
   import Task from './Task.svelte';
   import LoadingRow from './LoadingRow.svelte';
 
-  /* Sets the loading state */
-  export let loading = false;
+  interface Props {
+    /** Checks if it's in loading state */
+    loading?: boolean;
+    /** The list of tasks */
+    tasks: TaskData[];
+    /** Event to change the task to pinned */
+    onPinTask: (id: string) => void;
+    /** Event to change the task to archived */
+    onArchiveTask: (id: string) => void;
+  }
 
-  /* Defines a list of tasks */
-  export let tasks = [];
+  const {
+    loading = false,
+    tasks = [],
+    onPinTask,
+    onArchiveTask,
+  }: Props = $props();
 
-  /* Reactive declaration (computed prop in other frameworks) */
-  $: noTasks = tasks.length === 0;
-  $: emptyTasks = noTasks && !loading;
-  $: tasksInOrder = [
+  const noTasks = $derived(tasks.length === 0);
+  const tasksInOrder = $derived([
     ...tasks.filter((t) => t.state === 'TASK_PINNED'),
-    ...tasks.filter((t) => t.state !== 'TASK_PINNED')
-  ];
+    ...tasks.filter((t) => t.state !== 'TASK_PINNED'),
+  ]);
 </script>
 
 {#if loading}
-  <div class="list-items">
+  <div class="list-items" data-testid="loading" id="loading">
     <LoadingRow />
     <LoadingRow />
     <LoadingRow />
@@ -197,17 +225,18 @@ And update `TaskList.svelte` to the following:
     <LoadingRow />
   </div>
 {/if}
-{#if emptyTasks}
+{#if !loading && noTasks}
   <div class="list-items">
     <div class="wrapper-message">
-      <span class="icon-check" />
+      <span class="icon-check"></span>
       <p class="title-message">You have no tasks</p>
       <p class="subtitle-message">Sit back and relax</p>
     </div>
   </div>
 {/if}
+
 {#each tasksInOrder as task}
-  <Task {task} on:onPinTask on:onArchiveTask />
+  <Task {task} {onPinTask} {onArchiveTask} />
 {/each}
 ```
 
@@ -215,7 +244,7 @@ The added markup results in the following UI:
 
 <video autoPlay muted playsInline loop>
   <source
-    src="/intro-to-storybook/finished-tasklist-states-7-0.mp4"
+    src="/intro-to-storybook/finished-tasklist-states-9-0.mp4"
     type="video/mp4"
   />
 </video>
diff --git a/content/intro-to-storybook/svelte/en/data.md b/content/intro-to-storybook/svelte/en/data.md
index 03740ef72..10957eba8 100644
--- a/content/intro-to-storybook/svelte/en/data.md
+++ b/content/intro-to-storybook/svelte/en/data.md
@@ -12,89 +12,99 @@ This tutorial doesn’t focus on the particulars of building an app, so we won
 
 Our `TaskList` component as currently written is “presentational” in that it doesn’t talk to anything external to its own implementation. To get data into it, we need a “container”.
 
-This example uses [Svelte's Stores](https://svelte.dev/docs/svelte-store), Svelte's default data management API, to build a simple data model for our app. However, the pattern used here applies just as well to other data management libraries like [Apollo](https://www.apollographql.com/client/) and [MobX](https://mobx.js.org/).
+For this tutorial, we'll use Svelte's [runes](https://svelte.dev/docs/svelte/what-are-runes), a powerful reactivity system that provides explicit, fine-grained reactive primitives to implement a simple store. We'll use the [`$state`](https://svelte.dev/docs/svelte/$state) rune to build a simple data model for our application and help us manage the state of our tasks.
 
-First, we’ll construct a simple Svelte store that responds to actions that change the state of tasks in a file called `store.js` in the `src` directory (intentionally kept simple):
+First, we’ll construct a simple store that responds to actions that change the state of tasks in a file called `store.svelte.ts` in the `src/lib/state` directory (intentionally kept simple):
 
-```js:title=src/store.js
-// A simple Svelte store implementation with update methods and initial data.
+```ts:title=src/lib/state/store.svelte.ts
+// A simple Svelte state management implementation using runes update methods and initial data.
 // A true app would be more complex and separated into different files.
+import type { TaskData } from '../../types';
 
-import { writable } from 'svelte/store';
+interface TaskBoxState {
+  tasks: TaskData[];
+  status: 'idle' | 'loading' | 'failed' | 'succeeded';
+  error: string | null;
+}
 /*
  * The initial state of our store when the app loads.
  * Usually, you would fetch this from a server. Let's not worry about that now
  */
-const defaultTasks = [
+const defaultTasks: TaskData[] = [
   { id: '1', title: 'Something', state: 'TASK_INBOX' },
   { id: '2', title: 'Something more', state: 'TASK_INBOX' },
   { id: '3', title: 'Something else', state: 'TASK_INBOX' },
   { id: '4', title: 'Something again', state: 'TASK_INBOX' },
 ];
 
-const TaskBox = () => {
-  // Creates a new writable store populated with some initial data
-  const { subscribe, update } = writable({
-    tasks: defaultTasks,
-    status: 'idle',
-    error: false,
-  });
-
-  return {
-    subscribe,
-    // Method to archive a task, think of a action with redux or Pinia
-    archiveTask: (id) =>
-      update((store) => {
-        const filteredTasks = store.tasks
-          .map((task) =>
-            task.id === id ? { ...task, state: 'TASK_ARCHIVED' } : task
-          )
-          .filter((t) => t.state === 'TASK_INBOX' || t.state === 'TASK_PINNED');
-
-        return { ...store, tasks: filteredTasks };
-      }),
-    // Method to archive a task, think of a action with redux or Pinia
-    pinTask: (id) => {
-      update((store) => {
-        const task = store.tasks.find((t) => t.id === id);
-        if (task) {
-          task.state = 'TASK_PINNED';
-        }
-        return store;
-      });
-    },
-  };
+const initialState: TaskBoxState = {
+  tasks: defaultTasks,
+  status: 'idle',
+  error: null,
 };
-export const taskStore = TaskBox();
+
+
+export const store = $state<TaskBoxState>(initialState);
+
+// Function that archives a task
+export function archiveTask(id: string) {
+  const filteredTasks = store.tasks
+    .map((task): TaskData =>
+      task.id === id ? { ...task, state: 'TASK_ARCHIVED' as TaskData['state'] } : task
+    )
+    .filter((t) => t.state === 'TASK_INBOX' || t.state === 'TASK_PINNED');
+  store.tasks = filteredTasks;
+}
+
+// Function that pins a task
+export function pinTask(id: string) {
+  const task = store.tasks.find((task) => task.id === id);
+  if (task) {
+    task.state = 'TASK_PINNED';
+  }
+}
 ```
 
-Then we'll update our `TaskList` to read data out of the store. First, let's move our existing presentational version to the file `src/components/PureTaskList.svelte` and wrap it with a container.
+Then we'll update our `TaskList` to read data out of the store. First, let's move our existing presentational version to the file `src/lib/components/PureTaskList.svelte` and wrap it with a container.
 
-In `src/components/PureTaskList.svelte`:
+In `src/lib/components/PureTaskList.svelte`:
 
-```html:title=src/components/PureTaskList.svelte
+```html:title=src/lib/components/PureTaskList.svelte
 <!--This file moved from TaskList.svelte-->
-<script>
+<script lang="ts">
+  import type { TaskData } from '../../types';
+
   import Task from './Task.svelte';
+
   import LoadingRow from './LoadingRow.svelte';
 
-  /* Sets the loading state */
-  export let loading = false;
+  interface Props {
+    /** Checks if it's in loading state */
+    loading?: boolean;
+    /** The list of tasks */
+    tasks: TaskData[];
+    /** Event to change the task to pinned */
+    onPinTask: (id: string) => void;
+    /** Event to change the task to archived */
+    onArchiveTask: (id: string) => void;
+  }
 
-  /* Defines a list of tasks */
-  export let tasks = [];
+  const {
+    loading = false,
+    tasks = [],
+    onPinTask,
+    onArchiveTask,
+  }: Props = $props();
 
-  /* Reactive declaration (computed prop in other frameworks) */
-  $: noTasks = tasks.length === 0;
-  $: emptyTasks = noTasks && !loading;
-  $: tasksInOrder = [
+  const noTasks = $derived(tasks.length === 0);
+  const tasksInOrder = $derived([
     ...tasks.filter((t) => t.state === 'TASK_PINNED'),
     ...tasks.filter((t) => t.state !== 'TASK_PINNED'),
-  ];
+  ]);
 </script>
 
 {#if loading}
-  <div class="list-items">
+  <<div class="list-items" data-testid="loading" id="loading">
     <LoadingRow />
     <LoadingRow />
     <LoadingRow />
@@ -102,111 +112,107 @@ In `src/components/PureTaskList.svelte`:
     <LoadingRow />
   </div>
 {/if}
-{#if emptyTasks}
+{#if !loading && noTasks}
   <div class="list-items">
     <div class="wrapper-message">
-      <span class="icon-check" />
+      <span class="icon-check"></span>
       <p class="title-message">You have no tasks</p>
       <p class="subtitle-message">Sit back and relax</p>
     </div>
   </div>
 {/if}
+
 {#each tasksInOrder as task}
-  <Task {task} on:onPinTask on:onArchiveTask />
+  <Task {task} {onPinTask} {onArchiveTask} />
 {/each}
 ```
 
-In `src/components/TaskList.svelte`:
+In `src/lib/components/TaskList.svelte`:
 
-```html:title=src/components/TaskList.svelte
-<script>
-  import PureTaskList from './PureTaskList.svelte';
-  import { taskStore } from '../store';
+```html:title=src/lib/components/TaskList.svelte
+<script lang="ts">
+  import { archiveTask, pinTask, store } from '../state/store.svelte';
 
-  function onPinTask(event) {
-    taskStore.pinTask(event.detail.id);
-  }
-  function onArchiveTask(event) {
-    taskStore.archiveTask(event.detail.id);
-  }
+  import PureTaskList from './PureTaskList.svelte';
 </script>
 
 <PureTaskList
-  tasks={$taskStore.tasks}
-  on:onPinTask={onPinTask}
-  on:onArchiveTask={onArchiveTask}
+  loading={store.status === "loading"}
+  tasks={store.tasks}
+  onPinTask={pinTask}
+  onArchiveTask={archiveTask}
 />
 ```
 
-The reason to keep the presentational version of the `TaskList` separate is that it is easier to test and isolate. As it doesn't rely on the presence of a store, it is much easier to deal with from a testing perspective. Let's rename `src/components/TaskList.stories.js` into `src/components/PureTaskList.stories.js` and ensure our stories use the presentational version:
-
-```js:title=src/components/PureTaskList.stories.js
-import PureTaskList from './PureTaskList.svelte';
-import MarginDecorator from './MarginDecorator.svelte';
-
-import * as TaskStories from './Task.stories';
-
-export default {
-  component: PureTaskList,
-  title: 'PureTaskList',
-  tags: ['autodocs'],
-  //👇 The auxiliary component will be added as a decorator to help show the UI correctly
-  decorators: [() => MarginDecorator],
-  render: (args) => ({
-    Component: PureTaskList,
-    props: args,
-    on: {
-      ...TaskStories.actionsData,
-    },
-  }),
-};
+The reason to keep the presentational version of the `TaskList` separate is that it is easier to test and isolate. As it doesn't rely on the presence of a store, it is much easier to deal with from a testing perspective. Let's rename `src/lib/components/TaskList.stories.svelte` into `src/lib/components/PureTaskList.stories.svelte` and ensure our stories use the presentational version:
 
-export const Default = {
-  args: {
-    // Shaping the stories through args composition.
-    // The data was inherited from the Default story in task.stories.js.
-    tasks: [
-      { ...TaskStories.Default.args.task, id: '1', title: 'Task 1' },
-      { ...TaskStories.Default.args.task, id: '2', title: 'Task 2' },
-      { ...TaskStories.Default.args.task, id: '3', title: 'Task 3' },
-      { ...TaskStories.Default.args.task, id: '4', title: 'Task 4' },
-      { ...TaskStories.Default.args.task, id: '5', title: 'Task 5' },
-      { ...TaskStories.Default.args.task, id: '6', title: 'Task 6' },
-    ],
-  },
-};
+```html:title=src/lib/components/PureTaskList.stories.svelte
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
+
+  import PureTaskList from './PureTaskList.svelte';
+  import MarginDecorator from './MarginDecorator.svelte';
+
+  import * as TaskStories from './Task.stories.svelte';
+
+  export const TaskListData = [
+    { ...TaskStories.TaskData, id: '1', title: 'Task 1' },
+    { ...TaskStories.TaskData, id: '2', title: 'Task 2' },
+    { ...TaskStories.TaskData, id: '3', title: 'Task 3' },
+    { ...TaskStories.TaskData, id: '4', title: 'Task 4' },
+    { ...TaskStories.TaskData, id: '5', title: 'Task 5' },
+    { ...TaskStories.TaskData, id: '6', title: 'Task 6' },
+  ];
+
+  const { Story } = defineMeta({
+    component: PureTaskList,
+    title: 'PureTaskList',
+    tags: ['autodocs'],
+    excludeStories: /.*Data$/,
+    decorators: [() => MarginDecorator],
+    args: {
+      ...TaskStories.TaskData.events,
+    },
+  });
+</script>
 
-export const WithPinnedTasks = {
-  args: {
-    // Shaping the stories through args composition.
-    // Inherited data coming from the Default story.
+<Story
+  name="Default"
+  args={{
+    tasks: TaskListData,
+    loading: false,
+  }}
+/>
+<Story
+  name="WithPinnedTasks"
+  args={{
     tasks: [
-      ...Default.args.tasks.slice(0, 5),
+      ...TaskListData.slice(0, 5),
       { id: '6', title: 'Task 6 (pinned)', state: 'TASK_PINNED' },
     ],
-  },
-};
+  }}
+/>
 
-export const Loading = {
-  args: {
+<Story
+  name="Loading"
+  args={{
     tasks: [],
     loading: true,
-  },
-};
+  }}
+/>
 
-export const Empty = {
-  args: {
-    // Shaping the stories through args composition.
-    // Inherited data coming from the Loading story.
-    ...Loading.args,
+<Story
+  name="Empty"
+  args={{
+    tasks: TaskListData.slice(0, 0),
     loading: false,
-  },
-};
+  }}
+/>
 ```
 
 <video autoPlay muted playsInline loop>
   <source
-    src="/intro-to-storybook/finished-puretasklist-states-7-0.mp4"
+    src="/intro-to-storybook/finished-puretasklist-states-9-0.mp4"
     type="video/mp4"
   />
 </video>
diff --git a/content/intro-to-storybook/svelte/en/deploy.md b/content/intro-to-storybook/svelte/en/deploy.md
index 2f088fd14..311ac5651 100644
--- a/content/intro-to-storybook/svelte/en/deploy.md
+++ b/content/intro-to-storybook/svelte/en/deploy.md
@@ -2,7 +2,6 @@
 title: 'Deploy Storybook'
 tocTitle: 'Deploy'
 description: 'Learn how to deploy Storybook online'
-commit: '73f95be'
 ---
 
 Throughout this tutorial, we built components on our local development machine. At some point, we'll need to share our work to get team feedback. Let's deploy Storybook online to help teammates review UI implementation.
@@ -66,7 +65,14 @@ yarn chromatic --project-token=<project-token>
 
 When finished, you'll get a link `https://random-uuid.chromatic.com` to your published Storybook. Share the link with your team to get feedback.
 
-![Storybook deployed with chromatic package](/intro-to-storybook/chromatic-manual-storybook-deploy.png)
+<!--
+ TOOO:
+   - Follow up Design to get updated versions of this assets
+     - One for non-React versions that showcase the same structure (i.e., Task, PureTaskList and InboxScreen)
+     - One for React that showcases the following structure (i.e., Task, TaskList and InboxScreen)
+ -->
+
+![Storybook deployed with chromatic package](/intro-to-storybook/chromatic-manual-storybook-deploy-non-react.png)
 
 Hooray! We published Storybook with one command, but manually running a command every time we want to get feedback on UI implementation is repetitive. Ideally, we'd publish the latest version of components whenever we push code. We'll need to continuously deploy Storybook.
 
diff --git a/content/intro-to-storybook/svelte/en/get-started.md b/content/intro-to-storybook/svelte/en/get-started.md
index f0e452a04..296226872 100644
--- a/content/intro-to-storybook/svelte/en/get-started.md
+++ b/content/intro-to-storybook/svelte/en/get-started.md
@@ -40,9 +40,15 @@ yarn dev
 
 Our main frontend app modalities: component development (Storybook), and the application itself.
 
-<!-- Needs to be updated and the link updated to ![Main modalities](/intro-to-storybook/app-main-modalities-svelte.png) -->
+<!--
 
-![3 modalities](/intro-to-storybook/app-three-modalities-svelte.png)
+TODO:
+- Update the image  to include the default Vite start screen and updated Storybook UI
+- Link and description updated to ![Main modalities](/intro-to-storybook/app-main-modalities-svelte.png)
+
+-->
+
+![3 modalities](/intro-to-storybook/app-main-modalities-svelte.png)
 
 Depending on what part of the app you’re working on, you may want to run one or more of these simultaneously. Since our current focus is creating a single UI component, we’ll stick with running Storybook.
 
diff --git a/content/intro-to-storybook/svelte/en/screen.md b/content/intro-to-storybook/svelte/en/screen.md
index 1157335c0..8be86f8ef 100644
--- a/content/intro-to-storybook/svelte/en/screen.md
+++ b/content/intro-to-storybook/svelte/en/screen.md
@@ -8,113 +8,133 @@ We've concentrated on building UIs from the bottom up, starting small and adding
 
 In this chapter, we continue to increase the sophistication by combining components in a screen and developing that screen in Storybook.
 
-## Nested container components
+## Connected pages
 
-As our app is straightforward, the screen we’ll build is pretty trivial, simply wrapping the `TaskList` component (which supplies its own data via Svelte Store) in some layout and pulling a top-level `error` field out of the store (let's assume we'll set that field if we have some problem connecting to our server).
+As our application is straightforward, the screen we'll build is pretty trivial. It simply fetches data from a remote API, wraps the `TaskList` component (which supplies its own data via a custom store using the `$state` rune) in some layout, and pulls a top-level `error` field out of the store (let's assume we'll set that field if we have some problem connecting to our server).
 
-Let's start by updating our Svelte store (in `src/store.js`) to include our new `error` field we want:
+We'll start by updating our store (in `src/lib/state/store.svelte.ts`) to connect to a remote API and handle the various states for our application (i.e., `error`, `succeeded`):
 
-```diff:title=src/store.js
-// A simple Svelte store implementation with update methods and initial data.
+```ts:title=src/lib/state/store.svelte.ts
+// A simple Svelte state management implementation using runes update methods and initial data.
 // A true app would be more complex and separated into different files.
+import type { TaskData } from '../../types';
 
-import { writable } from "svelte/store";
-
-/*
- * The initial state of our store when the app loads.
- * Usually, you would fetch this from a server. Let's not worry about that now
- */
-const defaultTasks = [
-  { id: '1', title: 'Something', state: 'TASK_INBOX' },
-  { id: '2', title: 'Something more', state: 'TASK_INBOX' },
-  { id: '3', title: 'Something else', state: 'TASK_INBOX' },
-  { id: '4', title: 'Something again', state: 'TASK_INBOX' },
-];
-
-const TaskBox = () => {
-  // Creates a new writable store populated with some initial data
-  const { subscribe, update } = writable({
-    tasks: defaultTasks,
-    status: 'idle',
-    error: false,
-  });
-  return {
-    subscribe,
-    // Method to archive a task, think of a action with redux or Pinia
-    archiveTask: (id) =>
-      update((store) => {
-        const filteredTasks = store.tasks
-          .map((task) =>
-            task.id === id ? { ...task, state: 'TASK_ARCHIVED' } : task
-          )
-          .filter((t) => t.state === 'TASK_INBOX' || t.state === 'TASK_PINNED');
-
-        return { ...store, tasks: filteredTasks };
-      }),
-    // Method to archive a task, think of a action with redux or Pinia
-    pinTask: (id) => {
-      update((store) => {
-        const task = store.tasks.find((t) => t.id === id);
-        if (task) {
-          task.state = 'TASK_PINNED';
-        }
-        return store;
-      });
-    },
-+   isError: () => update((store) => ({ ...store, error: true })),
-  };
+interface TaskBoxState {
+  tasks: TaskData[];
+  status: 'idle' | 'loading' | 'failed' | 'succeeded';
+  error: string | null;
+}
+
+const initialState: TaskBoxState = {
+  tasks: [],
+  status: 'idle',
+  error: null,
 };
-export const taskStore = TaskBox();
+
+
+export const store = $state<TaskBoxState>(initialState);
+
+// Function that fetches tasks from the API to populate the store
+export async function fetchTasks() {
+  store.status = 'loading';
+  try {
+    const response = await fetch('https://jsonplaceholder.typicode.com/todos?userId=1');
+    const data = await response.json();
+    // Transform the data to match the TaskData type
+    const result = data.map(
+      (task: { id: number; title: string; completed: boolean }) => ({
+        id: `${task.id}`,
+        title: task.title,
+        state: task.completed ? 'TASK_ARCHIVED' : 'TASK_INBOX',
+      })
+    ).filter(
+      (task: TaskData) => task.state === 'TASK_INBOX' || task.state === 'TASK_PINNED');
+
+
+    store.tasks = result;
+    store.status = 'succeeded';
+  } catch (error) {
+    if (error && typeof error === 'object' && 'message' in error) {
+      store.error = (error as { message: string }).message;
+    } else {
+      store.error = String(error);
+    }
+    store.status = 'failed';
+  }
+}
+
+// Function that archives a task
+export function archiveTask(id: string) {
+  const filteredTasks = store.tasks
+    .map((task): TaskData =>
+      task.id === id ? { ...task, state: 'TASK_ARCHIVED' as TaskData['state'] } : task
+    )
+    .filter((t) => t.state === 'TASK_INBOX' || t.state === 'TASK_PINNED');
+  store.tasks = filteredTasks;
+}
+
+// Function that pins a task
+export function pinTask(id: string) {
+  const task = store.tasks.find((task) => task.id === id);
+  if (task) {
+    task.state = "TASK_PINNED";
+  }
+}
 ```
 
-Now that we have the store updated with the new field. Let's create `InboxScreen.svelte` in your `components` directory:
+Now that we've updated our store to retrieve the data from a remote API endpoint and prepared it to handle the various states of our app, let's create our `InboxScreen.svelte` in the `src/lib/components` directory:
+
+```html:title=src/lib/components/InboxScreen.svelte
+<script lang="ts">
+  import TaskList from './TaskList.svelte';
+
+  import { fetchTasks, store } from '../state/store.svelte';
 
-```html:title=src/components/InboxScreen.svelte
-<script>
-  import TaskList from "./TaskList.svelte";
-  export let error = false;
+  $effect(() => {
+    fetchTasks();
+  });
 </script>
 
-<div>
-  {#if error}
-    <div class="page lists-show">
-      <div class="wrapper-message">
-        <span class="icon-face-sad" />
-        <p class="title-message">Oh no!</p>
-        <p class="subtitle-message">Something went wrong</p>
-      </div>
-    </div>
-  {:else}
-    <div class="page lists-show">
-      <nav>
-        <h1 class="title-page">Taskbox</h1>
-      </nav>
-      <TaskList />
+{#if store.status === "failed"}
+  <div class="page lists-show">
+    <div class="wrapper-message">
+      <span class="icon-face-sad"></span>
+      <p class="title-message">Oh no!</p>
+      <p class="subtitle-message">Something went wrong</p>
     </div>
-  {/if}
-</div>
+  </div>
+{:else}
+  <div class="page lists-show">
+    <nav>
+      <h1 class="title-page">Taskbox</h1>
+    </nav>
+    <TaskList />
+  </div>
+{/if}
 ```
 
 We also need to change the `App` component to render the `InboxScreen` (eventually, we would use a router to choose the correct screen, but let's not worry about that here):
 
 ```html:title=src/App.svelte
-<script>
-  import InboxScreen from './components/InboxScreen.svelte';
-  import { taskStore } from './store';
+<script lang="ts">
+  import InboxScreen from "./lib/components/InboxScreen.svelte";
 </script>
 
-<InboxScreen error={$taskStore.error} />
+<InboxScreen />
 ```
 
-And finally, the `src/main.js`:
+And finally, the `src/main.ts`:
+
+```diff:title=src/main.ts
+import { mount } from 'svelte';
 
-```diff:title=src/main.js
 - import './app.css';
 + import './index.css';
+
 import App from './App.svelte';
 
-const app = new App({
-  target: document.getElementById("app"),
+const app = mount(App, {
+  target: document.getElementById('app')!,
 });
 
 export default app;
@@ -122,29 +142,127 @@ export default app;
 
 However, where things get interesting is in rendering the story in Storybook.
 
-As we saw previously, the `TaskList` component is a **container** that renders the `PureTaskList` presentational component. By definition, container components cannot be simply rendered in isolation; they expect to be passed some context or connected to a service. What this means is that to render a container in Storybook, we must mock (i.e., provide a pretend version) the context or service it requires.
+As we saw previously, the `TaskList` component is a **container** that renders the `PureTaskList` presentational component. By definition, container components cannot be rendered in isolation; they expect to be passed some context or connected to a service. What this means is that to render a container in Storybook, we must mock the context or service it requires.
 
-When placing the `TaskList` into Storybook, we were able to dodge this issue by simply rendering the `PureTaskList` and avoiding the container. We'll do something similar and render the `InboxScreen` in Storybook also.
+When placing the `TaskList` into Storybook, we were able to dodge this issue by simply rendering the `PureTaskList` and avoiding the container. However, as our application grows, it quickly becomes unmanageable to keep the connected components out of Storybook and create presentational components for each. As our `InboxScreen` is a connected component, we'll need to provide a way to mock the store and the data it provides.
 
-So when we set up our stories in `InboxScreen.stories.js`:
+So when we set up our stories in `InboxScreen.stories.svelte`:
 
-```js:title=src/components/InboxScreen.stories.js
-import InboxScreen from './InboxScreen.svelte';
+```html:title=src/lib/components/InboxScreen.stories.svelte
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
 
-export default {
-  component: InboxScreen,
-  title: 'InboxScreen',
-  tags: ['autodocs'],
-};
+  import InboxScreen from './InboxScreen.svelte';
+
+  const { Story } = defineMeta({
+    component: InboxScreen,
+    title: 'InboxScreen',
+    tags: ['autodocs'],
+  });
+</script>
+
+<Story name="Default" />
+
+<Story name="Error" />
+
+```
+
+We can quickly spot an issue with the `Error` story. Instead of displaying the right state, it shows a list of tasks. We could easily apply the same approach as in the last chapter. Instead, we'll use a well-known API mocking library alongside a Storybook addon to help us solve this issue.
+
+<!-- TODO:
+  - Follow up with Design to get an updated image for both permutations
+    - Non-react version that shows the same structure as below
+    - React version that showcases Task, TaskList, and InboxScreen
+-->
+
+![Broken inbox screen state](/intro-to-storybook/broken-inbox-error-state-9-0-non-react.png)
+
+## Mocking API services
+
+As our application is pretty straightforward and doesn't depend too much on remote API calls, we're going to use [Mock Service Worker](https://mswjs.io/) and [Storybook's MSW addon](https://storybook.js.org/addons/msw-storybook-addon). Mock Service Worker is an API mocking library. It relies on service workers to capture network requests and provides mocked data in responses.
+
+When we set up our app in the [Get started section](/intro-to-storybook/svelte/en/get-started) both packages were also installed. All that remains is to configure them and update our stories to use them.
+
+In your terminal, run the following command to generate a generic service worker inside your `public` folder:
+
+```shell
+yarn init-msw
+```
+
+Then, we'll need to update our `.storybook/preview.ts` and initialize them:
+
+```diff:title=.storybook/preview.ts
+import type { Preview } from '@storybook/svelte-vite';
 
-export const Default = {};
+import '../src/index.css';
 
-export const Error = {
-  args: { error: true },
++ import { initialize, mswLoader } from 'msw-storybook-addon';
+
+// Registers the msw addon
++ initialize();
+
+const preview: Preview = {
+  parameters: {
+    controls: {
+      matchers: {
+        color: /(background|color)$/i,
+        date: /Date$/i,
+      },
+    },
+  },
++ loaders: [mswLoader],
 };
+
+export default preview;
 ```
 
-We see that both the `Error` and `Default` stories work just fine.
+Finally, update the `InboxScreen` stories and include a [parameter](https://storybook.js.org/docs/writing-stories/parameters) that mocks the remote API calls:
+
+```diff:title=src/lib/components/InboxScreen.stories.svelte
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
+
++ import { http, HttpResponse } from 'msw';
+
+  import InboxScreen from './InboxScreen.svelte';
+
+  import * as PureTaskListStories from './PureTaskList.stories.svelte';
+
+  const { Story } = defineMeta({
+    component: InboxScreen,
+    title: 'InboxScreen',
+    tags: ['autodocs'],
+  });
+</script>
+
+<Story
+  name="Default"
++   parameters={{
++     msw: {
++       handlers: [
++         http.get('https://jsonplaceholder.typicode.com/todos?userId=1', () => {
++           return HttpResponse.json(PureTaskListStories.TaskListData);
++         }),
++       ],
++     },
++   }}
+/>
+
+<Story
+  name="Error"
++  parameters={{
++     msw: {
++       handlers: [
++         http.get('https://jsonplaceholder.typicode.com/todos?userId=1', () => {
++           return new HttpResponse(null, {
++             status: 403,
+          });
++         }),
++       ],
++     },
++   }}
+/>
+```
 
 <div class="aside">
 
@@ -152,119 +270,123 @@ We see that both the `Error` and `Default` stories work just fine.
 
 </div>
 
-Cycling through states in Storybook makes it easy to test we’ve done this correctly:
+Check your Storybook, and you'll see that the `Error` story is now working as intended. MSW intercepted our remote API call and provided the appropriate response.
 
 <video autoPlay muted playsInline loop >
   <source
-    src="/intro-to-storybook/finished-inbox-screen-states-svelte-7-0.mp4"
+    src="/intro-to-storybook/inbox-screen-with-msw-addon-non-react-9.0.mp4"
     type="video/mp4"
   />
 </video>
 
-## Component tests
+## Interaction tests
 
 So far, we've been able to build a fully functional application from the ground up, starting from a simple component up to a screen and continuously testing each change using our stories. But each new story also requires a manual check on all the other stories to ensure the UI doesn't break. That's a lot of extra work.
 
 Can't we automate this workflow and test our component interactions automatically?
 
-### Write a component test using the play function
+### Write an interaction test using the play function
 
-Storybook's [`play`](https://storybook.js.org/docs/writing-stories/play-function) and [`@storybook/addon-interactions`](https://storybook.js.org/docs/writing-tests/interaction-testing) help us with that. A play function includes small snippets of code that run after the story renders.
+Storybook's [`play`](https://storybook.js.org/docs/writing-stories/play-function) can help us with that. A play function includes small snippets of code that run after the story renders. It uses framework-agnostic DOM APIs, meaning we can write stories with the play function to interact with the UI and simulate human behavior, regardless of the frontend framework. We'll use them to verify that the UI behaves as expected when we update our tasks.
 
-The play function helps us verify what happens to the UI when tasks are updated. It uses framework-agnostic DOM APIs, which means we can write stories with the play function to interact with the UI and simulate human behavior no matter the frontend framework.
+Update your newly created `InboxScreen` story, and set up component interactions by adding the following:
 
-The `@storybook/addon-interactions` helps us visualize our tests in Storybook, providing a step-by-step flow. It also offers a handy set of UI controls to pause, resume, rewind, and step through each interaction.
+```diff:title=src/lib/components/InboxScreen.stories.svelte
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
 
-Let's see it in action! Update your newly created `InboxScreen` story, and set up component interactions by adding the following:
+  import { http, HttpResponse } from 'msw';
 
-```diff:title=src/components/InboxScreen.stories.js
-import InboxScreen from './InboxScreen.svelte';
++ import { waitFor, waitForElementToBeRemoved } from 'storybook/test';
 
-+ import { fireEvent, within } from '@storybook/test';
-
-export default {
-  component: InboxScreen,
-  title: 'InboxScreen',
-  tags: ['autodocs'],
-};
+  import InboxScreen from './InboxScreen.svelte';
 
-export const Default = {};
+  import * as PureTaskListStories from './PureTaskList.stories.svelte';
 
-export const Error = {
-  args: { error: true },
-};
+  const { Story } = defineMeta({
+    component: InboxScreen,
+    title: 'InboxScreen',
+    tags: ['autodocs'],
+  });
+</script>
 
-+ export const WithInteractions = {
-+  play: async ({ canvasElement }) => {
-+    const canvas = within(canvasElement);
-+    // Simulates pinning the first task
-+    await fireEvent.click(canvas.getByLabelText('pinTask-1'));
-+    // Simulates pinning the third task
-+    await fireEvent.click(canvas.getByLabelText('pinTask-3'));
-+  },
-+ };
+<Story
+  name="Default"
+  parameters={{
+    msw: {
+      handlers: [
+        http.get('https://jsonplaceholder.typicode.com/todos?userId=1', () => {
+          return HttpResponse.json(PureTaskListStories.TaskListData);
+        }),
+      ],
+    },
+  }}
++ play={async ({ canvas, userEvent }) => {
++   await waitForElementToBeRemoved(await canvas.findByTestId("loading"));
++   await waitFor(async () => {
++     await userEvent.click(canvas.getByLabelText("pinTask-1"));
++     await userEvent.click(canvas.getByLabelText("pinTask-3"));
++   });
++ }}
+/>
+
+<Story
+  name="Error"
+  parameters={{
+    msw: {
+      handlers: [
+        http.get('https://jsonplaceholder.typicode.com/todos?userId=1', () => {
+          return new HttpResponse(null, {
+            status: 403,
+          });
+        }),
+      ],
+    },
+  }}
+/>
 ```
 
 <div class="aside">
 
-💡 The `@storybook/test` package replaces the `@storybook/jest` and `@storybook/testing-library` testing packages, offering a smaller bundle size and a more straightforward API based on the [Vitest](https://vitest.dev/) package.
+💡 The `Interactions` panel helps us visualize our tests in Storybook, providing a step-by-step flow. It also offers a handy set of UI controls to pause, resume, rewind, and step through each interaction.
 
 </div>
 
-Check your newly created story. Click the `Interactions` panel to see the list of interactions inside the story's play function.
+Check the `Default` story. Click the `Interactions` panel to see the list of interactions inside the story's play function.
 
 <video autoPlay muted playsInline loop>
   <source
-    src="/intro-to-storybook/storybook-interactive-stories-play-function-svelte.mp4"
+    src="/intro-to-storybook/storybook-play-function-non-react.mp4"
     type="video/mp4"
   />
 </video>
 
-### Automate tests with the test runner
+### Automate test with the Vitest addon
 
-With Storybook's play function, we were able to sidestep our problem, allowing us to interact with our UI and quickly check how it responds if we update our tasks—keeping the UI consistent at no extra manual effort.
+With the play function, we were able to quickly simulate user interactions with our component and verify how it behaves when we update our tasks—keeping the UI consistent. However, if we look into our Storybook, we can see that our interaction tests only run when viewing the story. This means that if we make a change, we still have to go through each story to run all checks manually. Couldn't we automate it?
 
-But, if we take a closer look at our Storybook, we can see that it only runs the interaction tests when viewing the story. Therefore, we'd still have to go through each story to run all checks if we make a change. Couldn't we automate it?
+We can! Storybook's [Vitest addon](https://storybook.js.org/docs/writing-tests/integrations/vitest-addon) allows us to run our interaction tests in a more automated way, leveraging the power of Vitest for a faster and more efficient testing experience. Let's see how it works!
 
-The good news is that we can! Storybook's [test runner](https://storybook.js.org/docs/writing-tests/test-runner) allows us to do just that. It's a standalone utility—powered by [Playwright](https://playwright.dev/)—that runs all our interactions tests and catches broken stories.
+With your Storybook running, click the "Run Tests" in the sidebar. This will run tests on our stories, how they render, their behavior, and the interactions defined in the play function, including the one we just added to the `InboxScreen` story.
 
-Let's see how it works! Run the following command to install it:
-
-```shell
-yarn add --dev @storybook/test-runner
-```
-
-Next, update your `package.json` `scripts` and add a new test task:
-
-```json:clipboard=false
-{
-  "scripts": {
-    "test-storybook": "test-storybook"
-  }
-}
-```
-
-Finally, with your Storybook running, open up a new terminal window and run the following command:
-
-```shell
-yarn test-storybook --watch
-```
+<video autoPlay muted playsInline loop>
+  <source
+    src="/intro-to-storybook/storybook-vitest-addon-non-react.mp4"
+    type="video/mp4"
+  />
+</video>
 
 <div class="aside">
 
-💡 Component testing with the play function is a fantastic way to test your UI components. It can do much more than we've seen here; we recommend reading the [official documentation](https://storybook.js.org/docs/writing-tests/component-testing) to learn more about it.
-
-For an even deeper dive into testing, check out the [Testing Handbook](/ui-testing-handbook). It covers testing strategies used by scaled-front-end teams to supercharge your development workflow.
+💡 The Vitest addon can do much more than we've seen here, including other types of testing. We recommend reading the [official documentation](https://storybook.js.org/docs/writing-tests/integrations/vitest-addon) to learn more about it.
 
 </div>
 
-![Storybook test runner successfully runs all tests](/intro-to-storybook/storybook-test-runner-execution.png)
-
-Success! Now we have a tool that helps us verify whether all our stories are rendered without errors and all assertions pass automatically. What's more, if a test fails, it will provide us with a link that opens up the failing story in the browser.
+Now, we have a tool that helps us automate our UI testing without the need for manual checks. This is a great way to ensure that our UI remains consistent and functional as we continue to build out our application. What's more, if our tests fail, we'll be notified immediately, allowing us to fix any outstanding issues quickly and easily.
 
 ## Component-Driven Development
 
-We started from the bottom with `Task`, then progressed to `TaskList`, now we’re here with a whole screen UI. Our `InboxScreen` accommodates a nested container component and includes accompanying stories.
+We started from the bottom with `Task`, then progressed to `TaskList`, now we’re here with a whole screen UI. Our `InboxScreen` accommodates connected components and includes accompanying stories.
 
 <video autoPlay muted playsInline loop style="width:480px; height:auto; margin: 0 auto;">
   <source
diff --git a/content/intro-to-storybook/svelte/en/simple-component.md b/content/intro-to-storybook/svelte/en/simple-component.md
index e9baad38b..c201e226d 100644
--- a/content/intro-to-storybook/svelte/en/simple-component.md
+++ b/content/intro-to-storybook/svelte/en/simple-component.md
@@ -19,41 +19,44 @@ As we start to build `Task`, we first write our test states that correspond to t
 
 ## Get set up
 
-First, let’s create the task component and its accompanying story file: `src/components/Task.svelte` and `src/components/Task.stories.js`.
+First, let’s create the task component and its accompanying story file: `src/lib/components/Task.svelte` and `src/lib/components/Task.stories.svelte`.
 
 We’ll begin with a baseline implementation of the `Task`, simply taking in the attributes we know we’ll need and the two actions you can take on a task (to move it between lists):
 
-```html:title=src/components/Task.svelte
-<script>
-  import { createEventDispatcher } from 'svelte';
-
-  const dispatch = createEventDispatcher();
-
-  /** Event handler for the Pin Task */
-  function PinTask() {
-    dispatch('onPinTask', {
-      id: task.id,
-    });
-  }
+```html:title=src/lib/components/Task.svelte
+<script lang="ts">
+  type TaskData = {
+    id?: string;
+    title?: string;
+    state: 'TASK_ARCHIVED' | 'TASK_INBOX' | 'TASK_PINNED';
+  };
 
-  /** Event handler for the Archive Task */
-  function ArchiveTask() {
-    dispatch('onArchiveTask', {
-      id: task.id,
-    });
+  interface Props {
+    task: TaskData;
+    onArchiveTask: (id: string) => void;
+    onPinTask: (id: string) => void;
   }
 
-  /** Composition of the task */
-  export let task = {
-    id: '',
-    title: '',
-    state: '',
-  };
+  const {
+    task = {
+      id: '',
+      title: '',
+      state: 'TASK_INBOX',
+    },
+    onArchiveTask,
+    onPinTask,
+  }: Props = $props();
 </script>
 
 <div class="list-item">
-  <label for="title" aria-label={task.title}>
-    <input type="text" value={task.title} name="title" readonly />
+  <label for={`title-${task.id}`} aria-label={task.title}>
+    <input
+      type="text"
+      value={task.title}
+      readOnly
+      name="title"
+      id={`title-${task.id}`}
+    />
   </label>
 </div>
 ```
@@ -62,63 +65,48 @@ Above, we render straightforward markup for `Task` based on the existing HTML st
 
 Below we build out Task’s three test states in the story file:
 
-```js:title=src/components/Task.stories.js
-import Task from './Task.svelte';
+```html:title=src/lib/components/Task.stories.svelte
+<script module>
+  import { defineMeta } from '@storybook/addon-svelte-csf';
 
-import { action } from '@storybook/addon-actions';
+  import { fn } from 'storybook/test';
 
-export const actionsData = {
-  onPinTask: action('onPinTask'),
-  onArchiveTask: action('onArchiveTask'),
-};
+  import Task from './Task.svelte';
 
-export default {
-  component: Task,
-  title: 'Task',
-  tags: ['autodocs'],
-  //👇 Our exports that end in "Data" are not stories.
-  excludeStories: /.*Data$/,
-  render: (args) => ({
-    Component: Task,
-    props: args,
-    on: {
-      ...actionsData,
+  export const TaskData = {
+    id: '1',
+    title: 'Test Task',
+    state: 'TASK_INBOX',
+    events: {
+      onArchiveTask: fn(),
+      onPinTask: fn(),
     },
-  }),
-};
+  };
 
-export const Default = {
-  args: {
-    task: {
-      id: "1",
-      title: "Test Task",
-      state: "TASK_INBOX",
+  const { Story } = defineMeta({
+    component: Task,
+    title: 'Task',
+    tags: ['autodocs'],
+    excludeStories: /.*Data$/,
+    args: {
+      ...TaskData.events,
     },
-  },
-};
+  });
+</script>
 
-export const Pinned = {
-  args: {
-    task: {
-      ...Default.args.task,
-      state: "TASK_PINNED",
-    },
-  },
-};
+<Story name="Default" args={{ task: TaskData }} />
 
-export const Archived = {
-  args: {
-    task: {
-      ...Default.args.task,
-      state: "TASK_ARCHIVED",
-    },
-  },
-};
+<Story name="Pinned" args={{ task: { ...TaskData, state: 'TASK_PINNED' } }} />
+
+<Story
+  name="Archived"
+  args={{ task: { ...TaskData, state: 'TASK_ARCHIVED' } }}
+/>
 ```
 
 <div class="aside">
 
-💡 [**Actions**](https://storybook.js.org/docs/essentials/actions) help you verify interactions when building UI components in isolation. Oftentimes you won't have access to the functions and state you have in context of the app. Use `action()` to stub them in.
+💡 [**Actions**](https://storybook.js.org/docs/essentials/actions) help you verify interactions when building UI components in isolation. Oftentimes you won't have access to the functions and state you have in context of the app. Use `fn()` to stub them in.
 
 </div>
 
@@ -129,61 +117,61 @@ There are two basic levels of organization in Storybook: the component and its c
   - Story
   - Story
 
-To tell Storybook about the component we are documenting, we create a `default` export that contains:
+To tell Storybook about the component we're testing, we'll use the `defineMeta` function from the community-driven [Svelte CSF format](https://github.com/storybookjs/addon-svelte-csf), which allows us to define metadata for our component, including the following properties:
 
 - `component` -- the component itself
-- `title` -- how to refer to the component in the sidebar of the Storybook app
-- `excludeStories` -- information required by the story but should not be rendered by the Storybook app
+- `title` -- how to refer to the component in the Storybook sidebar
+- `excludeStories` -- information required by the story but should not be rendered by Storybook
 - `tags` -- to automatically generate documentation for our components
-- `render` -- a function that gives additional control over how the story is rendered
+- `args` -- define the action [args](https://storybook.js.org/docs/essentials/actions#action-args) that the component expects to mock out the custom events
 
-To define our stories, we'll use Component Story Format 3 (also known as [CSF3](https://storybook.js.org/docs/api/csf) ) to build out each of our test cases. This format is designed to build out each of our test cases in a concise way. By exporting an object containing each component state, we can define our tests more intuitively and author and reuse stories more efficiently.
+To define our stories, we'll use the `Story` component returned from the `defineMeta` function to build out each of our test cases.
 
 Arguments or [`args`](https://storybook.js.org/docs/writing-stories/args) for short, allow us to live-edit our components with the controls addon without restarting Storybook. Once an [`args`](https://storybook.js.org/docs/writing-stories/args) value changes, so does the component.
 
-`action()` allows us to create a callback that appears in the **actions** panel of the Storybook UI when clicked. So when we build a pin button, we’ll be able to determine if a button click is successful in the UI.
+`fn()` allows us to create a callback that appears in the **Actions** panel of the Storybook UI when clicked. So when we build a pin button, we’ll be able to determine if a button click is successful in the UI.
 
-As we need to pass the same set of actions to all permutations of our component, it is convenient to bundle them up into a single `actionsData` variable and pass them into our story definition each time. Another nice thing about bundling the `actionsData` that a component needs is that you can `export` them and use them in stories for components that reuse this component, as we'll see later.
-
-When creating a story, we use a base `task` arg to build out the shape of the task the component expects. Typically modeled from what the actual data looks like. Again, `export`-ing this shape will enable us to reuse it in later stories, as we'll see.
+As we need to pass the same set of actions to all permutations of our component, it is convenient to bundle them up into a single `TaskData` variable and pass them into our story definition each time. Another nice thing about bundling the `TaskData` that a component needs is that you can `export` them and use them in stories for components that reuse this component, as we'll see later.
 
 ## Config
 
 We'll need to make a couple of changes to Storybook's configuration files so it notices our recently created stories and allows us to use the application's CSS file (located in `src/index.css`).
 
-Start by changing your Storybook configuration file (`.storybook/main.js`) to the following:
+Start by changing your Storybook configuration file (`.storybook/main.ts`) to the following:
+
+```diff:title=.storybook/main.ts
+import type { StorybookConfig } from '@storybook/svelte-vite';
 
-```diff:title=.storybook/main.js
-/** @type { import('@storybook/svelte-vite').StorybookConfig } */
-const config = {
+const config: StorybookConfig = {
 - stories: [
 -   '../src/**/*.stories.mdx',
 -   '../src/**/*.stories.@(js|jsx|ts|tsx)'
 - ],
-+ stories: ['../src/components/**/*.stories.js'],
++ stories: ['../src/lib/**/*.stories.@(js|ts|svelte)'],
   staticDirs: ['../public'],
   addons: [
-    '@storybook/addon-links',
-    '@storybook/addon-essentials',
-    '@storybook/addon-interactions',
+    '@storybook/addon-svelte-csf',
+    '@chromatic-com/storybook',
+    '@storybook/addon-docs',
+    '@storybook/addon-vitest',
   ],
   framework: {
     name: '@storybook/svelte-vite',
     options: {},
   },
 };
+
 export default config;
 ```
 
-After completing the change above, inside the `.storybook` folder, change your `preview.js` to the following:
+After completing the change above, inside the `.storybook` folder, change your `preview.ts` to the following:
+
+```diff:title=.storybook/preview.ts
+import type { Preview } from '@storybook/svelte-vite';
 
-```diff:title=.storybook/preview.js
 + import '../src/index.css';
 
-//👇 Configures Storybook to log the actions( onArchiveTask and onPinTask ) in the UI.
-/** @type { import('@storybook/svelte').Preview } */
-const preview = {
-  actions: { argTypesRegex: "^on.*" },
+const preview: Preview = {
   parameters: {
     controls: {
       matchers: {
@@ -197,15 +185,13 @@ const preview = {
 export default preview;
 ```
 
-[`parameters`](https://storybook.js.org/docs/writing-stories/parameters) are typically used to control the behavior of Storybook's features and addons. In our case, we're going to use them to configure how the `actions` (mocked callbacks) are handled.
-
-`actions` allows us to create callbacks that appear in the **Actions** panel of the Storybook UI when clicked. So when we build a pin button, we’ll be able to determine if a button click is successful in the UI.
+[`parameters`](https://storybook.js.org/docs/writing-stories/parameters) are typically used to control the behavior of Storybook's features and addons. In our case, we won't use them for that purpose. Instead, we will import our application's CSS file.
 
 Once we’ve done this, restarting the Storybook server should yield test cases for the three Task states:
 
 <video autoPlay muted playsInline loop>
   <source
-    src="/intro-to-storybook/inprogress-task-states-7-0.mp4"
+    src="/intro-to-storybook/inprogress-task-states-9-0.mp4"
     type="video/mp4"
   />
 </video>
@@ -216,30 +202,34 @@ Now that we have Storybook set up, styles imported, and test cases built out, we
 
 The component is still rudimentary at the moment. First, write the code that achieves the design without going into too much detail:
 
-```html:title=src/components/Task.svelte
-<script>
-  import { createEventDispatcher } from 'svelte';
-  const dispatch = createEventDispatcher();
-
-  /** Event handler for the Pin Task */
-  function PinTask() {
-    dispatch('onPinTask', { id: task.id });
-  }
+```html:title=src/lib/components/Task.svelte
+<script lang="ts">
+  type TaskData = {
+    id: string;
+    title: string;
+    state: 'TASK_ARCHIVED' | 'TASK_INBOX' | 'TASK_PINNED';
+  };
 
-  /** Event handler for the Archive Task */
-  function ArchiveTask() {
-    dispatch('onArchiveTask', { id: task.id });
+  interface Props {
+    /** Composition of the task */
+    task: TaskData;
+    /** Event to change the task to archived */
+    onArchiveTask: (id: string) => void;
+    /** Event to change the task to pinned */
+    onPinTask: (id: string) => void;
   }
 
-  /** Composition of the task */
-  export let task = {
-    id: '',
-    title: '',
-    state: ''
-  };
+  const {
+    task = {
+      id: '',
+      title: '',
+      state: 'TASK_INBOX',
+    },
+    onArchiveTask,
+    onPinTask,
+  }: Props = $props();
 
-  /* Reactive declaration (computed prop in other frameworks) */
-  $: isChecked = task.state === "TASK_ARCHIVED";
+  const isChecked = $derived(task.state === 'TASK_ARCHIVED');
 </script>
 
 <div class="list-item {task.state}">
@@ -255,14 +245,19 @@ The component is still rudimentary at the moment. First, write the code that ach
       name={`checked-${task.id}`}
       id={`archiveTask-${task.id}`}
     />
-    <!-- svelte-ignore a11y-click-events-have-key-events -->
     <span
-      class="checkbox-custom"
       role="button"
-      on:click={ArchiveTask}
+      class="checkbox-custom"
+      aria-label={`archivedTask-${task.id}`}
+      onclick={() => onArchiveTask(task.id ?? "")}
+      onkeydown={(e) => {
+        if (e.key === "Enter" || e.key === " ") {
+          e.preventDefault();
+          onArchiveTask(task.id ?? "");
+        }
+      }}
       tabindex="-1"
-      aria-label={`archiveTask-${task.id}`}
-    />
+    ></span>
   </label>
   <label for={`title-${task.id}`} aria-label={task.title} class="title">
     <input
@@ -274,14 +269,17 @@ The component is still rudimentary at the moment. First, write the code that ach
       placeholder="Input title"
     />
   </label>
-  {#if task.state !== 'TASK_ARCHIVED'}
+  {#if task.state !== "TASK_ARCHIVED"}
     <button
       class="pin-button"
-      on:click|preventDefault={PinTask}
+      onclick={(e) => {
+        e.preventDefault();
+        onPinTask(task.id ?? "");
+      }}
       id={`pinTask-${task.id}`}
       aria-label={`pinTask-${task.id}`}
     >
-      <span class="icon-star" />
+      <span class="icon-star"></span>
     </button>
   {/if}
 </div>
@@ -291,65 +289,111 @@ The additional markup from above combined with the CSS we imported earlier yield
 
 <video autoPlay muted playsInline loop>
   <source
-    src="/intro-to-storybook/inprogress-task-states-7-0.mp4"
+    src="/intro-to-storybook/finished-task-states-9-0.mp4"
     type="video/mp4"
   />
 </video>
 
-## Component built!
-
-We’ve now successfully built out a component without needing a server or running the entire frontend application. The next step is to build out the remaining Taskbox components one by one in a similar fashion.
+## Specify data requirements
 
-As you can see, getting started building components in isolation is easy and fast. We can expect to produce a higher-quality UI with fewer bugs and more polish because it’s possible to dig in and test every possible state.
+As we continue to build out our components, we can specify the shape of the data that the `Task` component expects by defining a TypeScript type. This way, we can catch errors early and ensure the component is used correctly when adding more complexity. Start by creating a `types.ts` file in the `src` folder and move our existing `TaskData` type there:
 
-## Catch accessibility issues
+```ts:title=src/types.ts
+export type TaskData = {
+  id: string;
+  title: string;
+  state: 'TASK_ARCHIVED' | 'TASK_INBOX' | 'TASK_PINNED';
+};
+```
 
-Accessibility tests refer to the practice of auditing the rendered DOM with automated tools against a set of heuristics based on [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) rules and other industry-accepted best practices. They act as the first line of QA to catch blatant accessibility violations ensuring that an application is usable for as many people as possible, including people with disabilities such as vision impairment, hearing problems, and cognitive conditions.
+Then, update the `Task` component to use our newly created type:
 
-Storybook includes an official [accessibility addon](https://storybook.js.org/addons/@storybook/addon-a11y). Powered by Deque's [axe-core](https://github.com/dequelabs/axe-core), it can catch up to [57% of WCAG issues](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/).
+```html:title=src/lib/components/Task.svelte
+<script lang="ts">
+  import type { TaskData } from '../../types';
 
-Let's see how it works! Run the following command to install the addon:
+  interface Props {
+    /** Composition of the task */
+    task: TaskData;
+    /** Event to change the task to archived */
+    onArchiveTask: (id: string) => void;
+    /** Event to change the task to pinned */
+    onPinTask: (id: string) => void;
+  }
 
-```shell
-yarn add --dev @storybook/addon-a11y
-```
+  const {
+    task = {
+      id: '',
+      title: '',
+      state: 'TASK_INBOX',
+    },
+    onArchiveTask,
+    onPinTask,
+  }: Props = $props();
 
-Then, update your Storybook configuration file (`.storybook/main.js`) to enable it:
+  const isChecked = $derived(task.state === 'TASK_ARCHIVED');
+</script>
 
-```diff:title=.storybook/main.js
-/** @type { import('@storybook/svelte-vite').StorybookConfig } */
-const config = {
-  stories: ['../src/components/**/*.stories.js'],
-  staticDirs: ['../public'],
-  addons: [
-    "@storybook/addon-links",
-    "@storybook/addon-essentials",
-    "@storybook/addon-interactions",
-+   '@storybook/addon-a11y',
-  ],
-  framework: {
-    name: "@storybook/svelte-vite",
-    options: {},
-  },
-};
-export default config;
+<div class="list-item {task.state}">
+  <label
+    for={`checked-${task.id}`}
+    class="checkbox"
+    aria-label={`archiveTask-${task.id}`}
+  >
+    <input
+      type="checkbox"
+      checked={isChecked}
+      disabled
+      name={`checked-${task.id}`}
+      id={`archiveTask-${task.id}`}
+    />
+    <span
+      role="button"
+      class="checkbox-custom"
+      aria-label={`archivedTask-${task.id}`}
+      onclick={() => onArchiveTask(task.id ?? "")}
+      onkeydown={(e) => {
+        if (e.key === "Enter" || e.key === " ") {
+          e.preventDefault();
+          onArchiveTask(task.id ?? "");
+        }
+      }}
+      tabindex="-1"
+    ></span>
+  </label>
+  <label for={`title-${task.id}`} aria-label={task.title} class="title">
+    <input
+      type="text"
+      value={task.title}
+      readonly
+      name="title"
+      id={`title-${task.id}`}
+      placeholder="Input title"
+    />
+  </label>
+  {#if task.state !== "TASK_ARCHIVED"}
+    <button
+      class="pin-button"
+      onclick={(e) => {
+        e.preventDefault();
+        onPinTask(task.id ?? "");
+      }}
+      id={`pinTask-${task.id}`}
+      aria-label={`pinTask-${task.id}`}
+    >
+      <span class="icon-star"></span>
+    </button>
+  {/if}
+</div>
 ```
 
-Finally, restart your Storybook to see the new addon enabled in the UI.
-
-![Task accessibility issue in Storybook](/intro-to-storybook/finished-task-states-accessibility-issue-7-0.png)
+Now, an error in development will appear if the Task component is misused.
 
-Cycling through our stories, we can see that the addon found an accessibility issue with one of our test states. The message [**"Elements must have sufficient color contrast"**](https://dequeuniversity.com/rules/axe/4.4/color-contrast?application=axeAPI) essentially means there isn't enough contrast between the task title and the background. We can quickly fix it by changing the text color to a darker gray in our application's CSS (located in `src/index.css`).
+## Component built!
 
-```diff:title=src/index.css
-.list-item.TASK_ARCHIVED input[type="text"] {
-- color: #a0aec0;
-+ color: #4a5568;
-  text-decoration: line-through;
-}
-```
+We’ve now successfully built out a component without needing a server or running the entire frontend application. The next step is to build out the remaining Taskbox components one by one in a similar fashion.
 
-That's it! We've taken the first step to ensure that UI becomes accessible. As we continue to add complexity to our application, we can repeat this process for all other components without needing to spin up additional tools or testing environments.
+As you can see, getting started building components in isolation is easy and fast. We can expect to produce a higher-quality UI with fewer bugs and more polish because it’s possible to dig in and test every possible state.
 
 <div class="aside">
 💡 Don't forget to commit your changes with git!
diff --git a/content/intro-to-storybook/svelte/en/test.md b/content/intro-to-storybook/svelte/en/test.md
index d1bc4ebf9..1372202d9 100644
--- a/content/intro-to-storybook/svelte/en/test.md
+++ b/content/intro-to-storybook/svelte/en/test.md
@@ -4,21 +4,18 @@ tocTitle: 'Visual Testing'
 description: 'Learn the ways to test UI components'
 ---
 
-No Storybook tutorial would be complete without testing. Testing is essential to creating high-quality UIs. In modular systems, minuscule tweaks can result in major regressions. So far, we have encountered three types of tests:
+No Storybook tutorial would be complete without testing. Testing is essential to creating high-quality UIs. In modular systems, minuscule tweaks can result in major regressions. So far, we have encountered two types of tests:
 
-- **Manual tests** rely on developers to manually look at a component to verify it for correctness. They help us sanity check a component’s appearance as we build.
-
-- **Accessibility tests** with a11y addon verify that the component is accessible to everyone. They're great for allowing us to collect information about how people with certain types of disabilities use our components.
-
-- **Component tests** with the play function verify that the component behaves as expected when interacting with it. They're great for testing the behavior of a component when it's in use.
+- **Component tests** with Storybook and the Vitest integration help developers automate rendering and component behavior in a real browser environment.
+- **Interaction tests** with the play function verify that the component behaves as expected when interacting with it. They're great for testing the behavior of a component when it's in use.
 
 ## “But does it look right?”
 
 Unfortunately, the aforementioned testing methods alone aren’t enough to prevent UI bugs. UIs are tricky to test because design is subjective and nuanced. Manual tests are, well, manual. Other UI tests, such as snapshot tests, trigger too many false positives, and pixel-level unit tests are poorly valued. A complete Storybook testing strategy also includes visual regression tests.
 
-## Visual testing for Storybook
+## Visual testing with Storybook
 
-Visual regression tests, also called visual tests, are designed to catch changes in appearance. They work by capturing screenshots of every story and comparing them commit-to-commit to surface changes. It's perfect for verifying graphical elements like layout, color, size, and contrast.
+Visual tests are designed to catch visual regressions and ensure consistent UI appearance. They work by capturing snapshots of every test and comparing them commit-to-commit to surface changes. It's perfect for verifying graphical elements like layout, color, size, and contrast.
 
 <video autoPlay muted playsInline loop style="width:480px; margin: 0 auto;">
   <source
@@ -27,13 +24,13 @@ Visual regression tests, also called visual tests, are designed to catch changes
   />
 </video>
 
-Storybook is a fantastic tool for visual regression testing because every story is essentially a test specification. Each time we write or update a story, we get a spec for free!
+Storybook is a fantastic tool for visual tests because every story is essentially a test specification. Each time we write or update a story, we get a spec for free!
 
-There are several tools for visual regression testing. We recommend [**Chromatic**](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook), a free publishing service made by the Storybook maintainers that runs visual tests in a lightning-fast cloud browser environment. It also allows us to publish Storybook online, as we saw in the [previous chapter](/intro-to-storybook/svelte/en/deploy/).
+There are several tools for visual testing. We recommend [**Chromatic**](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook), a free publishing service made by the Storybook maintainers that runs visual tests in a lightning-fast cloud browser environment. It also allows us to publish Storybook online, as we saw in the [previous chapter](/intro-to-storybook/svelte/en/deploy/).
 
 ## Catch a UI change
 
-Visual regression testing relies on comparing images of the newly rendered UI code to the baseline images. If a UI change is caught, we'll get notified.
+Visual tests rely on comparing images of the newly rendered UI code to the baseline images. If a UI change is caught, we'll get notified.
 
 Let's see how it works by tweaking the background of the `Task` component.
 
@@ -43,9 +40,34 @@ Start by creating a new branch for this change:
 git checkout -b change-task-background
 ```
 
-Change `src/components/Task.svelte` to the following:
+Change `src/lib/components/Task.svelte` to the following:
+
+```diff:title=src/lib/components/Task.svelte
+<script lang="ts">
+  import type { TaskData } from '../../types';
+
+  interface Props {
+    /** Composition of the task */
+    task: TaskData;
+    /** Event to change the task to archived */
+    onArchiveTask: (id: string) => void;
+    /** Event to change the task to pinned */
+    onPinTask: (id: string) => void;
+  }
+
+  const {
+    task = {
+      id: '',
+      title: '',
+      state: 'TASK_INBOX',
+    },
+    onArchiveTask,
+    onPinTask,
+  }: Props = $props();
+
+  const isChecked = $derived(task.state === 'TASK_ARCHIVED');
+</script>
 
-```diff:title=src/components/Task.svelte
 <div class="list-item {task.state}">
   <label
     for={`checked-${task.id}`}
@@ -59,14 +81,19 @@ Change `src/components/Task.svelte` to the following:
       name={`checked-${task.id}`}
       id={`archiveTask-${task.id}`}
     />
-    <!-- svelte-ignore a11y-click-events-have-key-events -->
     <span
-      class="checkbox-custom"
       role="button"
-      on:click={ArchiveTask}
+      class="checkbox-custom"
+      aria-label={`archivedTask-${task.id}`}
+      onclick={() => onArchiveTask(task.id ?? "")}
+      onkeydown={(e) => {
+        if (e.key === "Enter" || e.key === " ") {
+          e.preventDefault();
+          onArchiveTask(task.id ?? "");
+        }
+      }}
       tabindex="-1"
-      aria-label={`archiveTask-${task.id}`}
-    />
+    ></span>
   </label>
   <label for={`title-${task.id}`} aria-label={task.title} class="title">
     <input
@@ -79,14 +106,17 @@ Change `src/components/Task.svelte` to the following:
 +     style="background-color: red;"
     />
   </label>
-  {#if task.state !== 'TASK_ARCHIVED'}
+  {#if task.state !== "TASK_ARCHIVED"}
     <button
       class="pin-button"
-      on:click|preventDefault={PinTask}
+      onclick={(e) => {
+        e.preventDefault();
+        onPinTask(task.id ?? "");
+      }}
       id={`pinTask-${task.id}`}
       aria-label={`pinTask-${task.id}`}
     >
-      <span class="icon-star" />
+      <span class="icon-star"></span>
     </button>
   {/if}
 </div>
@@ -94,7 +124,16 @@ Change `src/components/Task.svelte` to the following:
 
 This yields a new background color for the item.
 
-![task background change](/intro-to-storybook/chromatic-task-change-7-0.png)
+<!--
+ TODO: Follow up with Design for:
+   - A non-React version of this asset to include PureTaskList to align with the overall design and tutorial structure
+   - A React version of this asset
+   - Filenames should be as follows:
+     - chromatic-task-changes-non-react-9-0.png
+     - chromatic-task-changes-react-9-0.png
+ -->
+
+![task background change](/intro-to-storybook/chromatic-task-changes-non-react-9-0.png)
 
 Add the file:
 
@@ -124,15 +163,21 @@ Add a descriptive text to your pull request and click `Create pull request`. Cli
 
 It will show you the UI changes caught by your commit.
 
+<!--
+ TODO: Follow up with Design for:
+   - A non-React version of this asset to include PureTaskList to align with the overall design and tutorial structure
+   - A React version of this asset
+ -->
+
 ![Chromatic caught changes](/intro-to-storybook/chromatic-catch-changes.png)
 
-There are a lot of changes! The component hierarchy where `Task` is a child of `TaskList` and `Inbox` means one small tweak snowballs into major regressions. This circumstance is precisely why developers need visual regression testing in addition to other testing methods.
+There are a lot of changes! The component hierarchy where `Task` is a child of `PureTaskList` and `InboxScreen` means one small tweak snowballs into major regressions. This circumstance is precisely why developers need visual tests and other testing methods.
 
 ![UI minor tweaks major regressions](/intro-to-storybook/minor-major-regressions.gif)
 
 ## Review changes
 
-Visual regression testing ensures components don’t change by accident. But it’s still up to us to determine whether changes are intentional or not.
+Visual tests ensure components don’t change by accident. But it’s still up to us to determine whether changes are intentional or not.
 
 If a change is intentional, we'll need to update the baseline to compare future tests to the latest version of the story. If a change is unintentional, it needs to be fixed.
 
@@ -149,8 +194,12 @@ Since modern apps are constructed from components, it’s important that we test
 
 When we’ve finished reviewing, we’re ready to merge UI changes with confidence--knowing that updates won’t accidentally introduce bugs. If you like the new `red` background, then accept the changes. If not, revert to the previous state.
 
-![Changes ready to be merged](/intro-to-storybook/chromatic-review-finished.png)
+<!--
+ TODO: Follow up with Design for:
+   - A non-React version of this asset to include PureTaskList to align with the overall design and tutorial structure
+   - A React version of this asset
+ -->
 
-Storybook helps us **build** components; testing helps us **maintain** them. The four types of UI testing covered in this tutorial were manual, snapshot, unit, and visual regression testing. You can automate the last three by adding them to a CI as we've just finished setting up, and it helps us ship components without worrying about stowaway bugs. The whole workflow is illustrated below.
+![Changes ready to be merged](/intro-to-storybook/chromatic-review-finished.png)
 
-![Visual regression testing workflow](/intro-to-storybook/cdd-review-workflow.png)
+Storybook helps us **build** components; testing helps us **maintain** them. So far, the two types of UI testing covered in this tutorial were manual and visual tests. Both can be automated in CI as we've just finished setting up, and it helps us ship components without worrying about stowaway bugs. However, these are not the only ways to test components. We'll need to ensure our components remain accessible to all users, including those with disabilities. This means incorporating accessibility testing into our workflow.
diff --git a/content/intro-to-storybook/svelte/en/using-addons.md b/content/intro-to-storybook/svelte/en/using-addons.md
deleted file mode 100644
index f66655d5b..000000000
--- a/content/intro-to-storybook/svelte/en/using-addons.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: 'Addons'
-tocTitle: 'Addons'
-description: 'Learn how to integrate and use the popular Controls addon'
----
-
-Storybook has a robust ecosystem of [addons](https://storybook.js.org/docs/configure/storybook-addons) that you can use to enhance the developer experience for everybody in your team. View them all [here](https://storybook.js.org/integrations).
-
-If you've been following this tutorial, you've already encountered multiple addons and set one up in the [Testing](/intro-to-storybook/svelte/en/test/) chapter.
-
-There are addons for every possible use case, and it would take forever to write about them all. Let's integrate one of the most popular addons: [Controls](https://storybook.js.org/docs/essentials/controls).
-
-## What is Controls?
-
-Controls allows designers and developers to easily explore component behavior by _playing_ with its arguments. No code required. Controls creates an addon panel next to your stories, so you can edit their arguments live.
-
-Fresh installs of Storybook include Controls out of the box. No extra configuration needed.
-
-<!-- record video  -->
-<video autoPlay muted playsInline loop>
-  <source
-    src="/intro-to-storybook/controls-in-action-svelte-7-0.mp4"
-    type="video/mp4"
-  />
-</video>
-
-## Addons unlock new Storybook workflows
-
-Storybook is a wonderful [component-driven development environment](https://www.componentdriven.org/). The Controls addon evolves Storybook into an interactive documentation tool.
-
-### Using Controls to find edge cases
-
-With Controls, QA Engineers, UI Engineers, or any other stakeholder can push the component to the limit! Considering the following example, what would happen to our `Task` if we added a **MASSIVE** string?
-
-![Oh no! The far right content is cut-off!](/intro-to-storybook/task-edge-case-7-0.png)
-
-That's not right! It looks like the text overflows beyond the bounds of the Task component.
-
-Controls allowed us to quickly verify different inputs to a component--in this case, a long string--and reduced the work required to discover UI problems.
-
-Now let's fix the issue with overflowing by adding a style to `Task.svelte`:
-
-```diff:title=src/components/Task.svelte
-<div class="list-item {task.state}">
-  <label
-    for={`checked-${task.id}`}
-    class="checkbox"
-    aria-label={`archiveTask-${task.id}`}
-  >
-    <input
-      type="checkbox"
-      checked={isChecked}
-      disabled
-      name={`checked-${task.id}`}
-      id={`archiveTask-${task.id}`}
-    />
-    <!-- svelte-ignore a11y-click-events-have-key-events -->
-    <span
-      class="checkbox-custom"
-      role="button"
-      on:click={ArchiveTask}
-      tabindex="-1"
-      aria-label={`archiveTask-${task.id}`}
-    />
-  </label>
-  <label for={`title-${task.id}`} aria-label={task.title} class="title">
-    <input
-      type="text"
-      value={task.title}
-      readonly
-      name="title"
-      id={`title-${task.id}`}
-      placeholder="Input title"
-+     style="text-overflow: ellipsis;"
-    />
-  </label>
-  {#if task.state !== 'TASK_ARCHIVED'}
-    <button
-      class="pin-button"
-      on:click|preventDefault={PinTask}
-      id={`pinTask-${task.id}`}
-      aria-label={`pinTask-${task.id}`}
-    >
-      <span class="icon-star" />
-    </button>
-  {/if}
-</div>
-```
-
-![That's better.](/intro-to-storybook/edge-case-solved-with-controls-7-0.png)
-
-Problem solved! The text is now truncated when it reaches the boundary of the Task area using a handsome ellipsis.
-
-### Adding a new story to avoid regressions
-
-In the future, we can manually reproduce this problem by entering the same string via Controls. But it's easier to write a story that showcases this edge case. That expands our regression test coverage and clearly outlines the limits of the component(s) for the rest of the team.
-
-Add a new story for the long text case in `Task.stories.js`:
-
-```js:title=src/components/Task.stories.js
-const longTitleString = `This task's name is absurdly large. In fact, I think if I keep going I might end up with content overflow. What will happen? The star that represents a pinned task could have text overlapping. The text could cut-off abruptly when it reaches the star. I hope not!`;
-
-export const LongTitle = {
-  args: {
-    task: {
-      ...Default.args.task,
-      title: longTitleString,
-    },
-  },
-};
-```
-
-Now we can reproduce and work on this edge case with ease.
-
-<video autoPlay muted playsInline loop>
-  <source
-    src="/intro-to-storybook/task-stories-long-title-svelte-7-0.mp4"
-    type="video/mp4"
-  />
-</video>
-
-If we are [visual testing](/intro-to-storybook/svelte/en/test/), we'll also be informed if the truncating solution breaks. Obscure edge cases are liable to be forgotten without test coverage!
-
-<div class="aside">
-
-💡 Controls is a great way to get non-developers playing with your components and stories. It can do much more than we've seen here; we recommend reading the [official documentation](https://storybook.js.org/docs/essentials/controls) to learn more about it. However, there are many more ways you can customize Storybook to fit your workflow with addons. In the [create an addon guide](https://storybook.js.org/docs/addons/writing-addons) we'll teach you that, by creating an addon that will help you supercharge your development workflow.
-
-</div>
-
-### Merge Changes
-
-Don't forget to merge your changes with git!
diff --git a/gatsby-config.js b/gatsby-config.js
index 159ab14e3..fd9edd3b8 100644
--- a/gatsby-config.js
+++ b/gatsby-config.js
@@ -52,7 +52,7 @@ module.exports = {
           pt: 5.3,
         },
         svelte: {
-          en: 8.3,
+          en: 9.0,
           es: 5.3,
         },
       },
diff --git a/static/intro-to-storybook/accessibility-issue-task-non-react-9-0.png b/static/intro-to-storybook/accessibility-issue-task-non-react-9-0.png
new file mode 100644
index 000000000..c579ca58b
Binary files /dev/null and b/static/intro-to-storybook/accessibility-issue-task-non-react-9-0.png differ
diff --git a/static/intro-to-storybook/app-main-modalities-svelte.png b/static/intro-to-storybook/app-main-modalities-svelte.png
new file mode 100644
index 000000000..041c6002b
Binary files /dev/null and b/static/intro-to-storybook/app-main-modalities-svelte.png differ
diff --git a/static/intro-to-storybook/broken-inbox-error-state-9-0-non-react.png b/static/intro-to-storybook/broken-inbox-error-state-9-0-non-react.png
new file mode 100644
index 000000000..5a867c81c
Binary files /dev/null and b/static/intro-to-storybook/broken-inbox-error-state-9-0-non-react.png differ
diff --git a/static/intro-to-storybook/chromatic-a11y-tests-enabled.png b/static/intro-to-storybook/chromatic-a11y-tests-enabled.png
new file mode 100644
index 000000000..9c2ceca13
Binary files /dev/null and b/static/intro-to-storybook/chromatic-a11y-tests-enabled.png differ
diff --git a/static/intro-to-storybook/chromatic-build-a11y-tests.png b/static/intro-to-storybook/chromatic-build-a11y-tests.png
new file mode 100644
index 000000000..61c36e13f
Binary files /dev/null and b/static/intro-to-storybook/chromatic-build-a11y-tests.png differ
diff --git a/static/intro-to-storybook/chromatic-manual-storybook-deploy-non-react.png b/static/intro-to-storybook/chromatic-manual-storybook-deploy-non-react.png
new file mode 100644
index 000000000..48f0a3778
Binary files /dev/null and b/static/intro-to-storybook/chromatic-manual-storybook-deploy-non-react.png differ
diff --git a/static/intro-to-storybook/chromatic-task-changes-non-react-9-0.png b/static/intro-to-storybook/chromatic-task-changes-non-react-9-0.png
new file mode 100644
index 000000000..361de5ffc
Binary files /dev/null and b/static/intro-to-storybook/chromatic-task-changes-non-react-9-0.png differ
diff --git a/static/intro-to-storybook/finished-puretasklist-states-9-0.mp4 b/static/intro-to-storybook/finished-puretasklist-states-9-0.mp4
new file mode 100644
index 000000000..68be8674c
Binary files /dev/null and b/static/intro-to-storybook/finished-puretasklist-states-9-0.mp4 differ
diff --git a/static/intro-to-storybook/finished-task-states-9-0.mp4 b/static/intro-to-storybook/finished-task-states-9-0.mp4
new file mode 100644
index 000000000..f7fbb34e2
Binary files /dev/null and b/static/intro-to-storybook/finished-task-states-9-0.mp4 differ
diff --git a/static/intro-to-storybook/finished-tasklist-states-9-0.mp4 b/static/intro-to-storybook/finished-tasklist-states-9-0.mp4
new file mode 100644
index 000000000..807c165bd
Binary files /dev/null and b/static/intro-to-storybook/finished-tasklist-states-9-0.mp4 differ
diff --git a/static/intro-to-storybook/inbox-screen-with-msw-addon-non-react-9.0.mp4 b/static/intro-to-storybook/inbox-screen-with-msw-addon-non-react-9.0.mp4
new file mode 100644
index 000000000..7873cd0f0
Binary files /dev/null and b/static/intro-to-storybook/inbox-screen-with-msw-addon-non-react-9.0.mp4 differ
diff --git a/static/intro-to-storybook/inprogress-task-states-9-0.mp4 b/static/intro-to-storybook/inprogress-task-states-9-0.mp4
new file mode 100644
index 000000000..006275dcc
Binary files /dev/null and b/static/intro-to-storybook/inprogress-task-states-9-0.mp4 differ
diff --git a/static/intro-to-storybook/inprogress-tasklist-states-9-0.mp4 b/static/intro-to-storybook/inprogress-tasklist-states-9-0.mp4
new file mode 100644
index 000000000..bfa5d947d
Binary files /dev/null and b/static/intro-to-storybook/inprogress-tasklist-states-9-0.mp4 differ
diff --git a/static/intro-to-storybook/storybook-play-function-non-react.mp4 b/static/intro-to-storybook/storybook-play-function-non-react.mp4
new file mode 100644
index 000000000..2550250ac
Binary files /dev/null and b/static/intro-to-storybook/storybook-play-function-non-react.mp4 differ
diff --git a/static/intro-to-storybook/storybook-vitest-addon-non-react.mp4 b/static/intro-to-storybook/storybook-vitest-addon-non-react.mp4
new file mode 100644
index 000000000..eefe6a670
Binary files /dev/null and b/static/intro-to-storybook/storybook-vitest-addon-non-react.mp4 differ