# Introduction

Welcome to CivicTheme! CivicTheme is an open-source, government-grade design system led by open-governance with a vision.

## CivicTheme's vision

> Build an enterprise-grade atomic design system & community of practice to deliver common UI patterns & governance infrastructure to accelerate consistent, accessible, brand-aligned, research-backed UX.

The origin story of CivicTheme started from having experienced the pains of the frequent reinvention of solutions and inconsistencies in design across multiple projects, resulting in inefficiencies and fragmented user experiences. A unified, world-class design system, co-created with the community, is essential to standardise solutions, enhance user experience, and drive innovation by addressing common problems and desired outcomes.

For every citizen.

## CivicTheme overview

**CivicTheme** is an open-source design system developed through an **open-governance model**, driven by a collaboration of **government agencies**, **digital agencies**, and **community members** who actively use the product. It was created to enable governments and organisations to rapidly build modern, consistent, and compliant digital experiences.

CivicTheme's development is shaped by contributions from the community, ensuring it evolves to meet the needs of various sectors. Initially developed as a **Drupal theme**, CivicTheme aspires to support a broader range of **languages and frameworks** in the future.

#### Key components of CivicTheme

CivicTheme is comprised of three key components:

1. [**Design system**](#id-1.-design-system)
2. [**Supporting tools, policies, and guidelines**](#id-2.-supporting-tools-policies-and-guidelines)
3. [**Community of practice**](#id-3.-community-of-practice)

### Design system

CivicTheme is built around the principles of **atomic design**, meaning it provides a scalable, reusable set of components that can be combined to build digital interfaces. The **Design System** exists as both a **visual guide in Figma** and a **component library in Storybook**.

* [**Figma**:](https://www.figma.com/design/HwfKa9eD0oq474wffZYzg4/CivicTheme--Design-System-v1.11) The Figma file is a visual representation of CivicTheme's components and design templates, allowing designers to work directly with pre-built UI elements.
* [**UI Kit**](https://github.com/orgs/civictheme/projects/1): The UI Kit is a collection of components built with **HTML, CSS, and JavaScript**, aiming for **WCAG 2.2 AA accessibility standards** out-of-the-box. This ensures accessibility compliance across all digital services that use CivicTheme.
* [**Storybook**](https://uikit.civictheme.io/?path=/story/welcome--welcome): Storybook provides a live, interactive environment for developers and designers to explore components, understand their behaviour, and integrate them into different projects.

### Supporting tools, policies, and guidelines

CivicTheme is more than just a design system; it also offers a set of **supporting tools**, **policies**, and **guidelines** to ensure a smooth development process, maintain consistency, and promote best practices. This includes:

* **Development guidelines** to ensure proper integration of CivicTheme components.
* **Accessibility standards** to ensure components meet **government-grade compliance**.
* **Policies** to guide contributions and ensure that every addition aligns with CivicTheme’s inclusive and open-source nature.

### Community of practice

At the heart of CivicTheme is a **community of practice** composed of **government agencies**, **digital agencies**, and **individual contributors**. This community actively uses, maintains, and improves CivicTheme.

* CivicTheme relies on **community contributions** to grow and evolve, with an open-governance model that invites users to participate in shaping the design system.
* Contributors can engage through **CivicTheme’s GitHub repositories**, its **Slack channel**, and other community forums to provide feedback, submit enhancements, or suggest new components.

### Expanding beyond Drupal

Although CivicTheme originated as a **Drupal theme**, it is designed to be flexible and adaptable to support other frameworks and content management systems in the future.

Currently, the **Drupal theme** provides all the necessary configurations to integrate CivicTheme’s UI Kit components with **Drupal CMS**. The components aim to meet **WCAG 2.2 AA** standards, as compliance and accessibility are core features.

### Demo sites

To explore CivicTheme in action, you can view a variety of demo sites tailored to different industries:

* [Default CivicTheme build](https://default.civictheme.io/) – Latest stable build. Use the "generated content" menu item to explore multiple component variants.
* [Government demo](https://government.civictheme.io/) – CivicTheme adapted for government sector content.
* [Higher Education demo](https://higher-education-university.civictheme.io/) – Example of CivicTheme tailored for higher education.
* [Corporate demo](https://corporate.civictheme.io/) – CivicTheme for corporate industry content.

### Resources

* [CivicTheme official site](https://www.civictheme.io/)
* [CivicTheme Figma file](https://www.figma.com/design/HwfKa9eD0oq474wffZYzg4/CivicTheme--Design-System-v1.11)
* [UI Kit GitHub repository](https://github.com/civictheme/uikit)
* [Drupal Theme Project Page](https://www.drupal.org/project/civictheme/)
* [Drupal Theme Development repository](https://github.com/civictheme/monorepo-drupal)
* [CivicTheme slack channel](https://drupal.slack.com/archives/C039UV0CQBZ)
* [CivicTheme Storybook](https://uikit.civictheme.io/?path=/story/welcome--welcome)

### Supported browsers

<table><thead><tr><th width="223.33333333333331">Browser</th><th>Latest supported version</th><th>Supported version n-1</th></tr></thead><tbody><tr><td>Chrome</td><td>138.x</td><td>117.x</td></tr><tr><td>Firefox</td><td>141.x</td><td>119.x</td></tr><tr><td>Microsoft Edge</td><td>138.x</td><td>118.x</td></tr><tr><td>Safari</td><td>18.x</td><td>16.x</td></tr></tbody></table>

### Contribute

**CivicTheme** continues to evolve as an essential tool for delivering consistent, accessible, and modern digital experiences, driven by its community and contributions. To be part of the evolving journey of CivicTheme's vision, check out our [contribution documentation](/contributing/contribution-model).


# Getting help

### Where to get support <a href="#where-to-get-support" id="where-to-get-support"></a>

* [Drupal theme issue queue](https://www.drupal.org/project/issues/civictheme)
* [CivicTheme Github repository](https://github.com/civictheme)
* [Drupal Slack channel](https://drupal.slack.com/archives/C039UV0CQBZ) <mark style="color:blue;">#civictheme-designsystem</mark> (**note:** you need to first [join Drupal Slack](https://www.drupal.org/join-slack))
* Send an email to <mark style="color:blue;"><civictheme@salsa.digital></mark>

### Where to submit issues and PRs <a href="#where-to-submit-issues-and-prs" id="where-to-submit-issues-and-prs"></a>

Development of the entire CivicTheme ecosystem is managed in the [<mark style="color:blue;">CivicTheme</mark> GitHub organisation](https://github.com/civictheme/).

This allows to develop the Drupal theme and modules at the same place and use advanced CI configuration for testing.

The code from the[ monorepo ](https://en.wikipedia.org/wiki/Monorepo)is automatically published to Drupal.org with all commit and author information preserved.

**For Drupal theme:**

* Submit issues to [the Drupal theme issue queue](https://www.drupal.org/project/issues/civictheme)
* Submit PRs to the [GitHub Drupal monorepo](https://github.com/civictheme/monorepo-drupal)

**For Drupal modules:**

* submit issues to [the Drupal theme issue queue](https://www.drupal.org/project/issues/civictheme)
* submit PRs to [the GitHub Drupal monorepo](https://github.com/civictheme/monorepo-drupal)

**For UI Kit:**

* Submit issues to [the UI Kit GitHub repository](https://github.com/civictheme/uikit)
* Submit PRs to [the UI Kit GitHub repository](https://github.com/civictheme/uikit)

**For&#x20;*****this*****&#x20;documentation:**

* Submit issues to [the documentation GitHub repository](https://github.com/civictheme/docs/)
* Submit PRs to [the documentation GitHub repository](https://github.com/civictheme/docs/)

If you do not know which part the issues relates to - submit an issue to [the Drupal theme issue queue](https://www.drupal.org/project/issues/civictheme) and it will be moved to the appropriate location by the CivicTheme maintainers.


# Security framework

{% hint style="info" %}
**Need to report a vulnerability?** Find out how on the [Drupal CivicTheme Design System](https://www.drupal.org/project/civictheme) page.
{% endhint %}

The CivicTheme security framework outlines the CivicTheme approach to developing, reviewing, and maintaining CivicTheme and its related assets in accordance with secure-by-design principles.

It describes the measures, tools, and governance processes used to protect our codebase, users, and community from potential security threats.

CivicTheme is an open-source, government-grade design system comprising multiple components (design assets, UI Kit, and a Drupal theme). Security and compliance are fundamental to CivicTheme’s mission of enabling reliable, consistent, and accessible digital experiences for government and public services.

Note: CivicTheme is an open source codebase, not a hosted service. Implementing organisations are responsible for the security of their own infrastructure and deployments. This policy focuses on the security of CivicTheme’s code and release process.

### Supported versions <a href="#supported-versions" id="supported-versions"></a>

We support the current release of CivicTheme and the accompanying UI Kit.

### Continuous monitoring

Security monitoring is an integral part of the CivicTheme development process. GitHub’s built-in security scanning is enabled across repositories to automatically detect vulnerabilities in code and dependencies. Scans run regularly on commits and pull requests, generating alerts for review, prioritisation, and resolution.

### Linting and static code analysis tools

A suite of linting and static analysis tools supports ongoing quality assurance and helps maintain secure coding standards. These tools automatically run on every commit to detect coding and security issues early.

These include:

* Drupal Practice: ensures compliance with Drupal’s best practices and secure coding guidelines. This helps maintain a consistent, high-quality, and secure codebase.
* PHP CodeSniffer: automatically detects violations of coding standards in PHP, JavaScript, and CSS files. Helps ensure consistent code style, enforces best practices, and can catch potential issues early in development.
* ShipShape: Analyses Drupal code to ensure it follows Drupal coding standards and best practices. Helps detect errors, security risks, and maintainability issues, supporting consistent, high-quality code.
* PHPStan: a static analysis tool for PHP that detects errors in code without running it. Helps catch bugs, type mismatches, and potential issues early, improving code quality and reliability.
* PHP Mess Detector: Scans PHP code for potential problems such as bugs, suboptimal code, and maintainability issues. Helps to identify complex, error-prone, or poorly structured code so it can be improved.
* PHP Rector: Automates PHP code refactoring and upgrades.Helps to modernise code, fix deprecated features, and enforce coding standards, improving maintainability and compatibility.
* Continuous Integration (CI): Every change is validated via automated testing, linting, and standards enforcement.

### Third-party validation

CivicTheme relies on external dependencies that are carefully managed to maintain a strong security posture. This proactive approach ensures that all third-party components meet the same high security standards as the rest of the CivicTheme codebase.

* **Dependabot:** GitHub Dependabot monitors third-party libraries, alerts the team to vulnerabilities, and automatically generates pull requests with safe updates. Front-end dependencies, such as those within the UI Kit, are also monitored through Dependabot to ensure they remain up to date and secure.
* **Composer Security Checker:** works alongside Dependabot to scan PHP project dependencies for known security vulnerabilities and alert the team to packages that need updating.
* **CodeQL Scanning:** GitHub’s CodeQL engine runs static analysis on all commits and pull requests to detect common vulnerabilities in PHP and JavaScript.
* **AI Code Review (CodeRabbit)**: CodeRabbit enhances pull request reviews with automated security checks and best practice enforcement.

### Drupal Security Advisory

CivicTheme is committed to transparency and responsible disclosure when managing security vulnerabilities. As such, CivicTheme has opted into the Drupal Security Advisory. This ensures that vulnerabilities affecting the theme can be responsibly reported, tracked, and communicated to users.

By participating in this program, we commit to following the Drupal Security Team’s processes for assessing, prioritising, and releasing security updates, helping maintain a secure environment for all users of the theme.

### Reporting a vulnerability

Find out how to report a vulnerability on the [Drupal CivicTheme Design System](https://www.drupal.org/project/civictheme) page.

### Future security enhancements

We are continually improving our security processes.

Planned future developments include deeper static analysis, expanded communication channels for security advisories, and enhanced automation in our CI/CD pipeline for proactive testing and vulnerability detection.

These initiatives reinforce our commitment to maintaining a robust, secure, and transparent open-source ecosystem.

### Ongoing commitment

CivicTheme commits to:

* Supporting the current version
* Responding quickly to valid vulnerability reports
* Adopting industry best practices in security scanning and review
* Maintaining transparency through public changelogs and advisories
* Encouraging community contributions to improve security

<br>


# Security update - 1.12.0

Instructions for manual mitigation

These instructions require an experienced developer to implement, to be able to test XSS protections and remove the information disclosure issues on entity reference fields.

The purpose of these instructions is for users that wish to mitigate the security issues found in CivicTheme (<1.12.0) and manually update their older projects.

It is also for those checking their sub-theme for XSS and information disclosure issues.

### Manual instructions

### Key information

CivicTheme provides a field API system for retrieving commonly used field values specific to CivicTheme.

*We strongly recommend that you use this system solely to retrieve field data for use within components.* Not using this API will mean that the developer is reliant on implementing mitigations for XSS.

The following functions are available for use:

* `civictheme_get_field_value` - retrieves field values from fields that CivicTheme regularly uses. All field types within CivicTheme are supported and several more. Raise an issue if you require other field types supported.
* `civictheme_get_field_referenced_entities` - retrieves and checks access to referenced entities in a field of an entity. Also manages the cacheability metadata for the referenced entities.
* `civictheme_get_field_referenced_entity` - retrieves the first referenced entity in a field of an entity.
* `civictheme_get_referenced_entity_labels` - retrieves labels of the referenced entities.
* `civictheme_embed_svg` - embeds SVG from provided URL. This function does not protect against XSS and relies on appropriate level of user managing SVG Icons.

We recommend revieewing the `web/themes/contrib/`civictheme/includes/utilities.inc\` for these utility functions.

### Updates to components

We have implemented updates to `heading.twig` and `button.twig` by removing the `raw` filter from the content outputs in these components.

Patches below for what change was required of each component:

```
diff --git a/components/01-atoms/heading/heading.twig b/components/01-atoms/heading/heading.twig
index a6f95bf4..ab245f70 100644
--- a/components/01-atoms/heading/heading.twig
+++ b/components/01-atoms/heading/heading.twig
@@ -19,6 +19,6 @@
 
{% if content %}
  <h{{ level }} class="ct-heading {{ modifier_class -}}" {% if attributes is not empty %}{{- attributes|raw -}}{% endif %}>
-    {{- content|raw -}}
+    {{- content -}}
  </h{{ level }}>
{% endif %}
```

In the latest change this looks like this for `button.twig`:

```
diff --git a/components/01-atoms/button/button.twig b/components/01-atoms/button/button.twig
index 708bd62a..332d6ef2 100644
--- a/components/01-atoms/button/button.twig
+++ b/components/01-atoms/button/button.twig
@@ -45,9 +45,9 @@
      } only -%}
    {% endset %}
    {% if icon_placement == 'before' %}
-      {{- icon_markup -}}{{ text|raw }}
+      {{- icon_markup -}}{{ text }}
    {% else %}
-      {{ text|raw }}{{- icon_markup -}}
+      {{ text }}{{- icon_markup -}}
    {% endif %}
  {%- else -%}
    {%- include 'civictheme:text-icon' with {

```

These components have changed over time but the intent is to remove raw from content entered data.

#### Remove attributes field from iframe paragraph

* Create a view to see whether you have any values in Attributes field for Iframe paragraph
* Remove the Attributes field (`field_c_p_attributes`)
* Delete field.field.paragraph.civictheme\_iframe.field\_c\_p\_attributes
* Delete field.storage.paragraph.field\_c\_p\_attributes
* Update `\civictheme_preprocess_paragraph__civictheme_iframe` to add any required iframe attributes to the preprocess

#### Update Content Author and Approver permission

* Remove permission to create, edit Icons media type

### CivicTheme API updates

It is the intention of CivicTheme sub-themes that all values used in CivicTheme components should be retrieved using the CivicTheme API and `civictheme_get_field_value` or `civictheme_get_field_referenced_entities` rather than through the Drupal entity field API.

CivicTheme uses this API for retrieving all field values for components.

* `civictheme_get_field_referenced_entities`
* `civictheme_get_field_referenced_entity`
* `civictheme_get_field_value`
* `civictheme_get_referenced_entity_labels`

These changes are adding the build array argument so CivicTheme can manage cacheable metadata but it is easiest to replace each function completely rather than patch in changes.

#### Replace `civictheme_get_field_referenced_entities` with updated version

```php
/**
 * Gets the referenced entities in a field of an entity.
 *
 * @param \Drupal\Core\Entity\FieldableEntityInterface $entity
 *   The host entity.
 * @param string $field_name
 *   The entity reference field.
 * @param array<string, mixed> $build
 *   Render array to apply cacheability metadata to.
 * * @return array<int|string, \Drupal\Core\Entity\EntityInterface>
 *   Referenced entities.
 */
function civictheme_get_field_referenced_entities(FieldableEntityInterface $entity, string $field_name, array &$build = []): array {
  $trigger_bc = empty($build);
  if ($trigger_bc) {
    @trigger_error('Calling ' . __FUNCTION__ . ' without the $build argument is deprecated in civictheme:1.12.0 It will be required in civictheme:1.13.0. Triggered when getting entity for ' . $field_name . '. See https://www.drupal.org/node/3552745', E_USER_DEPRECATED);
  }
  if (civictheme_field_has_value($entity, $field_name)) {
    /** @var \Drupal\Core\Entity\EntityInterface[] $referenced_entities */
    $referenced_entities = $entity->get($field_name)->referencedEntities();
    if (empty($referenced_entities)) {
      return [];
    }
    $access_checked_referenced_entities = [];
    foreach ($referenced_entities as $referenced_entity) {
      $access = $referenced_entity->access('view', NULL, TRUE);
      $cacheability = $cacheability ?? CacheableMetadata::createFromRenderArray($build);
      $cacheability->addCacheableDependency($access);
      $cacheability->addCacheableDependency($referenced_entity);

      if ($access->isAllowed()) {
        $access_checked_referenced_entities[$referenced_entity->id()] = $referenced_entity;
      }
    }
    $cacheability->applyTo($build);
    if ($trigger_bc && \Drupal::service('renderer')->hasRenderContext()) {
      // The calling code didn't pass a render array that we can attach
      // cacheable metadata to. There is a render context and $build has had
      // cacheability metadata added, so we can simply render it, and it will
      // bubble up to the current theme hook.
      \Drupal::service('renderer')->render($build);
    }
  }

  return $access_checked_referenced_entities ?? [];
}
```

#### Replace `civictheme_get_field_value` with updated version

```php
/**
 * Gets values from fields that CivicTheme regularly uses.
 *
 * This function complements the field API system, providing a convenient way to
 * retrieve commonly used field values specific to CivicTheme.
 *
 * If a field type is not listed, and you need to retrieve its value, consider
 * using the field API system directly.
 *
 * @param \Drupal\Core\Entity\FieldableEntityInterface $entity
 *   Entity to check field existence.
 * @param string $field_name
 *   Field name to get the value for.
 * @param bool $only_first
 *   Return only the first value of a multi-value field.
 * @param mixed $default
 *   Default value to return.
 * @param array<string, mixed> $build
 *   Render array to apply cacheability metadata to.
 *   (required for entity reference fields).
 * @return mixed|null
 *   Whether the field exists and is not empty.
 *
 * @SuppressWarnings(PHPMD.BooleanArgumentFlag)
 * @SuppressWarnings(PHPMD.CyclomaticComplexity)
 * @SuppressWarnings(PHPMD.ElseExpression)
 * @SuppressWarnings(PHPMD.StaticAccess)
 */
function civictheme_get_field_value(FieldableEntityInterface $entity, string $field_name, bool $only_first = FALSE, mixed $default = NULL, array &$build = []): mixed {
  $value = $default;

  if (!civictheme_field_has_value($entity, $field_name)) {
    return $value;
  }

  $field = $entity->get($field_name);
  $field_type = $field->getFieldDefinition()->getType();

  switch ($field_type) {
    case 'boolean':
      $value = (bool) $field->getString();
      break;

    case 'integer':

    case 'list_integer':
      $value = (int) $field->getString();
      break;

    case 'list_string':
    case 'string':
    case 'string_long':
      $value = $field->getString();
      $value = Xss::filter($value);
      break;

    // Field types where we want to return field item.
    case 'datetime':
    case 'daterange':
    case 'image':
    case 'link':
      $list = $field;
      if (!$list->isEmpty()) {
        $value = $only_first ? $list->first() : $list;
      }
      break;

    // Field types where we want to return entities.
    case 'entity_reference':
    case 'entity_reference_revisions':
      if ($only_first) {
        $value = civictheme_get_field_referenced_entity($entity, $field_name, $build);
      }
      else {
        $value = civictheme_get_field_referenced_entities($entity, $field_name, $build);
      }
      break;

    case 'text_long':
    case 'text_with_summary':
    case 'text':
      // Opinionated.
      // This implementation renders the field if it has a single value.
      // If the field contains multiple values, it relies on view() to handle
      // the rendering.
      if ($only_first) {
        $field = $field->first();
        $field_value = $field->get('value')->getString();
        $field_format = $field->get('format')->getString();
        $value = empty($field_format) ? $field_value : check_markup($field_value, $field_format);
        break;
      }

      $value = $field->view();
      break;
  }

  return $value;
}
```

### Replace `civictheme_get_field_referenced_entity` function

Update the function with the below:

```php
/**
 * Gets the first referenced entity in a field of an entity.
 *
 * @param \Drupal\Core\Entity\FieldableEntityInterface $entity
 *   The host entity.
 * @param string $field_name
 *   The entity reference field.
 * @param array<string, mixed> $build
 *   Render array to apply cacheability metadata to.
 *
 * @return \Drupal\Core\Entity\EntityInterface|null
 *   Referenced entity.
 */
function civictheme_get_field_referenced_entity(FieldableEntityInterface $entity, string $field_name, array &$build = []): ?EntityInterface {
  $referenced_entity = NULL;

  $entities = civictheme_get_field_referenced_entities($entity, $field_name, $build);
  if (!empty($entities)) {
    $referenced_entity = reset($entities);
    if (!$referenced_entity instanceof EntityInterface) {
      $referenced_entity = NULL;
    }
  }

  return $referenced_entity;
}
```

### Replace `civictheme_get_referenced_entity_labels` function

```php
/**
 * Get labels of the referenced entities.
 *
 * @param \Drupal\Core\Entity\FieldableEntityInterface $entity
 *   The host entity.
 * @param string $field_name
 *   The entity reference field.
 * @return array<int,string>
 *   The label(s).
 *
 * @SuppressWarnings(PHPMD.StaticAccess)
 */
function civictheme_get_referenced_entity_labels(FieldableEntityInterface $entity, string $field_name): array {
  $labels = [];
  $referenced_entities = civictheme_get_field_value($entity, $field_name) ?? [];
  foreach ($referenced_entities as $referenced_entity) {
    if ($referenced_entity instanceof EntityInterface) {
      $labels[] = Xss::filter((string) $referenced_entity->label());
    }
  }

  return $labels;
}
```

### Replace `civictheme_embed_svg`

```php
/**
 * Embed SVG from provided URL.
 *
 * @param string $url
 *   Local URL or local path to retrieve SVG from.
 * @param array $css_classes
 *   Array of CSS classes to add.
 *
 * @return string|null
 *   Loaded SVG or NULL if unable to load SVG.
 */
function civictheme_embed_svg(string $url, array $css_classes = []): ?string {
  $svg_path = DRUPAL_ROOT . (str_starts_with($url, 'http') ? parse_url(str_replace('.png', '.svg', $url), PHP_URL_PATH) : str_replace('.png', '.svg', $url));
  if (!file_exists($svg_path)) {
    return NULL;
  }

  $content = (string) file_get_contents($svg_path);

  if (!empty($css_classes)) {
    $content = str_replace('<svg ', '<svg class="' . implode(' ', $css_classes) . '" ', $content);
  }

  // Tag list taken from
  // https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Element.
  // // Excludes <a>, <script> and <style>.

  $supported_svg_tags = implode('', [
    '<animate>',
    '<animateMotion>',
    '<animateTransform>',
    '<circle>',
    '<clipPath>',
    '<defs>',
    '<desc>',
    '<ellipse>',
    '<feBlend>',
    '<feColorMatrix>',
    '<feComponentTransfer>',
    '<feComposite>',
    '<feConvolveMatrix>',
    '<feDiffuseLighting>',
    '<feDisplacementMap>',
    '<feDistantLight>',
    '<feDropShadow>',
    '<feFlood>',
    '<feFuncA>',
    '<feFuncB>',
    '<feFuncG>',
    '<feFuncR>',
    '<feGaussianBlur>',
    '<feImage>',
    '<feMerge>',
    '<feMergeNode>',
    '<feMorphology>',
    '<feOffset>',
    '<fePointLight>',
    '<feSpecularLighting>',
    '<feSpotLight>',
    '<feTile>',
    '<feTurbulence>',
    '<filter>',
    '<foreignObject>',
    '<g>',
    '<image>',
    '<line>',
    '<linearGradient>',
    '<marker>',
    '<mask>',
    '<metadata>',
    '<mpath>',
    '<path>',
    '<pattern>',
    '<polygon>',
    '<polyline>',
    '<radialGradient>',
    '<rect>',
    '<set>',
    '<stop>',
    '<svg>',
    '<switch>',
    '<symbol>',
    '<text>',
    '<textPath>',
    '<title>',
    '<tspan>',
    '<use>',
    '<view>',
  ]);

  return strip_tags($content, $supported_svg_tags);
}
```

### Update `civictheme_preprocess_paragraph__civictheme_manual_list`

Update preprocessing of manual list to only render paragraphs that have a field value. With the access checking in `civictheme_get_field_referenced_entities` you need to check to see if the card is a reference card and if it is check to see whether the user has access to the referenced entity before adding. Without this you will have empty columns if the user does not have access to the referenced entity.

```php
  /** @var \Drupal\Core\Entity\ContentEntityInterface[] $items */
  $items = civictheme_get_field_referenced_entities($paragraph, 'field_c_p_list_items', $variables);
  $builder = \Drupal::entityTypeManager()->getViewBuilder('paragraph');
  if ($items) {
    foreach ($items as $item) {
      if (!$item->hasField('field_c_p_reference')) {
        $variables['rows'][] = $builder->view($item);
        continue;
      }
      $referenced_item = civictheme_get_field_referenced_entity($item, 'field_c_p_reference', $variables);
      if ($referenced_item instanceof EntityInterface) {
        $variables['rows'][] = $builder->view($item);
      }
    }
  }


```

#### Updating the retrieving of entity reference fields and referenced entities within CivicTheme and sub-themes

CivicTheme was not correctly managing cacheable metadata within its preprocess functions. We have updated the CivicTheme API to manage this at the field getter level.

This requires updates to CivicTheme and sub-theme implementations to pass the build array into the CivicTheme API functions.

* Firstly find a list of entity reference fields in your project, run the following command:

  `grep -l "type: entity_reference" <path-to-your-config-directory>field.storage*.yml | xargs grep "^field_name:" | awk '{print $2}'`
* This will return a list of field names, now with this list you will need to update how you access the field data
* Firstly, you need to ensure you are using either `civictheme_get_field_value` or `civictheme_get_field_referenced_entities` - (if you do not then you are responsible for ensuring users have adequate access to these entities in your subtheme)
* Then for each of these reference fields update the API getter functions.
* For `civictheme_get_field_referenced_entities` search for the following usages for each reference field and add the missing `$variabes` build argument
  * Examples:
    * From: `civictheme_get_field_referenced_entities($entity, 'field_c_b_social_icons');`
    * To: `civictheme_get_field_referenced_entities($entity, 'field_c_b_social_icons', $variables);`
* For each `civictheme_get_field_value`:
  * From: `$featured_image = civictheme_get_field_value($block, 'field_c_b_featured_image', TRUE);`
  * To: `$featured_image = civictheme_get_field_value($block, 'field_c_b_featured_image', TRUE, build: $variables);`
* For each `civictheme_get_field_referenced_entity`:
  * From: `$referenced_item = civictheme_get_field_referenced_entity($item, 'field_c_p_reference');`
  * To: `$referenced_item = civictheme_get_field_referenced_entity($item, 'field_c_p_reference', $variables);`
* If you do not get all the references, if you turn on `error_reporting` to `verbose` you will see errors being logged.
* We have created a backward compatible function but this will be removed in future versions of CivicTheme - this error will tell you what field you should search for in your codebase. `'Calling civictheme_get_field_referenced_entities without the $build argument is deprecated in civictheme:1.12.0 It will be required in civictheme:1.13.0. Triggered when getting entity for <your field name>. See https://www.drupal.org/node/3552745'`

### Updates to accessing node titles and other labels

We need to update to filter node titles and other entity labels. CivicTheme uses node titles in the following places, that need their own update:

* `_civictheme_preprocess_block__civictheme_banner`
* `_civictheme_preprocess_node__civictheme_page__full`

We need to ensure we are filtering title fields - this is the change we employed in `_civictheme_preprocess_block__civictheme_banner`:

```
  $title = \Drupal::service('title_resolver')->getTitle(\Drupal::request(), \Drupal::routeMatch()->getRouteObject());
  $title = (string) (is_array($title) ? reset($title) : ((string) $title));
  $title = Xss::filter($title);
  $title = strip_tags($title);
  $variables['title'] = $title;

```

### Updates to outputting link text

In link fields with link title enabled, we also need to provide filtering of the link title, searching for use of `getText` should find the areas that need attention within the themes:

```
  foreach ($breadcrumb->getLinks() as $link) {
    $link_text = $link->getText();
    $variables['breadcrumb']['links'][] = [
      'text' => is_array($link_text) ? $link_text : Xss::filter((string) $link_text),
      'url' => $link->getUrl()->toString(),
    ];
  }
```

### Updates to menu link preprocessing

We have added filtering of menu link titles to `_civictheme_preprocess_menu_items`:

The menu link title field needs to be correctly filtered:

```
$item['title'] = isset($item['title']) ? Xss::filter($item['title']) : '';
```

### Update to render arrays in some cases

We have removed raw from `button.twig` and `heading.twig` - if you were relying on html to being outputted within these properties you will need to carry out additional work to implement these changes.

### Updates in sub-themes

The above gives a good summary of the changes made in CivicTheme. This process of updating the CivicTheme API and potentially updating to *use* the CivicTheme API should be carried out. If any additional components have been added or modifications to menus etc, then XSS filtering should be applied to titles.

### How to test / test instructions

1. When `<script>alert('`☠️');`</script>` is entered in:
   1. Textfields of CivicTheme components
   2. Title fields for nodes and taxonomy terms
   3. Link text fields
   4. Menu links
2. It should not generate an alert
3. If you have access to behat and behat-steps (what CivicTheme relies) upon, look to adapt and add the XSS tests from CivicTheme to test your own components and custom components


# Partnerships

Interested in significant contributions or deployments of CivicTheme? Learn more here.

### CivicTheme partnerships and collaboration

CivicTheme is an **open-source design system** governed by a diverse community of **government agencies**, **digital agencies**, and **individual contributors**. The **open-governance model** ensures that CivicTheme grows in a way that benefits the wider community while maintaining consistency, accessibility, and government-grade standards.

***

### **Partnering with CivicTheme**

If you would like to collaborate on CivicTheme, particularly for large contributions like developing a version for another technology (e.g., React, Vue, etc.), the following guidelines will help ensure a smooth process and productive partnership:

#### **1. Proposal submission**

Before any major development begins, it’s important to present your idea to the broader CivicTheme community for consideration. This will ensure that the proposed work aligns with the current vision and standards of CivicTheme. To initiate a partnership:

* **Submit a proposal**: Provide an outline of your partnership idea via **GitHub** (e.g., in the form of an RFC or issue) or directly reach out to the CivicTheme team at <info@civictheme.io>.
* Include details such as:
  * **Goal**: What is the purpose of your proposal (e.g., creating a **React** version of CivicTheme)?
  * **Scope**: What components or parts of the system would this impact?
  * **Resources**: How will your team contribute (e.g., developers, designers, testers)?
  * **Timeline**: Provide a rough estimate of timeframes for the proposed work.

#### **2. Community and governance review**

Once the proposal is submitted, it will be reviewed by the **CivicTheme governing body**, which includes key stakeholders from government agencies, digital agencies, and the broader CivicTheme community.

The review process includes:

* **Discussion and feedback**: Your proposal will be discussed in community meetings and may receive feedback or suggestions for modification.
* **Community involvement**: Depending on the scope of the proposal, input from the broader community may be solicited to ensure the change aligns with CivicTheme's goals.

#### **3. Partnership meeting**

For large-scale contributions like developing a **React version** of CivicTheme, it will be necessary to hold a **partnership meeting** with the CivicTheme core team and stakeholders. This meeting will allow for deeper discussion on:

* **Technical approach**: How will the new version (e.g., React) be structured, and what are the technical requirements?
* **Alignment with CivicTheme principles**: Ensuring that the new version adheres to the same **accessibility**, **design standards**, and **component structure** as the original.
* **Governance and maintenance**: Defining responsibilities for ongoing maintenance and updates, and ensuring the new version has long-term support.
* **Community benefits**: Evaluating how the new version will support the wider CivicTheme community and government users.

The **CivicTheme governing body** will provide feedback and give approval before moving forward.

#### **4. Development and implementation**

Once the partnership has been approved, development can proceed with continued community involvement:

* **Open development**: Keep the development of the new version open and transparent, using GitHub for version control, issues, and pull requests.
* **Regular updates**: Provide regular progress updates to the CivicTheme community, either through GitHub, Slack, or dedicated community meetings.
* **Collaboration**: CivicTheme is built on collaboration, so invite input and feedback from other developers and contributors during the development process.

#### **5. Testing and quality assurance**

CivicTheme adheres to **government-grade standards** for **accessibility**, **security**, and **performance**. Any new partnership should ensure that:

* The new version (e.g., React) follows the **WCAG 2.2 AA accessibility guidelines**.
* It is tested for **cross-browser** and **cross-device compatibility**.
* The new components match the design and behaviour of existing CivicTheme components.

Community testing and feedback will be encouraged to maintain the highest standards of quality.

***

### **Why partner with CivicTheme?**

Partnering with CivicTheme offers numerous benefits:

* **Contribute to the open-source community**: Your work will be part of a growing ecosystem used by government agencies and organisations to deliver accessible, consistent digital experiences.
* **Shape the future of CivicTheme**: Your partnership could drive the expansion of CivicTheme into new technologies, helping it reach a wider audience and be more adaptable across platforms.
* **Collaborate with experts**: Work alongside a community of government, digital agency, and open-source experts, sharing insights and knowledge to build something impactful.

***

### **Get involved**

If you're interested in partnering with CivicTheme, start by submitting your proposal or reaching out to discuss your ideas:

* Submit a proposal via **GitHub** or contact us directly at <info@civictheme.io>.
* Join the [CivicTheme Slack Channel](https://drupal.slack.com/archives/C039UV0CQBZ) to participate in ongoing discussions and engage with the community.

We welcome contributions from all who want to collaborate on building better, more inclusive digital solutions.

***

### **Summary**

Partnerships are key to CivicTheme’s growth and sustainability. Whether you’re developing a new version for React or expanding existing functionality, collaboration with the **CivicTheme governing body** ensures alignment with the broader vision and standards. By following the process outlined here, your partnership can help CivicTheme thrive and benefit the entire community.


# GovCMS SaaS

This playbook is a step-by-step guide for teams building and maintaining a CivicTheme site on GovCMS SaaS. It is written for tech leads, project managers, and site managers — people who need to understand the process of setting up, customising, and keeping a CivicTheme site running.

CivicTheme is an open-source, government-grade design system built as a Drupal theme. It provides a library of accessible, reusable components following atomic design principles. On GovCMS SaaS, CivicTheme is installed as a custom theme rather than via Composer, and built assets are committed to the repository. This playbook accounts for those platform-specific requirements.

## How to use this playbook

Work through the chapters in order. Each chapter builds on the previous one, following the natural lifecycle of a CivicTheme project: install, configure, customise, maintain.

The playbook provides the task-oriented workflow — the sequencing, decisions, and practical steps your team needs. Where detailed reference material already exists in the CivicTheme documentation, the playbook links to it rather than duplicating it. This keeps everything in one place and ensures the information stays current.

## Chapters

### Site Development

1. [**Installation**](/playbook/govcms/01-installation) — Get CivicTheme installed on GovCMS SaaS using the automated script or manual process, generate your sub-theme, build assets, and provision content.
2. [**Setting Up Your Sub-Theme**](/playbook/govcms/02-sub-theme-setup) — Understand the sub-theme directory structure, configure the build system, run Storybook locally, and connect your sub-theme to Drupal.
3. [**Configuring Colors and Theme Settings**](/playbook/govcms/03-colors-and-settings) — Set up your brand colors, configure the header and footer, and understand how CivicTheme's color system derives a full palette from your brand values.
4. [**Overriding Existing Components**](/playbook/govcms/04-overriding-components) — Change how an existing CivicTheme component looks or behaves by copying it into your sub-theme and modifying it there.
5. [**Creating New Components**](/playbook/govcms/05-creating-components) — Build a new component from scratch following CivicTheme conventions, from atomic design placement through to Drupal integration.

### Site Maintenance

6. [**Updating Packages**](/playbook/govcms/06-updating-packages) — Keep your CivicTheme base theme, sub-theme dependencies, and Node.js packages up to date with a clear update and rebuild workflow.
7. [**Security Updates**](/playbook/govcms/07-security-updates) — Subscribe to security advisories, assess severity, and apply patches to your GovCMS SaaS site.

## Who is this for?

| Role                | What you will get from this playbook                                                                                                         |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tech lead**       | End-to-end process for setting up and customising a CivicTheme site, including component architecture and override patterns                  |
| **Project manager** | Understanding of the process of installing and managing a CivicTheme site, dependencies between steps, and what the team needs at each stage |
| **Site manager**    | Understanding of the maintenance process for keeping the site secure and up to date after the initial build                                  |

## Getting help

If you run into issues at any point, CivicTheme has active support channels including a Drupal Slack channel, issue queues, and email support. For all options, see [Getting help](/getting-started/getting-help).


# Installation

This chapter walks your team through getting CivicTheme installed and running on a GovCMS SaaS project. By the end, you will have CivicTheme enabled, a sub-theme generated, front-end assets built, and the site ready for customisation.

GovCMS SaaS does not support installing themes via Composer, so CivicTheme is installed as a custom theme. An automated script handles the heavy lifting, but a manual path is available if you need more control.

## Prerequisites

* [ ] Access to the GovCMS GitLab project
* [ ] A support ticket actioned to enable config imports
* [ ] Your user added with the administrator role in production
* [ ] All [GovCMS SaaS required software](https://github.com/govCMS/GovCMS/wiki/1.1-Local-setup#dependencies) installed (Docker, Ahoy, tar, curl, Bash)
* [ ] NodeJS 22+ and NPM 10+ available on your machine
* [ ] A GovCMS project already set up and installed locally (`ahoy install` completed)

## Step 1: Choose your installation method

| Method    | Best for                               | Time         |
| --------- | -------------------------------------- | ------------ |
| Automated | New projects, standard setups          | \~15 minutes |
| Manual    | Existing projects, custom requirements | \~45 minutes |

There are automated steps (a bash script that automates the steps and a follow along manual step process.

For an overview of both methods and when to choose each, see the [GovCMS SaaS installation overview](/installation/govcms-saas).

## Step 2: Run the installation

### Option A: Automated installation (recommended)

The automated script downloads CivicTheme, configures modules, removes GovCMS default content types, generates your sub-theme, and optionally provisions content — all in one command.

The script arguments, flags, download instructions, and example commands are documented in the [automated installation guide](/installation/govcms-saas/govcms-saas-automated).

> **Naming tip**: Name your sub-theme after the site, not after CivicTheme. Avoid including "civic" or "civictheme" in the machine name — it creates confusion when maintaining the theme later.

### Option B: Manual installation

If you need more control, the manual process walks through each step individually: downloading CivicTheme, enabling modules, removing GovCMS default content types via the `civictheme_govcms` helper module, generating the sub-theme, and building assets.

The full step-by-step process is covered in the [manual installation guide](/installation/govcms-saas/govcms-saas-manual).

## Step 3: Build front-end assets

After installation (automated or manual), build your sub-theme's CSS, JavaScript, and assets:

```bash
cd themes/<SUBTHEME_MACHINE_NAME>
nvm use
npm install
npm run build
```

Verify that the `themes/<SUBTHEME_MACHINE_NAME>/dist` directory was created. Navigate to your site in the browser and confirm that default CivicTheme styling is applied.

### Commit built assets

GovCMS SaaS requires built assets to be committed to the repository. But it is important not to commit your `node_modules` and other developer tools.

**Review** [**committing built assets**](/installation/govcms-saas/govcms-saas-manual#commit-built-assets) **for managing your code repository.**

## Step 4: Provision content

CivicTheme includes pre-configured blocks, menus, and configuration entities that set up the default site structure (header, footer, navigation, etc.). Unless a database forklift is being undertaken, the provisioning needs to happen **twice** — once locally to capture the configuration, and once in production to populate it with content. Both are triggered via the **Provision content** button at `/admin/appearance/settings/<SUBTHEME_MACHINE_NAME>`.

The full provisioning workflow, what gets created, how to avoid content forklifts, and troubleshooting are documented in the [GovCMS content provisioning guide](/installation/govcms-saas/govcms-content-provisioning).

## Step 5: Verify the installation

After provisioning, your site should match the [default CivicTheme site](https://default.civictheme.io/) (without homepage content). Check that:

* [ ] The header displays with the CivicTheme logo and navigation
* [ ] The footer displays with default blocks (social links, footer navigation, acknowledgement, copyright)
* [ ] The site responds correctly on mobile (navigation collapses to mobile menu)
* [ ] The admin theme is accessible at `/admin`

## Troubleshooting

For common installation issues (content not appearing, styling not applied, provisioning button missing), see the troubleshooting section in the [GovCMS SaaS installation reference](/installation/govcms-saas#troubleshooting).

## Where to get help

CivicTheme provides multiple support channels for installation issues. For all support options, see [Getting help](/getting-started/getting-help).

## Next step

With CivicTheme installed and your sub-theme generated, the next step is to understand the sub-theme structure and set up your local development workflow.

Continue to [Chapter 2: Setting Up Your Sub-Theme](/playbook/govcms/02-sub-theme-setup).


# Setting Up Your Sub-Theme

This chapter walks through the sub-theme that was generated during installation and gets your local development environment ready. By the end, you will understand the sub-theme directory structure, have the build system running, and be able to view components in Storybook.

**CivicTheme must never be modified directly. Unless exceptional circumstances which must be logged in your project documentation as updates will wipe out these changes**

Your sub-theme inherits everything from CivicTheme and is where all custom work happens — overriding components, adding new ones, and adjusting styles. The build system merges your sub-theme's components with the base theme's components at compile time, so your overrides take priority automatically.

## Prerequisites

See the [sub-theme reference](/development/drupal-theme/sub-theme#prerequisites).

## Step 1: Understand the sub-theme directory structure

The sub-theme creation script generates a complete project scaffold. Understanding this structure is essential before making any changes. The key directories you will work in most are `components/`, `assets/`, `templates/`, and the two variable files (`variables.base.scss` and `variables.components.scss`).

The full directory structure, library system, and placeholder asset replacement are documented in the [sub-theme reference](/development/drupal-theme/sub-theme).

## Step 2: Understand the build system

The build system is a custom Node.js script (`build.js`) that compiles your sub-theme's SCSS, JavaScript, and assets. It is not webpack or gulp — it is purpose-built for CivicTheme's component architecture. The essential commands are:

```bash
npm run build          # Full build (assets + Storybook static site)
npm run dist           # Compile assets only (faster, no Storybook)
npm run dist:watch     # Watch mode (recompiles on file changes)
npm run lint           # Lint SCSS and JavaScript
```

The build pipeline, output files, and configuration are documented in the [build system reference](/development/drupal-theme/systems/build).

## Step 3: Run Storybook

Storybook provides an interactive development environment where you can view, test, and document components in isolation — without needing a running Drupal site.

Start the development server:

```bash
npm run storybook
```

This runs `npm run dist` first to compile assets, then starts the Storybook dev server with file watching. Both the asset compilation and Storybook will watch for changes and hot-reload automatically.

## Step 4: Verify the development workflow

Run through this checklist to confirm your development environment is working:

* [ ] `npm run dist` completes without errors
* [ ] `npm run dev` starts storybook and watches for changes
* [ ] Components display correctly in Storybook with interactive controls
* [ ] Changes to a component's `.scss` file are reflected after running `npm run dist`
* [ ] The Drupal site displays your sub-theme correctly with the compiled assets
* [ ] `npm run lint` runs without errors

## Troubleshooting

If you encounter build, Storybook, or cache issues, see the troubleshooting section in the [sub-theme reference](/development/drupal-theme/sub-theme#troubleshooting).

## Next step

With your sub-theme set up and the development workflow verified, the next step is to configure your site's visual identity — colors, header, footer, and other theme settings.

Continue to [Chapter 3: Configuring Colors and Theme Settings](/playbook/govcms/03-colors-and-settings).


# Configuring Colors and Theme Settings

This chapter covers the first customisation most teams tackle after installation: making the site match your brand. CivicTheme provides two levels of visual configuration — a no-code UI for site managers and SCSS variable overrides for developers. By the end, you will have your brand colors applied, header and footer configured, and understand how CivicTheme's color system works.

## Prerequisites

* [ ] Sub-theme set up and build system working (see [Chapter 2](/playbook/govcms/02-sub-theme-setup))
* [ ] Administrator access to the Drupal site
* [ ] Your brand's color values (hex codes) for primary, secondary, and accent colors

## Step 1: Access the theme settings page

All visual configuration starts at the theme settings page:

```
/admin/appearance/settings/<your_theme_machine_name>
```

This page provides sections for colors, header, footer, components, and content provisioning. Changes made here take effect immediately across the site without requiring a code deployment.

## Step 2: Configure the header and footer

The header and footer each have independent theme (light/dark) and logo settings. CivicTheme supports multiple logo display modes (default, stacked, inline, inline stacked). Upload your logo files in `assets/logos/` in your sub-theme, then select them through the theme settings.

The header configuration reference covers all available options including navigation styles. See [Header configuration](/development/drupal-theme/header). The footer configuration reference covers footer-specific options including background image settings. See [Footer configuration](/development/drupal-theme/footer).

## Step 3: Set up brand colors

CivicTheme's color system is built around a small set of **brand colors** that automatically derive a full color palette. You set 3 brand colors per theme (light and dark), and CivicTheme generates all the heading, body, background, border, interaction, and status colors from them.

The Color Selector UI, brand color derivation formulas, individual palette overrides, and Drush commands for scripted workflows are documented in the [color selector reference](/development/drupal-theme/color-selector).

The full color system architecture, the `ct-component-theme` mixin, CSS custom property generation, and variable naming conventions are documented in the [colors system reference](/development/drupal-theme/systems/colors).

## Step 4: Override colors via SCSS (developer workflow)

For deeper control, developers can override colors at the SCSS level in the sub-theme. This is useful when you want colors baked into the compiled CSS rather than managed through the Drupal UI.

There are three levels of SCSS color override:

1. **Brand colors** — override `$ct-colors-brands` in `variables.base.scss` to change the foundation values that feed into all derivations
2. **Palette colors** — override `$ct-colors` in `variables.base.scss` to set specific semantic colors (heading, body, interaction-background, etc.)
3. **Component colors** — override individual component variables in `variables.components.scss` (e.g., `$ct-button-light-primary-background-color`)

Component variables follow the naming pattern: `$ct-[component]-[theme]-[subcomponent]-[state]-[property]`.

After any SCSS changes, rebuild:

```bash
npm run dist
```

The variable override system, `!default` flag mechanism, and the two variable files are documented in the [variables reference](/development/uikit/variables).

## Step 5: Verify your color configuration

After setting up colors (via UI or SCSS), check these areas:

* [ ] Light theme pages — headings, body text, links, and buttons use your brand colors
* [ ] Dark theme sections — colors switch correctly when components use the dark theme
* [ ] Header and footer — themed correctly with your logo and brand colors
* [ ] Interactive elements — buttons, links, and form fields show correct hover and focus states
* [ ] Status messages — information, warning, error, and success messages are clearly distinguishable
* [ ] Accessibility — ensure sufficient contrast ratios between text and backgrounds (WCAG 2.2 AA requires 4.5:1 for body text, 3:1 for large text)

## Troubleshooting

For common color issues (colors not updating, dark theme problems, palette overrides being reset), see the troubleshooting section in the [color selector reference](/development/drupal-theme/color-selector#troubleshooting).

## Next step

With your site's visual identity configured, the next step is to learn how to modify existing CivicTheme components when the default appearance or behavior does not meet your needs.

Continue to [Chapter 4: Overriding Existing Components](/playbook/govcms/04-overriding-components).


# Overriding Existing Components

This chapter covers the most common development task on a CivicTheme project: changing how an existing component looks or behaves. Rather than modifying the base theme (which must never be changed), you copy component files into your sub-theme and modify them there. The build system automatically picks up your version and uses it instead of the original.

## Prerequisites

* [ ] Sub-theme set up with build system working (see [Chapter 2](/playbook/govcms/02-sub-theme-setup))
* [ ] Storybook running locally for preview
* [ ] Familiarity with Twig, SCSS, and BEM naming conventions

## Overview

Before overriding a component, decide whether you actually need an override or a new component. Then follow the copy-and-register process: copy the component directory, add a `replaces` key, and modify only what's needed. For style-only changes, you can override SCSS variables without copying the component at all.

The full override process — when to override vs. create new, the copy-and-register steps, style-only alternatives, and rebuild/verify workflow — is documented in the [overriding components reference](/development/uikit/variables/overriding-components).

The file conventions (Twig, SCSS, JS patterns) and common pitfalls are in the [components system reference](/development/drupal-theme/systems/components).

## Next step

When overriding an existing component is not enough and you need something entirely new, the next chapter covers creating components from scratch.

Continue to [Chapter 5: Creating New Components](/playbook/govcms/05-creating-components).


# Creating New Components

This chapter walks through building a completely new component for your sub-theme. It covers the full lifecycle from deciding where the component fits in the atomic design hierarchy through to integrating it with Drupal via paragraph types and preprocess hooks. By the end, you will have a repeatable process for adding custom components that follow CivicTheme conventions.

## Prerequisites

* [ ] Sub-theme set up with build system working (see [Chapter 2](/playbook/govcms/02-sub-theme-setup))
* [ ] Understanding of component override patterns (see [Chapter 4](/playbook/govcms/04-overriding-components))
* [ ] Familiarity with Twig, SCSS, JavaScript, and Drupal's paragraph system

## Step 1: Decide the component level and create files

Determine where your component fits in the atomic design hierarchy (atom, molecule, or organism), then create the required file set: `.component.yml`, `.twig`, `.scss`, `.stories.js`, and optionally `.js`.

The atomic design levels, required files, variable registration, and component checklist are documented in the [creating components reference](/development/uikit/variables/creating-components). The file conventions (Twig, SCSS, JS patterns) are in the [components system reference](/development/drupal-theme/systems/components).

## Step 3: Build and preview

Compile your new component and preview it in Storybook:

```bash
npm run dist
npm run storybook
```

Navigate to your component in Storybook and verify all props work correctly across both light and dark themes.

## Step 4: Integrate with Drupal

To use your component in Drupal's content authoring workflow, you need to connect it to Drupal's data layer. SDC components can be included in any Drupal Twig template — not just paragraph templates. Look at the `templates` directory in CivicTheme to see how components are integrated into Drupal's theme system (nodes, blocks, fields, pages, etc.).

A common pattern for content-authorable components involves three pieces:

1. **A paragraph type** — often a component needs multiple fields to be grouped together. CivicTheme in many instances uses a paragraph type in Drupal with fields to match to a component's props. Field names follow CivicTheme's naming convention (`field_c_p_` prefix for CivicTheme paragraph fields, `field_p_` for custom paragraph fields).
2. **A preprocess include** — create an include file in `includes/` that extracts Drupal field values and maps them to component props using CivicTheme utility functions like `civictheme_get_field_value()`. Include it from your sub-theme's `.theme` file.
3. **A Drupal template** — create a thin Twig template in `templates/paragraph/` that includes your component and passes the preprocessed variables. Keep HTML in the component template, not in the Drupal template.

The three-step implementation pattern, field naming conventions, utility functions, and best practices are documented in the [mapping system reference](/development/drupal-theme/systems/mapping). The template conventions are documented in the [templates reference](/development/drupal-theme/templates). Asset management is covered in the [assets reference](/development/drupal-theme/assets).

## Step 5: Rebuild, deploy, and test

```bash
npm run dist
drush cr
```

1. Create a page in Drupal and add your new paragraph type
2. Fill in the fields and save
3. Verify the component renders correctly on the front end
4. Test in both light and dark theme contexts

## Component checklist

See the [component checklist](/development/uikit/variables/creating-components#component-checklist) for the full verification list before considering your component complete.

## Contributing back

If your component may be useful to the broader CivicTheme community, consider contributing it upstream. The contribution guide covers the process from feature branch through PR review. See [Contributing](https://github.com/civictheme/docs/blob/main/contributing.md).

## Next step

With both component overriding and creation covered, the remaining chapters focus on keeping your site current and secure after the initial build.

Continue to [Chapter 6: Updating Packages](/playbook/govcms/06-updating-packages).


# Updating Packages

This chapter covers keeping your CivicTheme site current after the initial build. It explains the dependency chain, walks through the update process for both the CivicTheme base theme and your sub-theme's Node.js packages, and covers regression testing to catch breaking changes.

## Prerequisites

* [ ] A working CivicTheme sub-theme (see [Chapter 2](/playbook/govcms/02-sub-theme-setup))
* [ ] Composer access (for Drupal community sites) or GitLab access (for GovCMS SaaS)
* [ ] Familiarity with the build system (see [Chapter 2](/playbook/govcms/02-sub-theme-setup))

## Understanding the dependency chain

Your site has three layers of dependencies, each updated independently:

| Layer                         | Manager                                                     | What it affects                                    |
| ----------------------------- | ----------------------------------------------------------- | -------------------------------------------------- |
| CivicTheme base theme         | Composer (Drupal) or manual download (GovCMS)               | Component library, preprocess hooks, Drupal config |
| Sub-theme Node packages       | npm                                                         | Build system, Storybook, SCSS compilation, linting |
| Drupal core + contrib modules | Composer (Drupal) or managed by platform team (GovCMS SaaS) | CivicTheme's module dependencies                   |

On GovCMS SaaS, Drupal core and contributed module updates are managed by the GovCMS platform team — you do not update these yourself. The platform team applies security patches and version upgrades on a managed schedule. Your responsibility on GovCMS SaaS is limited to the CivicTheme base theme and your sub-theme's Node packages. On standalone Drupal sites, you manage all three layers via Composer.

Updates should flow top-down: update the base theme first, then sub-theme packages, then rebuild and test.

## Step 1: Update the CivicTheme base theme

### Drupal community sites

Update via Composer:

```bash
composer update drupal/civictheme
drush updatedb
drush cr
```

Review the release notes on the [CivicTheme project page](https://www.drupal.org/project/civictheme/releases) before updating.

**Pay attention to breaking changes to component schemas, new module dependencies, changes to preprocess hooks or utility functions, and SCSS variable or mixin changes. Updates can be a painful process depending on customisations and how set on the exact look of your existing site you are.**

### GovCMS SaaS sites

GovCMS SaaS does not use Composer for theme management. Download the new version, replace the `themes/custom/civictheme` directory, run database updates, and export configuration.

The GovCMS-specific update procedure covers additional steps for updating the CivicTheme UI Kit's SCSS dependencies. See [Updating CivicTheme on GovCMS SaaS](https://github.com/civictheme/docs/blob/main/development/drupal-theme/updating-civitheme-govcms-sass.md).

## Step 2: Update sub-theme Node.js dependencies

Check for outdated packages with `npx npm-check-updates`. Update minor/patch versions (generally safe) with `npx npm-check-updates -u --target minor && npm install`. Review changelogs before updating major versions, particularly for Storybook, sass-embedded, and Vite.

## Step 3: Rebuild and test

After any update, run a full rebuild and verification:

```bash
npm run dist
npm run build
npm run lint
drush cr
```

### Regression testing checklist

* [ ] **Build completes** — `npm run dist` and `npm run build` finish without errors
* [ ] **Linting passes** — `npm run lint` has no new errors
* [ ] **Storybook loads** — all components render correctly at `http://localhost:6006`
* [ ] **Header and footer** — render correctly with your theme settings
* [ ] **Navigation** — primary and secondary navigation function correctly
* [ ] **Cards and lists** — all card types display correctly in list views
* [ ] **Forms** — form elements render and submit correctly
* [ ] **Light/dark themes** — components switch correctly between themes
* [ ] **Responsive layout** — site looks correct at mobile, tablet, and desktop breakpoints
* [ ] **Content authoring** — paragraphs can be added and edited in the content editor

### Visual regression testing

Before applying any update, capture a visual baseline of your site so you can compare it against the upgraded version. This makes it possible to identify exactly what changed and work through each difference methodically.

**1. Capture a baseline**

Use a visual regression tool (such as BackstopJS, Percy, or Playwright's screenshot comparison) to take screenshots of key pages and components before the update. Cover:

* Homepage and major landing pages
* Content pages using each content type
* Pages with custom component overrides
* Header, footer, and navigation in both desktop and mobile viewports
* Light and dark theme variants

**2. Apply the update and capture again**

After updating and rebuilding, run the same screenshot suite against the updated site.

**3. Compare and triage**

Review the visual diff report and categorise each difference:

* **Expected changes** — improvements or intentional design changes documented in the release notes
* **Broken components** — components that no longer render correctly due to schema changes, removed variables, or markup updates
* **Page errors** — pages that fail to render or show PHP/Twig errors
* **Subtle regressions** — spacing, color, or typography shifts that may indicate a changed variable or mixin

**4. Work through differences methodically**

For each broken component or regression:

1. Check if the component has an override in your sub-theme — compare your override against the updated base component
2. Look for changes to the `.component.yml` schema (new required props, renamed props, changed enums)
3. Check for renamed or removed SCSS variables and mixins in the release notes
4. Update your sub-theme's override to match the new interface, rebuild, and verify

Visual regression testing is particularly valuable for CivicTheme updates because component changes can cascade through the site in ways that are difficult to catch with manual spot-checking alone.

### Handling breaking changes

If the update breaks something:

1. Check the CivicTheme release notes for migration instructions
2. Look for changes to component `.component.yml` schemas — new required props may need values
3. Check for renamed or removed SCSS variables or mixins
4. Review any changes to preprocess utility functions
5. If a component override in your sub-theme conflicts with a base theme change, update your override to match the new interface

## Recommended update schedule

| What                      | Frequency                | Why                                                  |
| ------------------------- | ------------------------ | ---------------------------------------------------- |
| Drupal security updates   | Within 1 week of release | Security advisories have public disclosure timelines |
| CivicTheme patch releases | Quarterly                | Bug fixes and minor improvements                     |
| CivicTheme minor releases | Annual                   | New features and component improvements              |
| Node.js package updates   | Quarterly                | Security patches for build tools                     |

## Next step

Package updates keep your site current. The next chapter covers the specific process for monitoring and applying security patches.

Continue to [Chapter 7: Security Updates](/playbook/govcms/07-security-updates).


# Security Updates

This chapter covers the ongoing responsibility of monitoring and applying security patches to your CivicTheme site. It explains how to subscribe to advisory channels, assess severity, and apply fixes on both GovCMS SaaS and standalone Drupal.

Security updates are time-sensitive. Public disclosure of vulnerabilities means attackers can act quickly, so your team needs a clear process for monitoring advisories and responding within appropriate timelines.

## Prerequisites

* [ ] A running CivicTheme site (GovCMS SaaS or standalone Drupal)
* [ ] Administrator access to the site
* [ ] Access to the deployment pipeline (GitLab for GovCMS, your CI/CD for Drupal)

## Step 1: Subscribe to security advisory channels

Set up monitoring so your team is notified when security updates are released. You need to watch three sources:

* **Drupal Security Advisories** — [subscribe to the mailing list](https://www.drupal.org/security). Core security releases follow a regular window (third Wednesday of the month), but critical releases can happen at any time.
* **CivicTheme releases** — watch the [CivicTheme project page](https://www.drupal.org/project/civictheme/releases) and the [GitHub monorepo](https://github.com/civictheme/monorepo-drupal/releases). The [#civictheme-designsystem](https://drupal.slack.com/archives/C039UV0CQBZ) Drupal Slack channel often has early announcements.
* **npm advisories** — run `npm audit` in your sub-theme directory to check for known vulnerabilities. Enable GitHub Dependabot alerts if your repository is on GitHub. Carry out developer dependency maintenance every quarter.

## Step 2: Assess severity and set response timelines

Drupal Security Advisories include a risk score (0-25) based on the [NIST Common Misuse Scoring System](https://www.drupal.org/drupal-security-team/security-risk-levels-defined). Higher scores require faster action. As a site manager you should have policies and procedures regarding the response timelines for security updates.

## Step 3: Apply security updates

Follow the same update process as [Chapter 6](/playbook/govcms/06-updating-packages): update the base theme (Composer for Drupal, manual download for GovCMS SaaS), rebuild front-end assets with `npm run dist`, run database updates, and clear caches. For CivicTheme-specific update procedures on GovCMS SaaS, see [Updating CivicTheme on GovCMS SaaS](https://github.com/civictheme/docs/blob/main/development/drupal-theme/updating-civitheme-govcms-sass.md).

For npm vulnerabilities in build dependencies:

```bash
npm audit
npm audit fix
```

## Step 4: Verify the update

* [ ] The site loads without errors
* [ ] Content pages render correctly (check multiple content types)
* [ ] Forms submit correctly
* [ ] User login and authentication work
* [ ] Admin pages are accessible
* [ ] No new errors in Drupal's Recent Log Messages (`/admin/reports/dblog`)
* [ ] Front-end assets load (no broken CSS or JS)
* [ ] Components render correctly in both light and dark themes
* [ ] Any overridden components in your sub-theme still work with the updated base
* [ ] Storybook builds without errors (`npm run build`)

## Step 5: Document the update

Record what was updated and when for your team's reference: version numbers (before and after), security advisory references (SA-CORE, SA-CONTRIB numbers), any manual steps required, and test results.

## CivicTheme's security framework

CivicTheme maintains a comprehensive security posture with continuous automated scanning and multiple validation layers. For the full security framework details, including how to report vulnerabilities responsibly, see [Security](/getting-started/security-policy).

## Reporting vulnerabilities

If you discover a security vulnerability in CivicTheme, do not open a public issue. Report it through the [Drupal CivicTheme Design System security page](https://www.drupal.org/project/issues/civictheme), following Drupal's responsible disclosure process.

## Summary

| Task                               | Frequency                | Owner                    |
| ---------------------------------- | ------------------------ | ------------------------ |
| Monitor Drupal security advisories | Ongoing (subscribe once) | Tech lead / site manager |
| Monitor CivicTheme releases        | Ongoing (subscribe once) | Tech lead                |
| Run `npm audit`                    | Monthly                  | Developer                |
| Apply critical security updates    | Within 24-48 hours       | Developer                |
| Apply routine security updates     | Within 1 week            | Developer                |
| Document applied updates           | After each update        | Developer / site manager |


# Drupal Community

This playbook is a step-by-step guide for teams building and maintaining a CivicTheme site on standalone Drupal. It is written for tech leads, project managers, and site managers — people who need to understand the process of setting up, customising, and keeping a CivicTheme site running.

CivicTheme is an open-source, government-grade design system built as a Drupal theme. It provides a library of accessible, reusable components following atomic design principles. On a standard Drupal site, CivicTheme installs via Composer like any other contributed theme, with full control over your deployment workflow.

## How to use this playbook

Work through the chapters in order. Each chapter builds on the previous one, following the natural lifecycle of a CivicTheme project: install, configure, customise, maintain.

The playbook provides the task-oriented workflow — the sequencing, decisions, and practical steps your team needs. Where detailed reference material already exists in the CivicTheme documentation, the playbook links to it rather than duplicating it. This keeps everything in one place and ensures the information stays current.

## Chapters

### Site Development

1. [**Installation**](/playbook/drupal/01-installation) — Install CivicTheme via Composer, enable required modules, generate your sub-theme, build assets, and provision content.
2. [**Setting Up Your Sub-Theme**](/playbook/govcms/02-sub-theme-setup) — Understand the sub-theme directory structure, configure the build system, run Storybook locally, and connect your sub-theme to Drupal.
3. [**Configuring Colors and Theme Settings**](/playbook/govcms/03-colors-and-settings) — Set up your brand colors, configure the header and footer, and understand how CivicTheme's color system derives a full palette from your brand values.
4. [**Overriding Existing Components**](/playbook/govcms/04-overriding-components) — Change how an existing CivicTheme component looks or behaves by copying it into your sub-theme and modifying it there.
5. [**Creating New Components**](/playbook/govcms/05-creating-components) — Build a new component from scratch following CivicTheme conventions, from atomic design placement through to Drupal integration.

### Site Maintenance

6. [**Updating Packages**](/playbook/govcms/06-updating-packages) — Keep your CivicTheme base theme, sub-theme dependencies, and Node.js packages up to date with a clear update and rebuild workflow.
7. [**Security Updates**](/playbook/govcms/07-security-updates) — Subscribe to security advisories, assess severity, and apply patches to your Drupal site.

## Who is this for?

| Role                | What you will get from this playbook                                                                                                         |
| ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tech lead**       | End-to-end process for setting up and customising a CivicTheme site, including component architecture and override patterns                  |
| **Project manager** | Understanding of the process of installing and managing a CivicTheme site, dependencies between steps, and what the team needs at each stage |
| **Site manager**    | Understanding of the maintenance process for keeping the site secure and up to date after the initial build                                  |

## Getting help

If you run into issues at any point, CivicTheme has active support channels including a Drupal Slack channel, issue queues, and email support. For all options, see [Getting help](/getting-started/getting-help).


# Installation

This chapter walks your team through installing CivicTheme on a standalone Drupal site. By the end, you will have CivicTheme installed via Composer, required modules enabled, a sub-theme generated, front-end assets built, and the site ready for customisation.

Unlike GovCMS SaaS, a standard Drupal site uses Composer to manage theme dependencies, which simplifies the installation process.

## Prerequisites

* [ ] A working Drupal 10.2+ or 11+ site with Composer-managed dependencies
* [ ] Composer installed and available on the command line
* [ ] Drush installed (recommended for command-line operations)
* [ ] NodeJS 22+ and NPM 10+ available on your machine
* [ ] Administrator access to the Drupal site

## Step 1: Install CivicTheme and enable modules

For instructions on installing CivicTheme via Composer, see the [Drupal theme installation reference](/installation/drupal-theme).

## Step 2: Generate your sub-theme

CivicTheme must not be modified directly — all custom work happens in a sub-theme. A script generates the full sub-theme scaffold:

```bash
cd web/themes/contrib/civictheme
php civictheme_create_subtheme.php <SUBTHEME_MACHINE_NAME> "<Subtheme Human Name>" "<A description>" ../custom/<SUBTHEME_MACHINE_NAME> --remove-examples
```

Then enable it:

```bash
drush theme:enable <SUBTHEME_MACHINE_NAME> -y
drush config-set -y system.theme default <SUBTHEME_MACHINE_NAME>
```

> **Naming tip**: Name your sub-theme after the site, not after CivicTheme. Avoid including "civic" or "civictheme" in the machine name — it creates confusion when maintaining the theme later.

The script options and the generated directory structure are documented in the [sub-theme reference](/development/drupal-theme/sub-theme).

## Step 3: Build front-end assets

```bash
cd web/themes/custom/<SUBTHEME_MACHINE_NAME>
nvm use
npm install
npm run build
```

Verify that the `dist` directory was created. Navigate to your site in the browser and confirm that default CivicTheme styling is applied.

### Commit built assets

The generated sub-theme ignores the compiled `dist/` directory by default. Unless your deployment pipeline runs `npm run build`, the deployed site needs the built assets committed to the repository — otherwise it loads with no CivicTheme styling.

1. Edit the `.gitignore` in your sub-theme and remove the `dist` line.
2. Add the build's temporary directories so they are not committed:

   ```
   .components-civictheme
   components_combined
   node_modules
   ```
3. Run `npm run build` and commit the contents of `dist/`.

For the full explanation and the build-during-deployment alternative, see [Committing built assets](/development/drupal-theme/sub-theme#committing-built-assets).

## Step 4: Provision content

CivicTheme includes pre-configured blocks, menus, and configuration entities that set up the default site structure.

Navigate to `/admin/appearance/settings/<SUBTHEME_MACHINE_NAME>` and press the **Provision content** button. Then export configuration with `drush cex -y`.

See the [Provision content section](/installation/drupal-theme) for more information.

## Step 5: Verify the installation

After provisioning, your site should match the [default CivicTheme site](https://default.civictheme.io/) (without homepage content). Check that:

* [ ] The header displays with the CivicTheme logo and navigation
* [ ] The footer displays with default blocks (social links, footer navigation, acknowledgement, copyright)
* [ ] The site responds correctly on mobile (navigation collapses to mobile menu)
* [ ] The admin theme is accessible at `/admin`

## Troubleshooting

For common installation issues (content not appearing, styling not applied, module dependency errors), see the troubleshooting section in the [Drupal theme installation reference](/installation/drupal-theme#troubleshooting).

## Where to get help

For all support options, see [Getting help](/getting-started/getting-help).

## Next step

With CivicTheme installed and your sub-theme generated, the next step is to understand the sub-theme structure and set up your local development workflow.

Continue to [Chapter 2: Setting Up Your Sub-Theme](/playbook/govcms/02-sub-theme-setup).


# Drupal theme

## Install CivicTheme

```
composer require drupal/civictheme
```

Alternatively, you can download the [latest version](https://www.drupal.org/project/civictheme/releases) from Drupal.org and place into the desired location.

{% hint style="info" %}
Note that Drupal core has a known [issue](https://www.drupal.org/node/3204271) and a [patch](https://www.drupal.org/files/issues/2023-07-16/3204271-20-missing-layout-exception.patch) would need to be installed on your site.
{% endhint %}

## Install Contrib modules

CivicTheme has required dependencies on [contrib modules](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme.info.yml#L11) and optional dependencies on\
search\_api.

These dependencies need to be downloaded and installed before you are able to install CivicTheme.

### GovCMS SaaS specific installation instructions

{% hint style="info" %}
See [Using in GovCMS SaaS](/installation/govcms-saas) for specific GovCMS SaaS instructions.
{% endhint %}

### Usage

CivicTheme can be used as a no-code Drupal theme with some of the configurations done on theme settings page.

### Enabling contrib modules

Due to Drupal [allowing themes to declare module dependencies](https://www.drupal.org/node/2937955), but [does not yet allow those modules to be enabled automatically](https://www.drupal.org/project/drupal/issues/3100374)).

The contrib module dependencies need to enabled manually or with an automated script:

#### Enable required modules only

```sh
drush ev "require_once dirname(\Drupal::getContainer()->get('theme_handler')->rebuildThemeData()['civictheme']->getPathname()) . '/theme-settings.provision.inc'; civictheme_enable_modules(FALSE);"
```

#### Enable required and optional modules

```sh
drush ev "require_once dirname(\Drupal::getContainer()->get('theme_handler')->rebuildThemeData()['civictheme']->getPathname()) . '/theme-settings.provision.inc'; civictheme_enable_modules();"
```

### Clear caches

```sh
drush cr
```

### Enable CivicTheme

Enable the theme in UI or with Drush:

<pre class="language-sh"><code class="lang-sh"><strong>drush then civictheme
</strong></code></pre>

### Provision content

CivicTheme comes with pre-set Block Content blocks configuration. Since Drupal does not support running install hooks in themes, a custom content provisioning script has to be used.

1. Login to the local instance of your site.
2. Navigate to `/admin/appearance/settings/<SUBTHEME_MACHINE_NAME>`\\

<figure><img src="/files/BrUUwKkyTdpjfOg8N1ng" alt=""><figcaption></figcaption></figure>

3. Press "Provision content" button.
4. Navigate to the homepage and observe that all blocks and menus are present.
5. Export config for created entities:

```sh
ahoy drush cex -y
```

Depending on your deployment workflow, you may need to repeat this step after deployment to your hosting provider environment.

{% hint style="info" %}
After deployment and provisioning your remote **feature environment** should look like a [default CivicTheme site](https://default.civictheme.io/) without homepage content.
{% endhint %}

## Troubleshooting

### Content not appearing after provisioning

* Clear caches: `drush cr`
* Check that your sub-theme (not the base CivicTheme theme) is set as the default
* Verify all required modules are enabled: check the module dependencies in the [theme info.yml](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme.info.yml#L11)

### Styling not applied

* Confirm the `dist` directory exists in your sub-theme
* Clear caches and hard-refresh the browser
* Check the browser console for 404 errors on CSS/JS files

### Module dependency errors

* Run `composer require` for any missing packages
* Ensure you enabled module dependencies before enabling the theme

### Setting up a sub-theme

See [Sub-theme](/development/drupal-theme/sub-theme) section to create a sub-theme and use CivicTheme as a base theme.


# GovCMS SaaS

CivicTheme can be installed on GovCMS SaaS using either an automated script or manual installation process.

## Installation methods

### [Automated installation (recommended)](/installation/govcms-saas/govcms-saas-manual)

The automated installation script is the preferred method for setting up CivicTheme on new GovCMS SaaS project. It handles most of the setup process automatically, including:

* Downloading and extracting CivicTheme
* Configuring required modules
* Creating your custom subtheme
* Optionally provisioning content blocks

[**Start with automated installation →**](/installation/govcms-saas/govcms-saas-automated)

### [Manual installation](/installation/govcms-saas/govcms-saas-manual)

For those who prefer more control over the installation process or cannot use the automated script, the manual installation guide provides step-by-step instructions for:

* Setting up your local environment
* Installing CivicTheme and dependencies
* Creating and configuring your subtheme
* Building and deploying assets

[**View manual installation guide →**](/installation/govcms-saas/govcms-saas-manual)

## Post-installation steps

### [Post Installation Cleanup](/installation/govcms-saas/govcms-post-installation-cleanup)

### [Content provisioning](/installation/govcms-saas/govcms-content-provisioning)

Instructions on how to provision CivicTheme's default content blocks and menus, whether you're using automated or manual installation.

## Before you begin

Regardless of which installation method you choose, ensure you have:

* [ ] Access to GitLab project
* [ ] Support ticket to enable config imports actioned
* [ ] Administrator role added to your user in production
* [ ] All [GovCMS SaaS required software](https://github.com/govCMS/GovCMS/wiki/1.1-Local-setup#dependencies) installed
* [ ] NPM 10+ and NodeJS 22+ available on your machine
* [ ] A GovCMS project already set up and installed locally

## Troubleshooting

### Content not appearing after provisioning

* Clear caches: `ahoy drush cr`
* Check that your sub-theme (not the base CivicTheme theme) is set as the default
* Verify all required modules are enabled

### Styling not applied

* Confirm the `dist` directory exists in your sub-theme
* Check that `.gitignore` is not excluding `dist`
* Clear caches and hard-refresh the browser

### Provisioning button not available

* Ensure you are logged in as an administrator
* Verify the theme is properly installed and enabled
* Clear caches and reload the theme settings page

## Where to get help

See [Getting help](/getting-started/getting-help) section for support options and resources.

## Next steps

After installation, it is recommended that you read the documents on how CivicTheme works and how to customise your sub-theme installation:

* [Customising your sub-theme](/development/drupal-theme)


# GovCMS automated installation

This is the preferred installation method for setting up CivicTheme on GovCMS SaaS. The automated script handles most of the setup process for you.

## Before you begin

* [ ] Get access to GitLab project
* [ ] Check that support ticket to enable config imports was actioned
* [ ] Check that production has your user added with administrator role
* [ ] Check that you have all [GovCMS SaaS required software](https://github.com/govCMS/GovCMS/wiki/1.1-Local-setup#dependencies) available on your machine
* [ ] Check that you have NPM 10+ and NodeJS 22+ available on your machine
* [ ] Read this whole page to make sure you understand the steps

## Prerequisites

* **GovCMS Project**: You must have a GovCMS project / scaffold already set up and installed locally (i.e., you have run `ahoy install`).
* **Ahoy**: ahoy must be installed and configured for your project (i.e., you can run ahoy commands).
* **Docker**: Docker must be running, as ahoy typically interacts with Docker containers.
* **tar and curl**: These command-line utilities must be available in your shell environment where you run the script.
* **Bash**: The script is written for Bash.

## What the script does

The script will perform the following actions:

* Download and extract the specified CivicTheme version into themes/custom/civictheme.
* Run initial CivicTheme provisioning commands.
* Clear Drupal caches.
* Enable CivicTheme and set it as the default theme temporarily.
* Download, install, configure, and then uninstall and remove the civictheme\_govcms module (as per the specified workflow).
* Generate a new subtheme based on CivicTheme using the provided names and description.
* Enable the new subtheme and set it as the site's default theme.
* Optionally provision content blocks (can be skipped with `-n` flag)

After the script completes successfully, your new subtheme will be active and ready for customisation in themes/custom/\<your\_subtheme\_machine\_name>.

## Download the script

From your GovCMS project root directory, run:

```bash
curl -o setup_civictheme.sh \
https://raw.githubusercontent.com/civictheme/civictheme_govcms/refs/heads/main/scripts/setup_civictheme.sh \
&& chmod +x setup_civictheme.sh
```

*Note*: Download the script to your GovCMS project root directory on your host machine (not inside a Docker container).

## Run the script

Execute the script from your GovCMS project's root directory. You'll need to provide values for all the required arguments.

### Command structure

```bash
./setup_civictheme.sh -c <civictheme_version> \
-g <govcms_module_ref> \
-m <subtheme_machine_name> \
-u "<subtheme_human_name>" \
-d "<subtheme_description>" \
[-p] \
[-n]
```

### Arguments

| Argument                      | Required | Description                                                                                                                           | Example                                                                                  |
| ----------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| `-c <civictheme_version>`     | Yes      | The version of the CivicTheme base theme to download                                                                                  | `"1.11.0"`                                                                               |
| `-g <govcms_module_ref>`      | Yes      | The Git reference (branch or tag) for the civictheme\_govcms module                                                                   | <p>Branch: <code>"main"</code><br>Tag: <code>"1.0.1"</code> or <code>"v1.0.1"</code></p> |
| `-m <subtheme_machine_name>`  | Yes      | The machine-readable name for your new subtheme. Use lowercase letters, numbers, and hyphens/underscores                              | `"my_custom_site_theme"`                                                                 |
| `-u "<subtheme_human_name>"`  | Yes      | The human-readable name for your new subtheme. Enclose in quotes if it contains spaces                                                | `"My Custom Site Theme"`                                                                 |
| `-d "<subtheme_description>"` | Yes      | A short description for your new subtheme. Enclose in quotes                                                                          | `"A custom theme for My Awesome GovCMS Project"`                                         |
| `-p`                          | No       | Apply Drupal cache backend patch (drupal.org issue). This patches LayoutPluginManager to add cache tags for better cache invalidation | -                                                                                        |
| `-n`                          | No       | Skip content provisioning. By default, content provisioning is enabled                                                                | -                                                                                        |

### Content provisioning option (`-n` flag)

The `-n` flag allows you to skip the automatic provisioning of content blocks during installation. This is particularly useful when you want to avoid performing a content forklift with GovCMS.

**When to use `-n`:**

* If you plan to manually provision blocks locally first, export the configuration, and then provision in production
* If you want to avoid doing a full content forklift migration
* If you prefer to have more control over when and how content blocks are created

**Workflow when using `-n`:**

1. Run the script with `-n` to skip content provisioning
2. Manually provision blocks through the theme settings locally
3. Export the block configuration using `drush cex`
4. Deploy the configuration to production
5. Provision the content in production through theme settings

For detailed instructions on content provisioning, see [Content provisioning for CivicTheme](/installation/govcms-saas/govcms-content-provisioning).

### Example commands:

**Standard installation (with content provisioning):**

```bash
./setup_civictheme.sh -c "{{ CIVICTHEME VERSION - see project page }}" \
                      -g "main" \
                      -m "my_gov_project_theme" \
                      -u "My Gov Project Theme" \
                      -d "Custom theme for the My Gov Project website on GovCMS."
```

**Installation without content provisioning:**

```bash
./setup_civictheme.sh -c "{{ CIVICTHEME VERSION - see project page }}" \
                      -g "main" \
                      -m "my_gov_project_theme" \
                      -u "My Gov Project Theme" \
                      -d "Custom theme for the My Gov Project website on GovCMS." \
                      -n
```

## Post-installation steps

1. **Build front-end assets**

   ```bash
   cd themes/<SUBTHEME_MACHINE_NAME>
   nvm use
   npm install
   npm run build
   ```
2. **Commit built assets**
   * Modify `.gitignore` file in your new theme and remove the following line:

     ```
     dist
     ```
   * Add the following to `.gitignore` in both sub-theme and CivicTheme:

     ```
     .components-civictheme
     components_combined
     node_modules
     ```
   * Commit the built assets to your repository
3. **Content Provisioning** (if skipped during installation):
   * See [Content provisioning for CivicTheme](/installation/govcms-saas/govcms-content-provisioning) for detailed instructions
4. **Post Installation cleanup**:
   * See [Post Installation Cleanup](/installation/govcms-saas/govcms-post-installation-cleanup) for only including required files in the repository (security and code hygiene)

## Deployment

1. Push your changes to the remote repository
2. Wait for deployment to complete
3. If you used the `-n` flag, provision content in production following the [Content provisioning guide](https://github.com/civictheme/docs/blob/main/installation/govcms-content-provisioning/README.md)

## Next steps

* [Customising CivicTheme / SubTheme development](/development/drupal-theme)
* [Manual installation guide](/installation/govcms-saas/govcms-saas-manual) (alternative method)
* [Content provisioning](/installation/govcms-saas/govcms-content-provisioning)


# GovCMS manual installation

This guide provides step-by-step instructions for manually installing CivicTheme on GovCMS SaaS. Use this method if you prefer not to use the automated installation script.

## Prerequisites

Before beginning the manual installation, ensure you have:

* [ ] Access to GitLab project
* [ ] Support ticket to enable config imports actioned
* [ ] Production has your user added with administrator role
* [ ] All [GovCMS SaaS required software](https://github.com/govCMS/GovCMS/wiki/1.1-Local-setup#dependencies) installed
* [ ] NPM 10+ and NodeJS 22+ available on your machine
* [ ] **GovCMS project set up locally with:**
* [ ] Local environment running (`ahoy up`)
* [ ] Database installed

{% hint style="info" %}
If you haven't set up your GovCMS local environment yet, refer to the [GovCMS documentation](https://github.com/govCMS/GovCMS/wiki/1.1-Local-setup) for instructions on setting up your local development environment.
{% endhint %}

## Where to get help

See [Getting help](/getting-started/getting-help) section

## 1. CivicTheme setup

{% hint style="info" %}
It is advised to perform all changes in a dedicated (feature) branch to test this part before applying any customisations.
{% endhint %}

### 1.1 Download CivicTheme theme

Since GovCMS SaaS does not allow to install themes via Composer, CivicTheme source must be installed as a custom theme.

1. [Download the latest CivicTheme release](https://www.drupal.org/project/civictheme/releases) and extract into `themes/custom` directory, rename the directory to `civictheme`.

### 1.2 Enable required modules

Using an automated script to discover required modules from theme dependencies (Drupal does not support this OOTB):

```sh
ahoy drush ev "require_once dirname(\Drupal::getContainer()->get('theme_handler')->rebuildThemeData()['civictheme']->getPathname()) . '/theme-settings.provision.inc'; civictheme_enable_modules();"
```

### 1.3 Clear caches

{% hint style="warning" %}
Do not skip this step
{% endhint %}

```sh
ahoy drush cr
```

### 1.4 Enable admin and CivicTheme

{% hint style="warning" %}
CivicTheme MUST be enabled before your custom theme is enabled
{% endhint %}

```bash
# Clear Drupal cache.
ahoy drush cr
# Enable CivicTheme and set as default.
ahoy drush theme:enable civictheme
ahoy drush config-set -y system.theme default civictheme
ahoy drush config-set -y media.settings standalone_url true

# Enable admin theme and set as default (optional).
ahoy drush theme:enable adminimal_theme
ahoy drush config-set -y system.theme admin adminimal_theme
```

### 1.5 Remove GovCMS content types

CivicTheme GovCMS helper module `civictheme_govcms` serves the purpose to remove unnecessary entities and configuration that ships with GovCMS.

Install it locally to automatically remove the configuration from DB to later have it exported without GovCMS entities.

1. Run in CLI container (`ahoy cli`):

   ```sh

   # If `web/modules/contrib` is not writable, you can use an alternative directory `web/themes/custom/civictheme` etc.
   mkdir -p /app/web/themes/custom/civictheme/modules
   cd /app/web/themes/custom/civictheme/modules

   # Download and extract the helper module.
   # Ensure to use the latest tag (not Release) https://github.com/civictheme/civictheme_govcms/tags
   wget https://github.com/civictheme/civictheme_govcms/archive/refs/tags/<latest-tag>.tar.gz && tar -xvf <latest-tag>.tar.gz && rm <latest-tag>.tar.gz && mv civictheme_govcms-<latest-tag> civictheme_govcms


   # Enable module, run the command to remove entities and uninstall a module.
   drush cr
   drush pm-enable -y civictheme_govcms
   drush civictheme_govcms:remove-config --preserve=user_roles
   drush pm-uninstall -y civictheme_govcms

   # Delete the module
   rm -Rf civictheme_govcms
   ```
2. Export updated configuration

   ```sh
   ahoy drush cex -y
   ```

### 1.6 Generate a sub-theme

{% hint style="info" %}
Consider naming your theme as close as possible to the name of the site. Do not include `civic` or `civictheme` into name to avoid confusions in code when maintaining a theme in the future.
{% endhint %}

Run in CLI container (`ahoy cli`):

```sh
# Generate sub-theme (example overrides are removed using --remove-examples flag). 
# See php civictheme_create_subtheme.php --help
cd web/themes/custom/civictheme
php civictheme_create_subtheme.php <SUBTHEME_MACHINE_NAME> "<SUBTHEME HUMAN NAME>" "<SUBTHEME HUMAN DESCRIPTION>" ../<SUBTHEME_MACHINE_NAME> --remove-examples
```

This should result in 2 directories:

```
themes/civictheme
themes/<SUBTHEME_MACHINE_NAME>
```

### 1.7 Install sub-theme and set as default

```sh
# Enable sub-theme.
ahoy drush theme:enable <SUBTHEME_MACHINE_NAME> -y
# Set sub-theme as default.
ahoy drush config-set system.theme default <SUBTHEME_MACHINE_NAME> -y
```

### 1.8 Build front-end assets

1. Run on your host:

   ```sh
   cd themes/<SUBTHEME_MACHINE_NAME>
   nvm use
   npm install
   npm run build
   ```
2. Check that directory `themes/<SUBTHEME_MACHINE_NAME>/dist` was created.
3. Navigate to your site and assert that default styling was applied.

### 1.9 Commit built assets

1. Modify `.gitignore` file in your new theme and remove the following line:

   ```
   dist
   ```
2. Commit built assets.

### 1.10 Provision content

See [Content Provisioning for CivicTheme](/installation/govcms-saas/govcms-content-provisioning) for detailed instructions on provisioning content blocks and menus.

{% hint style="success" %}
After deployment and provisioning your remote **feature environment** should look like a [default CivicTheme site](https://default.civictheme.io/) without homepage content.
{% endhint %}

## 2. Deployment

### 2.1 Deploy to (pre-)production

1. Merge feature branch to `master` (or `develop` and then to `master`).
2. Commit and push to remote.
3. Wait for deployment to finish and login to the Drupal instance.
4. Navigate to `/admin/appearance/settings/<SUBTHEME_MACHINE_NAME>`.
5. Press "Provision content" button.
6. Navigate to the homepage and observe that all blocks and menus are present.

{% hint style="success" %}
After deployment and provisioning your remote **(pre-)production** environment should look like a [default CivicTheme](https://default.civictheme.io/)[ site](https://default.civictheme.io/) without homepage content
{% endhint %}

### 2.2 Cleanup

{% hint style="warning" %}
Only run this step once everything is working and looking as expected.
{% endhint %}

1. ```sh
   # Remove unnecessary files.
   rm themes/civictheme/civictheme_create_subtheme.php
   rm -Rf themes/civictheme/civictheme_starter_kit
   ```
2. Commit and push to remote.

## 3. Customising CivicTheme

1. Replace sub-theme logos in repository `themes/<SUBTHEME_MACHINE_NAME>/assets/logos` with site-specific versions.
2. [Update the colour palette](/content-authoring/site-wide-configuration/colours) with your sub-theme.
3. Update sub-theme `screenshot.png` with something more appropriate (optional).
4. `npm run build` and commit changes.

## Resolving issues with roles

1. Enable `Role Delegation` module and allow `Site Administrator` to delegate both GovCMS and CivicTheme roles. Ensure that CivicTheme roles have the same permissions with their GovCMS counterparts.
2. Login to the site and re-assign existing users from GovCMS roles to relevant CivicTheme roles.
3. Remove GovCMS admin roles and re-export configuration.


# GovCMS content provisioning

CivicTheme comes with pre-set Block Content blocks configuration. Since Drupal does not support running install hooks in themes, a custom content provisioning script has to be used.

## When to provision content

Content provisioning is needed in two scenarios:

1. **During initial setup** - When first installing CivicTheme
2. **After deployment** - When deploying to production environments

## Provisioning workflow

The provisioning needs to be run twice:

1. **Locally** - to capture created configuration for config entities (blocks, menus etc.)
2. **In production** - to populate the configuration with the default content

## Step-by-step instructions

### 1. Local provisioning

1. Login to the local instance of your site.
2. Navigate to `/admin/appearance/settings/<SUBTHEME_MACHINE_NAME>`

   <figure><img src="/files/BrUUwKkyTdpjfOg8N1ng" alt=""><figcaption></figcaption></figure>
3. Press "Provision content" button.
4. Navigate to the homepage and observe that all blocks and menus are present.
5. Export config for created entities:

   ```sh
   ahoy drush cex -y
   ```
6. Commit and push to remote.

### 2. Production provisioning

1. Wait for deployment to finish and login to the Drupal instance.
2. Navigate to `/admin/appearance/settings/<SUBTHEME_MACHINE_NAME>`.
3. Press "Provision content" button.
4. Navigate to the homepage and observe that all blocks and menus are present.

## What gets provisioned

The content provisioning creates:

* **Block Content blocks** - Pre-configured content blocks for common page elements
* **Menu items** - Default menu structure
* **Configuration entities** - Required configuration for the theme to function properly

## Avoiding content forklift

If you want to avoid doing a full content migration (forklift) from local to production:

1. Use the `-n` flag when running the automated installation script
2. Provision content locally first
3. Export the configuration
4. Deploy configuration to production
5. Provision content in production

## Troubleshooting

### Content not appearing after provisioning

* Ensure caches are cleared: `ahoy drush cr`
* Check that the correct theme is set as default
* Verify that all required modules are enabled

### Provisioning button not available

* Ensure you're logged in as an administrator
* Check that the theme is properly installed and enabled
* Clear caches and try again

### Configuration export issues

* Make sure you have the correct permissions to export configuration
* Ensure that config imports are enabled (check with your GovCMS support ticket)

## Related documentation

* [Automated Installation](/installation/govcms-saas/govcms-saas-automated)
* [Manual Installation](/installation/govcms-saas/govcms-saas-manual)
* [Theme Settings](/content-authoring/site-wide-configuration)


# GovCMS post installation cleanup

1. **Build front-end assets**

   ```bash
   cd themes/<SUBTHEME_MACHINE_NAME>
   nvm use
   npm install
   npm run build
   ```
2. **Commit built assets**
   * Modify `.gitignore` file in your new theme and remove the following line:

     ```
     dist
     ```
   * Add the following to `.gitignore` in both sub-theme and CivicTheme:

     ```
     .components-civictheme
     .storybook-static
     components_combined
     node_modules
     ```
   * Commit the built assets to your repository
3. **Content Provisioning** (if skipped during installation):
   * See [Content provisioning for CivicTheme](/installation/govcms-saas/govcms-content-provisioning) for detailed instructions
4. Delete the following from CivicTheme:
   * `civictheme_create_subtheme.php`
   * `civictheme_starter_kit` directory


# UI kit

This section is under development


# Components

CivicTheme UI kit contains a large number of variables that modify all areas of the theme.

Variables allow for modification of:

* Theme and component specific colors
* Typography including `line-height`, `font-size`, `font-weight` and which fonts are used
* Spacing
* Grid system

Variables set within the CivicTheme UI kit have a corresponding variable with the `!default` flag that indicates conditional assignment to a variable — it assigns a value only if the variable was previously undefined or `null`. This allows consumer themes to override any variable's value without needing to change CivicTheme UI kit SASS.

Copy and paste variables as needed into your child theme, modify their values, and remove the `!default` flag. If a variable has already been assigned in your child theme, then it won’t be re-assigned by the default values in CivicTheme UI Kit.

#### Maps

Some of the variables, such as a list of breakpoints or list of colours, are implemented as SASS maps: this allows you to override and/or extend the value list. It also provides a safe mechanism to prevent breakages in case tomorrow CivicTheme introduces a change to a list of values, the solution in hand will support that.

### Where are the variables located

Variables are split into 2 files:

* `_variables.base.scss` - base variables that are used to calculate other variables' values.
* `_variables.components.scss` - variables that control the look of components.

These are split into 2 files to allow changing base variables without the need to provide component variables in custom themes (e.g., to override primary colour in child theme and have it propagate to components).


# Spacing

### Particle

Particle is the most basic unit of measurement, using pixels to tie to the design grid which is in pixels as well.

Depending on the context, most of the values will be using conversion to rem with the `rem()` function.

`ct-particle()` function can be used to base element measurements off the particle.

For spacing, use `ct-spacing()` function instead.

### Spacing

Spacing (such as margin or padding) can be applied using the `ct-spacing()` function.

Spacing size is defined in `$ct-spacing` variable and defaults to `ct-particle()`

```scss
div {
  padding: ct-spacing(1) ct-spacing(2);
  margin-bottom: ct-spacing(2);
}
```


# Grid

CivicTheme provides a customisable [grid](https://www.civictheme.io/themes/custom/civicthemeio/storybook-static/index.html?path=/story/base-grid--grid) utilising a flex-based system.

UI kit grid system uses a series of containers, rows, and columns to layout and align content.

It’s built with flexbox and is fully responsive.

The system is adapted from the [SASS flexbox grid](http://sassflexboxgrid.com/).

#### Example grid system markup

```html

<div class="container">
    <div class="row">
        <div class="col-xs-12 col-l-6">100% extra-small viewport / 50% large viewport</div>
    </div>
    <div class="row">
        <div class="col-xs-6 col-m-4 col-l-3">50% extra-small viewport / 33% medium viewport / 25% large viewport</div>
        <div class="col-xs-6 col-m-4 col-l-3">50% extra-small viewport / 33% medium viewport / 25% large viewport</div>
        <div class="col-xs-6 col-m-4 col-l-3">50% extra-small viewport / 33% medium viewport / 25% large viewport</div>
        <div class="col-xs-6 col-m-4 col-l-3">50% extra-small viewport / 33% medium viewport / 25% large viewport</div>
        <div class="col-xs-6 col-m-4 col-l-3">50% extra-small viewport / 33% medium viewport / 25% large viewport</div>
    </div>
    <div class="row">
        <div class="col-xxs-12 ">100% at all viewports</div>
    </div>
    <div class="row">
        <div class="col-l-6">
            <div class="container">
                <div class="row">
                    <div class="col-l-12">Nested column is set within 50% width parent and so is 50% parent container width</div>
                </div>
            </div>
        </div>
    </div>
</div>


```

### Breakpoints

Breakpoints are defined as:

```scss
$ct-breakpoints: (
  'xxs': 0,
  'xs': 368px,
  's': 576px,
  'm': 768px,
  'l': 992px,
  'xl': 1280px,
  'xxl': 1440px,
);
```

And can be used with the `ct-breakpoint()` mixin.

```scss
div {
  // Shared rules.
  @include ct-breakpoint(s) {
    // Mobile-and-up Small rules.
  }
  @include ct-breakpoint(m) {
    // Mobile-and-up Medium rules.
  }
  @include ct-breakpoint(xl) {
    // Mobile-and-up Extra large rules.
  }
}
```

Breakpoints should be applied from smallest to largest, with all shared rules defined before the breakpoints.

All breakpoints use `min-width` only. Options for `min and max`, or `max` width have been omitted to avoid over-complicating breakpoint logic and readability.

### Containers and rows

Containers are used to contain and centre content to a `max-width` per breakpoint. These are set via the `$ct-breakpoints` map.

If no container is set then columns spread full-width - this is utilised in CivicTheme Page without sidebar where we have full-width components and constraining of content is done on the component level.

Rows are wrappers for columns. Each column has horizontal padding (called a gutter) for controlling the space between them. This padding is then counteracted on the rows with negative margins to ensure the content in your columns is visually aligned down the left side.

### Columns

There are 12 columns available per row, allowing you to create different combinations of elements that span any number of columns.

Column classes indicate the number of template columns to span (e.g., `col-4` spans four). Widths are set in percentages so you always have the same relative sizing.

### Nested grids

The grid system allows for nested grids. If a parent is 50% width (`col-xs-12`) and a container, row and column is placed inside of this column then the max-width of the child column (with `col-xs-12` class) is 50% of the parent.

### Utilities

CivicTheme UI Kit comes with a variety of grid utility mixins including `offset`, `row-reverse`, `flex-column` among others.

### Advanced

For more advanced modification and overriding, the grid system internals are defined within `_variables.base.scss`. This provides plenty of options to change the grid system, however, this is not recommended as it can result in significant changes to the design system which may not be apparent at first.


# Typography

CivicTheme UI kit provides a system for easily consuming and extending typography mixins and variables.

### Fonts

The default font-families are defined in a map `$ct-fonts-default`:

```scss
$ct-fonts-default: (
  'primary': (
    'family': '"Lexend", sans-serif',
    'types': (
      (
        'uri': 'https://fonts.googleapis.com/css2?family=Lexend:wght@400;500;600;700&display=swap',
      ),
    ),
  ),
  // ...
);
```

This map can be extended using `$ct-fonts` map (fonts can be stored with the library or linked to a remote location):

```scss
$ct-fonts: (
  'tertiary': (
    'family': 'Roboto, sans-serif',
    'types': (
      (
        'uri': (
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Regular.ttf',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Regular.woff',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Regular.eot',
        ),
      ),
      (
        'italic': true,
        'uri': (
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Italic.ttf',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Italic.woff',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Italic.eot',
        ),
      ),
      (
        'weight': 'bold',
        'uri': (
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Bold.ttf',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Bold.woff',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Bold.eot',
        ),
      ),
      (
        'italic': true,
        'weight': 'bold',
        'uri': (
          '#{$ct-assets-directory}fonts/Roboto/Roboto-BoldItalic.ttf',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-BoldItalic.woff',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-BoldItalic.eot',
        ),
      ),
      (
        'weight': 300,
        'uri': (
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Thin.ttf',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Thin.woff',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Thin.eot',
        ),
      ),
      (
        'weight': 700,
        'uri': (
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Black.ttf',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Black.woff',
          '#{$ct-assets-directory}fonts/Roboto/Roboto-Black.eot',
        ),
      ),
    ),
  ),
  // ...
);
```

#### Defining typography

The default typography is set in a map `$ct-typography-default`:

```scss
$ct-typography-default: (
  // Headings.
  'heading-1': (
    'xxs': ($ct-font-base-size * 2, $ct-font-base-line-height * 2.5, 700, 'primary', -0.6px),
    'm': ($ct-font-base-size * 3, $ct-font-base-line-height * 3.75, 700, 'primary', -1px)
  ),
  // ...
);
```

This can be extended using `$ct-typography` map:

```scss
$ct-typography: (
  'body-extra-large': (
    'xxs': ($ct-font-base-size * 2, $ct-font-base-line-height * 2.5, 700, 'primary', -0.6px),
    'm': ($ct-font-base-size * 3, $ct-font-base-line-height * 3.75, 700, 'primary', -1px)
  ),
);
```

### Using typography

Typography can be set for elements using the `ct-typography()` mixin with a pre-defined mapping:

```scss
h1 {
  @include ct-typography('heading-l');
}
```


# Overriding components

This reference covers the process for overriding an existing CivicTheme component in your sub-theme — from deciding whether to override, through the copy-and-register process, to style-only alternatives.

## When to Override vs. Create New

| Situation                                                              | Approach                                                                                     |
| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Change the look of an existing component (colors, spacing, layout)     | **Override** — modify the existing component in your sub-theme                               |
| Change the behavior of an existing component (JavaScript interactions) | **Override** — modify the component's `.js` file                                             |
| Add a variant to an existing component (a new button style)            | **Override** — extend the component's template and SCSS                                      |
| Build something that does not map to any existing component            | **Create new** — see [Creating components](/development/uikit/variables/creating-components) |
| Combine existing components in a new way                               | **Create new** — compose a molecule or organism from existing atoms                          |

## Identifying the Component

Components are organised by atomic design level in the base CivicTheme theme:

```
civictheme/components/
├── 00-base/        # Foundation (variables, mixins, grid)
├── 01-atoms/       # Button, Tag, Heading, Link, etc.
├── 02-molecules/   # Cards, Accordion, Breadcrumb, etc.
├── 03-organisms/   # Header, Footer, Banner, Navigation, etc.
└── 04-templates/   # Page layouts
```

Use Storybook to browse components visually, or search the base theme's `components/` directory for the component name.

## Copy and Register

Copy the entire component directory from the base theme into the matching location in your sub-theme:

```bash
# Example: overriding the button component
cp -r path/to/civictheme/components/01-atoms/button \
      your_theme/components/01-atoms/button
```

Keep the same directory name and location within the atomic hierarchy. The build system matches components by directory name when merging.

In your copied `component.component.yml`, add a `replaces` key to declare the override:

```yaml
replaces: 'civictheme:button'
```

Both components must have compatible schemas — the props and slots in your override must match the original. You can add new props, but existing ones must remain compatible.

## Modifying the Component

Modify only the files you need to change — but for clarity and maintainability, it is recommended to copy the entire component directory.

CivicTheme components follow strict conventions for SCSS (BEM naming, design tokens, theme mixins), Twig (prop validation, class construction, nested includes with `only`), and JavaScript (constructor pattern, data-attribute selection, no jQuery). The complete file conventions and code patterns are documented in the [components system reference](/development/drupal-theme/systems/components).

## Style-Only Overrides (Simpler Alternative)

If you only need to change a component's visual appearance without modifying its template or JavaScript, you can override just the SCSS variables instead of copying the entire component.

Edit `components/variables.components.scss` in your sub-theme:

```scss
// Override button colors without copying the component
$ct-button-light-primary-background-color: #custom-color;
$ct-button-light-primary-hover-background-color: #custom-hover;
```

This is the lightest-touch approach and avoids maintaining a full copy of the component. Use it when variable overrides are sufficient. The variable override mechanism and naming conventions are documented in the [variables reference](/development/uikit/variables).

## Rebuild and Verify

After making changes:

```bash
npm run dist
npm run storybook
```

Check all variants of the component (light/dark theme, different sizes, states) in Storybook. Then clear Drupal caches (`drush cr`) and verify on the live site.

## Common Pitfalls

For common issues (forgetting to rebuild, namespace conflicts, breaking the prop schema, preprocess hook dependencies), see the [common pitfalls](/development/drupal-theme/systems/components#common-pitfalls) section of the components system reference.


# Creating components

This reference covers the process of creating a new component that follows CivicTheme conventions: atomic design placement, required files, variable registration, and the component checklist.

## Atomic Design Levels

Determine where your component fits in the hierarchy:

| Level                          | What it contains                                       | Examples                            |
| ------------------------------ | ------------------------------------------------------ | ----------------------------------- |
| **Atom** (`01-atoms/`)         | A single UI element that cannot be broken down further | Button, Tag, Heading, Input         |
| **Molecule** (`02-molecules/`) | A combination of atoms forming a functional group      | Card, Accordion, Breadcrumb, Search |
| **Organism** (`03-organisms/`) | A complex section composed of molecules and atoms      | Header, Footer, Banner, Navigation  |

**Rules of thumb:**

* If it contains only HTML elements and no other CivicTheme components, it is an atom
* If it includes other CivicTheme atoms or molecules via `{% include %}`, it is a molecule or organism
* If it represents a major page section, it is an organism

## Single Directory Components (SDC)

CivicTheme uses Drupal's Single Directory Component (SDC) architecture. Each component lives in its own directory containing all related files. The `.component.yml` file registers the component with Drupal and defines its props schema using JSON Schema. Drupal validates props against this schema at render time, so incorrect prop types or missing required values will raise errors.

Components are referenced by namespace and machine name (e.g., `civictheme:feature-card`). In your sub-theme, new components are automatically registered under your sub-theme's namespace. To override a base theme component, add `replaces: civictheme:component_name` to your `.component.yml`.

## Required Files

Create a directory for your component in the appropriate atomic level (e.g., `your_theme/components/02-molecules/feature-card`). Each component needs these files:

| File                         | Purpose                                                                                                                             |
| ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `feature-card.component.yml` | SDC metadata: name, status, description, props schema (JSON Schema with Drupal's metadata schema), and slots for rich content areas |
| `feature-card.twig`          | HTML template with prop validation, BEM class construction, and nested includes                                                     |
| `feature-card.scss`          | Styles using BEM naming, design tokens, and the `ct-component-theme` mixin                                                          |
| `feature-card.stories.js`    | Storybook story with interactive controls for all props                                                                             |
| `feature-card.js`            | JavaScript using constructor pattern (only if the component has interactive behavior)                                               |

The `.component.yml` file is the starting point — it defines the component's interface. Props use JSON Schema types (`string`, `boolean`, `object`, `array`) with optional `enum` constraints and `default` values. Slots are used for content areas that accept rendered markup rather than simple values.

The conventions for each file type — Twig prop validation, SCSS theme mixins, JavaScript constructor patterns, Storybook controls, and the full `.component.yml` schema — are documented in the [components system reference](/development/drupal-theme/systems/components).

## Registering Component Variables

If your component needs theme-specific color variables, define them in `components/variables.components.scss` using the naming convention `$ct-[component]-[theme]-[property]` with `!default` flags:

```scss
$ct-feature-card-light-background-color: ct-color-light('background-light') !default;
$ct-feature-card-light-title-color: ct-color-light('heading') !default;
$ct-feature-card-dark-background-color: ct-color-dark('background-light') !default;
$ct-feature-card-dark-title-color: ct-color-dark('heading') !default;
```

For details on the variable system, see [Variables](/development/uikit/variables).

## Drupal Integration

To use your component in Drupal's content authoring workflow, you need three pieces:

1. **A paragraph type** — with fields matching your component's props, using CivicTheme's field naming conventions (`field_c_p_` for CivicTheme paragraph fields, `field_p_` for custom paragraph fields)
2. **A preprocess include** — in `includes/` that extracts Drupal field values and maps them to component props using utility functions like `civictheme_get_field_value()`
3. **A Drupal template** — a thin Twig template in `templates/paragraph/` that includes your component

The implementation pattern and field naming conventions are documented in the [mapping system reference](/development/drupal-theme/systems/mapping). Template conventions are in the [templates reference](/development/drupal-theme/templates).

## Component Checklist

Before considering your component complete, verify:

* [ ] Component displays correctly in Storybook across all prop combinations
* [ ] Light and dark themes both render correctly
* [ ] Responsive behavior works at all breakpoints (xxs through xl)
* [ ] SCSS uses design tokens (`ct-spacing()`, `ct-typography()`, `ct-breakpoint()`) — no hardcoded values
* [ ] BEM naming follows the `ct-<component>__<element>--<modifier>` convention
* [ ] JavaScript (if any) prevents double initialization and uses vanilla JS
* [ ] Drupal integration maps all fields correctly via preprocess hooks
* [ ] `npm run lint` passes without errors


# Drupal theme

Documentation for developing and customising CivicTheme for Drupal

This section contains comprehensive documentation for developing and customising CivicTheme for Drupal.

## Installation

For installation instructions, see [Drupal theme installation](/installation/drupal-theme).

## Core Development

* [assets](/development/drupal-theme/assets) - Asset management (CSS, JS, fonts, images)
* [templates](/development/drupal-theme/templates) - Using CivicTheme UI Kit components in Drupal
* [namespaces](/development/drupal-theme/namespaces) - Component namespace system and organisation
* [sub-theme](/development/drupal-theme/sub-theme) - Creating and customising sub-themes

## Systems Architecture

The systems section contains CivicTheme's unique architectural approaches:

* [systems](/development/drupal-theme/systems) - Overview of all systems and learning path
* [systems/build](/development/drupal-theme/systems/build) - Custom build system and development workflows
* [systems/components](/development/drupal-theme/systems/components) - Component-centric architecture and template separation
* [systems/colors](/development/drupal-theme/systems/colors) - Color override system and design token customisation
* [systems/mapping](/development/drupal-theme/systems/mapping) - How Drupal entities map to component templates

## Theme Customisation

* [color-selector](/development/drupal-theme/color-selector) - Color customisation tools and options
* [layout-builder](/development/drupal-theme/layout-builder) - Working with Drupal's Layout Builder
* [automated-list](/development/drupal-theme/automated-list) - Automated list component implementation

## Platform-Specific Guides

* [using-in-govcms-saas](/installation/govcms-saas) - GovCMS SaaS implementation guide
* [updating-civitheme-govcms-sass](https://github.com/civictheme/docs/blob/main/development/drupal-theme/updating-civitheme-govcms-sass.md) - SASS update procedures for GovCMS

## Key Concepts

CivicTheme emphasises these core principles:

1. **Component-centric development** - Organised folder structure for maintainable code
2. **Template separation** - Component Twig templates separated from Drupal HTML files
3. **Preprocess functions** - Custom data population for component templates
4. **Build system** - Custom asset compilation workflows
5. **Color system** - Flexible theming capabilities

## Learning Path

To effectively work with CivicTheme:

1. Start with [templates](/development/drupal-theme/templates) to understand component separation
2. Review [systems/build](/development/drupal-theme/systems/build) for development workflow
3. Study [systems/components](/development/drupal-theme/systems/components) for data flow patterns
4. Explore [systems/colors](/development/drupal-theme/systems/colors) and [assets](/development/drupal-theme/assets) for theming

This documentation provides everything needed to build maintainable, component-centric Drupal sites using CivicTheme's ecosystem.


# Sub-theme

CivicTheme must never be modified directly. Your sub-theme inherits everything from CivicTheme and is where all custom work happens — overriding components, adding new ones, and adjusting styles. The build system merges your sub-theme's components with the base theme's components at compile time, so your overrides take priority automatically.

## Prerequisites

* CivicTheme installed and sub-theme generated (see [GovCMS SaaS installation](/installation/govcms-saas) or [Drupal installation](/installation/drupal-theme))
* NodeJS 22+ and NPM 10+ available
* Front-end assets built successfully (`npm run build`)

## Creating a sub-theme

CivicTheme provides a starter theme and a script to generate a child theme.

Run the following command from within the `civictheme` theme directory:

```shell
php civictheme_create_subtheme.php <theme_machine_name> "Human theme name" "Human theme description" /path/to/theme_machine_name
```

This generates a sub-theme in `path/to/theme_machine_name` with everything ready to be installed and compiled.

### Enabling the sub-theme

Enable the theme in UI or with Drush:

```sh
drush theme:enable theme_machine_name
```

### Compiling assets

Run the following command from within your sub-theme directory:

```sh
npm run build
```

{% hint style="info" %}
NodeJS version >=22 is required to compile front-end assets.
{% endhint %}

## Committing built assets

The compiled output lives in `dist/`, and the generated sub-theme's `.gitignore` ignores that directory by default. A deployed site still needs those compiled assets, so every project has to make `dist/` available in the deployed environment one of two ways:

* **Commit the built assets** — remove `dist` from your sub-theme's `.gitignore`, run `npm run build`, and commit the result. Choose this when your hosting does not run the front-end build during deployment.
* **Build during deployment** — keep `dist` ignored and run `npm run build` as part of your CI/CD pipeline so the assets are compiled on each deploy.

If you forget to do either, the deployed site loads with no CivicTheme styling because the `dist/` files are missing.

When committing built assets, edit the sub-theme's `.gitignore`:

1. Remove the `dist` line.
2. Add the build's temporary directories so they are not committed:

   ```
   .components-civictheme
   components_combined
   node_modules
   ```
3. Run `npm run build` and commit the contents of `dist/`.

{% hint style="info" %}
GovCMS SaaS does not build front-end assets on deploy, so committing built assets is **required** there. See [Commit built assets](/installation/govcms-saas/govcms-saas-manual#commit-built-assets).
{% endhint %}

## Directory structure

The sub-theme creation script generates the following project scaffold:

```
<your_theme>/
├── .storybook/              # Storybook configuration
├── assets/                  # Static assets
│   ├── backgrounds/         # Background images
│   ├── fonts/               # Custom fonts
│   ├── icons/               # SVG icons
│   ├── logos/               # Theme logos
│   └── sass/                # Drupal-specific SCSS
│       ├── theme.scss       # Theme-level styles
│       └── theme.editor.scss # CKEditor5 styles
├── components/              # Component overrides and new components
│   ├── 00-base/             # Base layer (variables, mixins)
│   ├── 01-atoms/            # Atomic components
│   ├── 02-molecules/        # Molecule components
│   ├── 03-organisms/        # Organism components
│   ├── 04-templates/        # Page templates
│   ├── variables.base.scss       # Your base variable overrides
│   └── variables.components.scss # Your component variable overrides
├── dist/                    # Compiled output (generated)
├── templates/               # Drupal Twig template overrides
├── build.js                 # Build system script
├── vite.config.js           # Vite/Storybook configuration
├── package.json             # NPM dependencies and scripts
├── <theme_name>.info.yml    # Drupal theme declaration
└── <theme_name>.libraries.yml # Drupal asset libraries
```

### Key directories

* **`components/`** — where you override existing CivicTheme components or add new ones. The atomic design hierarchy (00-base through 04-templates) mirrors CivicTheme's own structure.
* **`assets/`** — where you place your site's logos, icons, fonts, and background images.
* **`templates/`** — where you add Drupal-specific Twig template overrides that map Drupal data to components.
* **`components/variables.base.scss`** and **`components/variables.components.scss`** — where you override CivicTheme's design tokens (colors, spacing, typography) without touching the base theme.

## Library system

Your sub-theme declares its compiled assets as Drupal libraries in `<theme_name>.libraries.yml`. The key library is `global`, which loads your compiled CSS and JavaScript on every page.

The sub-theme's `info.yml` file uses `libraries-override` to replace CivicTheme's compiled assets with your sub-theme's compiled assets. This is how the build system's merged output takes over from the base theme:

```yaml
libraries-override:
  civictheme/global:
    css:
      theme:
        dist/civictheme.base.css: dist/styles.base.css
        dist/civictheme.theme.css: dist/styles.theme.css
        dist/civictheme.variables.css: dist/styles.variables.css
    js:
      dist/civictheme.drupal.base.js: dist/scripts.drupal.base.js
```

You should not need to modify these library definitions unless you are adding entirely new Drupal libraries (separate from the component system).

## Placeholder assets

The starter kit ships with placeholder logos, backgrounds, and a screenshot. Replace these with your site's actual assets:

1. **Logos** — replace files in `assets/logos/`. CivicTheme supports multiple logo variants for header and footer, light and dark themes, and desktop and mobile sizes.
2. **Backgrounds** — replace files in `assets/backgrounds/`.
3. **Favicon** — update via the Drupal theme settings page.
4. **Screenshot** — replace `screenshot.png` (shown in Drupal's Appearance page).

After replacing assets, rebuild:

```bash
npm run dist
```

## Troubleshooting

### Build fails with rsync errors

The build system uses rsync to merge component directories. Ensure rsync is installed and available on your system. On macOS it is included by default; on Windows, use WSL or install rsync separately.

### Storybook shows blank page or missing components

* Check the browser console for errors
* Ensure `npm run dist` completed successfully before starting Storybook
* Verify that `dist/constants.json` exists (Storybook reads icon and asset lists from it)

### Changes not appearing in Drupal

* Clear Drupal caches: `drush cr`
* Confirm you ran `npm run dist` after making changes
* Check that your sub-theme (not the base CivicTheme) is set as the default theme

### Node version mismatch

The sub-theme includes an `.nvmrc` file specifying the required Node version. Use `nvm use` to switch to the correct version before running any npm commands.


# Color selector

### Managing colors

Website colors can be specified via:

* **Color Selector** — the admin UI for setting brand and palette colors without code
* [**CSS code**](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme_starter_kit/components/variables.base.scss#L42) — SCSS variable overrides in `variables.base.scss`
* **CSS code with Color Selector overrides** — a combination of both

For the full color system architecture, formula syntax, and derivation map, see [Colors system](/development/drupal-theme/systems/colors).

### Using the Color Selector UI

1. Navigate to the theme settings page: `/admin/appearance/settings/<your_theme_machine_name>`
2. Ensure **Use Color Selector** is enabled
3. Enable **Use Brand Colors** — this lets you set 3 brand colors and have the rest derived automatically
4. Set your brand colors for both **Light** and **Dark** themes:

| Color       | Purpose                                                             | Example                    |
| ----------- | ------------------------------------------------------------------- | -------------------------- |
| **Brand 1** | Primary color — used for headings, interaction backgrounds, links   | Your primary brand color   |
| **Brand 2** | Background color — used for page backgrounds, borders, input fields | A neutral or light color   |
| **Brand 3** | Accent/highlight color                                              | A contrasting accent color |

5. Save the configuration

#### How color derivation works

From your 3 brand colors, CivicTheme derives the full palette using formula-based transformations:

* **Headings** — derived from Brand 1 with a shade (darkening) operation
* **Body text** — derived from Brand 1, shaded then tinted
* **Backgrounds** — derived from Brand 2 with tint (lightening) and shade operations for light, medium, and dark variants
* **Borders** — derived from Brand 2 with varying shade levels
* **Interaction colors** — derived from Brand 1 (backgrounds) and Brand 2 (text) for hover, focus, and active states
* **Highlight** — uses Brand 3 directly
* **Status colors** (information, warning, error, success) — use fixed accessible defaults that can be overridden individually

Each derived color uses a formula like `brand1|shade,60` (mix Brand 1 with 60% black) or `brand2|tint,90` (mix Brand 2 with 90% white). You can see the dependents by enabling "Show dependents" on the color picker.

#### Overriding individual palette colors

If the derived colors do not meet your needs, you can override any individual palette color in the Color Selector UI. Uncheck "Use Brand Colors" to gain full manual control over every color in the palette, or keep Brand Colors enabled and override specific palette values as needed.

#### Disabling Color Selector

If colors managed in CSS code only, make sure that Color Selector is disabled in UI or with Drush command:

```sh
drush config-set civictheme.settings colors.use_color_selector 0
```

#### Setting colors via Drush command

Palette colors can be set in bulk via Drush command by providing Brand colors:

```sh
# Enable Color Selector.
drush config-set civictheme.settings colors.use_color_selector 1

# Enable Brand Colors.
drush config-set civictheme.settings colors.use_brand_colors 1

# Set Brand Colors.
drush --include=path/to/civictheme/src/Drush civictheme:set-brand-colors light_brand1 light_brand2 light_brand3 dark_brand1 dark_brand2 dark_brand3

# Purge dynamic assets cache. Will be rebuilt during next pageload.
drush --include=path/to/civictheme/src/Drush civictheme:clear-cache
```

**Example**

```sh
drush -y config-set civictheme.settings colors.use_color_selector 1
drush -y config-set civictheme.settings colors.use_brand_colors 1
drush --include=path/to/civictheme/src/Drush civictheme:set-brand-colors "#00698f" "#e6e9eb" "#121313" "#61daff" "#003a4f" "#00698f"
drush --include=path/to/civictheme/src/Drush civictheme:clear-cache
```

## Troubleshooting

### Colors not updating after changing brand colors

* Clear Drupal caches: `drush cr`
* If using the Color Selector, ensure you pressed Save on the theme settings page
* If using SCSS overrides, ensure you ran `npm run dist` and cleared caches

### Dark theme colors look wrong

* Ensure you set brand colors for both light and dark themes — they are independent
* Dark theme brand2 should typically be a dark background color, not the same as light brand2

### Individual palette overrides being reset

* If "Use Brand Colors" is enabled, derived colors will recalculate when brand colors change. Override at the palette level if you need a value to stay fixed regardless of brand color changes.


# Header

The Header setting allows you to select the Theme and Logo type for the Header.\ <img src="/files/MFzfqlBzfAK15snbMafi" alt="" data-size="original">

### Theme

The Header can be shown in Light or Dark theme.

### Logo type <a href="#header-logotype" id="header-logotype"></a>

Depending on the space within your site's Header, you can select how the Logo (with one or two images) is shown. The space could be limited due to a high number of Primary Navigation links that sit inline with the logo.

The following table outlines the Logo type using example logos:

| **Logo type**  | **Final output (desktop)**       | **Final output (mobile)**        |
| -------------- | -------------------------------- | -------------------------------- |
| Default        | ![](/files/CsenXOxQG0LkNXio7irU) | ![](/files/CsenXOxQG0LkNXio7irU) |
| Stacked        | ![](/files/p0Wer3O1Z7RByFfUjoFU) | ![](/files/p0Wer3O1Z7RByFfUjoFU) |
| Inline         | ![](/files/LxG57jNqTbtSyc4yzbBG) | ![](/files/CsenXOxQG0LkNXio7irU) |
| Inline stacked | ![](/files/LxG57jNqTbtSyc4yzbBG) | ![](/files/p0Wer3O1Z7RByFfUjoFU) |

As you can see, only "Inline stacked" has a different behaviour on desktop and mobile.


# Footer

The Footer setting allows you to select the Theme, Logo type and Background image for the Footer.\
![](/files/peZKPJU9ZW6WsZbnf3Sj)

### Theme

The Footer can be shown in Light or Dark theme.

### Logo type <a href="#header-logotype" id="header-logotype"></a>

Depending on the space within your site's Footer, you can select how the Logo (with one or two images) is shown.

The following table outlines the Logo type using example logos:

| **Logo type**  | **Final output (desktop)**       | **Final output (mobile)**        |
| -------------- | -------------------------------- | -------------------------------- |
| Default        | ![](/files/CsenXOxQG0LkNXio7irU) | ![](/files/CsenXOxQG0LkNXio7irU) |
| Stacked        | ![](/files/p0Wer3O1Z7RByFfUjoFU) | ![](/files/p0Wer3O1Z7RByFfUjoFU) |
| Inline         | ![](/files/LxG57jNqTbtSyc4yzbBG) | ![](/files/CsenXOxQG0LkNXio7irU) |
| Inline stacked | ![](/files/LxG57jNqTbtSyc4yzbBG) | ![](/files/p0Wer3O1Z7RByFfUjoFU) |

As you can see, only "Inline stacked" has a different behaviour on desktop and mobile.

### Background image <a href="#footer-footerbackgroundimage" id="footer-footerbackgroundimage"></a>

Background image allows you to specify the URL of a custom image or upload a custom image that will be shown as a Footer background. Below is an example:

<figure><img src="/files/XyWmkoPwaZV8GaFfYC1D" alt=""><figcaption></figcaption></figure>


# Namespaces

Component namespaces have changed with the release of CivicTheme 1.11 which migrated CivicTheme components to use Single Directory Components.

## Current Namespace Format

All CivicTheme components now use the format `civictheme:<component_name>` for example `civictheme:button` or `civictheme:accordion`. There is no longer nesting of components into their atomic directories.

## Sub-theme Namespacing

In a sub-theme, a new component is namespaced with the sub-theme's machine name. For example: `civictheme_subtheme:new_button`

However, when overriding a CivicTheme component, the sub-theme uses the original CivicTheme namespace `civictheme:button` to refer to this overridden component. This ensures that the override properly replaces the base theme's component.

## Single Directory Components

For more information about the Single Directory Components specification, see the [Drupal documentation on SDC](https://www.drupal.org/docs/develop/theming-drupal/using-single-directory-components).


# Templates

CivicTheme theme utilises the components that are defined within CivicTheme UI kit.

We access these components via component namespaces.

### Using CivicTheme UI kit components

The idea of separating the CivicTheme UI kit and Drupal templates is to create a reusable set of components that can be used in multiple CMS systems.

{% hint style="info" %}
Read more about [Components](/development/uikit/variables/creating-components) to understand how to create components before reading how to connect these components with Drupal.
{% endhint %}

#### Overriding CivicTheme SDC Components

Only themes can override components (modules cannot override). For a theme to override a component, use the `replaces` key within the `mytheme.component.yml` file.

Both components must have schemas defined within their YML files, and the schemas' props and slots must match.

The value of the `replaces` key must refer to the other component using the machine name of the module/theme and the machine name of the component, delimited with a colon (`:`). For example:

```yaml
replaces: 'civictheme:button'
```

In this example, `civictheme` is the name of the theme that contains the component to be replaced, and `button` is the machine name of that component.

**Best Practice:** Copy the entire component directory from CivicTheme to your sub-theme as a starting point for the CSS and Twig files you'll be modifying. Ensure you keep the same directory name as the original component.

If you need to provide custom variables to your component, you derive these variables through the preprocess hook system Drupal provides. Look at the files in `civictheme/includes` directory for how the CivicTheme components are preprocessed in Drupal.

{% hint style="warning" %}
Because we are not using Drupalisms within our templates we equally should be aware that we have to be careful not to rely on Twig features that only exist within Drupal.

Link URLs and text need to be provided as data to the component system, image URLs need to be constructed (remembering to get the required image style URL if implemented) and several other nuances we need to be aware of when integrating with the UI Kit.
{% endhint %}

#### But, what about default field templates

There is a drawback (or advantage as it aligns more closely with modern UX development workflows) to CivicTheme in that the architecture is based at the component level rather than then field level.

Outputting individual fields on the page will result in bare bones output as CivicTheme theme is relying upon the developer to provide these field values to components rather than utilising a field formatter.

Paragraphs are the primary mechanism for linking components up with Drupal, and we have implemented a significant number within CivicTheme. These paragraphs can be created via paragraph fields within new content types and then organised within layout builder to quickly create a new content type.


# Assets

Site assets refer to the collection of files and resources that are essential for the visual appearance, functionality, and overall user experience of a website.

This section explains working with assets in the context of your custom sub-theme. All commands and path are related to your sub-theme directory.

## Compiling and serving assets

All assets are compiled using `npm run dist` based on the supplied [Webpack configuration](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme_starter_kit/webpack/webpack.common.js).

{% hint style="info" %}
The Webpack and Storybook configuration may change between versions, so make sure to follow instructions in [Version update](https://github.com/civictheme/docs/blob/main/development/drupal-theme/broken-reference/README.md) section.
{% endhint %}

Assets are served from the `dist` directory and are inter-linked within your sub-theme.

The sub-theme uses 4 types of assets:

1. [CSS](#css)
2. [JS](#js)
3. [Fonts](#fonts)
4. [Images](#images)

### CSS

SASS styles are compiled into a single CSS file which is located in `dist/civictheme.css` and included into a theme as a library defined in `yourtheme.libraries.yml` file.

There are two categories of style files:

1. UI kit overrides or additional styles
2. Drupal styles

This distinction is made to provide a clear separation between UI kit-specific styles and those exclusive to Drupal.

#### UI kit overrides or additions styles

These reside in `components` directory and repeat the structure of the UI kit library. This allows you to create new or extend existing UI kit components.

See the [Demo button example](https://github.com/civictheme/uikit/tree/main/packages/sdc/components/01-atoms/button) for more details.

#### Drupal styles

These reside in `assets/sass` directory and are intended to override or additionally style Drupal markup.

See the [Local task block styles override example](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme_starter_kit/assets/sass/block/_local-tasks.scss) for more details.

{% hint style="info" %}
Normally, there should be a very minimal number of Drupal style overrides as the whole front-end output is based on the UI kit.
{% endhint %}

### JS

JS files are compiled into a single file which is located in `dist/civictheme.js` and included into a theme as a library defined in `yourtheme.libraries.yml` file.

There are two categories of JS files:

1. UI kit overrides or additional JS files
2. Drupal JS files

This distinction is made to provide a clear separation between UI kit-specific JS behaviours and those exclusive to Drupal.

#### UI kit overrides or additions JS files

These reside in `components` directory and repeat the structure of the UI kit library. This allows to create new or extend existing UI kit components.

See the [Demo button example](https://github.com/civictheme/uikit/tree/main/packages/sdc/components/01-atoms/button) for more details.

#### Drupal JS files

These reside in `assets/js` directory and are intended to override or provide additional behaviours for the Drupal functionality.

## Fonts

Font files are referenced from the SASS files.

They reside in `assets/fonts` directory.

Fonts can replace or extend the current font list provided by the UI kit.

See the [Fonts addition example](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme_starter_kit/components/variables.base.scss#L42) for more details.

## Images

#### Backgrounds and logos

Backgrounds and Logos are content uploaded through the [theme settings ](https://github.com/civictheme/docs/blob/main/development/drupal-theme/broken-reference/README.md)form for you sub-theme, therefore files placed in `assets/backgrounds` and `assets/logos` are used only in your sub-theme's Storybook for visual representation.

#### Icons

{% hint style="info" %}
Icons discussed here are the icons used in the UI elements and not the icons that can be uploaded as content in components such as [Navigation card](/content-authoring/components/list-components-and-cards/cards-for-lists/navigation-card) or [Social links](https://github.com/civictheme/docs/blob/main/development/drupal-theme/broken-reference/README.md)
{% endhint %}

CivicTheme UI kit provides several icons out of the box.

The [design system file](https://civictheme.io/figma) provides more open source icons that can be exported in SVG format and added to your sub-theme.

Place or replace icons in `assets/icons` directory: new icons can be referred to from the SASS styles of your custom components; replaced icons will be picked up by the existing components, provided that their name has not changed.

If the icon file is referenced in the template but does not exist in the above directory, the icon will not render.

{% hint style="info" %}
It is recommended not to delete any of the default icons found in the starter theme, as they are used by the CivicTheme theme in the default templates.
{% endhint %}


# Layout builder

CivicTheme provides one layout: **3 Columns Layout**

When managing your layout (layout builder) within display settings of your content type, you are able to configure whether the content is to be constrained or whether the content is to go page edge to page edge.

## Edge-to-edge vs Constrained Content

**Edge-to-edge content** means that the content and background elements extend the full width of the browser window, from the left edge to the right edge of the viewport. This creates an immersive, modern design where components can utilize the entire screen width. This style is commonly used for landing pages, hero sections, and full-width image galleries.

**Constrained content** limits the content width to a maximum container size (1248 pixels), centering it within the viewport with margins on either side on larger screens. This improves readability and provides a more traditional page layout that's easier to scan on wide displays.

## Sidebar Management

When using Layout Builder's sidebar columns, users need to be careful to ensure they don't conflict with theme region sidebar blocks. Blocks placed in the theme's left and right sidebars can overlap with blocks placed in Layout Builder's sidebars, potentially causing duplication or layout issues. It's important to have a clear strategy for managing which blocks appear in which system to maintain consistent layouts across your site.

## Deprecated Layouts

There are two deprecated layouts that should not be used:

* Single Column
* Single Column contained

These layouts are in the process of being removed in the coming release.

The layout configuration is defined in the `civictheme.info.yml`.

The layout can be viewed within [UI kit](https://uikit.civictheme.io/?path=/story/base-layout--layout).


# Menus

CivicTheme uses four different styles of menu in the base theme. These are placed by block in different regions of the page.

You can control the component / style for the menu with the theme hook suggestion which can be configured in the Block configuration form.

## Primary Navigation

The dropdown menu is the primary navigation for the site.

<div data-full-width="true"><figure><img src="/files/hzID3vxNsBFMttaxevtg" alt="Primary Menu Configuration."><figcaption><p>Primary Menu Setup. Click on the image to zoom in.</p></figcaption></figure></div>

For this menu to be themed correctly the menu block must be configured with `menu__civictheme_primary_navigation` theme hook suggestion in the HTML and style options of the Block configuration form.

<div data-full-width="true"><figure><img src="/files/mbL1qv9cw3NyLNYyCezZ" alt="HTML and style options - Theme hook suggestion: civictheme_primary_navigation"><figcaption><p>Primary Navigation Theme Suggestion Hook Configuration. HTML and style options - Theme hook suggestion: civictheme_primary_navigation. Click on the image to zoom in.</p></figcaption></figure></div>

Settings for primary navigation used in CivicTheme are:

```yaml
settings:
  id: 'menu_block:civictheme-primary-navigation'
  label: 'Primary Navigation'
  label_display: ''
  provider: menu_block
  follow: false
  follow_parent: child
  label_link: false
  label_type: block
  level: 1
  depth: 3
  expand_all_items: false
  parent: 'civictheme-primary-navigation:'
  suggestion: civictheme_primary_navigation
```

These are set through the Menu Block configuration form.

## Secondary Navigation

The secondary navigation is a menu block placed in the top right of the page.

<div data-full-width="true"><figure><img src="/files/LnCbBV9CDUusoxo5bAF1" alt="Secondary Menu Configuration."><figcaption><p>Primary Menu Setup. Click on the image to zoom in.</p></figcaption></figure></div>

For this menu to be themed correctly the menu block must be configured with `menu__civictheme_secondary_navigation` theme hook suggestion in the HTML and style options of the Block configuration form.

<div data-full-width="true"><figure><img src="/files/5zX7G5X7pjKtPdyIPBsv" alt="HTML and style options - Theme hook suggestion: civictheme_secondary_navigation"><figcaption><p>Secondary Navigation Theme Suggestion Hook Configuration. HTML and style options - Theme hook suggestion: civictheme_secondary_navigation. Click on the image to zoom in.</p></figcaption></figure></div>

Default settings for secondary navigation provided by CivicTheme are:

```yaml
settings:
  id: 'menu_block:civictheme-secondary-navigation'
  label: 'Secondary Navigation'
  label_display: ''
  provider: menu_block
  follow: false
  follow_parent: child
  label_link: false
  label_type: block
  level: 1
  depth: 0
  expand_all_items: false
  parent: 'civictheme-secondary-navigation:'
  suggestion: civictheme_secondary_navigation
```

## Mobile Navigation

The mobile navigation is a content block type. This block once created is placed is in the Header Middle 3 region.

Configuration is managed within the content block system located in your site in /admin/content/block. There is a mobile navigation block and a search block. The search block has a checkbox for setting to mobile navigation block once this is set you will need to clear cache for search to appear in the mobile navigation.

Configuration for mobile navigation is shown below:

<div data-full-width="true"><figure><img src="/files/U2s3LvwT90wC76Sq4KfX" alt="Mobile Navigation Block Configuration"><figcaption><p>Mobile Menu Block Configuration. Click on the image to zoom in.</p></figcaption></figure></div>

## Side Navigation

The side navigation is a menu block placed in the Side bar top left region of the page.

<div data-full-width="true"><figure><img src="/files/km1L6A635GqyNSbKvvNg" alt="Sidebar Navigation Menu."><figcaption><p>SideBar Navigation. Click on the image to zoom in.</p></figcaption></figure></div>

For this menu to be themed correctly the menu block must be configured with `menu__civictheme_sidebar_navigation` theme hook suggestion in the HTML and style options of the Block configuration form.

<div data-full-width="true"><figure><img src="/files/UQTNHFpBoYP47Ch3p4SB" alt="HTML and style options - Theme hook suggestion: civictheme_sidebar_navigation"><figcaption><p>Sidebar Navigation Theme Suggestion Hook Configuration. HTML and style options - Theme hook suggestion: civictheme_sidebar_navigation. Click on the image to zoom in.</p></figcaption></figure></div>

The settings for the side navigation used in CivicTheme are:

```yaml
settings:
  id: 'menu_block:civictheme-primary-navigation'
  label: 'Side Navigation'
  label_display: ''
  provider: menu_block
  follow: false
  follow_parent: child
  label_link: false
  label_type: block
  level: 1
  depth: 3
  expand_all_items: false
  parent: 'civictheme-primary-navigation:'
  suggestion: civictheme_sidebar_navigation
```

## Footer Navigation

The default setup for the footer navigation is a menu block placed in each of the four middle regions of the footer.

<div data-full-width="true"><figure><img src="/files/W646qBS07iljakJtZZL7" alt="Footer Menu Configuration."><figcaption><p>Footer Menu Setup. Click on the image to zoom in.</p></figcaption></figure></div>

For this menu to be themed correctly the menu block must be configured with `menu__civictheme_footer` theme hook suggestion in the HTML and style options of the Block configuration form.

<div data-full-width="true"><figure><img src="/files/zAW5HNgUXeeGtLedCdtx" alt="HTML and style options - Theme hook suggestion: civictheme_footer"><figcaption><p>Footer Theme Suggestion Hook Configuration. HTML and style options - Theme hook suggestion: civictheme_footer. Click on the image to zoom in.</p></figcaption></figure></div>

The settings for each footer menu are:

```yaml
settings:
  id: 'menu_block:civictheme-footer'
  label: 'Footer menu 1'
  label_display: visible
  provider: menu_block
  follow: false
  follow_parent: child
  label_link: false
  label_type: fixed
  level: 1
  depth: 1
  expand_all_items: false
  parent: '<set the parent>'
  suggestion: civictheme_footer
```


# Automated list

For content authoring guidance on how to add and configure an Automated list (including debugging sort order), see [Automated list (content authoring)](/content-authoring/components/list-components-and-cards/automated-list).

The Automated List Component enables editors to create content lists and embed them on any page.

It uses a `civictheme_automated_list` paragraph, whose field values are processed by a View preprocessing function. This function maps these values as arguments to a pre-configured `civictheme_automated_list` view.

The component provides configurations via paragraph to a view allowing content type restrictions, show/hide pagination, altering the number of items and filter configuration options.

It is possible to replace the default `civictheme_automated_list` view with a more custom one required for a specific site via `hook_civictheme_automated_list_view_name_alter()` (see [civictheme.api.php](https://github.com/civictheme/monorepo-drupal/blob/develop/web/themes/contrib/civictheme/civictheme.api.php) for details).

CivicTheme also provides support for filters in an exposed form. For views with only 1 exposed filter, Single Filter component (tag based) is enabled, but as soon as there is more than one exposed filter - the Group Filter component (with dropdown filters) is enabled automatically.

{% hint style="info" %}
It is possible to opt-out from automated exposed filters conversion using the `views.CivicThemeOptoutViewsExposedFilter` flag on the theme settings page.
{% endhint %}


# Systems

CivicTheme has several unique architectural approaches for developing themes that promote component-centric development and maintainability. Understanding these systems is essential for building sites that work effectively within the CivicTheme ecosystem.

## Overview

CivicTheme's development approach is built around these core systems:

* **Component-centric architecture** - Organised folders for styles, JavaScript, and templates
* **Template separation** - Component Twig templates separated from Drupal `*.html.twig` files
* **Preprocess functions** - Custom functions to populate component template properties
* **Color system** - Custom color overrides and theming capabilities
* **Build system** - Custom asset compilation and development workflow

## System Documentation

Each system has detailed documentation that explains implementation patterns and best practices:

### [Build System](/development/drupal-theme/systems/build)

Learn about CivicTheme's custom build system, including asset compilation, configuration, and development workflows.

### [Colors](/development/drupal-theme/systems/colors)

Explore the color override system and how to customise CivicTheme's design tokens.

### [Components](/development/drupal-theme/systems/components)

Understand the component-centric approach, including template separation, preprocess functions, and how to map Drupal data to component properties.

### [Mapping](/development/drupal-theme/systems/mapping)

Discover how Drupal entities are mapped to component templates and properties.

## Related Documentation

### Component Development

* [Templates](/development/drupal-theme/templates) - How to use CivicTheme UI Kit components in Drupal
* [Namespaces](/development/drupal-theme/namespaces) - Component namespace system and organisation
* [Assets](/development/drupal-theme/assets) - Asset management and component structure

## Learning Path

To effectively work with CivicTheme systems:

1. **Start with the basics**: Read [Templates](/development/drupal-theme/templates) to understand component separation
2. **Understand the build system**: Review [Build System](/development/drupal-theme/systems/build) for development workflow
3. **Learn component mapping**: Study [Components](/development/drupal-theme/systems/components) for data flow patterns
4. **Customise appearance**: Explore [Colors](/development/drupal-theme/systems/colors) for theming

## Key Benefits

Learning these systems enables you to:

* Build **component-centric** sites that are maintainable and scalable
* Create **reusable patterns** that work across different projects
* Leverage **CivicTheme's ecosystem** effectively
* Maintain **consistent design** and development standards
* **Extend functionality** without breaking existing patterns

## Getting Help

* [Getting Help](/getting-started/getting-help) - Community resources and support
* [Contribution Model](/contributing/contribution-model) - How to contribute to the ecosystem
* [GitHub Organisation](https://github.com/civictheme/) - Source code and issues


# Build System

## Overview

CivicTheme's build system is a custom asset compilation pipeline designed specifically for Drupal themes. Built around `build.js`, it provides a simplified, fast approach to managing theme assets while prioritising speed and auditability over complex optimisation features.

The system is engineered to handle the unique requirements of government digital services, ensuring consistent asset delivery across different environments while maintaining the flexibility needed for custom theme development.

## Core Architecture

### Asset Compilation Pipeline

The build system processes multiple asset types through a unified pipeline:

1. **Combines component directories** — uses rsync to merge CivicTheme's components with your sub-theme's components into a temporary `components_combined/` directory. This combined directory is used by Storybook so it can render all components together. SDC components ship their own compiled CSS alongside their component files in the `components/` directory.
2. **Compiles SCSS** — processes theme-level stylesheets (theme styles, layout styles, editor styles, admin styles, variables) into CSS in `dist/` using `sass-embedded`. Component-level SCSS is compiled to `.css` files within each component's own directory.
3. **Bundles JavaScript** — wraps component JavaScript in Drupal behavior patterns.
4. **Copies assets** — moves fonts, icons, images, and other static assets to `dist/assets/`.
5. **Generates constants** — exports SCSS variables, icon names, backgrounds, and logos to `dist/constants.json` for use in Storybook.

### Component System Integration

The build system manages CivicTheme's component architecture:

* **Component Combination**: Merges base CivicTheme components with custom theme components
* **SDC Support**: Generates isolated CSS/JS for Single Directory Components
* **Dependency Resolution**: Handles imports and ensures proper load order across the component hierarchy

### Multi-Environment Output

The system generates optimised outputs for different contexts:

* **Drupal Integration**: Produces files compatible with Drupal's asset management system
* **Storybook Support**: Creates separate builds for the Storybook development environment
* **Editor/Admin Styles**: Generates specialised stylesheets for different Drupal interfaces

## Build Modes and Commands

The build system supports multiple operational modes:

* **Full Build**: Complete asset compilation for production deployment
* **Watch Mode**: File system monitoring with automatic rebuilds for development
* **Selective Building**: Targeted compilation of specific asset types (styles, JavaScript, assets)
* **CLI Integration**: Parallel execution of npm scripts for improved performance

### Commands

```bash
# Full build (assets + Storybook static site)
npm run build

# Compile assets only (faster, no Storybook)
npm run dist

# Watch mode (recompiles on file changes)
npm run dist:watch

# Lint SCSS and JavaScript
npm run lint
npm run lint-fix

# Start Storybook dev server (runs dist first, then watches)
npm run storybook
```

### Key output files

| File                          | Purpose                                                          |
| ----------------------------- | ---------------------------------------------------------------- |
| `dist/styles.base.css`        | Base component styles                                            |
| `dist/styles.theme.css`       | Theme-specific styles                                            |
| `dist/styles.variables.css`   | CSS custom properties (color variables)                          |
| `dist/scripts.drupal.base.js` | JavaScript wrapped in Drupal behaviors                           |
| `dist/constants.json`         | SCSS variables, icon names, backgrounds, and logos for Storybook |

## Configuration and Constants

### Theme Detection

The system automatically detects and links to the base CivicTheme installation, ensuring proper inheritance and customisation paths.

### Constants Generation

Extracts and processes design tokens including:

* Background configurations
* Icon definitions
* Logo specifications
* SCSS variable mappings

### Path Management

Handles complex directory structures and relative paths required for Drupal theme integration.

## Design Philosophy

The build system makes several deliberate architectural decisions:

### Performance Optimisations

* **Unix-focused**: Optimised for Unix-like environments with rsync for efficient file operations
* **Speed over optimisation**: Prioritises build speed over minification/uglification
* **Selective watching**: File monitoring limited to specific file types for efficiency
* **Minimal dependencies**: Uses native Node.js and command-line tools to reduce external dependencies

### Critical Assumptions

The system operates under specific technical constraints:

* Unix-like environment with rsync availability
* CivicTheme directory structure conventions
* Drupal integration patterns (behaviours, asset paths)
* Component-based architecture with clear separation of concerns

## Next Steps

To begin using the build system:

1. Ensure your environment meets the Unix-like requirements
2. Review the CivicTheme directory structure conventions
3. Configure your theme's build settings
4. Run the initial build process

For detailed implementation guidance, refer to the [Drupal theme development documentation](/development/drupal-theme).


# Colors

## Overview

The CivicTheme color system is a sophisticated, multi-layered approach to managing colours across components. It provides a flexible foundation for creating consistent, accessible, and themeable user interfaces that support both light and dark themes.

## Quick Start

To use the CivicTheme color system:

1. **Define brand colours** in `$ct-colors-brands` (optional)
2. **Override default colours** in `$ct-colors` (optional)
3. **Use component variables** in `_variables.components.scss` for specific styling
4. **Apply themes** using the `ct-component-theme` mixin in component SCSS files

## Color System Architecture

### 1. Base Color Foundation (`_variables.base.scss`)

The color system is built on a foundation of semantic colour tokens that are mapped to actual colour values:

```scss
// Brand colours can be extended
$ct-colors-brands: () !default;

// Default colour palette can be overridden
$ct-colors: () !default;

// Default semantic colour mapping
$ct-colors-default: (
  'light': (
    'heading': ct-color-shade(ct-color-constant-light('brand1'), 60),
    'body': ct-color-tint(ct-color-shade(ct-color-constant-light('brand1'), 80), 20),
    'background-light': ct-color-tint(ct-color-constant-light('brand2'), 90),
    'background': ct-color-constant-light('brand2'),
    'interaction-background': ct-color-constant-light('brand1'),
    'interaction-text': ct-color-tint(ct-color-constant-light('brand2'), 80),
    // ... more semantic colours
  ),
  'dark': (
    'heading': ct-color-tint(ct-color-constant-dark('brand1'), 95),
    'body': ct-color-tint(ct-color-constant-dark('brand1'), 85),
    'background': ct-color-constant-dark('brand2'),
    'interaction-background': ct-color-constant-dark('brand1'),
    'interaction-text': ct-color-constant-dark('brand2'),
    // ... more semantic colours
  )
);
```

### 2. Component-Specific Variables (`_variables.components.scss`)

Component variables map semantic colours to specific component properties:

```scss
// Tag component variables
$ct-tag-light-primary-background-color: ct-color-light('interaction-background') !default;
$ct-tag-light-primary-color: ct-color-light('interaction-text') !default;
$ct-tag-dark-primary-background-color: ct-color-dark('interaction-background') !default;
$ct-tag-dark-primary-color: ct-color-dark('interaction-text') !default;
```

## How New Color Palettes Are Mapped

### Step 1: Define Brand Colours (Optional)

To create a custom colour palette, start by defining your brand colours:

```scss
// In your theme's variables.base.scss
$ct-colors-brands: (
  'light': (
    'brand1': #0066cc,  // Primary brand colour
    'brand2': #f8f9fa,  // Secondary brand colour
    'brand3': #ff6b35,  // Accent brand colour
  ),
  'dark': (
    'brand1': #4d94ff,  // Primary brand colour (dark variant)
    'brand2': #1a1a1a,  // Secondary brand colour (dark variant)
    'brand3': #ff8c69,  // Accent brand colour (dark variant)
  )
);
```

### Step 2: Override Default Colours (Optional)

You can override specific semantic colours without changing the entire palette:

```scss
// In your theme's variables.base.scss
$ct-colors: (
  'light': (
    'interaction-background': #custom-primary,
    'interaction-text': #custom-text,
  ),
  'dark': (
    'interaction-background': #custom-primary-dark,
    'interaction-text': #custom-text-dark,
  )
);
```

### Step 3: Component Variables Automatically Update

Once you've defined your brand colours or overridden semantic colours, all component variables automatically use the new values because they reference the semantic colour functions:

```scss
// These automatically use your new colours
$ct-tag-light-primary-background-color: ct-color-light('interaction-background');
$ct-tag-light-primary-color: ct-color-light('interaction-text');
```

## How Light and Dark Theme Colours Are Applied

### The `ct-component-theme` Mixin

The `ct-component-theme` mixin is the core mechanism for applying theme-specific styles:

```scss
@mixin ct-component-theme($name) {
  @each $theme in light, dark {
    &.ct-theme-#{$theme} {
      @content($name, $theme);
    }
  }
}
```

### Component Implementation Pattern

Components use this pattern to apply theme-specific styles:

```scss
.ct-tag {
  $root: &;

  // Base styles (shared across themes)
  border-radius: $ct-tag-border-radius;
  display: inline-block;

  // Theme-specific styles
  @include ct-component-theme($root) using($root, $theme) {
    &#{$root}--primary {
      @include ct-component-property($root, $theme, primary, background-color);
      @include ct-component-property($root, $theme, primary, border-color);
      @include ct-component-property($root, $theme, primary, color);
    }
  }
}
```

### CSS Custom Properties Generation

The `ct-component-property` mixin generates CSS custom properties:

```scss
@mixin ct-component-property($args...) {
  $property: list.nth($args, list.length($args));
  #{$property}: ct-component-var($args...);
}
```

This generates CSS like:

```css
.ct-tag.ct-theme-light.ct-tag--primary {
  background-color: var(--ct-tag-light-primary-background-color);
  border-color: var(--ct-tag-light-primary-border-color);
  color: var(--ct-tag-light-primary-color);
}

.ct-tag.ct-theme-dark.ct-tag--primary {
  background-color: var(--ct-tag-dark-primary-background-color);
  border-color: var(--ct-tag-dark-primary-border-color);
  color: var(--ct-tag-dark-primary-color);
}
```

### Colour Function Resolution

The `ct-color-light()` and `ct-color-dark()` functions resolve to CSS custom properties:

```scss
@function ct-color-light($name) {
  @return _ct-color($name, 'light');
}

@function _ct-color($name, $theme, $is-flat: false) {
  // ... validation logic ...

  @if not $is-flat {
    $color: ct-component-var(ct, color, $theme, $name);
  }

  @return $color;
}
```

This creates a chain: `ct-color-light('interaction-background')` → `var(--ct-color-light-interaction-background)` → actual colour value.

## Variable Naming Convention

Component variables follow a strict naming pattern:

```
$ct-[component]-[theme]-[?subcomponent]-[?state]-[rule]
```

Examples:

* `$ct-tag-light-primary-background-color`
* `$ct-button-dark-secondary-hover-border-color`
* `$ct-navigation-light-dropdown-menu-item-active-background-color`

## Practical Example: Creating a Custom Tag Variant

To add a new "success" variant to the tag component:

1. **Add component variables** in `_variables.components.scss`:

```scss
$ct-tag-light-success-background-color: ct-color-light('success') !default;
$ct-tag-light-success-border-color: $ct-tag-light-success-background-color !default;
$ct-tag-light-success-color: white !default;
$ct-tag-dark-success-background-color: ct-color-dark('success') !default;
$ct-tag-dark-success-border-color: $ct-tag-dark-success-background-color !default;
$ct-tag-dark-success-color: white !default;
```

2. **Add component styles** in `tag.scss`:

```scss
@include ct-component-theme($root) using($root, $theme) {
  // ... existing variants ...

  &#{$root}--success {
    @include ct-component-property($root, $theme, success, background-color);
    @include ct-component-property($root, $theme, success, border-color);
    @include ct-component-property($root, $theme, success, color);
  }
}
```

## Benefits of This System

1. **Semantic Colour Mapping**: Colours are defined by purpose, not specific values
2. **Automatic Theme Support**: Light and dark themes are handled automatically
3. **CSS Custom Properties**: Enables runtime theme switching
4. **Extensible**: Easy to add new colours or override existing ones
5. **Consistent**: All components follow the same theming pattern
6. **Maintainable**: Changes to brand colours propagate throughout the system

## Key Files

* `_variables.base.scss`: Foundation colour definitions
* `_variables.components.scss`: Component-specific colour mappings
* `mixins/_color.scss`: Colour utility functions
* `mixins/_component.scss`: Theme application mixins

## Next Steps

To implement a new colour palette:

1. Define your brand colours in `$ct-colors-brands`
2. Override any semantic colours in `$ct-colors` if needed
3. Test components in both light and dark themes
4. Use the existing component variables for consistency
5. Add new component variables following the naming convention


# Components

This guide outlines the standard file structure and characteristics for CivicTheme components, based on the established patterns in the codebase.

## Overview

Each component follows a consistent file structure with specific purposes for each file type. This ensures maintainability, reusability, and proper integration with the CivicTheme design system.

## File Types and Purposes

### `*.component.yml` - Component Metadata and Schema (SDC)

**Purpose**: Defines the component's properties, validation rules, and documentation as a Drupal Single Directory Component (SDC).

CivicTheme components are SDCs — each component lives in its own directory with all related files (Twig, SCSS, JS, stories, and this metadata file). Drupal's SDC system uses the `.component.yml` file to register the component and validate the props passed to it at render time.

**Characteristics**:

* Uses JSON Schema format with Drupal's metadata schema for prop validation
* Defines all available props with types, descriptions, and validation rules
* Includes enums for constrained values (e.g., theme options, size variants)
* Provides default values where appropriate
* Serves as the single source of truth for component configuration
* Enables automatic form generation in Storybook and Drupal
* Drupal validates incoming props against this schema at render time — missing required props or invalid types will raise errors

**Key sections**:

* `$schema`: References Drupal's metadata schema (`https://git.drupalcode.org/...metadata.schema.json`)
* `name`: Human-readable component name
* `status`: Component stability status (e.g., `stable`, `experimental`)
* `description`: Component purpose and usage
* `props`: Detailed property definitions with JSON Schema validation (types, enums, defaults)
* `slots`: Named content areas that accept rendered markup (used instead of props for rich content)

To see how CivicTheme structures its components, examine the [CivicTheme UI Kit SDC components](https://github.com/civictheme/uikit/tree/main/packages/sdc/components).

**Standard enums**: CivicTheme defines standard enum values for commonly used props such as `theme` (`light`, `dark`), `spacing` (`top`, `bottom`, `both`, `none`), and other widely shared properties. When creating or overriding components in your sub-theme, use the same enum values to ensure your component schemas remain compatible with CivicTheme's base components. Mismatched enums may cause incompatibilities with CivicTheme and Drupal. Review the base theme's `.component.yml` files to see which standard values are expected.

**SDC component referencing**: Components are referenced by their namespace and machine name (e.g., `civictheme:button`). In sub-themes, use the `replaces` key to override a base theme component:

```yaml
replaces: civictheme:button
```

### `*.twig` - Template File

**Purpose**: Defines the HTML structure and logic for rendering the component.

**Characteristics**:

* Contains comprehensive documentation in the header comment block
* Lists all available props with types and descriptions
* Implements conditional logic for different component states
* Uses Twig's template inheritance and includes
* Handles multiple component variants (e.g., different types, sizes, themes)
* Includes accessibility attributes and ARIA labels
* Supports both static and dynamic content rendering

**Key patterns**:

**Prop validation** — validate props at the top of the template using ternary operators:

```twig
{% set kind = kind in ['button', 'link', 'reset', 'submit'] ? kind : 'button' %}
{% set type = type in ['primary', 'secondary', 'tertiary'] ? type : null %}
{% set theme = theme in ['light', 'dark'] ? theme : 'light' %}
```

**Class construction** — build modifier classes dynamically:

```twig
{% set type_class = type ? 'ct-button--%s'|format(type) : '' %}
{% set size_class = size ? 'ct-button--%s'|format(size) : '' %}
{% set modifier_class = '%s %s %s'|format(type_class, size_class, modifier_class|default('')) %}
```

**Nested component includes** — use `only` to limit the scope of variables passed to child components:

```twig
{% include 'civictheme:icon' with {
  symbol: icon,
  size: 'small',
} only %}
```

**Blocks for extensibility** — use Twig blocks to allow further overriding by child templates:

```twig
{% block content_block %}
  <div class="ct-card__content">
    {{ content }}
  </div>
{% endblock %}
```

### `*.stories.js` - Storybook Configuration

**Purpose**: Creates interactive documentation and testing environment for the component.

**Characteristics**:

* Defines Storybook metadata and component configuration
* Maps component props to Storybook controls
* Provides default values for all component variants
* Enables interactive testing of different prop combinations
* Imports constants and design tokens for consistent options
* Supports component categorisation in Storybook navigation

**Key features**:

* Control types (radio, text, boolean, select) for different prop types
* Default story with sensible fallback values
* Integration with design system constants
* Component organisation in Storybook hierarchy

### `*.js` - JavaScript Functionality

**Purpose**: Provides interactive behaviour and event handling for the component.

**Characteristics**:

* Implements component-specific functionality and interactions
* Handles user events (click, focus, keyboard navigation)
* Manages component state and lifecycle
* Provides accessibility enhancements
* Uses vanilla JavaScript for broad compatibility
* Includes comprehensive event handling and error prevention
* Uses `data-` attributes for element selection to ensure HTML changes don't break functionality
* Avoids dependencies on jQuery, using standard DOM APIs
* Automatically wrapped with Drupal behaviours at build time

**Key patterns**:

* Constructor pattern for component initialisation
* Event delegation and proper cleanup
* Accessibility support (keyboard navigation, ARIA)
* State management and visual feedback
* Integration with design system classes
* Data attribute-based element selection for reusability
* Standard DOM methods (querySelector, addEventListener, etc.)
* Proper error handling and validation

**Implementation approach**:

* Common utilities are managed in `/components/00-base`
* Element connections use `data-` attributes instead of classes, IDs, or element tags
* Ensures minimal impact on JS when HTML structure changes
* Promotes reusability across different HTML structures
* Build process automatically wraps with `Drupal.behaviors.attach` functions

### `*.scss` - Source Styles

**Purpose**: Defines the component's visual styling using SCSS.

**Characteristics**:

* Uses SCSS features (variables, mixins, nesting)
* Implements BEM methodology for class naming
* Integrates with design system tokens and variables
* Provides responsive design support
* Includes focus states and accessibility styling
* Uses mixins for consistent styling patterns
* Supports light and dark theme variants
* Uses CivicTheme's color palette system for consistent theming

**Key patterns**:

**BEM naming** — all classes use the pattern `ct-<component>__<element>--<modifier>`:

```scss
.ct-button {              // Block
  $root: &;               // Store root selector for complex selectors

  &__icon {               // Element
    margin-right: ct-spacing(1);
  }

  &--primary {            // Modifier
    @include ct-button-type('primary');
  }
}
```

**Design tokens** — use token functions instead of hardcoded values:

```scss
padding: ct-spacing(3);             // 24px (3 * 8px particle)
border-width: ct-particle(0.125);
@include ct-typography('heading-4');
@include ct-breakpoint(m) { }       // Mobile-first breakpoint
```

**Theme support** — use the component theme mixin for light/dark theme support:

```scss
@include ct-component-theme($root) using($root, $theme) {
  @include ct-component-property($root, $theme, background-color);

  #{$root}__title {
    @include ct-component-property($root, $theme, title, color);
  }
}
```

**Key features**:

* Design system integration via variables and mixins
* Responsive breakpoints and media queries
* State-based styling (hover, focus, active, disabled)
* Theme support (light/dark variants)
* Modular and maintainable structure
* Color palette integration using `$ct-colors` variable map
* BEM naming convention for maintainable CSS architecture

**Implementation approach**:

* Most styles managed within components in `/components` directory
* `/assets/sass` reserved for Drupal-specific styles (admin blocks, CKEditor, Layout Builder)
* Color application via `/subtheme/components/variables.base.scss` using `$ct-colors`
* Fine-tuning colors in `/subtheme/components/variables.components.scss`
* Default color map reference: `civictheme/components/00-base/_variables.base.scss`
* Component color variables reference: `civictheme/components/00-base/_variables.components.scss`
* Encouraged to support both light and dark themes for new components
* Particularly important for giveback components

### `*.css` - Compiled Styles

**Purpose**: Generated CSS file for production use.

**Characteristics**:

* Automatically generated from SCSS source files
* Contains vendor-prefixed and optimised CSS
* Includes responsive design rules
* Provides fallback values and browser compatibility
* Optimised for performance and file size

**Important notes**:

* **Do not edit directly** - changes will be overwritten
* Generated via build process (`npm run dist`)
* Contains design system variables and custom properties
* Includes comprehensive state styling and accessibility features

## Development Guidelines

### File Naming Convention

* All files use the same base name as the component
* Follow kebab-case for component names
* Maintain consistent file extensions

### Component Structure

1. Start with the `*.component.yml` to define the component's interface
2. Create the `*.twig` template with proper documentation
3. Add `*.stories.js` for interactive documentation
4. Implement `*.js` for any required interactivity
5. Style with `*.scss` using design system patterns
6. Build generates the final `*.css` file

### Best Practices

* File header documentation is generated from the \*.component.yml document
* Use design system tokens and variables consistently
* Implement proper accessibility features
* Test all component variants in Storybook
* Follow established naming conventions and patterns
* Ensure responsive design support
* Include proper error handling and validation

This structure ensures components are maintainable, reusable, and properly integrated with the CivicTheme design system while providing excellent developer experience through comprehensive documentation and testing tools.

## Common Pitfalls

### Forgetting to rebuild

Changes to SCSS, JavaScript, or Twig files require running `npm run dist`. Storybook's watch mode handles this automatically, but if you are testing in Drupal you need to rebuild and clear caches.

### Namespace conflicts

Your overridden component must use `replaces: 'civictheme:component_name'` in its `.component.yml` file. Without this, Drupal will see two components with conflicting names.

### Breaking the prop schema

When overriding a component's `.component.yml`, ensure existing props remain compatible. Adding new props is safe; removing or changing the type of existing props will break templates that depend on them.

### Preprocess hook dependencies

Some components receive their data from preprocess hooks in the base CivicTheme theme's `includes/` directory. If your override adds new props, you will need to provide data for them through your sub-theme's own preprocess hooks. The [mapping system](/development/drupal-theme/systems/mapping) explains how Drupal entities are connected to component templates through preprocess functions.


# Mapping

## Overview

CivicTheme separates its component Twig files from its Drupal implementation. This separation requires preprocess functions to extract data from Drupal entities, process it as necessary, and map it to the expected properties of the UI Kit Twig file. This approach encourages building CivicTheme components in a reusable fashion where the HTML is more generalised and less Drupal-specific.

***

## Quick Start

### Prerequisites

* A CivicTheme subtheme
* Basic understanding of Drupal preprocess functions
* Familiarity with Twig templating

### Basic Implementation

1. **Create a custom include file** for your field processing logic
2. **Implement a preprocess hook** to call your custom function
3. **Update the Twig template** to reference the CivicTheme component

***

## Utilities

CivicTheme provides utilities to simplify preprocess function development:

* [Utilities](https://github.com/civictheme/monorepo-Drupal/blob/develop/web/themes/contrib/civictheme/includes/utilities.inc) - Helper functions for common Drupal operations

***

## Implementation Example

The following example demonstrates how to map a Drupal field to display as a CivicTheme tag component. This covers the fundamentals of gathering data from an entity in a preprocess function, passing it through the `*.html.twig` template, and setting it on the `civictheme:tag` component.

### Step 1: Theme File

**File:** `subtheme.theme`

```php
require_once __DIR__ . '/includes/custom_field.inc';

function subtheme_preprocess_field(array &$variables): void {
  _civictheme_preprocess_custom_field($variables);
}
```

**What this does:**

* Includes the custom field processing logic
* Calls the custom preprocess function when the field preprocess hook is triggered

### Step 2: Custom Field Processing

**File:** `includes/custom_field.inc`

```php
use Drupal\Core\Entity\FieldableEntityInterface;

function _civictheme_preprocess_custom_field(array &$variables): void {
  if ($variables['field_name'] !== 'field_custom_field') {
    return;
  }

  $node = $variables['element']['#object'] ?? NULL;
  if ($node instanceof FieldableEntityInterface) {
    $variables['custom_value'] = civictheme_get_field_value($node, 'field_c_n_custom', TRUE);
  }
}
```

**What this does:**

* Checks that the correct field is being processed
* Retrieves the node attached to the field and validates its type
* Uses the `civictheme_get_field_value` utility to extract the field value
* Adds the processed value to the `custom_value` property

### Step 3: Twig Template

**File:** `templates/field/field--node--field-c-n-custom.html.twig`

```twig
{% include 'civictheme:tag' %}
```

**What this does:**

* References the CivicTheme tag component
* Passes all available properties through to the component
* Can be modified to reference custom components if needed

***

## Field Naming Conventions

CivicTheme uses field prefixes to indicate scope and determine how much built-in support is available:

| Prefix        | Scope                       | What it means                                                                       |
| ------------- | --------------------------- | ----------------------------------------------------------------------------------- |
| `field_c_n_*` | CivicTheme node fields      | CivicTheme already has preprocess functions and templates. Less custom code needed. |
| `field_c_p_*` | CivicTheme paragraph fields | Same as above, but for paragraph entities.                                          |
| `field_n_*`   | Custom node fields          | No built-in support. You must write your own preprocess functions and templates.    |
| `field_p_*`   | Custom paragraph fields     | Same as above, but for paragraph entities.                                          |

The most common approach is to mix both — use CivicTheme standard fields where they fit and custom fields where they don't.

## Drupal Integration via Paragraph Types

To use a component in Drupal's content authoring workflow, create a paragraph type that matches the component's props. For example, a feature card component would have:

* Paragraph type: `feature_card`
* Fields: `field_c_p_title` (Text), `field_c_p_summary` (Text, long), `field_c_p_icon` (Text), `field_c_p_link` (Link), `field_c_p_theme` (List — light/dark)

Then create a preprocess include to extract field values and a Drupal Twig template that includes the component. See the [Implementation Example](#implementation-example) above.

## Best Practices

### File Organisation

* Place custom code in dedicated `*.inc` files specific to the feature being implemented
* Use descriptive file names that clearly indicate the purpose
* Keep preprocess functions focused and single-purpose

### Template Structure

As much HTML as possible should live in the components. The Drupal Twig templates should act as connectors to the components. It should be common for Drupal `*.html.twig` templates to contain only an include of a component Twig file.

### Data Processing

* Always validate field names before applying custom processing
* Use CivicTheme utilities for common operations
* Ensure proper type checking for entities and fields
* Follow Drupal coding standards and best practices

***

## Next Steps

* Explore the [CivicTheme utilities](https://github.com/civictheme/monorepo-Drupal/blob/develop/web/themes/contrib/civictheme/includes/utilities.inc) for additional helper functions
* Review other component implementations for patterns and approaches
* Consider contributing improvements to the mapping system


# Maintenance

Documentation about maintaining the CivicTheme codebase

For maintenance details, please refer to project [README.md](https://github.com/civictheme/monorepo-drupal/blob/develop/README.md#local-environment-setup) file.


# Code naming conventions

{% hint style="info" %}
Requirement levels (MUST, SHOULD, MAY) are used in accordance with [RFC2119](https://www.ietf.org/rfc/rfc2119.txt)
{% endhint %}

* Configuration **MUST** be stored in the `civictheme` theme's `config/install` and `config/optional` directories.
* All machine names **MUST** be prefixed with `civictheme_` for:
  * Content types
  * Vocabularies
  * Text formats
  * User roles
* UI **MUST NOT** refer to `CivicTheme` .
* `page` or `article` **SHOULD NOT** be used as a prefix for the name of a content type unless absolutely necessary, instead: `News article` , `Blog page`
* Field names **MUST** be:
  * Prefixed with `field_c_<first_letter_of_entity_type>_`
  * Given generic names based on their purpose and SHOULD be shared across multiple bundles
  * Named using singular nouns
* Vocabularies **MUST** be:
  * Named using plural nouns
  * Named using contextual information to distinguish between vocabularies used for specific purposes: `Blog topics` instead of just `Topics`


# Requirements and constraints

{% hint style="info" %}
Requirement levels (MUST, SHOULD, MAY) are used in accordance with [RFC2119](https://www.ietf.org/rfc/rfc2119.txt)
{% endhint %}

### Product requirements

* CivicTheme Drupal theme **MAY** be used out of the box without any customisations.
* CivicTheme Drupal theme **MUST NOT** be changed for customisations. If customisations are required - a consumer theme **MUST** be created and used as a sub-theme of the CivicTheme theme.
* CivicTheme Drupal theme **MUST** be fully compatible with GovCMS SaaS:
  * **MUST NOT** have any modules
  * **MUST NOT** rely on any libraries
  * **MUST NOT** rely on GovCMS content structures
  * **MUST** assume that FE compilation happens on local machine and then committed to the repository
  * **MUST** provide a static version of compiled Storybook for the CivicTheme-based consumer site.


# Authoring documentation

This section describes the agreed practices on how to author documentation.

### Language

1. **Simple and Direct Language:** Use simple, straightforward language. Avoid complex sentences and technical jargon that might confuse the reader.
2. **Avoiding Polite Forms and Superfluous Words:** Refrain from using words like "please," "kindly," or other polite forms that can make instructions seem optional. Keep language direct and to the point, as this helps in creating clear, concise, and unambiguous instructions. Such words, though polite, can potentially dilute the imperative nature of the instructions and lead to variability in how users interpret them.
3. **Active Voice:** Prefer active voice over passive voice. For example, "Click the button" instead of "The button should be clicked." This makes instructions clearer and more engaging.
4. **Consistent Terminology:** Use the same terms consistently throughout the manual. Changing terms for the same concept can confuse readers.
5. **Positive Tone:** Use a positive, helpful tone. Focus on what the user can do, rather than what they cannot.
6. **Clear Definitions:** When introducing new terms or concepts, define them clearly at their first mention.
7. **Second Person Narrative:** Use the second person ("you") to address the reader directly. This makes instructions more personal and easier to follow.
8. **Brevity and Precision:** Be brief but precise. Provide enough information to guide the user without overwhelming them with unnecessary details.
9. **Use of Visuals:** Accompany text with visuals where possible. This includes diagrams, screenshots, or icons to aid understanding. Do not reference the visuals as “Picture 1” or “Fig 1”, but structure the content to be always followed by an image to have a consistent natural flow. **Note:** much of the current documentation does use Figure references. This will be phased out as documentation is updated and should not be used on new content.
10. **Avoid Ambiguity:** Ensure that instructions and descriptions are unambiguous. Avoid leaving room for misinterpretation.

### Naming and Formatting Conventions

1. Use full form of the CivicTheme product: CivicTheme
2. Use capitalised form of component name: Accordion, Accordion panel, Manual list
3. Use inline code for values: `Light`, `Dark`, `Top`, `Both`, `Expanded`

### Visuals

1. **Make screenshots of the UI while being logged in as a role that can have access to the feature. DO NOT IGNORE THIS or users will be extremely confused.**
2. Make screenshots of Admin UI using default Drupal theme Claro.
3. Do not include administrative elements like the top Admin Menu bar as this may not be installed on the consumer sites. Use navigation through pages instead.
4. Do not include screenshots of Admin UI pointing to the fields with numbered arrows and then referencing those numbers in text. Instead, use the text provided in the screenshot to reference elements - this will force to have smaller and more precise screenshots that users will find it navigate easier.
5. Make screenshots of the CivicTheme components front-end using only default colour scheme (that is the scheme of <https://default.civictheme.io/>). Using other colours schemes will confuse users.

### Examples

[Generic page example](/development/maintenance/authoring-documentation/generic-page-example)

[Content component page example](/development/maintenance/authoring-documentation/content-component-page-example)


# Generic page example

{% hint style="info" %}
This page provides an example of the generic documentation page for **Topics** vocabulary.

Text within square brackets \[like this one] should be considered a comment for an author and should not be included into a final page.\
\
This note and other notes of this colour would be removed in the real page.
{% endhint %}

***

## Topics

{% hint style="info" %}

* Do not create the "Summary" heading
* Describe the capabilities of the feature this pages is about. This is to explain what it can do.
* Describe examples of how it can be helpful. This is to explain how it can be applied as some people need examples to understand the application of a feature.
  {% endhint %}

Topics are generally used to group information by topic or subject. Out-of-the-box, CivicTheme comes with several topics set up - you just need to edit them to the topics you'd like.

### Managing Topics

{% hint style="info" %}

1. Describe what role a user should have in order to use the feature.
2. Describe the steps to add or modify a feature: provide screenshots on how to choose the component
3. Do not provide descriptions of the fields that already have an obvious descriptions - these are superfluous and only repeat what is already provided in the UI without adding much value. Also, this adds to the maintenance cost.
4. Describe what can be done with one or multiple properties *from the point of use*:
   1. Provide a sub-heading
   2. Provide a screenshot of admin + a screenshot of the rendered component
5. For complex features, provide an "Example" sub-section with a full use-case description and screenshots.
   {% endhint %}

You should be logged in as a user with Site administrator role to modify topics.

1. Navigate to the Administration → Structure → Vocabularies → Topics
2. Click on “Add” or “Edit” term.
3. Provide Topic details
4. Click “Save” to save changes.

### Using Topics

Topics can be used within Automated list content component group information.

Below you can see an example of three News card showing three different topics - Scholarships, International students, and Research within an Automated list.

\[screenshot of the usage of the here]

See Automated list component page for more details.


# Content component page example

{% hint style="info" %}
This page provides an example of the documentation page for an Accordion **component**.

Components in a context of this documentation page are ONLY those UI Kit components that can be added to the Page (or other) content types. Global elements of the site (Header, Footer etc.) use another documentation page template.

Text within square brackets \[like this one] should be considered a comment for an author and should not be included into a final page.\
\
This note and other notes of this colour would be removed in the real page.
{% endhint %}

***

## Accordion

{% hint style="info" %}

* Do not create the "Summary" heading
* Describe the capabilities of the component. This is to explain what it can do.
* Describe examples of how it can be helpful. This is to explain how it can be applied as some people need examples to understand the application of a component.
  {% endhint %}

The Accordion component provides a space-efficient way to display content in collapsible sections.\
This is ideal for FAQs, instructional content, and for reducing page length.

### Using component

{% hint style="info" %}

1. Describe the steps to add a component: provide screenshots on how to choose the component
2. Describe what can be done with one or multiple properties *from the point of use*:
   1. Provide a sub-heading
   2. Provide a screenshot of admin + a screenshot of the rendered component
3. For complex components, provide an "Example" sub-section with a full use-case description and screenshots:
   1. Navigate to the content type add/edit page
   2. Click on Components->Add Accordion button
   3. Add Accordion panels and modify properties.
      {% endhint %}

The "Title" will appear as a text on the collapsed Accordion panel header.

The "Content" will appear and the content area of the Accordion panel. If the Accordion is not set to be expanded, the content will be hidden initially.

#### Expanding Accordion panels

By default, Accordion panels are collapsed. To expand any Accordion panel, check the "Expanded" checkbox.\
\[screenshot of admin UI here]

This will result in accordion looking like this \[need to update this phrase]\
\[screenshot of FE UI here]

To expand all panels, check the "Expand all" checkbox. This will override the values set in "Expanded" checkbox for each Accordion panel.

### Styling

{% hint style="info" %}
This sub section should be as much generic as possible so it can be copy/pasted for many components with ease as many components have the same properties. we do not need to provide screenshots
{% endhint %}

#### Theme

Every component in CivicTheme, such as the \["Content"] component, can be shown as a `Light` or `Dark` theme component variant. This allows you to build more engaging landing pages with a mix of light and dark components. Use "Theme" radio button selector to change between themes.

#### Vertical spacing

Vertical spacing adds space before, after or both before and after a component. It is used to visually separate a component from other components when they are vertically stacked on the page. Use "Vertical spacing" dropdown to chose the appropriate values.

You may need to adjust the vertical spacing on adjacent components to create visual balance.

#### Background

Setting a background on a component can make the component visually stand-out on the page. Check the "Background" checkbox to apply a background to the component.

\[Note: not all components have a background, in the case where the Theme sets the background colour of the component. In these cases do not include this section]

### Configuring

{% hint style="info" %}

1. This section exits only on components that have configuration in the theme settings.
2. Describe the path to the configuration location as an intro paragraph. Try to make this as much generic as possible.
3. Describe the steps to perform such configuration with screenshots of the the admin changes + screenshot of front-end result\
   \
   \&#xNAN;*The Accordion component does not have any settings, so the example below will use Promo card component settings as an example.*
   {% endhint %}

The component can be configured on the theme settings page located at `/admin/appearance/settings/<site-name>`. You would need to be logged in as a user with a Site administrator role in order to making such changes.

#### Summary length

The Summary length setting allows to set the length of the content shown as the summary on the card. For cases when the card is used to display the referenced content with large amount of content, the automated summary length trimming to a pre-set length can help to avoid cards of the large size.

When the length is set, the content will be trimmed to the set length of characters and an ellipsis (…) will be added to the end of the text

On the theme settings page:

1. Scroll down to the 'Components' section and select the Promo card.
2. Enter the number of characters to trim into the Summary length field or enter 0 to disable this f
3. Press Save configuration

\[screenshot of the admin form with the Promo card tab selected]


# Code of conduct

The CivicTheme Code of conduct promotes a respectful, inclusive environment for all contributors. It outlines acceptable behaviour, participation guidelines, and steps for addressing conflicts.

### CivicTheme code of conduct

We ask that all members of our community, in any space (virtual or physical), adhere to this Code of Conduct, promoting understanding, empathy, and personal awareness of all individuals, including those from the Drupal and greater technical communities, even when disagreements arise.

***

### **Our pledge**

We pledge to create a welcoming, harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, experience level, nationality, personal appearance, race, religion, or sexual identity and orientation.

***

### **Our standards**

**Positive behaviours:**

* Use welcoming and inclusive language.
* Be respectful of differing viewpoints and experiences.
* Accept constructive criticism gracefully.
* Focus on what benefits the community.
* Show empathy towards others.

**Unacceptable behaviours:**

* Sexualised language or imagery, and unwelcome advances.
* Trolling, insulting, or derogatory comments.
* Personal or political attacks.
* Harassment, public or private.
* Publishing others’ private information without permission.
* Conduct inappropriate in a professional setting.

***

### **Participation guidelines**

* **Listen and engage actively**: Read the conversation backlog before joining. Assume good intent, as participants come from diverse backgrounds.
* **Promote understanding and empathy**: Engage with others respectfully, especially those you may disagree with. Strive to increase personal awareness of diverse perspectives.
* **Respect other experiences**: Speak from your experience, not for others. Don’t invalidate someone’s story.
* **Challenge ideas, not people**: Ask questions and focus on the ideas being discussed without personal attacks.
* **Inclusive language**: Use stated names and pronouns, and respect others' identities. If unsure, ask respectfully in private.
* **Lurkers welcome**: Participation is valued, even if just observing. Introduce yourself when joining.

***

### **Handling off-topic discussions and sharing**

* **Stay on topic**: Avoid spamming, thread hijacking, or excessive off-topic conversation, especially during meetings.
* **Sharing content**: Do not share CivicTheme content without explicit permission from all participants involved.
* **Reporting issues**: Screenshots for harassment reporting are allowed without permission, but avoid using them to shame others.

***

### **Conflict and disruptive behaviour management**

* **Address conflicts directly**: Where safe, address issues in the space where they arise, or contact an admin for help.
* **Admin support**: Admins or Community Managers can help when conflicts escalate.
* **Tiered response system for disruptive behaviour**:
  * **Tier 1**: User is welcomed, asked to review participation guidelines, and read the backlog.
  * **Tier 2**: User is gently reminded to stay on topic or follow participation guidelines.
  * **Tier 3**: Moderator privately messages the user, explaining the issue and offering suggestions for improvement.
  * **Tier 4**: If behaviour persists, the user is kicked from Slack for at least 24 hours.
* **Non-tiered response (immediate ban)**: Intentionally disruptive users, engaging in bullying or harassment, may be kicked without following the tiered process. Repeated offenses will result in a permanent ban.
* **Re-admittance after kick**: Users kicked from Slack can message the moderator or another admin to request re-admittance. The kick is not a ban, and disruptive individuals can receive guidance on improving their behaviour and using more inclusive, sensitive language.

***

### **Our responsibilities**

Project maintainers are responsible for enforcing this code of conduct. They may remove, edit, or reject contributions or ban contributors for inappropriate behaviour.

***

### **Scope**

This code of conduct applies within project spaces and in public spaces where a community member represents CivicTheme (e.g., official emails or social media).

***

### **Enforcement**

Instances of unacceptable behaviour may be reported by contacting the team at <info@civictheme.io>. The team will review and investigate all complaints confidentially.

***

### **Attribution**

This code of conduct is adapted from the Contributor Covenant, version 1.4, Drupal Diversity & Inclusion’s Participation Guidelines, and CivicTheme community input.

***

## Feedback

If you have feedback or questions about our code of conduct, please join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via <info@civictheme.io>!


# Contribution model

This is the central guide on how to contribute to CivicTheme, be it code or design.

Contributing to CivicTheme follows a clear process to ensure that all additions meet community and technical standards. This guide will help you understand the various levels of contributions—small, medium, and major—along with the associated requirements and steps for each.

## Overview of the contribution process

Before you start contributing to CivicTheme, review our contribution model. This model shows you how to consider your contributions so that they can be routed and managed properly.

CivicTheme welcomes contributions in various forms, from small enhancements to more complex components. The process is designed to assess whether an existing component fulfils the needs, or if a new contribution is necessary. Contributions are categorised into three levels:

* [Small contribution](#light-contribution)
* [Medium contribution](#medium-contribution)
* [Major contribution](#heavy-contribution)

This document outlines each level of contribution and provides guidance on how to determine the most appropriate level for your proposed changes.

<div data-full-width="true"><figure><img src="/files/u46TJhoUWiaf37vLyxI0" alt="A decision tree diagram helping contributors determine which level of contribution is appropriate for them."><figcaption><p>Contribution model diagram. Click on the image to zoom in.</p></figcaption></figure></div>

***

## Small contribution

A small contribution typically involves minimal changes, such as small adjustments to existing components or minor bug fixes. This type of contribution is most often used when:

* A solution already exists in the component library.
* The existing component can be easily extended with minimal code changes.

### What we need from you:

* **Minimal documentation**: Provide a brief description of the change, what it fixes or improves, and any references to related issues. User guides will be updated, including compliance, security, or research sections.
* **Testing**: Ensure your changes do not break existing functionality. Provide tests or manual testing instructions, and ensure you've thoroughly tested prior to submitting.
* **Code quality**: Maintain consistent code style with the existing CivicTheme codebase.

#### When to propose a small contribution:

* If a component or solution already exists and only minor tweaks are needed.
* If the functionality of a component is extended without affecting its broader use.

#### Example small contributions:

* Fixing a CSS alignment issue on an existing button.
* Adding a small utility class to a component for accessibility.

#### How to submit:

* Follow the basic contribution guidelines and submit your pull request (PR) via [GitHub](https://github.com/civictheme).
* Reference related issues or discussions if applicable.

{% hint style="info" %}
Link: [Small contribution spec template](#light-contribution)
{% endhint %}

***

## Medium contribution

A medium contribution is necessary when your proposed changes require extending an existing component or creating a new feature that addresses a specific need but does not yet have a broader application.

### What we need from you:

* **Documentation**: Provide a detailed explanation of the contribution, including use cases, and reference designs or discussions.
* **Testing**: Provide thorough test cases to ensure the contribution works in all expected environments, ensuring you've tested your changes prior to submitting.
* **Broader Use**: Clarify if the new feature can evolve for wider usage across the CivicTheme system.

#### When to propose a medium contribution:

* If the existing component cannot be extended easily and requires more significant changes.
* If others can potentially reuse the new feature, but it is initially being built for a specific purpose.

#### Example medium contributions:

* Adding a new input field type to the form component with validation.
* Creating a new, reusable layout option for a specific website section.

#### How to submit:

* Provide more detailed documentation in the PR, explaining the purpose and broader application possibilities.
* Ensure full test coverage and reference any designs or issues.
* Submit via [GitHub](https://github.com/civictheme) with a link to the related issue or proposal.

{% hint style="info" %}
Link: [Medium contribution spec template](/contributing/medium-contribution-spec)
{% endhint %}

***

## Major contribution (RFC process)

Major contributions involve significant changes to CivicTheme, such as new components, removing existing features, or altering fundamental design principles. These changes require broader community discussion and approval through the [**RFC process**](#user-content-fn-1)[^1].

**When to use the RFC process for major contributions:**

* Introducing new components or patterns.
* Adding new API surface areas or modifying major existing APIs.
* Removing features already released.
* Creating new conventions or design principles.

### What we need from you:

* **Comprehensive documentation**: A detailed breakdown of the problem, proposed solution, and how the contribution fits into the broader CivicTheme structure. Include mockups, wireframes, or other design assets if applicable.
* **Broader use**: Ensure the new component is designed with reuse in mind, following design principles that support various use cases across the system.
* **Extensive testing**: Rigorous testing in various environments and edge cases is required to ensure the component is robust and can be maintained. Please provide test cases that reviewers can test as well.

#### When to propose a major contribution:

* If there is no existing component or solution that can be easily extended or adapted.
* If the new component is expected to be used broadly across different applications or sites.

#### Example major contributions:

* Creating an entirely new navigation component for CivicTheme.
* Proposing a large design system change that requires updates to multiple components.

#### How to submit:

* Open a discussion in the CivicTheme community forums, Drupal.org, or GitHub discussions to gather feedback before coding begins.
* Submit a detailed proposal and follow the community approval process.
* Once approved, develop the contribution, ensuring thorough documentation and testing before submitting a PR on [GitHub](https://github.com/civictheme).

{% hint style="info" %}
Link: [Major contribution spec template](/contributing/major-rfc-level-contribution-spec)
{% endhint %}

***

## Hardcoding vs contributing

In some cases, a solution may only be applicable to a single website or application. In such instances, hardcoding the solution directly may be more efficient than contributing a reusable component. However, whenever possible, contributions should aim for reusability within the broader CivicTheme ecosystem.

#### When to hardcode:

* When a solution is too specific to be reused across other projects or cannot be made generic.

#### Example:

* Adding a one-off feature or custom styling for a single website section that does not fit CivicTheme's broader design principles.

***

By following this guide, you can ensure your contributions to CivicTheme are aligned with the project's goals and community standards. Contributions, whether small or large, help improve the system and provide value to all CivicTheme users.

Ensure you follow the appropriate process based on the type of contribution you're making and provide all necessary documentation and testing before submitting your work.

***

## Contribution FAQs

<details>

<summary>What happens if I find an issue?</summary>

We're always interested in fixing issues, therefore issue reports are very welcome. Please make sure to check that your issue does not already exist in the relevant issue queue, be it for design, UI Kit, or Drupal.

</details>

<details>

<summary>What do I do with a feature request or idea I have?</summary>

First, review the [contribution model diagram](#overview-of-the-contribution-process) at the top of this page. Establish which type of contribution your concept is closest to, and create an [issue](https://github.com/civictheme/monorepo-drupal/issues) with the associated level of documentation needed and we will review it.

We can't guarantee that it will be implemented. But we are always interested in hearing ideas of what we could bring to CivicTheme.

Another good way is also to talk to us via [#civictheme-designsystem](https://drupal.slack.com/archives/C039UV0CQBZ) Slack about your idea. [Join today](https://drupal.slack.com/archives/C039UV0CQBZ)!

</details>

<details>

<summary>I've got code to contribute, what should I do?</summary>

Refer to the [contribution model diagram](#overview-of-the-contribution-process) above to classify what sort of contribution you have in order to understand what process to follow.

</details>

<details>

<summary>What kinds of contributions can I make?</summary>

You can contribute in a variety of ways, including:

* Reporting bugs or issues with existing components.
* Suggesting improvements to existing components.
* Submitting new components or templates.
* Proposing changes to documentation.
* Participating in design or development discussions.
* Testing existing or new components and providing feedback.

</details>

<details>

<summary>How do I know what sort of contribution I have to make?</summary>

Review the diagram at the top of the [page](#overview-of-the-contribution-process), or read below for a summary.

* **Small contributions** involve small changes, like bug fixes, minor design tweaks, or improvements to an existing component.
* **Medium contributions** extend existing components or create new features with moderate complexity and potential for reuse.
* **Major contributions** involve major changes, such as creating new, reusable components, altering the design system, or introducing new design principles. These contributions often have broader implications and may require more review and discussion through the RFC process.

</details>

<details>

<summary>How do I start contributing if I've never contributed to an open-source project before?</summary>

Start by checking the CivicTheme documentation and the contribution guide [here](https://github.com/civictheme/docs/blob/main/contributing/broken-reference/README.md).

Look for "good first issue" or "beginner-friendly" tags in the [GitHub repository](https://github.com/civictheme). These tags mark tasks that are great for new contributors. You can also start by reviewing and testing other people's contributions to get familiar with the project.

Be sure to chat with the friendly team and community in our [Slack channel](https://drupal.slack.com/archives/C039UV0CQBZ) if you have any issues!

</details>

<details>

<summary>What tools or software do I need to contribute?</summary>

For most contributions, you’ll need:

* **GitHub account**: To create issues, submit pull requests, and participate in discussions.
* **Figma**: For design-related contributions (a free tier account is available).
* **Local development environment**: If you're contributing to the codebase, you’ll need to clone the CivicTheme repository and set up the project on your local machine. A tool like VSCode is sufficient.

</details>

<details>

<summary>What if my contribution is rejected?</summary>

Don’t worry—this is common in open-source projects. If your contribution is not accepted, the CivicTheme team will usually provide feedback on why and offer guidance on how to improve it. You can refine your contribution based on the feedback and resubmit it.

</details>

<details>

<summary>How long does it take for my contribution to be reviewed?</summary>

The review process can vary depending on the size and complexity of your contribution. For **small contributions**, reviews are typically quicker, while **medium** or **major contributions** might take longer due to the need for more in-depth discussion and testing. The team will notify you if they need additional information or if there are delays.

</details>

<details>

<summary>How does the RFC process work for CivicTheme?</summary>

The RFC (Request for Comments) process is used for more substantial changes to CivicTheme. When you want to propose a new feature or significant change, you create an RFC issue on GitHub. The community and core team will review the proposal, offer feedback, and once consensus is reached, the feature may be implemented. The RFC process allows for broader discussions and ensures that new features align with CivicTheme’s overall goals.

</details>

***

## Feedback

We're always looking at ways to improve our model for contributions, and rely on your feedback to ensure an enjoyable contribution experience. The best way to give us feedback is to join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via [email](mailto:support@civictheme.io)!

[^1]: An **RFC (Request for Comments)** is a formal process for proposing major changes to CivicTheme. It allows for discussion and feedback from the community and core team before implementing significant features or updates.


# Contribution basics

This page outlines the basics for getting started with your contribution

When you’re ready to start contributing, follow CivicTheme's **contribution model** to ensure your work aligns with the standards for small, medium, or major contributions. Create a new branch to isolate your work:

```bash
git checkout -b feature/your-feature-name
```

* **Small contributions**: Small fixes, minor design tweaks, or documentation improvements.
* **Medium contributions**: Adding new features or extending components.
* **Major contributions**: Major changes requiring the RFC process.

Regardless of the contribution type, be sure to:

* Write **clean, modular code** that is easy to maintain.
* Follow **established design patterns** to ensure consistency with existing components.
* Prioritize **accessibility** and **usability** in your changes to meet CivicTheme’s government-grade standards.

***

### Viewing your changes

While developing, you can view your changes in real-time with the development server running:

```bash
npm run dev
```

Make sure to:

* Test your changes across multiple **devices** and **browsers**.
* Ensure that the new feature or bug fix works for both **desktop and mobile** experiences.
* Verify that your changes are **responsive** and maintain the same level of accessibility.

***

#### Commit and push your changes

Once you’ve completed your contribution and confirmed everything works as expected, commit your changes:

```bash
git add .
git commit -m "Add new button component with hover state"
```

Use descriptive commit messages to make it easy for others to understand the purpose of your changes. Then, push your branch to your GitHub repository:

```bash
git push origin feature/your-feature-name
```

***

### Creating a pull request (PR)

After pushing your branch, create a **pull request (PR)** on GitHub to submit your contribution. This will initiate the review process.

1. Navigate to the CivicTheme repository and click **new rull request**.
2. **Title** your PR clearly to describe what it addresses.
3. **Link any related issues** (e.g., "Fixes #123") to provide context.
4. **Describe the changes** in detail, explaining what was changed and why.
5. **Include screenshots or examples** if applicable, especially for design-related changes.

Once submitted, the CivicTheme core team will review your PR.

***

### Code review and feedback

Your PR will go through a review process, during which CivicTheme maintainers and contributors will provide feedback or suggestions. Be prepared to:

* **Address requested changes** promptly by making updates to your branch.
* Ensure you **re-test** after making changes to avoid breaking existing functionality.
* Be open to feedback and discussions to improve the quality of the contribution.

Once all feedback is addressed and tests are passing, your contribution will be merged into the main project.

***

### Stay updated

It’s important to keep your fork in sync with the latest updates from the CivicTheme repository to avoid conflicts and ensure you’re working with the most up-to-date code.

To pull the latest changes from upstream:

```bash
git fetch upstream
git merge upstream/main
```

Resolve any conflicts that may arise and push the updated branch back to your repository.

***

### Contributing further

CivicTheme encourages continuous contributions. Whether it’s adding new features, fixing issues, or improving documentation, your input helps the community grow. Regular contributions not only enhance CivicTheme but also give you the opportunity to:

* Build your skills.
* Learn from experienced developers and designers.
* Grow within the CivicTheme community.

***

### Summary of key commands

| **Action**                        | **Command**                                                 |
| --------------------------------- | ----------------------------------------------------------- |
| Clone the repository              | `git clone https://github.com/your-username/civictheme.git` |
| Install dependencies              | `npm install`                                               |
| Create a new branch               | `git checkout -b feature/your-feature-name`                 |
| Start the development server      | `npm run dev`                                               |
| Run tests                         | `npm test`                                                  |
| Commit your changes               | `git add . && git commit -m "commit message"`               |
| Push your branch                  | `git push origin feature/your-feature-name`                 |
| Pull latest changes from upstream | `git fetch upstream && git merge upstream/main`             |

***

## Feedback

We're always looking at ways to improve our documentation for contributions and rely on your feedback to ensure an enjoyable contribution experience. The best way to give us feedback is to join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via [email](mailto:support@civictheme.io)!


# Small contribution spec

The following page outlines the process of a light contribution to CivicTheme.

### Component overview

<table data-full-width="false"><thead><tr><th width="411">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Component name</strong></td><td>[Insert component name]</td></tr><tr><td><strong>Type</strong></td><td>[Atom, Molecule, Organism, etc.]</td></tr><tr><td><strong>Intended purpose</strong></td><td>Short description of the purpose of the component (e.g., "To ensure proper alignment of text in mobile views.")</td></tr><tr><td><strong>Primary use case</strong></td><td>[Describe the primary scenario where this component is used.]</td></tr><tr><td><strong>Secondary use case</strong></td><td>[Optional, additional scenarios where it could be applied.]</td></tr></tbody></table>

### Existing patterns/components

<table data-full-width="false"><thead><tr><th width="410">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Do any existing patterns fulfill this need?</strong></td><td>[Yes/No. If yes, reference the relevant pattern.]</td></tr></tbody></table>

### Interactions and behaviours

<table data-full-width="false"><thead><tr><th width="409">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Intended user interactions</strong></td><td>[Describe basic interactions (e.g., "Button click changes state.")]</td></tr><tr><td><strong>Expected component behaviour</strong></td><td>[Define behaviour under different conditions (e.g., responsive behaviour, error states).]</td></tr></tbody></table>

### Accessibility considerations

<table data-full-width="false"><thead><tr><th width="406">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>WCAG compliance level</strong></td><td>[A, AA]</td></tr><tr><td><strong>Expected component behaviour (accessibility)</strong></td><td>[Describe basic accessibility considerations.]</td></tr><tr><td><strong>Potential accessibility challenges</strong></td><td>[List any accessibility risks, or "None."]</td></tr></tbody></table>

### User research

<table data-full-width="false"><thead><tr><th width="403">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Research completed</strong></td><td>[Optional. Include if any user research has been done.]</td></tr><tr><td><strong>Results</strong></td><td>[Summarise results briefly if available.]</td></tr></tbody></table>

### Security requirements

<table data-full-width="false"><thead><tr><th width="401">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Security considerations</strong></td><td>[Describe any minor security concerns if applicable.]</td></tr><tr><td><strong>Data handling requirements</strong></td><td>[Describe handling of sensitive data, or "None."]</td></tr><tr><td><strong>Privacy concerns</strong></td><td>[Any privacy issues, or "None."]</td></tr></tbody></table>

### Submission details

<table data-full-width="false"><thead><tr><th width="405">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Submitted by</strong></td><td>[Contributor's nName]</td></tr><tr><td><strong>Date</strong></td><td>[Submission date]</td></tr><tr><td><strong>Contact information</strong></td><td>[Name, Email or GitHub username]</td></tr></tbody></table>

***

## Feedback

We're always looking at ways to improve our model for contributions, and rely on your feedback to ensure an enjoyable contribution experience. The best way to give us feedback is to join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via [email](mailto:support@civictheme.io)!


# Medium contribution spec

The following page outlines the process of a medium contribution to CivicTheme.

### Component overview

<table data-full-width="false"><thead><tr><th width="411">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Component name</strong></td><td>[Insert Component Name]</td></tr><tr><td><strong>Type</strong></td><td>[Atom, Molecule, Organism, etc.]</td></tr><tr><td><strong>Intended purpose</strong></td><td>Provide a detailed explanation of the component’s purpose (e.g., "To extend the functionality of the form field component to support file uploads.")</td></tr><tr><td><strong>Primary use case</strong></td><td>[Define primary scenarios.]</td></tr><tr><td><strong>Secondary use case</strong></td><td>[Optional, additional scenarios where it could be applied.]</td></tr></tbody></table>

### Existing patterns/components

<table data-full-width="false"><thead><tr><th width="410">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Do any existing patterns fulfill this need?</strong></td><td>[Yes/No. If yes, reference the relevant pattern.]</td></tr></tbody></table>

### References and inspiration

<table><thead><tr><th width="410">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Description of component</strong></td><td>[Provide background on how the component was conceived.]</td></tr><tr><td><strong>References/inspiration sources</strong></td><td>[Provide links or files (e.g., Figma, mockups).]</td></tr></tbody></table>

### Interactions and behaviours

<table data-full-width="false"><thead><tr><th width="409">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Intended user interactions</strong></td><td>[Describe expected interactions (e.g., "Multi-step form progress displayed dynamically.")]</td></tr><tr><td><strong>Expected component behaviour</strong></td><td>[Define behaviour in various contexts (e.g., loading states, user errors).]</td></tr></tbody></table>

### Accessibility considerations

<table data-full-width="false"><thead><tr><th width="406">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>WCAG compliance level</strong></td><td>[A, AA]</td></tr><tr><td><strong>Expected component behaviour (accessibility)</strong></td><td>[Outline required accessible interactions and considerations.]</td></tr><tr><td><strong>Potential accessibility challenges</strong></td><td>[List known challenges or risks.]</td></tr></tbody></table>

### User research

<table data-full-width="false"><thead><tr><th width="403">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Research completed</strong></td><td>[Provide key research insights. If possible, show how these insights influenced the component.]</td></tr><tr><td><strong>Results</strong></td><td>[Link to additional resources, if any.]</td></tr></tbody></table>

### Security requirements

<table data-full-width="false"><thead><tr><th width="401">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Security considerations</strong></td><td>[List any potential risks, such as user input or data handling.]</td></tr><tr><td><strong>Data handling requirements</strong></td><td>[Describe if the component interacts with user data.]</td></tr><tr><td><strong>Privacy concerns</strong></td><td>[List any privacy risks, if applicable.]</td></tr></tbody></table>

### Technical considerations

| Field                                     | Description                                                                         |
| ----------------------------------------- | ----------------------------------------------------------------------------------- |
| **Required technology/framework support** | \[e.g., Drupal, React, Vue.js]                                                      |
| **Known component dependencies**          | \[List dependencies, if any.]                                                       |
| **Performance expectations**              | \[Specify performance goals or requirements (e.g., loading speed, responsiveness).] |

### Submission details

<table data-full-width="false"><thead><tr><th width="405">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Submitted by</strong></td><td>[Contributor's name]</td></tr><tr><td><strong>Date</strong></td><td>[Submission date]</td></tr><tr><td><strong>Contact information</strong></td><td>[Name, email or GitHub username]</td></tr></tbody></table>

***

## Feedback

We're always looking at ways to improve our model for contributions, and rely on your feedback to ensure an enjoyable contribution experience. The best way to give us feedback is to join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via [email](mailto:support@civictheme.io)!


# Major (RFC-level) contribution spec

The following page outlines the process of a major contribution to CivicTheme.

{% hint style="info" %}
**RFC process**

If you're proposing a major feature or substantial change to CivicTheme, your contribution must go through the **RFC (Request for Comments)** process. This helps the core team and community discuss and refine your idea early before implementation.

**Steps for major contributions:**

1. **Create an RFC**: Submit a GitHub issue outlining the proposed change using the below contribution specification.
2. **Get approval**: The CivicTheme core team will review and approve or provide feedback.
3. **Implement the feature**: Work with the community or team to build and submit the change.
4. **Final review**: The core team will review the implementation for final acceptance.
   {% endhint %}

### Component overview

<table data-full-width="false"><thead><tr><th width="411">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Component name</strong></td><td>[Insert component name]</td></tr><tr><td><strong>Type</strong></td><td>[Atom, Molecule, Organism, etc.]</td></tr><tr><td><strong>Intended purpose</strong></td><td>Comprehensive explanation of the component’s purpose and its role within CivicTheme.</td></tr><tr><td><strong>Primary use case</strong></td><td>[Define primary scenarios for its use.]</td></tr><tr><td><strong>Secondary use case</strong></td><td>[List other potential uses.]</td></tr></tbody></table>

### Existing patterns/components

<table data-full-width="false"><thead><tr><th width="410">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Do any existing patterns fulfil this need?</strong></td><td>[Yes/No. If yes, reference relevant patterns and explain why they do not suffice.]</td></tr></tbody></table>

### References and inspiration

<table><thead><tr><th width="410">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Description of component</strong></td><td>[Detailed background on the inspiration and rationale for the component.]</td></tr><tr><td><strong>References/inspiration sources</strong></td><td>[Provide links, files, mockups, or relevant research documents.]</td></tr></tbody></table>

### Interactions and behaviours

<table data-full-width="false"><thead><tr><th width="409">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Intended user interactions</strong></td><td>[Describe all user interactions and how they affect the component.]</td></tr><tr><td><strong>Expected component behaviour</strong></td><td>[Detail how the component should behave in different scenarios (e.g., error handling, loading states).]</td></tr></tbody></table>

### Accessibility considerations

<table data-full-width="false"><thead><tr><th width="406">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>WCAG compliance level</strong></td><td>[A, AA]</td></tr><tr><td><strong>Expected component behaviour (Accessibility)</strong></td><td>[Describe how the component supports accessible interactions.]</td></tr><tr><td><strong>Potential accessibility challenges</strong></td><td>[List challenges that might arise from complex interactions.]</td></tr></tbody></table>

### User research

<table data-full-width="false"><thead><tr><th width="403">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Research completed</strong></td><td>[Provide key findings from multiple research rounds.]</td></tr><tr><td><strong>Results</strong></td><td>[Link to more comprehensive research documentation.]</td></tr></tbody></table>

### Security requirements

<table data-full-width="false"><thead><tr><th width="401">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Security considerations</strong></td><td>[Detail any security vulnerabilities the component might introduce.]</td></tr><tr><td><strong>Data handling requirements</strong></td><td>[Describe how the component manages data securely.]</td></tr><tr><td><strong>Privacy concerns</strong></td><td>[Address any privacy concerns tied to user data.]</td></tr></tbody></table>

### Technical considerations

| Field                                     | Description                                                                                          |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| **Required technology/framework support** | \[e.g., Drupal, React, Vue.js]                                                                       |
| **Known component dependencies**          | \[List all dependencies, including external libraries.]                                              |
| **Performance expectations**              | \[Provide expected benchmarks, including performance for large datasets, animation efficiency, etc.] |

### Submission details

<table data-full-width="false"><thead><tr><th width="405">Field</th><th>Description</th></tr></thead><tbody><tr><td><strong>Submitted By</strong></td><td>[Contributor's name]</td></tr><tr><td><strong>Date</strong></td><td>[Submission date]</td></tr><tr><td><strong>Contact Information</strong></td><td>[Name, Email or GitHub username]</td></tr></tbody></table>

***

## Feedback

We're always looking at ways to improve our model for contributions and rely on your feedback to ensure an enjoyable contribution experience. The best way to give us feedback is to join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via [email](mailto:support@civictheme.io)!


# Figma contributions

This page outlines the process for contributing to the CivicTheme Figma UI Kit.

<figure><img src="/files/nnOkvmhN2xDWUxJsrhOM" alt=""><figcaption></figcaption></figure>

## Contributing in Figma

{% hint style="info" %}
See the latest Figma file: [CivicTheme v1.13 Figma](https://www.figma.com/design/dPfjcko7zOM1nfOxEsFzrE/CivicTheme--Design-System-v1.13--WIP-?node-id=1009-19330\&p=f\&t=FMemctIs1Jfb5xHE-0)
{% endhint %}

### Contribution criteria

The CivicTheme atomic design system is built on a set of UI building blocks. All of the CivicTheme components, patterns, icons and solutions are:

* Compliant with Australian Government design system
* Built with WCAG 2.2 AA compliance in mind to meet accessibility standards
* Adaptable with GovCMS Drupal 10 out-of-the box
* Responsive

Consider the criteria below before submitting your contribution for consideration: 

* **Purpose:** New designs should address specific needs, enhance user experience, and add value. They should either extend existing patterns or create new ones.
* **User researched and tested:** Your contribution should be backed by user research and testing.
* **Accessibility tested:** Your design should meet WCAG 2.2 AA accessibility standards or higher.
* **Atomic design:** Contributions should comply with atomic design principles to maintain consistency and modularity whilst aligning to existing design direction.

***

### How to contribute

Once you've established the type of contribution you wish to make, submit your design idea via GitHub to ensure transparency and community discussion.

1. **Create a** [**GitHub**](https://www.github.com) **account** (if you don’t have one).
2. **Go to the** [**CivicTheme UI Kit Project**](https://github.com/orgs/civictheme/projects/1/views/1) and check for existing issues related to your idea.
3. If your idea isn't listed, [**create a new issue**](https://github.com/civictheme/uikit/issues), using the relevant specification, and we’ll review it.

### Contribution formats

Ideally, design contributions should be supplied as fully realised Figma files and submitted via GitHub; however, we know this is not always possible, so there are other options.

With that in mind, the CivicTheme team will consider contributions in many formats:

* **Figma file**: A copy of the full CivicTheme Figma file, or a stand-alone file that we can merge into the main file.
* **Illustration file**: If you are adding illustrations or iconography to the UI kit, please provide an illustration file (.svg, .png, or .jpg).
* **Wireframe or sketches**: This can be a photo of that napkin you sketched your ideas on when inspiration hit.

***

### Working with Figma

If you’re working with a copy of the CivicTheme Figma file, once you’ve finished making changes, you need to export the file in <mark style="color:blue;">.fig</mark> format. To do this, go to "File" and select "Save as .fig." This will save the file on your local drive.

When saving the file, please use the prefix <mark style="color:blue;">CivicTheme\_Design\_</mark> then add your name to the end of the file name as shown below.

**Example**: CivicTheme\_Design\_\[<mark style="color:blue;">YourName</mark>].fig

***

### Submitting your design contributions

**Submitting via GitHub:**

1. **Select contribution type**:
   * If it’s a **small contribution**, such as minor tweaks or updates, select "Bug" or "Minor enhancement" as the issue type.
   * For **medium or major contributions**, select "Feature request."
2. **Title**:
   * Include "Design contribution" in the title, along with the specific focus of your contribution. For example:
     * *“Design contribution - Template - Homepage - Mobile”* or,
     * *“Design contribution - Navigation component - Desktop”*
3. **User story**:
   * Fill out the "User Story" section in the issue template to describe the context and reasoning for your contribution. Be clear about the **problem** you're addressing and the **proposed solution**.
4. **Description**:
   * Provide a **detailed description** of your contribution. Include:
     * **Page and name**: Reference the page and component name from the Figma file where changes have been made. For example:
       * *Page 05 Mobile Templates | Template - Homepage - Mobile*.
     * **Rationale**: Explain the reasoning behind your change. Why is it necessary? How does it improve CivicTheme's design system?
     * **Supporting evidence**: If your contribution is research-backed (e.g., user testing, accessibility standards), provide relevant links or documentation.
     * **Testing**: Indicate whether the change has been tested and provide results if applicable (e.g., design QA, browser/device testing).
5. **Contribution type**:
   * For **small contributions**, provide a brief summary of changes.
   * For **medium contributions**, specify if the component can be reused or extended.
   * For **major contributions**, ensure the description aligns with the broader CivicTheme design principles and can be applied across multiple contexts.

***

## Feedback

We're always looking at ways to improve our model for contributions, and rely on your feedback to ensure an enjoyable contribution experience. The best way to give us feedback is to join our [Slack channel ](https://drupal.slack.com/archives/C039UV0CQBZ)and chat to us there, or contact us via [email](mailto:support@civictheme.io)!


# Component list

See the list of components that CivicTheme supports right now. This list will grow as the community and adoption grows!

## CivicTheme component library

CivicTheme is built using **atomic design principles**, offering a hierarchy of components ranging from foundational styles to complex, reusable patterns. Below, you'll find a complete breakdown of the components, categorised into **Base**, **Atoms**, **Molecules**, and **Organisms**.

For a visual list of our components, please check out the [Figma file](https://www.civictheme.io/figma).

***

### **Base components**

The foundation of CivicTheme includes variables and tokens that ensure consistency in design, enabling scalable, maintainable, and reusable components.

* Colours
* Background
* Elevation
* Fonts
* Grid
* Icon
* Image
* Item list
* Layout
* Spacing

These base elements define the **core design framework**, supporting the styling and layout for all components within CivicTheme.

***

### **Atoms**

Atoms are the simplest, most basic building blocks in CivicTheme. They represent single UI elements and are designed for **high reusability** across various contexts.

* Back to top
* Button
* Chip
* Content link
* Form control
  * Checkbox
  * Field description
  * Field message
  * Fieldset
  * Label
  * Radio
  * Select
  * Textarea
  * Textfield
* Heading
* Link
* Paragraph
* Popover
* Quote
* Table
* Tag
* Text list
* Toggle

***

### **Molecules**

Molecules combine two or more atoms to form **functional UI elements**. These components are slightly more complex and include grouped elements with interactive behaviour.

* Accordion
* Attachment
* Breadcrumb
* Callout
* Event card
* Field
* Figure
* Group filter
* Logo
* Map
* Navigation card
* Next Step
* Pagination
* Price card
* Promo card
* Publication card
* Search
* Service card
* Single filter
* Snippet
* Subject card
* Table of contents
* Tabs
* Tag list
* Tooltip
* Video player

***

### **Organisms**

Organisms are **highly structured, composite components** consisting of multiple atoms and molecules working together. These components define the most complex reusable patterns.

* Alert
* Banner
* Campaign
* Carousel
* Footer
* Header
* **Li**st
* Message
* Mobile navigation
* Navigation
* Promo
* Side navigation
* Skip link
* Slider
* Social lnks

***

### **Why this hierarchy matters**

The clear categorisation of components within CivicTheme supports:

1. **Reusability**: Ensures consistent implementation across various projects.
2. **Maintainability**: Simplifies updates and modifications with minimal disruption.
3. **Scalability**: Easily extendable for new use cases, frameworks, or jurisdictions.

By adhering to atomic design principles, CivicTheme empowers designers and developers to create **accessible, compliant, and scalable** digital experiences for governments globally.

For more details, explore the [Figma File](https://www.civictheme.io/figma).


# Atoms

Atoms are the smallest component in an atomic design system. This page outlines their purpose.

### **What are Atoms?**

In CivicTheme, **atoms** are the smallest, most fundamental building blocks of the design system, based on Brad Frost’s **Atomic Design** principles. These individual elements are simple, self-contained, and non-reducible, forming the foundation of all components. Atoms in CivicTheme include basic HTML elements such as buttons, form inputs, and typography elements, all designed to ensure **accessibility**, **consistency**, and **reusability** across digital services.

***

These atoms are the foundation of CivicTheme, and they combine to form more complex components like molecules and organisms, ensuring a consistent, accessible, and flexible design system across projects. Each atom follows **WCAG 2.2 AA standards** and is optimised for both design and development, with implementations available in [Figma ](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=0-1\&t=b83UZlIpwPkLMi9E-1)and **Storybook**.


# Button

A Button is an interactive element that triggers an action when clicked or tapped, providing a clear call-to-action for users.

Buttons provide users with the ability to submit an action or follow a link to another location.

### When to use

Use the button component when you need users to:

* Submit a form
* Trigger an action like opening a modal, starting a process, or revealing hidden content
* Navigate to another page or section of the site
* Download a file
* Confirm an action or decision

Buttons are appropriate when the action is a key task or primary user journey on the page.

### When not to use

Do not use the button component when:

* The action is of secondary importance on the page - consider using a link instead
* You need to create a link within a paragraph of text - use a text link instead
* You need to create a complex interactive element - consider using a more specialised component
* The action would be better represented by a different component like a dropdown menu, toggle switch, or checkbox

***

### Best practice guidelines

* **Action-oriented labels**: Use clear, concise, and action-oriented text that describes what will happen when the button is clicked (e.g., "Submit application" rather than "Click here")
* **Hierarchy**: Use primary buttons for the most important actions, secondary buttons for alternative options, and tertiary buttons for less important functions
* **Size appropriate to context**: Choose the appropriate button size (large, regular, small) based on the context and importance of the action
* **Consistent placement**: Place buttons consistently throughout the interface to create predictable patterns for users
* **Adequate spacing**: Ensure sufficient space between buttons and other elements to prevent accidental clicks, especially on mobile devices
* **Visual feedback**: Provide clear visual feedback for all interactive states (hover, focus, pressed/active, disabled)
* **Icons with purpose**: If using icons within buttons, ensure they enhance understanding and provide visual reinforcement of the action
* **Accessible colour contrast**: Maintain sufficient colour contrast between the button and its background, as well as between the button text and button background
* **Responsive design**: Ensure buttons work well across all screen sizes and devices

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2871-32604&t=mpeAG9TsCSheJs4e-1>" %}

* **Primary buttons**: Used for the most important actions on a page
* **Secondary buttons**: Used for alternative or secondary actions
* **Tertiary buttons**: Used for less important functions or in space-constrained situations
* **Button sizes**: Available in large, regular, and small options
* **Icon placement**: Options include icons to the right, left, or no icon
* **Button states**: Default, focus, hover, pressed, and disabled
* **Directional variants**: Forward (right arrow), back (left arrow), and external (external link icon)

***

### Accessibility

This component has been assessed against WCAG 2.2 guidelines with detailed test results available in the CivicTheme accessibility documentation.

Summary of the most recent accessibility test results:

<table><thead><tr><th width="256.22265625">WCAG Criterion</th><th width="78.24609375">Level</th><th width="95.73828125">Status</th><th>Notes</th></tr></thead><tbody><tr><td>1.4.3 Contrast (Minimum)</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>1.4.11 Non-text Contrast</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>2.1.1 Keyboard</td><td>A</td><td>Pass</td><td></td></tr><tr><td>2.4.4 Link Purpose (In Context)</td><td>A</td><td>Pass</td><td></td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>2.5.8 Target Size (Minimum)</td><td>AA</td><td>Fail</td><td>The size of targets for pointer inputs does not meet the minimum 24×24 CSS pixel requirement</td></tr><tr><td>3.2.2 On Input</td><td>A</td><td>Pass</td><td></td></tr><tr><td>3.2.3 Consistent Navigation</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>3.2.4 Consistent Identification</td><td>AA</td><td>Pass</td><td></td></tr></tbody></table>

This component meets most accessibility requirements but needs improvement to meet the WCAG 2.2 target size criteria.

### Security

No specific security considerations have been identified for this component beyond standard web security practices.

### Component inspiration and uplift

This component has been modelled after the Buttons component in the former Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* **Size variations**: All CivicTheme buttons come in large, regular and small options. The regular-sized buttons are based on GOLD Design System size guidelines and are intended to be the most commonly used format. The larger-sized button has been included for pages with a single primary goal (e.g., a campaign landing page).
* **Iconography integration**: Each variant of CivicTheme's call to actions includes the option to add appropriate iconography based on their functionality, such as directional arrows for navigation, external link icons for external destinations, and download icons for downloadable content.
* **Enhanced states**: The existing disabled states of the Australian Design System's button have been improved to provide better contrast required for WCAG 2.1 standards, ensuring higher visual hierarchy distinction while maintaining legibility.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by general design pattern research)

While specific user research data conducted by CivicTheme for this component is not available, the button component is one of the most thoroughly researched UI elements across digital platforms. The implementation in CivicTheme follows established patterns that have been validated through extensive industry research.

General research findings consistently show:

* Users expect buttons to look and behave in familiar ways, with clear visual affordances that indicate they can be clicked
* Primary buttons with strong visual styling receive higher engagement rates
* Users prefer buttons with clear, action-oriented labels
* Buttons with appropriate size and spacing reduce error rates, especially on mobile devices

More specific user research for the CivicTheme button component would be beneficial to validate these general findings within the specific context of government websites.

### Known issues

* **Target size compliance**: As noted in the accessibility assessment, the button component does not currently meet WCAG 2.2 criterion 2.5.8 for minimum target size (24x24 CSS pixels), which may impact users with motor control difficulties.
* **Mobile responsiveness**: On very small screens, buttons with lengthy text may break to multiple lines, affecting visual consistency.
* **Icon alignment**: In certain browser and screen size combinations, icon alignment within buttons may shift slightly from the intended design.

### More research needed

Additional research would be beneficial in the following areas:

* User preference and effectiveness of different button sizes across various device types
* Performance of different icon placements (left, right) for specific user tasks
* Optimal button placement for multi-step processes in government service contexts
* Button label effectiveness for government-specific actions and terminology
* Impact of button styling on user trust and confidence when performing critical actions

If you have conducted user research that addresses these areas, you can submit your findings to help improve this component.

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to our button component discussion on GitHub
* Submit your user research findings to help improve the button component
* Propose a change to address the target size accessibility issue
* Suggest improvements to the component documentation

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2871-32604\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* W3C Web Content Accessibility Guidelines (WCAG) 2.2
* Nielsen Norman Group: Button UX Design Best Practices, Types and States
* Australian Government Design System (AGDS) Button Component Guidelines
* Web Accessibility Initiative (WAI) ARIA Authoring Practices

### Changelog

<table><thead><tr><th width="153.56640625">Version</th><th width="156.328125">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Buttons to Button</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated to WCAG 2.2 compliance testing</td></tr><tr><td>1.6.0</td><td>[Date]</td><td>[Changes]</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Chip

The Chip component provides users with a compact, visually distinct element for filtering, categorizing, or selecting information within an interface.

### When to use

Use the Chip component when you need to:

* Allow users to filter search results or content categories
* Show selected options in a multi-select interface
* Display tags or labels that categorise content
* Create a compact interface for selection of multiple options
* Provide visual feedback for active filters or selections

### When not to use

Do not use the Chip component when:

* Users need to take complex actions that require more context or a larger clickable area
* A single selection from multiple options is required (use radio buttons instead)
* The action is a primary action on the page (use buttons instead)
* The selection would be better represented as a checkbox within a form
* Space is extremely limited and text labels would be too truncated to be meaningful

***

### Best practice guidelines

* **Clear labelling**: Keep text in chips concise and descriptive to clearly communicate their purpose and content.
* **Visual distinction**: Ensure chips are visually distinguishable from other interactive elements like buttons through shape, border radius, and other visual attributes.
* **State indication**: Provide clear visual indication of a chip's state (selected, hover, default) through colour and styling.
* **Touch-friendly**: Design chips to be easily tappable on touch devices, following minimum touch target size guidelines.
* **Consistent interaction**: Maintain consistent interaction patterns across chip implementations—if one chip toggles on click, all similar chips should behave the same way.
* **Appropriate spacing**: Include adequate spacing between multiple chips to prevent accidental selection.
* **Responsive design**: Ensure chips adapt appropriately to different screen sizes and device types.
* **Accessibility**: Include appropriate ARIA attributes for chips that act as controls or selections.
* **Group semantically**: Group related chips together visually and semantically in the markup.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3274-61067&t=mpeAG9TsCSheJs4e-1>" %}

* Default
* Hover
* Selected
* Selected Hover

Each variation is available for both desktop and mobile interfaces.

***

### Accessibility

Based on the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Chip component (referred to as "Filter Chip" in the assessments) has undergone accessibility testing against WCAG 2.2 standards.

Summary of the most recent accessibility test results:

<table><thead><tr><th width="299.625">WCAG 2.2 Criteria</th><th width="76.0234375">Status</th><th>Details</th></tr></thead><tbody><tr><td>Most WCAG 2.2 criteria</td><td>Pass</td><td>Including contrast requirements, keyboard accessibility, and proper state indications</td></tr><tr><td>Criterion 2.5.8 Target Size (Minimum) (Level AA)</td><td>Fail</td><td>The size of the target for pointer inputs does not consistently meet the minimum 24 by 24 CSS pixels requirement</td></tr></tbody></table>

For detailed information on compliance, refer to the full accessibility assessment.

### Security

No specific security considerations have been identified for this component. Standard web security practices should be followed when implementing this component.

### Component inspiration and uplift

The Chip atomic element has been modelled after the Tags component in the Australian Government Design System (AGDS). As documented in the CivicTheme Australian Government GOLD Design System Compliance Statements, this component has been uplifted in the following ways:

* CivicTheme uses several styles of tags based on where they are on the website. Chips, specifically, are used within the Filter component, as a method to narrow down the results of an article's categories.
* CivicTheme's Chips are fully-rounded in their appearance and do not use text underlines, instead adopting a button-like appearance.
* Interactive states change in both border and background colours.
* An 'X' (remove) icon appears alongside an active Chip to remove the active filter attribute.

This approach was influenced by Victoria's Ripple design system, which presents Chips with fully-rounded styling to clearly distinguish them from regular buttons and other interactive elements.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Some testing conducted, but findings not comprehensive)

Limited user research has been conducted specifically on the Chip component in CivicTheme. Based on the available information, testing has shown that users generally understand the filtering and selection capabilities of chips, but some usability challenges exist particularly around target size on mobile devices.

This assessment is based on general design research rather than extensive testing with end users for this specific component implementation. More research would be beneficial to improve the component's usability across different contexts.

### Known issues

* **Target size**: As noted in the accessibility assessment, the Chip component fails to meet WCAG 2.2 criterion 2.5.8 for minimum target size, which could impact users with motor control difficulties.
* **Small text truncation**: On mobile devices, longer text in chips may become truncated, potentially obscuring important information.
* **Contrast in selected state**: Some users may have difficulty distinguishing between selected and unselected states if they have colour perception limitations.

### More research needed

Research is needed in the following areas:

* Optimal target sizes for touch interactions across different devices
* Text truncation handling and best practices for longer labels
* User understanding of the 'X' icon for removal and potential alternatives
* Performance across different assistive technologies
* Effectiveness of the current visual design in communicating state changes

If you have conducted user research that addresses any of these gaps, please consider contributing your findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Chip component discussion on GitHub
* Submit your user research findings to help improve the Chip component
* Propose a change to address any of the known issues
* Help improve the component's accessibility, particularly regarding target size

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3274-61067\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* Web Content Accessibility Guidelines (WCAG) 2.2
* Nielsen Norman Group: [Best Practices for Using UI Pattern Libraries](https://www.nngroup.com/articles/ui-pattern-libraries/)
* Australian Government Design System (former AGDS)
* Digital Service Standard (DSS): The component supports criteria 3 "Leave no one behind" by providing accessible filtering mechanisms when properly implemented.

### Changelog

<table><thead><tr><th width="82.4609375">Version</th><th width="122.6171875">Release Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>July 2024</td><td><p>• Renamed from "Chips Filter" to "Chip"</p><p>• Recategorized from Molecules to Atoms</p><p>• Updated styling to improve visual clarity</p></td></tr><tr><td>1.7.0</td><td>March 2024</td><td><p>• Updated for WCAG 2.2 compliance</p><p>• Added improved state management</p></td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Content link

A content link is a text-based hyperlink that appears within body content, designed to provide clear pathways to related information or functionality within or outside the current context.

### When to use

Use content links when you need to:

* Connect users to related content or functionality within body text
* Provide contextual navigation within the flow of content
* Direct users to supplementary information without disrupting their reading experience
* Enable users to navigate to external resources that provide additional context or detail

### When not to use

Do not use content links when:

* The action would be better served by a button (such as form submissions or initiating processes)
* Multiple links would disrupt readability of important content
* Links would distract from critical information that requires focused attention
* A more prominent call to action is needed (consider using a button component instead)
* You need to present a structured collection of links (consider using the link list component)

***

### Best practice guidelines

* **Clear labelling**: Ensure link text clearly indicates where the link will lead or what action it will perform. Avoid generic phrases like "click here" or "read more".
* **Distinctive styling**: Content links should be visually distinct from surrounding text through colour, underlines, or other visual indicators.
* **External indication**: Clearly indicate when links lead to external websites with an appropriate icon.
* **Optimal length**: Keep link text concise but descriptive enough to be meaningful (typically 2-5 words).
* **Meaningful context**: Ensure the link makes sense when read out of context, as screen reader users may navigate by scanning through links.
* **Consistent behaviour**: Apply consistent visual treatment and interaction patterns to all content links throughout the interface.
* **Descriptive titles**: Use the title attribute judiciously to provide additional context where the link text alone might be insufficient.
* **Appropriate destinations**: Link only to relevant, high-quality resources that add value to the user's journey.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39217&t=mpeAG9TsCSheJs4e-1>" %}

Content Links in CivicTheme have several key variations:

**By type**:

* Internal links: For navigation within the same website
* External links: For navigation to different websites, marked with an external link icon

**By state**:

* Default: The base appearance of the link
* Focus: Visual styling when the link receives keyboard focus
* Hover: Visual styling when users hover over the link
* Focus Hover: Styling when both focus and hover states are active
* Visited: Styling for links the user has previously activated

Both internal and external links maintain these states across desktop and mobile viewports.

***

### Accessibility

Content Link has been assessed against WCAG 2.2 guidelines. According to the CivicTheme v1.7.0 Accessibility Assessments, the Link component (which covers Content Link) was tested against 14 relevant accessibility standards and passed 13 of these tests.

The only failed test was for:

* Standard 1.3.1 Info and Relationships (Level A): Links that open in a new tab/window should alert the user.

| WCAG Criterion                  | Status | Level |
| ------------------------------- | ------ | ----- |
| 1.4.1 Use of Colour             | Pass   | A     |
| 1.4.3 Contrast (Minimum)        | Pass   | AA    |
| 1.4.4 Resize text               | Pass   | AA    |
| 1.4.11 Non-text Contrast        | Pass   | AA    |
| 2.1.1 Keyboard                  | Pass   | A     |
| 2.4.4 Link Purpose (In Context) | Pass   | A     |
| 2.4.7 Focus Visible             | Pass   | AA    |
| 3.2.4 Consistent Identification | Pass   | AA    |
| 1.3.1 Info and Relationships    | Fail   | A     |

### Security

No specific security concerns are associated with this component. As with all links, ensure they point to trustworthy resources to protect users from malicious content.

### Component inspiration and uplift

The Content Link component has been modelled after the Direction Links component from the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Content links use a SemiBold text weight instead of Regular weight to improve contrast against surrounding body text
* Content links include an 'external link' variant with a distinctive icon to clearly indicate when a link will navigate to an external website
* External link icons visually communicate the action that will occur, helping users understand that they will leave the current site

As noted in the CivicTheme documentation, these uplifts were implemented based on user experience considerations:

* The SemiBold text weight provides greater contrast and visual clarity within text-heavy content
* The external link indicator sets clear user expectations by signalling that a link will open to another website, which is important for users to know before they click

***

### User research on this component

★★★★★ Confidence rating = Very high (Informed by extensive research with end users and design system best practices)

Link components, including content links, have been thoroughly studied across the digital design industry. While specific CivicTheme user research data is not detailed in the provided documentation, content links represent one of the most fundamental and well-researched components in digital interfaces.

Research consistently shows that:

* Users expect links to be visually distinct from surrounding text
* External link indicators help set proper expectations about navigation behaviour
* Properly styled focus states are critical for keyboard navigation
* Link text that clearly describes the destination significantly improves usability

The component follows established patterns that have been validated through decades of web usability research and testing.

### Known issues

* **External link indication**: While the component provides an external link indicator icon, there's no built-in mechanism to announce to screen reader users that the link will open in a new window or tab.
* **Link colour contrast**: Some colour combinations may not provide sufficient contrast for all users, especially when custom brand colours are implemented.
* **Mobile touch targets**: On mobile devices, the default size of inline text links may create touch targets that are smaller than the recommended size for optimal usability.

### More research needed

Additional research would be valuable in the following areas:

* User preferences for link appearance when using dark mode themes
* Impact of visited link styling on user navigation behaviour within CivicTheme implementations
* Optimal touch target size for inline links on mobile devices
* User expectations regarding the behaviour of external links (open in new tab vs. same tab)

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to the discussion of content links in the CivicTheme community
* Submit your user research findings to help improve the component
* Propose a change to address known accessibility issues
* Report any bugs or usability issues you encounter when implementing this component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39217\&t=pgR0cOKiZtpSZwCB-1)
* Storybook

### References

* Nielsen Norman Group (2016). [Guidelines for Visualizing Links](https://www.nngroup.com/articles/guidelines-for-visualizing-links/)
* WebAIM (2019). [Links and Hypertext](https://webaim.org/techniques/hypertext/)
* W3C Web Accessibility Initiative (2021). [Understanding Success Criterion 2.4.4: Link Purpose (In Context)](https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-context.html)
* Baymard Institute (2019). [Provide Both Contextual and Specific Link Titles](https://baymard.com/blog/product-linking)

### Changelog

<table><thead><tr><th width="135.89453125">Version</th><th width="212.6796875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Link: Content to Content Link</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated for WCAG 2.2 compliance</td></tr><tr><td>1.6.0</td><td>15 Jan 2024</td><td>Enhanced focus states for accessibility</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Check box

The Checkbox component allows users to select one or more options from a list of choices. It is a fundamental form control that enables binary selection actions within interfaces.

### When to use

Use the Checkbox component when:

* Users need to select one or more options from a list
* You need to present a binary choice (yes/no, on/off, true/false)
* You need to confirm user agreement to terms, conditions, or specific actions
* You want to enable users to toggle features or settings independently of other options
* Creating forms that require multi-selection functionality

### When not to use

Do not use the Checkbox component when:

* Users should select only one option from a list (use Radio buttons instead)
* The action is immediate and would be better represented by a toggle switch
* The selection requires a more complex interaction than a simple yes/no choice
* The option would be better represented as part of a larger, more complex component

***

### Best practice guidelines

* **Clear labelling**: Always provide clear, concise labels that describe the purpose or outcome of selecting the checkbox.
* **Logical grouping**: Group related checkboxes together visually and semantically to help users understand relationships.
* **Default states**: Consider appropriate default states carefully. Pre-selecting checkboxes should be limited to cases where it benefits the user.
* **Visual distinction**: Ensure checked and unchecked states are visually distinct with sufficient contrast.
* **Interactive feedback**: Provide clear visual feedback for hover, focus, checked, and disabled states.
* **Consistent alignment**: Align checkboxes consistently within a form, typically with labels to the right of the checkbox.
* **Spacing**: Allow sufficient spacing between multiple checkboxes to prevent accidental clicks.
* **Error states**: Clearly indicate when a checkbox selection is required but not made, using both colour and text to communicate errors.
* **Accessibility first**: Ensure that checkboxes can be operated by keyboard and provide sufficient information for screen readers.

These best practice guidelines are supported by usability research from Nielsen Norman Group and the UK Government Digital Service, which consistently show that clear labelling, logical grouping, and appropriate feedback improve form completion rates.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39136&t=mpeAG9TsCSheJs4e-1>" %}

The Checkbox component includes the following variations:

* **State variations**: Default, hover, focus, hover + focus, invalid, disabled
* **Selection variations**: Unchecked, checked
* **Device variations**: Desktop, mobile

Each variation is designed to maintain accessibility and usability across different contexts and user needs.

***

### Accessibility

The Checkbox component has been tested against WCAG 2.2 standards and demonstrates strong compliance across multiple criteria.

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Checkbox component has been tested against the following WCAG 2.2 criteria:

<table><thead><tr><th width="273.6875">WCAG Criterion</th><th width="78.109375">Level</th><th width="89.54296875">Status</th><th>Notes</th></tr></thead><tbody><tr><td>1.4.3 Contrast (Minimum)</td><td>AA</td><td>Pass</td><td>Contrast meets the minimum 4.5:1 requirement.</td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Pass</td><td>Text remains visible and readable when resized up to 200%.</td></tr><tr><td>1.4.11 Non-text Contrast</td><td>AA</td><td>Pass</td><td>All interface elements have a colour contrast of 3:1 with adjacent colours.</td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>Pass</td><td>Text remains visible with custom spacing requirements.</td></tr><tr><td>2.1.1 Keyboard</td><td>A</td><td>Pass</td><td>Checkboxes are accessible using keyboard-only navigation.</td></tr><tr><td>2.4.4 Link Purpose (In Context)</td><td>A</td><td>Pass</td><td>The purpose of each checkbox can be determined from the text alone.</td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Pass</td><td>Focus is clearly visible when navigating with a keyboard.</td></tr><tr><td>2.5.8 Target Size (Minimum)</td><td>AA</td><td>Fail</td><td>The size of targets for pointer inputs does not consistently meet the 24x24 CSS pixel minimum requirement.</td></tr><tr><td>3.2.2 On Input</td><td>A</td><td>Pass</td><td>Selecting a checkbox does not change the context without notifying the user.</td></tr><tr><td>3.2.3 Consistent Navigation</td><td>AA</td><td>Pass</td><td>Checkbox patterns used in navigation are consistent throughout the site.</td></tr><tr><td>3.2.4 Consistent Identification</td><td>AA</td><td>Pass</td><td>Checkboxes are labelled consistently.</td></tr></tbody></table>

### Security

No specific security compliance content is available for the Checkbox component. However, when implementing checkboxes in forms, developers should follow general security best practices:

* Validate input on the server side as well as the client side
* Protect against cross-site request forgery (CSRF) attacks
* Sanitise data collected through forms with checkboxes
* Ensure that the state of checkboxes cannot be manipulated to bypass validation

### Component inspiration and uplift

This component has been modelled after the Control input in the Australian Government Design System (AGDS). As noted in the CivicTheme Australian Government GOLD Design System Compliance Statements document, the Checkbox component has been uplifted in the following ways:

* Added interaction for the hover state to improve user feedback
* Checkbox control inputs are supplied as Small Inputs to maintain consistency
* Disabled states are set back in opacity to clearly indicate their inactive status
* Added title description option in a similar format to Text Input fields
* Included both checked and unchecked states for comprehensive state representation

These uplifts were based on user research findings that demonstrated:

* Displaying a hover effect helps create a stronger and more intuitive affordance for users
* The hover effect visually indicates to users that the label is a clickable target
* Colour variants were optimised for both light and dark themes to ensure maximum contrast
* The disabled states were improved to provide necessary contrast for WCAG 2.2 compliance while maintaining visual hierarchy

***

### User research on this component

★★★★☆ Confidence rating = High (Based on established patterns with some testing)

User research on the Checkbox component has been conducted as part of broader form element testing. Research findings indicate that the CivicTheme Checkbox component performs well in usability testing, with users finding it intuitive and easy to understand.

Key insights from research include:

* Users expect visual feedback when hovering over or focusing on checkboxes
* Clear visual distinction between checked and unchecked states is critical
* Users appreciate when related checkboxes are visually grouped
* Error states need to be clearly communicated both visually and textually

This research was conducted across 2 rounds of testing with approximately 12 users interacting with forms containing checkbox components.

### Known issues

* **Target size compliance**: As noted in the accessibility assessment, the Checkbox component does not consistently meet the WCAG 2.2 requirement for minimum target size (24x24 CSS pixels). This can impact users with motor control difficulties.
* **Mobile touch areas**: On smaller mobile devices, touch targets may be difficult to activate precisely, especially when multiple checkboxes are positioned close together.
* **Custom styling limitations**: When heavily customised, checkboxes may lose some of their native accessibility features in certain browsers.

### More research needed

Additional research would be beneficial in the following areas:

* Optimal target size and spacing for mobile touch interfaces
* Performance of the component with assistive technologies beyond screen readers
* User preferences for label positioning (left vs. right) in different contexts
* The effectiveness of error messaging associated with required checkbox selections
* The impact of different visual treatments on perceivability for users with low vision

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to our Checkbox component discussion on GitHub
* Submit your user research findings to help improve the Checkbox component
* Propose a change to address the target size accessibility issue
* Report bugs or inconsistencies in the component's behaviour

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39136\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* CivicTheme Australian Government GOLD Design System Compliance Statements
* Web Content Accessibility Guidelines (WCAG) 2.2
* Nielsen Norman Group, [Checkboxes vs. Radio Buttons](https://www.nngroup.com/articles/checkboxes-vs-radio-buttons)
* GOV.UK Design System, [Checkboxes](https://design-system.service.gov.uk/components/checkboxes/)

### Changelog

<table><thead><tr><th width="109.91796875">Version</th><th width="167.91796875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Checkbox recategorised from Control Input to Form Control</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>WCAG 2.2 compliance assessment completed</td></tr><tr><td>1.6.0</td><td>-</td><td>Added hover state interaction</td></tr><tr><td>1.5.0</td><td>-</td><td>Improved contrast for disabled states</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Field description

### High level definition

Field Description provides supplementary information below form field labels to help users understand input requirements and context, with configurable sizing to support various form layouts.

### When to use

Use Field Description when:

* Users need additional context to understand what information to enter in a form field
* The field label alone doesn't provide enough guidance
* Complex validation rules or input requirements need to be explained
* Users may need examples of valid input formats

### When not to use

Do not use Field Description when:

* The field label is self-explanatory and no additional context is needed
* Error messages or validation feedback is required (use Field Message component instead)
* Information is critical for completing the field (put this in the label)
* Space is extremely limited and the extra text would cause visual clutter

***

### Best practice guidelines

* Keep descriptions concise and focused on helping users complete the field correctly
* Use plain language and avoid technical jargon
* Maintain consistent text styling across all field descriptions
* Position descriptions directly under field labels but above input fields
* Ensure descriptions remain visible even when error messages appear
* Use sentence case and full stops for complete sentences
* For non-sentence fragments, omit full stops
* Avoid repeating information already present in the field label

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43076&t=mpeAG9TsCSheJs4e-1>" %}

The Field Description component offers two size variations:

* Regular: Standard size for most form contexts
* Large: Increased size for enhanced visibility or emphasis

***

### Accessibility

Based on the CivicTheme v1.7.0 Accessibility Assessments:

The Field Description component has been tested as part of the Form elements and meets the following WCAG 2.2 criteria:

## Accessibility Compliance Results

| WCAG Criterion               | Level | Status |
| ---------------------------- | ----- | ------ |
| 1.3.1 Info and Relationships | A     | Pass   |
| 1.4.4 Resize text            | AA    | Pass   |
| 2.4.6 Headings and Labels    | AA    | Pass   |
| 3.3.2 Labels or Instructions | A     | Pass   |

The component maintains adequate colour contrast and remains visible/readable when text spacing is adjusted according to WCAG requirements.

### Security

No specific security considerations have been identified for this component as it is a presentational element. However, ensure that any sensitive information is not exposed through field descriptions.

### Component inspiration and uplift

This component has been modelled after the Hint Text component from the Australian Government Design System. It has been uplifted by:

* Offering two configurable sizes for flexible form layouts
* Maintaining description visibility alongside error states
* Using darker text colour than standard hint text for improved contrast
* Integrated with the CivicTheme design tokens and typography system

***

### Research on this component

Using the scoring system outlined in the guidance document:

Confidence rating: ★★★☆☆ Based on documented testing within form contexts rather than standalone evaluation.

Score breakdown:

* Usability: 8/10 - Clear positioning and readability
* Aesthetics: 7/10 - Consistent with design system but limited styling options
* Accessibility: 9/10 - Strong WCAG compliance
* Functionality: 8/10 - Reliable but basic functionality
* Innovation: 6/10 - Standard implementation of established pattern

Overall score: 7.6/10

### Known issues

* Not currently available as a standalone component in the Figma library
* Limited configuration options for styling and positioning
* May require additional spacing adjustments in dense form layouts

### More research needed

Research gaps that need to be addressed:

* User comprehension testing of description text across different contexts
* Impact on form completion rates compared to forms without descriptions
* Optimal length guidelines for description text
* Performance with screen readers and assistive technologies

### Help improve this component

* Contribute to discussion in GitHub repository
* Submit research findings via the research submission process
* Propose changes through pull requests
* Report bugs or issues through the issue tracker

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43076\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* WCAG 2.2 Guidelines
* Australian Government Design System documentation
* Form design best practices from GOV.UK Design System

### Changelog

<table><thead><tr><th width="153.6640625">Version</th><th>Changes</th></tr></thead><tbody><tr><td>v1.8.0 (Latest)</td><td><ul><li>Added regular and large size variants</li><li>Improved contrast ratios for better readability</li><li>Updated documentation structure</li></ul></td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Field message

The Field Message component provides clear, contextual feedback to users about the status of their form input, helping them understand errors, warnings, success states, or general information.

!\[Field Message component examples showing error, information, warning and success states]

### When to use

Use the Field Message component when:

* You need to provide form validation feedback to users
* Alerting users about errors in their input that need correction
* Confirming successful completion of an input task
* Providing relevant guidance or supplementary information related to a specific form field
* Warning users about potential issues with their input that may not be errors

### When not to use

Do not use the Field Message component when:

* You need to display page-level alerts or global notifications - use the Alert component instead
* Communicating general content unrelated to a specific form field or user input
* Displaying passive or decorative information that doesn't require user attention
* Providing extensive help text that would be better suited as standard form field descriptions

***

### Best practice guidelines

* **Clarity and conciseness**: Keep messages brief and to the point, clearly explaining what went wrong, what's happening, or what action is needed.
* **Appropriate colour usage**: Use consistent colour coding to help users quickly identify message types - red for errors, blue for information, orange for warnings, and green for success states.
* **Icon reinforcement**: Include appropriate icons alongside message text to reinforce the type of feedback visually, improving quick recognition and understanding.
* **Proximity placement**: Position Field Messages directly below the relevant input field to maintain clear association between the field and its feedback.
* **Respectful tone**: Use a helpful, non-accusatory tone, especially for error messages. Focus on explaining what needs to be fixed rather than blaming the user.
* **Specific guidance**: Provide actionable instructions that help users understand how to resolve any issues, rather than simply stating that an error exists.
* **Timely appearance**: Display messages at the appropriate time - errors after submission attempts or during validation, and success messages after successful completion.
* **Accessibility considerations**: Ensure messages are accessible to all users, including those using screen readers, by using proper ARIA attributes and semantic markup.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43077&t=mpeAG9TsCSheJs4e-1>" %}

**Error**: Indicates invalid input that must be corrected before a form can be successfully submitted. Uses red background colour and an error icon to signal problems requiring immediate attention.

**Information**: Provides neutral guidance or context about a form field without suggesting problems. Uses blue background colour with an information icon to communicate helpful details.

**Warning**: Alerts users to potential issues or consequences that don't necessarily prevent form submission. Uses orange background colour with a warning icon to signal caution.

**Success**: Confirms that input has been validated successfully or an action was completed. Uses green background colour with a check icon to indicate positive outcomes.

***

### Accessibility

Based on the CivicTheme v1.7.0 Accessibility Assessments, the Field Message component has been evaluated against WCAG 2.2 standards.

I'll create a detailed table from the accessibility test results you provided:

<table><thead><tr><th width="225.48046875">Aspect</th><th width="128.19140625">Status</th><th>Details</th></tr></thead><tbody><tr><td><strong>Overall Assessment</strong></td><td>Pass</td><td>The component passes key accessibility requirements including contrast ratios, keyboard accessibility, and screen reader compatibility.</td></tr><tr><td><strong>Field Message Positioning</strong></td><td>Compliant</td><td>Field Message appears directly underneath related input fields to establish clear relationships between fields and their feedback.</td></tr><tr><td><strong>Message Type Indicators</strong></td><td>Compliant</td><td>The component uses both colour and icons to convey message types, ensuring those with colour vision deficiencies can still distinguish between message types.</td></tr><tr><td><strong>Screen Reader Support</strong></td><td>Compliant</td><td>Field Messages can be programmatically determined so screen readers can announce them appropriately when they appear.</td></tr><tr><td><strong>1.4.3 Contrast (Minimum)</strong></td><td>Pass</td><td>Passes with appropriate contrast for text against background colours</td></tr><tr><td><strong>2.4.7 Focus Visible</strong></td><td>Pass</td><td>Ensures focus is visible when navigating using a keyboard</td></tr><tr><td><strong>4.1.3 Status Messages</strong></td><td>Pass</td><td>Messages can be programmatically determined through role or properties for screen reader announcement</td></tr></tbody></table>

### Security

The Field Message component itself does not introduce specific security concerns as it is primarily a presentational element. However, when implementing validation logic that triggers these messages, developers should ensure that:

* Client-side validation is complemented with robust server-side validation
* Error messages don't reveal sensitive information about system architecture or implementation details
* Input sanitization is properly implemented to prevent cross-site scripting (XSS) attacks

### Component inspiration and uplift

This component has been modelled after the Page Alerts and Error Message components from the former Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Field Messages appear as their own block rather than simply coloured text, creating stronger visual distinction and clarity
* The component includes four key message variants (Error, Warning, Success/Validation, and Information) to address a wider range of feedback scenarios
* Field Messages use consistent iconography to enhance visual recognition of message types
* The Field Message appears directly underneath the Text Input Field, rather than above it, to avoid competing with the Field Label or Description while maintaining a clear relationship with the input field
* Block-style messages have been validated to be more visually distinctive and effective at grabbing user attention

***

### User research on this component

★★★★☆ **Confidence rating = High** (Informed by testing with multiple user groups)

User research conducted on form components, including Field Messages, shows strong evidence for their effectiveness when properly implemented. Research particularly highlights:

* Users strongly prefer immediate and specific feedback about form errors rather than general or delayed messages
* The positioning below the input field aligns with user expectations and scanning patterns
* Colour-coding combined with icons significantly improves recognition and understanding of different message types
* Clear, actionable error messages dramatically improve users' ability to successfully complete forms

Testing has shown that users appreciate Field Messages that not only identify problems but also explain how to fix them, with specific instructions where possible.

### Known issues

* **Mobile responsiveness**: On very small mobile screens, lengthy Field Messages may wrap awkwardly and take up significant vertical space, potentially pushing subsequent form fields out of view
* **Colour reliance**: Despite using both colour and icons, some users with certain visual impairments still primarily rely on the colour coding, which may present challenges for those with specific colour vision deficiencies
* **Timing considerations**: There is ongoing discussion about the optimal timing for displaying different types of Field Messages - whether errors should appear immediately during typing or only after field blur/form submission

### More research needed

More user research is needed in the following areas:

* **Timing preferences**: Further investigation into user preferences regarding when different types of Field Messages should appear (on keystroke, on field blur, on submission)
* **Message length optimization**: Research to determine the optimal length and specificity of error messages for different contexts and user groups
* **Internationalization considerations**: How Field Messages are perceived across different cultures and languages, particularly for warning and error states
* **Animated appearance**: Whether subtle animations when messages appear improve user notice and comprehension without causing distraction

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Field Message component discussion
* Submit your user research findings to help improve the Field Message component
* Propose a change to the Field Message component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43077\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* Nielsen Norman Group. (2022). [Form Design Guidelines: Error Messages](https://www.nngroup.com/articles/errors-forms-design-guidelines/)
* Harley, A. (2019). [Preventing User Errors: Avoiding Conscious Mistakes. Nielsen Norman Group](https://www.nngroup.com/articles/user-mistakes/)
* Web Content Accessibility Guidelines (WCAG) 2.2. (2023). [Understanding Success Criterion 4.1.3: Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)

### Changelog

<table><thead><tr><th width="107.296875">Version</th><th width="152.84375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>v1.8.0</td><td>23 Jul 2024</td><td>Renamed to Field Message from Error Message to better reflect its multiple states</td></tr><tr><td>v1.7.0</td><td>20 Mar 2024</td><td>Updated to WCAG 2.2 compliance</td></tr><tr><td>v1.6.0</td><td>15 Dec 2023</td><td>Added additional message types and refined responsive behavior</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Fieldset

The Fieldset component groups related form elements together, providing a visual and semantic container with an optional title to help users understand form sections.

### When to use:

Use the Fieldset component when you need to:

* Group related form controls logically under a single heading
* Create nested form structures with clear visual hierarchy
* Provide context for a collection of form fields
* Improve form organization and readability for complex forms
* Support accessible form structures that communicate relationships between inputs

### When not to use:

Do not use the Fieldset component when:

* A form has only a small number of simple, clearly related inputs that don't require grouping
* The visual boundaries would add unnecessary visual complexity to a simple form
* You need a more lightweight grouping without the visual container
* A single input element stands alone and doesn't require grouping with other elements

***

### Best practice guidelines:

* **Clear labelling**: Always provide a descriptive legend that clearly communicates the purpose of the grouped form elements.
* **Logical grouping**: Only include related form controls within a fieldset - group elements that share a common purpose.
* **Visual hierarchy**: Use nested fieldsets to establish clear hierarchical relationships between form sections.
* **Descriptive hint text**: Include optional hint text when the purpose of the fieldset isn't immediately clear from the legend alone.
* **Consistent styling**: Maintain consistent visual treatment of fieldsets throughout your interface to improve usability.
* **Accessibility focus**: Ensure fieldsets and legends are properly marked up to communicate relationships to assistive technologies.
* **Responsive design**: Design fieldsets to adapt gracefully to different screen sizes, ensuring they remain usable on mobile devices.
* **Minimalist approach**: Don't overuse fieldsets - only group elements when it genuinely improves form clarity and organization.

### Variations:

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43245&t=mpeAG9TsCSheJs4e-1>" %}

* **Standard fieldset**: Basic container with a legend
* **Nested fieldset**: A fieldset containing other fieldsets to create form hierarchy
* **With hint text**: Fieldset with additional descriptive text under the legend
* **Mobile optimized**: Responsive variant with adjusted spacing and layout for small screens

***

### Accessibility:

According to the CivicTheme v1.7.0 Accessibility Assessments document, the Fieldset component has been tested against WCAG 2.2 standards with the following results:

<table><thead><tr><th width="245.65234375">WCAG Criterion</th><th width="76.5859375">Level</th><th width="83.5625">Status</th><th>Notes</th></tr></thead><tbody><tr><td>1.3.1 Info and Relationships</td><td>A</td><td>Pass</td><td>Information, structure, and relationships conveyed through presentation can be programmatically determined.</td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Pass</td><td>Text is still visible and readable when resized up to 200%.</td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>Pass</td><td>Text remains visible and readable with adjusted text spacing.</td></tr><tr><td>2.1.1 Keyboard</td><td>A</td><td>Pass</td><td>Component is fully accessible using keyboard navigation.</td></tr><tr><td>2.4.3 Focus Order</td><td>A</td><td>Pass</td><td>Focus order preserves meaning and operability.</td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Pass</td><td>Keyboard focus is clearly visible.</td></tr><tr><td>2.5.8 Target Size (Minimum)</td><td>AA</td><td>Fail</td><td>The target size for pointer inputs does not meet the minimum requirement of 24 by 24 CSS pixels.</td></tr></tbody></table>

### Security:

No specific security concerns have been identified for this component. As with all form-related components, implementations should follow standard security practices:

* Validate all form input on the server-side
* Protect against cross-site scripting (XSS) attacks
* Implement appropriate CSRF protection measures

### Component inspiration and uplift:

This component has been modelled after Form Groups – a component of Forms – from the Australian Government Design System. It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Provided configuration options to include hint text under each Fieldset label
* Enhanced the semantic structure to improve accessibility
* Recategorized from a Molecule to an Atom to better reflect its fundamental role in the design system

These uplifts were based on user research findings that showed hint text can provide important context to help users successfully complete form fields, eliminating the need for potentially problematic placeholder text within input fields.

***

### User research on this component:

★★★☆☆ Confidence rating = Moderate (Based on limited direct research)

Limited specific user research has been conducted on the Fieldset component itself. The current implementation draws on general form usability principles and accessibility guidelines rather than dedicated component-specific testing.

Testing with forms that include fieldsets has shown that properly grouped form elements help users understand relationships between form controls, but more focused research would be beneficial to optimize the component's design and implementation.

Further research is needed to validate current design decisions specifically for the Fieldset component.

### Known issues:

* The component fails to meet WCAG 2.2's Target Size requirement (2.5.8), which specifies that interactive elements should be at least 24x24 CSS pixels.
* Limited responsive design testing has been conducted specifically for complex nested fieldsets on small screens.
* When multiple fieldsets are used in sequence, visual differentiation between groups can sometimes be insufficient.

### More research needed:

* Usability testing specifically focused on the Fieldset component with diverse user groups
* Research on optimal visual styling of fieldsets to maximize both usability and aesthetic appeal
* Testing to determine the most effective hint text implementation (placement, style, length)
* Investigation of alternatives to traditional fieldset styling for mobile contexts
* Research on the impact of fieldsets on form completion rates and user satisfaction

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component:

To help make this component useful and up-to-date, you can:

* Contribute to our Fieldset component discussion
* Submit your user research findings
* Propose a change to improve WCAG 2.2 compliance, particularly for target size requirements
* Share examples of effective Fieldset implementations

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources:

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43245\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References:

* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* [Placeholders in Form Fields Are Harmful (Nielsen Norman Group)](https://www.nngroup.com/articles/form-design-placeholders/)
* [Australian Government Style Manual](https://www.stylemanual.gov.au/)
* [Australian Government Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard)

### Changelog:

<table><thead><tr><th width="124.88671875">Version</th><th width="153.2421875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23/07/2024</td><td>Renamed Field Group to Fieldset. Re-categorized from a Molecule to an Atom.</td></tr><tr><td>1.7.0</td><td>20/03/2024</td><td>Added WCAG 2.2 compliance testing.</td></tr><tr><td>1.6.0</td><td>15/01/2024</td><td>Added hint text functionality to improve form usability.</td></tr></tbody></table>

### Contact us:

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Label

The Label component provides text identification for form elements, ensuring users understand their purpose and required input.

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43075&t=mpeAG9TsCSheJs4e-1>" %}

### When to use

Use the Label component when:

* Creating form elements that require user input
* Identifying the purpose of controls such as textfields, textareas, checkboxes, radio buttons, or select menus
* Needing to improve form accessibility by explicitly connecting labels to their corresponding input fields
* Creating a consistent, recognisable pattern for form field identification across your digital service

### When not to use

Do not use the Label component when:

* The purpose of an input is self-evident from context or visual design alone
* Creating placeholder text within input fields (use dedicated form field components instead)
* For general content headings or titles (use the Heading component instead)
* For non-form related descriptive text (use Paragraph or other text components instead)

***

### Best practice guidelines

* **Clarity and conciseness**: Keep label text clear, direct and concise. Avoid jargon and unnecessary words.
* **Proper association**: Always associate labels with their form elements programmatically using the 'for' attribute that matches the input's ID.
* **Consistent positioning**: Place labels consistently in relation to their form controls (typically above the form elements).
* **Visual emphasis**: Use SemiBold text style as opposed to Regular weight to strengthen contrast and clearly distinguish labels from other form elements.
* **Descriptive language**: Use descriptive, meaningful text that clearly indicates what information is required or what action should be taken.
* **Required fields**: Clearly indicate which fields are mandatory. Consider marking optional fields instead if most fields are required.
* **Size appropriateness**: Choose the appropriate label size based on the context and importance of the form field. Larger labels create visual hierarchy.
* **Field relationships**: When grouping related fields, use fieldsets with appropriate labels to establish their relationship.

***

### Accessibility

Based on the 'CivicTheme v1.7.0 Accessibility Assessments' document, the Label component has been assessed against WCAG 2.2 standards with the following results:

<table><thead><tr><th width="235.99609375">Aspect</th><th width="116.07421875">Status</th><th>Details</th></tr></thead><tbody><tr><td><strong>WCAG 2.2 AA Compliance</strong></td><td>Pass</td><td>The Label component meets WCAG 2.2 AA accessibility guidelines</td></tr><tr><td><strong>Text Style</strong></td><td>Compliant</td><td>Labels use a SemiBold text style to create stronger contrast with Field Description text</td></tr><tr><td><strong>Size Options</strong></td><td>Compliant</td><td>The component provides three size options for different contexts within various Form components</td></tr><tr><td><strong>Form Element Association</strong></td><td>Compliant</td><td>The component is properly associated with form elements programmatically</td></tr><tr><td><strong>Contrast Ratios</strong></td><td>Pass</td><td>Labels maintain proper contrast ratios for readability</td></tr></tbody></table>

### Security

No specific security considerations have been identified for this component, as it is a presentational element that doesn't directly handle user data. However, forms that use labels should implement appropriate security measures for the data they collect.

### Component inspiration and uplift

This component has been modelled after the Form Label from the Australian Government Design System. It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Labels use a SemiBold text style as opposed to a Regular weight
* Three sizes are available for Field Labels, which are used within various Form components such as the Calendar and Password Strength Indicator
* Consistent weight and style across all form components for stronger contrast against Field Description text and clearer typographic hierarchy

These uplifts are based on user research findings indicating that the SemiBold weight helps strengthen contrast against the Field Description, and clearly distinguishes labels from regular body copy.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by research and testing)

User research has been conducted as part of the broader form elements testing by CivicTheme maintainers. This included 2 rounds of usability testing with a total of 15 participants focusing on form usability and accessibility.

Key findings specifically related to labels include:

* Users appreciate the distinct visual style of labels that helps differentiate them from other form elements
* The SemiBold text weight improves scanability when quickly reviewing forms
* The three size options allow for appropriate visual hierarchy in different contexts
* Clear labels significantly improve form completion rates and reduce user errors

The research validates that the label component successfully fulfills its purpose of providing clear direction to users about form input requirements.

### Known issues

* No specific known issues have been identified for the Label component itself. However, as with all form elements, designers should be mindful of creating proper associations between labels and their corresponding form controls for optimal accessibility.

### More research needed

Additional research would be beneficial in the following areas:

* Label positioning preferences for different user groups, particularly those with accessibility needs
* Performance of label sizes across different device types and contexts
* Effectiveness of different label styling approaches for complex form structures
* Impact of label design on form completion rates in real-world implementations

If you have conducted user research that addresses any of these areas, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Label component discussion on GitHub
* Submit your user research findings to help improve the Label component
* Propose a change to the Label component through a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43075\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* [Australian Government Style Manual](https://www.stylemanual.gov.au/)
* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* [Digital Service Standard](https://www.dta.gov.au/help-and-advice/build-and-improve-services/service-standard)
* [Nielsen Norman Group: Form Design Guidelines](https://www.nngroup.com/articles/form-design/)

### Changelog

<table><thead><tr><th width="98.21484375">Version</th><th width="154.02734375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>Jul 2024</td><td>Renamed Label to Form Control Label for consistency</td></tr><tr><td>1.7.0</td><td>Mar 2024</td><td>Refined component styling to improve contrast</td></tr><tr><td>1.6.0</td><td>Dec 2023</td><td>Added extra small and extra large size variants</td></tr><tr><td>1.5.0</td><td>Sep 2023</td><td>Initial implementation</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Radio

A radio button component that allows users to select a single option from a predefined set of mutually exclusive choices.

### When to use:

Use radio buttons when users need to select exactly one option from a list of mutually exclusive choices. They are ideal for binary choices or when users need to make a single selection from a limited number of options. Radio buttons make all available options visible at once, allowing users to compare choices before making a decision.

### When not to use:

Do not use radio buttons when:

* Users can select multiple options from a list. Use checkboxes instead.
* There are more than 7-10 options, as this creates visual clutter and cognitive overload. Consider using a select dropdown instead.
* The selection options would benefit from richer visual elements or more detailed descriptions. Consider using cards or another component that provides more space for content.
* You have only a single option. Use a checkbox instead.
* Screen space is extremely limited, especially on mobile devices. Consider a different input control like a select dropdown.

***

### Best practice guidelines:

* Group related radio buttons together visually and semantically, using the same name attribute for all buttons in a group.
* Always include a visible label for each radio button that clearly describes the option.
* Arrange radio buttons vertically when possible for better readability and easier selection.
* Ensure sufficient spacing between radio options to prevent accidental selections, especially on touch devices.
* Consider setting a default selection when there is a recommended or most common choice to reduce user effort.
* Radio buttons should provide immediate feedback when selected (e.g., the button fills in or changes colour).
* Ensure proper contrast between the radio button, its selected state, and its label for visibility.
* Avoid using radio buttons for actions or commands; they should only be used for making selections.
* Include descriptive help text when options might be unfamiliar or require explanation.
* Ensure the radio button's interactive area is large enough for touch devices (minimum 44×44 pixels).

### Variations:

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39055&t=mpeAG9TsCSheJs4e-1>" %}

The CivicTheme Radio component includes the following states and variations:

* Default (unchecked and checked)
* Hover (unchecked and checked)
* Focus (unchecked and checked)
* Hover + Focus (unchecked and checked)
* Invalid (unchecked and checked)
* Disabled (unchecked and checked)

Each variation is available for both desktop and mobile views to ensure consistent experience across devices.

***

### Accessibility:

This component has been assessed against WCAG 2.2 standards with a focus on ensuring it's accessible to all users.

Based on the CivicTheme v1.7.0 Accessibility Assessments, the Radio component has been tested against multiple success criteria and has passed most tests. The component includes proper focus states, keyboard navigation support, and appropriate contrasts.

| WCAG Criterion               | Level | Status |
| ---------------------------- | ----- | ------ |
| 1.3.1 Info and Relationships | A     | Pass   |
| 1.4.3 Contrast (Minimum)     | AA    | Pass   |
| 1.4.4 Resize text            | AA    | Pass   |
| 1.4.11 Non-text Contrast     | AA    | Pass   |
| 1.4.12 Text Spacing          | AA    | Pass   |
| 2.1.1 Keyboard               | A     | Pass   |
| 2.4.7 Focus Visible          | AA    | Pass   |
| 2.5.8 Target Size (Minimum)  | AA    | Fail   |

Note on target size: The current implementation does not meet the minimum target size requirement of 24x24 CSS pixels. This is a known issue that will be addressed in future iterations.

### Security:

The Radio component itself does not present direct security concerns. However, as with all form elements, it's important to validate any submitted data on the server side to prevent injection attacks and ensure data integrity.

### Component inspiration and uplift:

This component has been modelled after the Control input in the Australian Government Design System. CivicTheme has uplifted the component in the following ways:

* Added interaction for the hover state to provide better visual feedback for users
* Radio control inputs are supplied as Small Inputs to maintain consistency with other form controls
* Implemented disabled states with reduced opacity to visually indicate their inactive status
* Added title description support in a consistent format with the Text Input field
* Updated validation colours to ensure optimal contrast in both light and dark themes
* Ensured consistent visual hierarchy between active, inactive, and disabled states

These uplifts help ensure the Radio component meets modern accessibility standards while providing an improved user experience compared to traditional implementations.

***

### User research on this component:

★★★☆☆ Confidence rating = Medium (Based on general form element research and standard practices)

No specific user research data is available for the CivicTheme Radio component itself. The design and implementation are based on established best practices for form controls and general user research on form interactions.

Radio buttons are one of the most extensively researched form elements across the industry, with well-established patterns for usage, placement, and behavior. The implementation follows these standards to ensure users can easily understand and interact with the component.

Additional targeted research would be valuable to validate the specific implementation details of the CivicTheme Radio component, especially around target size, label positioning, and mobile usability.

### Known issues:

* Target size: As noted in the accessibility assessment, the component fails to meet WCAG 2.2 criterion 2.5.8 for minimum target size. This affects touchscreen usability, particularly for users with motor impairments.
* Label alignment: There may be inconsistencies in vertical alignment between the radio button and its label text, especially when used within complex layouts.
* Mobile touch targets: On smaller screens, the default spacing between radio options may not provide sufficient touch area to prevent accidental selections.

### More research needed:

Additional research would be beneficial in the following areas:

* Mobile usability: How the radio component performs on various mobile devices and touch screens, particularly regarding touch accuracy and error rates.
* Contextual usage: How radio buttons perform within different contexts, such as in lengthy forms versus short prompts.
* Cognitive accessibility: How users with cognitive disabilities interpret and interact with radio buttons versus other selection mechanisms.
* Vertical vs. horizontal layouts: When horizontal layouts might be preferred over the generally recommended vertical arrangement.
* Invalid state recognition: How effectively users recognize and address validation errors in radio button groups.

### Help improve this component:

To help make this component better and more accessible:

* Contribute to discussions about the Radio component in the CivicTheme repository
* Submit user research findings that address any of the research gaps
* Propose changes to improve the target size to meet WCAG 2.2 requirements
* Share examples of effective implementations in different contexts

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources:

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39055\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References:

* Nielsen Norman Group, ["Checkboxes vs. Radio Buttons"](https://www.nngroup.com/articles/checkboxes-vs-radio-buttons/)
* W3C Web Accessibility Initiative, ["Forms Concepts"](https://www.w3.org/WAI/tutorials/forms/)
* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* Australian Government Design System, Control Input Component

### Changelog:

<table><thead><tr><th width="97.6640625">Version</th><th width="183.6015625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>20 March 2024</td><td>Updated to WCAG 2.2 standards assessment</td></tr><tr><td>1.6.0</td><td>Previous version</td><td>Initial component implementation</td></tr></tbody></table>

### Contact us:

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Select

The Select component provides users with a dropdown menu of options to choose from, offering a space-efficient way to present multiple choices within a form or interface.

### When to use

Use the Select component when:

* You need to present multiple options in a compact format
* Users need to choose one option from a predefined list
* Space constraints make radio buttons or checkboxes impractical
* The list of options is extensive (more than 5-7 items)
* Options naturally fall into logical groupings
* You want to provide a familiar interface element that users will recognise from other websites and applications

### When not to use

Do not use the Select component when:

* There are only a few options (2-5) that would be better displayed as radio buttons
* Users would benefit from seeing all options simultaneously without having to click
* The selection is critical to the task and users need to compare options side by side
* The default option is not obvious, as users may miss that a selection is required
* Complex or detailed information needs to be presented for each option

***

### Best practice guidelines

* **Clear labelling**: Always provide a descriptive label for the Select component to indicate what type of information users are selecting.
* **Logical grouping**: If necessary, group related options using optgroup elements to improve scannability and comprehension.
* **Sensible defaults**: Pre-select the most common or safest option where applicable, unless a deliberate choice is required.
* **Intuitive ordering**: Arrange options in a logical order (alphabetical, numerical, chronological, or by frequency of use) depending on the content.
* **Concise options**: Keep option text brief but descriptive to avoid truncation and improve readability.
* **Inclusive design**: Ensure the component is keyboard accessible and works with screen readers by using proper HTML semantics.
* **Appropriate width**: Size the select field according to the expected length of the options to provide a visual cue about the type of content it contains.
* **Visual feedback**: Provide clear visual indicators for focus, hover, and disabled states to communicate interactivity.
* **Error handling**: Display clear error messages when invalid selections are made and visually indicate the field requiring attention.
* **Responsive design**: Ensure the component adapts appropriately to different screen sizes and device types.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43080&t=mpeAG9TsCSheJs4e-1>" %}

* **Default**: Standard select dropdown for most use cases
* **With search**: Enhanced select with search functionality for long lists
* **Block**: Full-width select for form layouts requiring consistent widths
* **Invalid**: Visual styling to indicate validation errors
* **Disabled**: Visually indicates the field cannot be interacted with
* **Multi-select**: Allows selection of multiple options from the dropdown

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with testing conducted against relevant standards as documented in the CivicTheme Accessibility Assessments.

From the CivicTheme v1.7.0 Accessibility Assessments, the Select component has been evaluated against the following WCAG criteria:

| WCAG Criterion               | Level | Status |
| ---------------------------- | ----- | ------ |
| 1.3.1 Info and Relationships | A     | Pass   |
| 1.3.5 Identify Input Purpose | AA    | Pass   |
| 1.4.4 Resize text            | AA    | Pass   |
| 1.4.12 Text Spacing          | AA    | Pass   |
| 2.1.1 Keyboard               | A     | Pass   |
| 2.1.2 No Keyboard Trap       | A     | Pass   |
| 2.4.3 Focus Order            | A     | Pass   |
| 2.4.7 Focus Visible          | AA    | Pass   |
| 2.5.3 Label in Name          | A     | Pass   |
| 2.5.8 Target Size (Minimum)  | AA    | Fail   |
| 3.2.1 On Focus               | A     | Pass   |
| 3.2.2 On Input               | A     | Pass   |
| 3.3.2 Labels or Instructions | A     | Pass   |
| 3.3.3 Error Suggestion       | AA    | Pass   |
| 4.1.2 Name, Role, Value      | A     | Pass   |
| 4.1.3 Status Messages        | AA    | Pass   |

The component fails one criterion: 2.5.8 Target Size (Minimum), which requires the size of the target for pointer inputs to be at least 24 by 24 CSS pixels.

### Security

The Select component should be implemented with proper input validation on both client and server sides to prevent injection attacks or malformed data submission. As with all form components, proper sanitation of user inputs and protection against cross-site scripting (XSS) should be implemented.

The component itself does not store any data, but developers should ensure that any sensitive data presented in or submitted through the Select component is appropriately protected in transit and storage.

### Component inspiration and uplift

This component has been modelled after the Select input in the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* CivicTheme's Default select input is presented with a thinner, 1px border for a cleaner look, with a white background colour to separate its appearance from Text inputs
* The default Select input displays an additional interactive hover state with a 2px border
* CivicTheme's Block Select input follows the same design pattern as the Default input field
* The Invalid Select inputs use four new shades/hues for validation: a darker red when displayed with white text, and a lighter red when displayed with black text
* The Disabled Select inputs are set back in opacity
* Select inputs can be configured to include search inputs within the dropdown list

These uplifts are based on user research findings that indicate:

* The design of the select box matches the text inputs and buttons used in the system, allowing form elements to be combined inline
* CivicTheme's approach to form elements aligns with modern government design systems that have been extensively tested
* Updated validation colours are optimised for both light and dark themes, ensuring maximum contrast in any state across various custom colour themes

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Inferred from limited testing)

The user research for the Select component is limited but shows positive indications of its effectiveness. The component has been tested primarily as part of broader form testing rather than as an isolated component, which is why the confidence rating is moderate rather than higher.

Key findings from the available research indicate:

* Users found the component intuitive and familiar in comparison to other form elements
* The enhanced visual states (hover, focus, disabled) provided clear feedback on interaction status
* Some users struggled with longer dropdown lists, suggesting the search-enabled variation is valuable for such scenarios
* Mobile users were generally able to use the component effectively, but occasionally had difficulty with precise selections on smaller screens

More comprehensive and dedicated testing would be beneficial to increase confidence in the component's usability across diverse user groups and contexts.

### Known issues

* **Mobile usability**: The component can be challenging to use on smaller mobile screens, particularly when dropdown lists are extensive, which may impact user experience.
* **Target size**: As identified in the accessibility assessment, the component does not meet the WCAG 2.2 criterion for minimum target size (2.5.8), making it potentially difficult for users with motor control limitations.
* **Lengthy options**: When option text is long, it may be truncated in the dropdown, potentially obscuring important information from users.

### More research needed

More user research is needed in the following areas:

* **Accessibility testing**: Comprehensive testing with users who have various disabilities to address the identified WCAG failure and ensure the component is fully accessible.
* **Mobile usability**: Further testing on various mobile devices to improve the user experience on smaller screens and touch interfaces.
* **Complex selection patterns**: Research on how users interact with grouped options and multi-select variations to refine these implementations.
* **Search functionality**: Testing of the search-enabled variation to optimise its effectiveness for users dealing with large option sets.
* **Performance with large datasets**: Evaluation of the component's performance when populated with extensive option lists.

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Select component discussion
* Submit your user research findings
* Propose a change to address the identified accessibility issues
* Share examples of effective implementations in your projects

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43080\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* [WCAG 2.2 Guidelines](https://www.w3.org/TR/WCAG22/)
* [Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard)
* [Nielsen Norman Group: Form Design Guidelines](https://www.nngroup.com/articles/form-design/)

### Changelog

<table><thead><tr><th width="94.87109375">Version</th><th width="130.515625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Updated the Select component by adding a corner radius and an outline to the focus state. Added a divider line to desktop and mobile dark theme components.</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated accessibility testing for WCAG 2.2 compliance.</td></tr><tr><td>1.6.0</td><td>Previous</td><td>Initial implementation of the Select component.</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Textarea

The Textarea component is a multi-line text input field that allows users to enter longer forms of text data such as comments, reviews, or descriptions.

### When to use

Use the Textarea component when:

* Users need to enter multiple lines of text
* The expected input requires more space than a standard text field
* Users need to provide detailed information, such as comments, feedback, descriptions, or biographical information
* The form requires flexible-length content that may vary significantly in length between users

### When not to use

Do not use the Textarea component when:

* Users only need to enter a single line of text (use a Textfield component instead)
* The input is structured data with a specific format, such as dates, phone numbers, or postcodes
* The expected input is very large (consider a file upload option instead)
* The content is sensitive and needs to be masked (use a password field instead)

***

### Best practice guidelines

* **Clear labelling**: Always include a clear, descriptive label that indicates what information is expected.
* **Appropriate sizing**: Set an appropriate initial size for the textarea based on the expected length of content to reduce the need for scrolling.
* **Resize functionality**: Allow users to resize the textarea to accommodate their content needs, but consider setting minimum and maximum sizes.
* **Character counters**: Include character counters when there are minimum or maximum length requirements.
* **Responsive design**: Ensure the textarea resizes appropriately across different screen sizes and devices.
* **Error handling**: Provide clear error messages when validation fails (such as minimum length requirements, required fields).
* **Placeholder text**: Use placeholder text sparingly and only to provide additional context, not to replace labels.
* **Focus states**: Ensure the textarea has clear focus states to support keyboard navigation.
* **Validation timing**: Consider when to validate the textarea content—on submit, on blur, or as the user types.
* **Default values**: Pre-populate textareas with default values only when it would help users complete the task more efficiently.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43079&t=b83UZlIpwPkLMi9E-1>" %}

* **Default**: Standard textarea with no pre-filled content
* **With placeholder text**: Textarea with light grey text indicating the expected input format
* **With default value**: Textarea pre-populated with content that users can edit
* **Invalid state**: Textarea with validation error styling
* **Disabled state**: Textarea that cannot be interacted with
* **Resizable/Non-resizable**: Controls whether users can manually resize the field
* **Fixed height/Auto-expanding**: Controls whether the textarea grows with content or uses scrollbars

***

### Accessibility

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Textarea component has been tested against WCAG 2.2 standards with the following results:

The Textarea component meets WCAG 2.2 compliance requirements, with specific tests for:

| WCAG Criterion                   | Level | Status |
| -------------------------------- | ----- | ------ |
| **1.3.1 Info and Relationships** | A     | Pass   |
| **1.3.5 Identify Input Purpose** | AA    | Pass   |
| **1.4.4 Resize text**            | AA    | Pass   |
| **1.4.12 Text Spacing**          | AA    | Pass   |
| **2.1.1 Keyboard**               | A     | Pass   |
| **2.1.2 No Keyboard Trap**       | A     | Pass   |
| **2.4.3 Focus Order**            | A     | Pass   |
| **2.4.7 Focus Visible**          | AA    | Pass   |
| **2.5.3 Label in Name**          | A     | Pass   |
| **2.5.8 Target Size (Minimum)**  | AA    | Fail   |
| **3.2.1 On Focus**               | A     | Pass   |
| **3.2.2 On Input**               | A     | Pass   |
| **3.3.2 Labels or Instructions** | A     | Pass   |
| **3.3.3 Error Suggestion**       | AA    | Pass   |
| **4.1.2 Name, Role, Value**      | A     | Pass   |
| **4.1.3 Status Messages**        | AA    | Pass   |

Note: The component fails the 2.5.8 Target Size (Minimum) criterion, which requires interaction targets to be at least 24 by 24 CSS pixels.

### Security

When implementing the Textarea component, consider the following security considerations:

* Implement proper input sanitization to prevent cross-site scripting (XSS) attacks
* Set appropriate character limits to prevent buffer overflow attacks
* Apply timeout features for forms containing sensitive information
* Ensure data submitted through textareas is properly validated server-side

These security considerations align with the requirements outlined in the Policy for the responsible use of AI in government v1.1, which emphasizes the importance of protecting user data when collecting input.

### Component inspiration and uplift

This component has been modelled after the Text input component in the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* CivicTheme's Textarea input field is presented with a thinner, 1px border for a cleaner look, while maintaining accessibility
* The component displays an additional interactive hover state with a 2px border (similar to ADS' default style)
* The handles for resizing the input are more prominent
* The Invalid inputs use new shades/hues for validation with both light and dark themes in mind
* Disabled text inputs are set back in opacity for clearer visual hierarchy

These uplifts are based on user research findings that showed the need for more consistent visual hierarchy and improved interactive states across form elements.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by multiple rounds of testing)

User research conducted on the Textarea component has shown several key findings:

* Users appreciate the resizable nature of textareas, particularly when entering longer content
* The visual distinction between focus, hover, and invalid states helps users understand the current state of the component
* Some users with motor impairments reported challenges with the resize handles
* The more prominent visual treatment of invalid states helped users identify and correct errors more quickly

Research included usability testing with diverse participants across multiple devices and platforms, ensuring the component meets the needs of a wide range of users.

### Known issues

* **Resize handle usability**: The resize handle can be difficult to use for people with motor impairments or when using certain touchscreen devices
* **Character count visibility**: When character counters are implemented, they can sometimes be overlooked by users
* **Mobile experience**: On mobile devices, textareas can sometimes be difficult to interact with due to virtual keyboard issues
* **Target size**: As noted in the accessibility assessment, the component fails the WCAG 2.2 criterion for minimum target size (2.5.8)

### More research needed

More user research is needed in the following areas:

* Optimizing the resize functionality for touchscreen devices
* Understanding user expectations for auto-expanding textareas versus fixed height with scrollbars
* Testing different approaches to character count indicators and validation feedback
* Exploring solutions to address the 2.5.8 Target Size failure for better accessibility compliance

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Textarea component discussion
* Submit your user research findings to help improve the Textarea component
* Propose a change to address known accessibility issues, particularly the target size requirement
* Help develop better responsive behaviors for mobile experiences

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43079\&t=b83UZlIpwPkLMi9E-1)
* Storybook
* GitHub

### References

* W3C Web Content Accessibility Guidelines (WCAG) 2.2
* Australian Government Style Manual
* Australian Government Design System documentation
* Digital Service Standard (DSS) requirements
* Nielsen Norman Group: Form Design Guidelines

### Changelog

<table><thead><tr><th width="113.52734375">Version</th><th width="160.45703125">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed from Text Inputs: Text Area to Textarea, added outline to focus state, removed active state variant</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated to improve WCAG 2.2 compliance</td></tr><tr><td>1.6.0</td><td>[Previous date]</td><td>Initial component release</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Text field

The Textfield component is a form input element that allows users to enter and edit single-line text, providing visual feedback on the input state.

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43079&t=mpeAG9TsCSheJs4e-1>" %}

### When to use

Use the Textfield component when you need to collect single-line text input from users, such as names, email addresses, search queries, or other short form data. Textfields are essential for forms and interactive interfaces where user input is required.

### When not to use

Do not use the Textfield component when:

* The user needs to enter multiple lines of text - use a Textarea component instead
* The input is limited to a specific format with validation (such as dates or numeric values) - consider using a specialised input type
* The user needs to select from pre-defined options - use radio buttons, checkboxes, or select menus instead
* The input data requires enhanced security (such as passwords) - use a specialised password field with appropriate security measures

***

### Best practice guidelines

* **Clear labelling:** Always provide a clear, descriptive label for each textfield that indicates what information is required.
* **Input validation:** Implement appropriate validation with clear error messages to help users correct input errors.
* **Visual states:** Ensure textfields have distinct visual states (default, hover, focus, disabled, invalid) to provide clear feedback to users.
* **Responsive design:** Design textfields to adapt appropriately to different screen sizes and device types.
* **Accessibility:** Ensure textfields are accessible to all users, including those using assistive technologies.
* **Consistent styling:** Maintain consistent styling of textfields throughout your interface to provide a cohesive user experience.
* **Placeholder text:** Use placeholder text to provide hints or examples, but never as a replacement for labels.
* **Field width:** Set appropriate field widths that correspond to the expected input length to provide visual cues about the expected content.
* **Required fields:** Clearly indicate which fields are required versus optional to set clear expectations for users.
* **Error recovery:** Provide clear error messages and guidance for recovery when input validation fails.

***

### Accessibility

According to the CivicTheme v1.7.0 Accessibility Assessments, the Textfield component has been tested against WCAG 2.2 standards. The component passes most accessibility requirements but fails on target size requirements.

Summary of the accessibility test results:

<table><thead><tr><th width="235.59375">WCAG 2.2 Criterion</th><th width="96.609375">Status</th><th>Details</th></tr></thead><tbody><tr><td>1.4.3 Contrast (Minimum)</td><td>Pass</td><td>Contrast meets minimum requirements</td></tr><tr><td>1.4.4 Text Resizing</td><td>Pass</td><td>Text can be resized without loss of content or functionality</td></tr><tr><td>1.4.12 Text Spacing</td><td>Pass</td><td>Content can be presented without loss when text spacing is adjusted</td></tr><tr><td>2.1.1 Keyboard Accessibility</td><td>Pass</td><td>Functionality is operable through a keyboard interface</td></tr><tr><td>2.4.7 Focus Visibility</td><td>Pass</td><td>Keyboard focus indicator is visible</td></tr><tr><td>2.5.3 Label in Name</td><td>Pass</td><td>Component passes label in name requirements</td></tr><tr><td>3.2.2 Input Handling</td><td>Pass</td><td>Changing the setting of any user interface component does not automatically cause a change of context</td></tr><tr><td>2.5.8 Target Size (Minimum)</td><td>Fail</td><td>The size of the target for pointer inputs does not meet the minimum requirement of 24 by 24 CSS pixels</td></tr></tbody></table>

### Security

When implementing Textfield components, consider these security aspects:

* Implement proper input sanitisation to prevent cross-site scripting (XSS) attacks
* Use appropriate form validation on both client and server sides
* Consider data privacy implications when collecting personal information
* Follow secure coding practices to prevent data leakage or unauthorised access

### Component inspiration and uplift

This component has been modelled after the Text Input component from the former Australian Government Design System (AGDS). According to the CivicTheme AGDS Compliance Statements document, the Textfield component has been uplifted in the following ways:

* A thinner 1px border is used in the resting state for a cleaner, more accessible look
* A darker background colour is applied to balance the thinner border and distinguish from the body background
* An additional hover state is included which presents a 2px border (matching the original AGDS appearance)
* Invalid inputs use distinct colour variations for better contrast ratios in both light and dark themes
* Disabled text inputs are set back in opacity while maintaining sufficient contrast
* Input widths can be configured according to the original AGDS guidelines

These enhancements improve both usability and accessibility while maintaining compatibility with the original AGDS design principles.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by research but with some limitations)

Based on the available information and applying the evaluation criteria from the scoring guidance, the Textfield component shows strong usability characteristics but has known accessibility limitations around target size.

The component follows established design patterns that have been validated through testing across multiple government design systems. Textfields represent a fundamental form element with well-established usage patterns, and CivicTheme's implementation incorporates best practices for input validation, visual states, and feedback mechanisms.

The component shows strong visual design with appropriate contrast levels and properly implemented states (default, hover, focus, invalid, disabled) that clearly communicate the component's status to users. However, the identified target size issue affects the component's accessibility score.

### Known issues

* **Target size limitations:** As noted in the accessibility assessment, the Textfield component fails to meet WCAG 2.2 requirements for minimum target size (24x24 CSS pixels).
* **Mobile usability challenges:** On smaller screens, textfields may be more difficult to interact with due to the limited target size, potentially causing input errors.
* **Responsive behaviour:** More testing may be needed to ensure consistent behaviour across all viewport sizes and device types.

### More research needed

Additional research would be beneficial in the following areas:

* Testing with users who have motor control difficulties to assess the impact of the target size issue
* Evaluating performance with various input methods (touch, stylus, keyboard, voice)
* Testing with diverse user groups to ensure the component works effectively across different contexts and use cases
* Assessing how the component performs as part of complex form implementations

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to discussions about addressing the target size accessibility issue
* Submit user research findings that could improve the Textfield implementation
* Propose code changes to enhance the component's accessibility and usability
* Test the component across different devices and contexts and report findings

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43078\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2019). Form Design Guidelines](https://www.nngroup.com/articles/form-design/)
* [W3C. (2022). Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* [Digital Service Standard (2023)](https://www.dta.gov.au/help-and-advice/digital-service-standard)
* [Australian Government Style Manual](https://www.stylemanual.gov.au/)

### Changelog

<table><thead><tr><th width="110.53125">Version</th><th width="136.765625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Text Inputs: Text Field to Textfield, added outline to focus state and removed active state variant</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated for WCAG 2.2 compliance assessment</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Heading

Headings provide hierarchical structure to content, allowing users to quickly understand and navigate information on a page.

### When to use

Use headings to:

* Create a clear hierarchy and structure for your content
* Help users scan and navigate content quickly
* Break up large blocks of text to improve readability
* Establish relationships between sections of content
* Support SEO by clearly structuring your content

### When not to use

Do not use headings when:

* You want to emphasise text without creating a new section or topic (use other text styling instead)
* You need decorative text that doesn't serve a structural purpose
* You want to create visual hierarchy without semantic meaning
* You simply want larger or bolder text without indicating a new section

***

### Best practice guidelines

* **Maintain hierarchy**: Always use headings in the correct order (H1, H2, H3, etc.) without skipping levels to maintain a logical content structure
* **Be descriptive**: Headings should accurately describe the content that follows
* **Keep it concise**: Aim for short, scannable headings (ideally under 80 characters)
* **Consistency matters**: Use similar phrasing patterns for headings at the same level
* **Avoid orphaned headings**: Don't place headings at the bottom of pages or sections without following content
* **Limit H1 usage**: Generally use only one H1 per page, representing the main page title
* **Consider SEO**: Include relevant keywords naturally, but avoid keyword stuffing
* **Mobile considerations**: Ensure headings remain readable at smaller screen sizes

These guidelines are derived from established content design principles and accessibility standards for government websites, including those from the Australian Government Style Manual.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2947-37042&t=mpeAG9TsCSheJs4e-1>" %}

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with the following key results based on the Accessibility Assessments file:

<table><thead><tr><th width="238.1875">WCAG Criterion</th><th width="85.32421875">Level</th><th width="95.54296875">Status</th><th>Notes</th></tr></thead><tbody><tr><td>1.3.1 Info and Relationships</td><td>A</td><td>Pass</td><td>Headings are properly marked up to convey structure</td></tr><tr><td>1.4.3 Contrast (Minimum)</td><td>AA</td><td>Pass</td><td>Heading text meets the minimum contrast ratio of 4.5:1</td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Pass</td><td>Headings remain readable when text is resized up to 200%</td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>Pass</td><td>Headings remain visible/readable with adjusted text spacing</td></tr><tr><td>2.4.6 Headings and Labels</td><td>AA</td><td>Pass</td><td>Headings accurately describe topic or purpose</td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Pass</td><td>Focus is visible when navigating using a keyboard</td></tr></tbody></table>

All tests for link headings also pass accessibility requirements, ensuring that interactive headings are properly accessible.

### Security

No specific security considerations apply to this component as it is primarily presentational and does not process user data.

### Component inspiration and uplift

This atomic element has been modelled after the Headings component in the former Australian Government Design System (AGDS). CivicTheme has uplifted the component in the following manner:

* All headings use the commercial-free Lexend font family as the primary web font, designed with variable, extended scaling to improve reading fluency and character recognition
* Supports a complete hierarchy from H1 to H6
* Headings are available in two states: default (without link) and link (with link)
* Previous styling included display headings, which have been removed in favour of a more logical H1-H6 structure that aligns better with SEO principles
* Simplified states by embedding the Link component inside Heading when needed, which automatically applies link interaction states to the Heading

These uplifts align with the Digital Service Standard requirements for clear, accessible content structure (Criteria 3: Leave no one behind) and build trust in design (Criteria 5) through consistent, recognisable patterns.

***

### Research on this component

★★★★☆ Confidence rating = High (Informed by extensive testing and established patterns)

While specific user research data isn't available exclusively for the Heading component, this component benefits from extensive research and established patterns in digital content design. Headings represent one of the most well-researched elements in digital interfaces.

Research consistently shows that:

* Users scan content rather than reading word by word, making properly structured headings critical for comprehension
* Clear heading hierarchy significantly improves information findability
* Screen reader users heavily rely on headings to navigate content efficiently
* Properly structured headings improve SEO performance

The component follows established best practices derived from extensive government and industry research into content readability and accessibility.

### Known issues

* **Responsive consistency**: When headings wrap to multiple lines on mobile devices, the visual hierarchy can sometimes appear inconsistent, particularly with longer headings
* **Alignment variations**: In certain contexts, heading alignment (left, center, right) may cause readability issues if not applied consistently
* **Heading links**: When headings contain links, users sometimes have difficulty identifying the clickable area, particularly when only part of the heading is linked

### More research needed

More user research would be beneficial in the following areas:

* Optimal heading sizes and spacing across different device types and screen sizes
* User preferences for heading styles in different content contexts (formal documentation vs. news content vs. service content)
* How heading styles impact reading comprehension and retention for different user groups
* The effectiveness of various heading formats in multilingual contexts

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to discussions about heading implementation on the CivicTheme GitHub repository
* Submit examples of effective heading implementations on your CivicTheme site
* Propose improvements to the heading styles or structure based on user research
* Report any accessibility or usability issues you encounter with this component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2947-37042\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* Australian Government Style Manual. [headings and subheadings](https://www.stylemanual.gov.au/format-writing-and-structure/structure/headings-and-subheadings)
* W3C Web Accessibility Initiative. [headings](https://www.w3.org/WAI/tutorials/page-structure/headings/)
* Nielsen Norman Group. [How Users Read on the Web](https://www.nngroup.com/articles/how-users-read-on-the-web/)
* Lexend. [Reading research](https://www.lexend.com/)

### Changelog

<table><thead><tr><th width="101.91796875">Version</th><th width="147.6015625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.0.0</td><td>Initial release</td><td>Base heading styles established</td></tr><tr><td>1.7.0</td><td>2024-03-20</td><td>Updated to support WCAG 2.2</td></tr><tr><td>1.8.0</td><td>2024-07-23</td><td>Renamed "Headings" to "Heading" component</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Link

A link allows users to navigate to related content, either within the current page, elsewhere on the site, or on external sites.

### When to use

Use links when you need to:

* Connect users to related content or functionality
* Provide navigation between pages within your website
* Direct users to external resources or websites
* Create in-page navigation to different sections
* Provide supplementary information without disrupting the primary content flow

### When not to use

Do not use links when:

* The action will change or manipulate data - use a button instead
* The interaction initiates a process or workflow - use a button instead
* Multiple actions are required in a form - use buttons to clearly indicate submission and cancellation
* The primary call to action needs to be emphasised - consider using a button which has greater visual prominence
* Text simply needs emphasis without navigation - use appropriate text styling instead

***

### Best practice guidelines

* **Descriptive text**: Write link text that clearly describes where the link will take the user. Avoid generic phrases like "click here" or "read more".
* **Length**: Keep link text concise but descriptive enough to make sense when read out of context.
* **Consistency**: Maintain consistent styling for links throughout your site to help users identify them.
* **States**: Implement all link states (default, hover, active, focus, visited) to provide users with appropriate visual feedback.
* **External links**: Clearly indicate when a link will take users to an external site using an icon and/or text.
* **Underlines**: Use underlines to help differentiate links from surrounding text, particularly within paragraphs.
* **Colour contrast**: Ensure links have sufficient contrast against their background (4.5:1 minimum) and are distinguishable from surrounding text through means other than colour alone.
* **Focus indicators**: Provide visible focus indicators that meet WCAG 2.2 standards for keyboard users.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3545-132879&t=mpeAG9TsCSheJs4e-1>" %}

The CivicTheme Link component includes the following variations:

* **Icon position**: Links can be displayed with icons at the start, end, or with no icon
* **States**: Default, hover, active, active hover, focus, focus hover, visited, and disabled states
* **Content vs. non-content links**: CivicTheme distinguishes between content links (within body text) and non-content links (navigation, utility links)

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with tests conducted against the standards.

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Link component has been tested against the following WCAG 2.2 criteria:

| WCAG Criterion                  | Level | Status |
| ------------------------------- | ----- | ------ |
| 1.3.1 Info and Relationships    | A     | FAIL   |
| 1.4.1 Use of Colour             | A     | PASS   |
| 1.4.3 Contrast (Minimum)        | AA    | PASS   |
| 1.4.4 Resize text               | AA    | PASS   |
| 1.4.11 Non-text Contrast        | AA    | PASS   |
| 1.4.12 Text Spacing             | AA    | PASS   |
| 2.1.1 Keyboard                  | A     | PASS   |
| 2.4.4 Link Purpose (In Context) | A     | PASS   |
| 2.4.6 Headings and Labels       | AA    | PASS   |
| 2.4.7 Focus Visible             | AA    | PASS   |
| 3.2.2 On Input                  | A     | PASS   |
| 3.2.3 Consistent Navigation     | AA    | PASS   |
| 3.2.4 Consistent Identification | AA    | PASS   |

One issue noted in the assessment: links that open in a new tab/window should alert the user (1.3.1 Info and Relationships - FAIL).

### Security

Security considerations for links include:

* External links should be carefully vetted to ensure they point to secure and trusted resources
* Implement proper validation to prevent malicious URLs
* Consider using rel="noopener noreferrer" on external links to prevent potential exploitation
* Monitor linked content regularly to ensure it remains appropriate and secure

### Component inspiration and uplift

This component has been modelled after the Main Nav component from the Australian Government Design System (AGDS). CivicTheme has uplifted the Link component in the following ways:

* Used the AGDS Main Nav component as the primary reference for all non-content links
* Added SemiBold text weight for better visibility and distinction
* Added left and right icon variants to clearly communicate different link actions
* Created a distinction between content links (used within body text) and non-content links (used in navigation and other UI elements)
* Enhanced focus states to improve accessibility compliance
* Implemented consistent hover and active states for better user feedback

These uplifts support the Digital Service Standard (DSS) requirements for building trust in design (Criterion 5) by providing clear visual cues about interactivity and consistency.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Based on indirect evidence)

Limited direct user research is available specifically for the CivicTheme Link component. However, the component's design decisions are informed by well-established accessibility standards and widely accepted usability principles for web links.

Research on similar link implementations across government websites indicates that users:

* Expect links to be visually distinct from regular text
* Benefit from clear visual indicators for external links
* Rely on consistent styling to identify clickable elements
* Need clear focus states for keyboard navigation

More dedicated research with end-users of CivicTheme implementations would strengthen confidence in this component's effectiveness.

### Known issues

* **External link indication**: The current implementation for signalling external links may not be sufficiently clear for all users, particularly when icons are disabled.
* **Mobile interaction areas**: Some link variants may have touch targets smaller than the recommended size on mobile devices, potentially creating difficulties for users with motor control limitations.
* **Link vs. button distinction**: There can be confusion between when to use links versus buttons, which may lead to inconsistent implementation across a site.

### More research needed

More user research would be beneficial in the following areas:

* Comparing effectiveness of different icon placements (left, right, none) for various use cases
* Testing comprehension of external link indicators across different user groups
* Evaluating the performance of different link states (particularly visited links) on user navigation efficiency
* Understanding user expectations and preferences for in-page links versus page navigation links
* Testing the impact of different focus styles on accessibility for keyboard and screen reader users

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to our link component discussion
* Submit user research findings to help improve the link component
* Propose a change to the link component design or implementation

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* Figma
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2020). Guidelines for Visualizing Links](https://www.nngroup.com/articles/guidelines-for-visualizing-links/)
* [W3C Web Accessibility Initiative. (2023). Link Purpose (In Context): Understanding SC 2.4.4.](https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-context.html)
* [Digital Transformation Agency. (2023). Digital Service Standard - Criterion 5: Build trust in design](https://www.dta.gov.au/help-and-advice/digital-service-standard/digital-service-standard-criteria/5-build-trust-design)

### Changelog

<table><thead><tr><th width="130">Version</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>Recategorised from Main Navigation to Atoms</td></tr><tr><td>1.7.0</td><td>Enhanced focus states for better accessibility compliance</td></tr><tr><td>1.6.0</td><td>Added support for icon positioning</td></tr><tr><td>1.5.0</td><td>Improved contrast ratios for all states</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Paragraph

Paragraph is a fundamental text element that presents content in structured blocks, enabling clear communication of information using CivicTheme's typography system.

### When to use:

Use the paragraph component when you need to present textual content in a structured format. Paragraphs are essential for:

* Main body content across web pages
* Descriptive text within components like cards, callouts, and banners
* Explanatory information alongside forms and interactive elements
* Terms and conditions, privacy policies, and other legal content
* Instructional content and step-by-step guides

### When not to use:

Do not use the paragraph component when:

* A heading would be more appropriate for section titles or page headings
* A list (ordered or unordered) would better present information in a scannable format
* Information can be better presented through tables, graphics, or other visual formats
* Content requires special formatting such as code snippets or blockquotes

***

### Best practice guidelines:

* Readability: Keep paragraphs concise—ideally 3-5 sentences—to improve readability and comprehension. Break longer content into multiple paragraphs.
* Logical structure: Start with the most important information and use paragraphs to group related ideas together, following a logical flow.
* Plain language: Write in plain language, avoiding jargon and complex terminology where possible. This aligns with the Australian Government Style Manual guidelines for clear communication.
* Appropriate styling: Use the right size and weight variant for the context. Lead copy (larger paragraphs) works well as introductions, while body copy is suitable for main content.
* Responsive considerations: Ensure paragraph text remains readable across all device sizes by maintaining appropriate line lengths (50-75 characters per line is ideal).
* White space: Maintain adequate spacing between paragraphs to create visual separation and improve readability.
* Consistency: Maintain consistent styling of paragraphs throughout your site to establish visual hierarchy and improve user comprehension.

### Variations:

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2947-38330&t=b83UZlIpwPkLMi9E-1>" %}

CivicTheme provides various paragraph styles to serve different content needs:

* Size variants: Extra large, large, regular, small
* Weight variants: Regular, bold
* Style variants: Regular, underline

These variants can be combined to create different text presentations suitable for different contexts, such as lead paragraphs, body text, captions, and footnotes.

***

### Accessibility:

This component meets WCAG 2.2 AA accessibility guidelines according to the CivicTheme v1.7.0 Accessibility Assessments.

| WCAG 2.2 Criterion       | Status | Level    |
| ------------------------ | ------ | -------- |
| 1.4.3 Contrast (Minimum) | Pass   | Level AA |
| 1.4.4 Resize text        | Pass   | Level AA |
| 2.1.1 Keyboard           | Pass   | Level A  |
| 1.4.12 Text Spacing      | Pass   | Level AA |

This ensures all paragraph text has sufficient contrast, can be resized up to 200% without loss of content, and maintains readability when text spacing is adjusted.

### Security:

Security data not available for this component.

### Component inspiration and uplift:

This component has been modelled after the Body component in the former Australian Government Design System (AGDS). CivicTheme has uplifted the component in the following ways:

* All typography uses the commercially free Lexend font family as the primary web font, which is specifically designed to improve reading fluency and character recognition.
* Body copy is restricted to 12-15 words per line, in line with Web Content Accessibility Guidelines recommendations of 80 characters (or less) per line.
* Paragraph breaks have been refined to span 1.5 times the height of a traditional line break, improving readability through appropriate white space.
* Anchored links use a background colour on hover state, rather than a standard underline or colour change, enhancing visibility of interactive elements.

The sans-serif Lexend font family with variable, extended scaling specifically aims to improve reading fluency, addressing the finding that over 60% of people experience some reading difficulty.

***

### User research on this component:

★★★★☆ Confidence rating = High (Informed by design system best practices and accessibility standards)

While there is no specific user research data available exclusively for the paragraph component in CivicTheme, its design is informed by well-established typography and readability standards. The component incorporates research findings about reading patterns, optimal line length, and spacing considerations that have been validated across numerous studies.

The choice of the Lexend font family was backed by specific research showing its effectiveness for reading fluency. Research led by Dr. Bonnie Shaver-Troup in 2000 demonstrated that sans-serif fonts with expanded scaling improve character recognition and reduce cognitive noise, benefiting a wide range of readers.

### Known issues:

* Line height considerations: In some contexts, the standard line height may need adjustment when paragraph text is displayed alongside other components with specific spacing requirements.
* Mobile text scaling: On extremely small screens, some paragraph variations may benefit from further size adjustments to maintain optimal readability.
* Multilingual support: When displaying content in languages that use different writing systems, additional considerations for font rendering and spacing may be needed.

### More research needed:

More user research is needed in the following areas:

* Performance impact of font loading strategies for the Lexend variable font family across different browsers and devices
* User preferences regarding optimal line length across different contexts and content types
* Effectiveness of different paragraph styles for improving comprehension of complex information
* Reading patterns and preferences for multilingual users accessing content in multiple languages

### Help improve this component:

To help make this component useful and up-to-date, you can:

* Contribute to our paragraph component discussion
* Submit your user research findings to help improve the paragraph component
* Propose a change to the paragraph component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources:

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2947-38330\&t=b83UZlIpwPkLMi9E-1)
* Storybook
* GitHub

### References:

* The Reading Teacher - Research on reading fluency and text formatting
* Lexend.com - Research on font readability and cognitive processing
* Australian Government Style Manual - Guidelines for clear writing and content structure
* Nielsen Norman Group - Research on reading patterns and optimal text presentation

### Changelog:

The paragraph component has evolved through various iterations of the CivicTheme design system to improve readability, accessibility and usability. Key changes include refinements to spacing, responsive behavior, and typography settings.

### Contact us:

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Popover

A popover is a contextual overlay that displays additional content or interactive elements when triggered by a user action, without requiring navigation away from the current screen.

### When to use

Use the popover component when you need to:

* Show additional information that would clutter the main interface if displayed permanently
* Present form elements such as radio buttons, checkboxes, or text inputs within a contextual dropdown
* Provide supplementary options or actions related to a specific element
* Display filtering controls that don't need to be visible at all times
* Create accessible dropdown menus with complex interaction patterns

### When not to use

Do not use the popover component when:

* The content is critical to the main user flow and should be immediately visible
* The information is extensive and would require significant scrolling within the popover
* You need to display complex interactions that would benefit from a dedicated page or modal
* Navigation to a new section or page would be more appropriate
* Multiple popovers would need to be open simultaneously, creating confusion

***

### Best practice guidelines

* **Clear triggering mechanism**: Ensure the element that triggers the popover clearly indicates its interactive nature through appropriate styling, iconography, and hover states.
* **Positioning and context**: Position the popover close to its triggering element to maintain context while ensuring it doesn't obscure important content.
* **Dismissal options**: Provide multiple ways to dismiss the popover, including clicking outside, pressing the Escape key, and including a close button for touch devices.
* **Content structure**: Organise content within the popover logically, with clear headings and concise text. Consider the popover's size and avoid overcrowding.
* **Responsive behaviour**: Design popovers to adapt to different screen sizes, potentially repositioning or reformatting on smaller screens to maintain usability.
* **Focus management**: Trap keyboard focus within the popover when open and return focus to the triggering element when closed to support accessibility.
* **Animation**: Use subtle animation for opening and closing to provide visual cues about the popover's appearance and disappearance without being distracting.
* **Consistency**: Maintain consistent styling, behaviour, and interaction patterns across all popovers within your application.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=5162-176554&t=pgR0cOKiZtpSZwCB-1>" %}

**Popover alignment**:

* Different alignment options (top, right, bottom, left) allow the popover to appear in the most appropriate position relative to the triggering element.

### **Content types**:

* Form elements: Contains form controls such as radio buttons, checkboxes, or text inputs
* Information: Displays additional contextual information or help text
* Action menu: Provides a list of actions or options related to the triggering element

***

### Accessibility

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Popover component demonstrates good accessibility compliance with the following results:

| WCAG Criterion                      | Level | Status |
| ----------------------------------- | ----- | ------ |
| 1.4.3 Contrast (Minimum)            | AA    | Pass   |
| 1.4.4 Resize text                   | AA    | Pass   |
| 1.4.12 Text Spacing                 | AA    | Pass   |
| 2.1.1 Keyboard                      | A     | Pass   |
| 2.4.7 Focus Visible                 | AA    | Pass   |
| 2.4.11 Focus Not Obscured (Minimum) | AA    | Pass   |
| 4.1.2 Name, Role, Value             | A     | Pass   |

This component supports the Digital Service Standard requirement to "Leave no one behind" by ensuring keyboard accessibility and proper focus management.

### Security

The Popover component itself doesn't present specific security concerns, but implementers should be aware that any form elements within popovers should follow standard security practices for form handling and input validation.

### Component inspiration and uplift

This component has been modelled after the Fieldset component from the former Australian Government Design System (AGDS). According to the CivicTheme documentation, it has been uplifted in the following ways:

* Applied a popover behaviour to the Fieldset component, which can be used in various areas across the CivicTheme design system, such as the Group Filter dropdown
* Provided configuration options to switch between radio blocks, checkbox blocks, and text input blocks

As noted in the CivicTheme documentation: "The browser's native dropdown lacked the tools to show multiple form elements. For example, it was not possible to display both an input field (for filtering) and a long list of attributes within the same native dropdown. This required a more robust solution in the form of an accessible design that CivicTheme could holistically control."

***

### User research on this component

**Confidence rating: Low (Limited evidence)**

No specific user research data is directly available for the CivicTheme Popover component. The rating is based on general usability principles and common patterns observed in similar components.

The limited research available suggests that popovers are effective when they:

* Clearly indicate their triggering mechanism
* Appear in a predictable location relative to the trigger
* Provide intuitive ways to dismiss
* Handle keyboard interactions appropriately

More dedicated research for this specific implementation would be valuable to increase confidence.

### Known issues

* **Mobile interaction challenges**: On small screens, popovers may not have sufficient space to display properly, potentially leading to content being cut off or difficult to interact with.
* **Focus management complexity**: Ensuring proper focus management in all scenarios (including screen reader usage) can be technically challenging to implement correctly.
* **Responsive positioning**: The component may struggle to position itself optimally on very small screens or in constrained layout situations.

### More research needed

More user research is needed in the following areas:

* Touch interactions on mobile devices, particularly regarding dismissal patterns and touch accuracy
* Screen reader user experiences with the popover and its various content types
* User expectations around popover positioning and behaviour across different contexts
* Performance impact when using multiple popovers in a single interface
* Optimal sizing guidelines for various content types and screen sizes

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our popover component discussion
* Submit your user research findings to help improve the popover component
* Propose a change to the popover component via the CivicTheme GitHub repository

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=5162-176554\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* Nielsen Norman Group. (2018). "Tooltip Guidelines." <https://www.nngroup.com/articles/tooltip-guidelines/>
* W3C. (2023). "Web Content Accessibility Guidelines (WCAG) 2.2." <https://www.w3.org/TR/WCAG22/>
* WebAIM. (2021). "Dropdown Accessibility." <https://webaim.org/techniques/dropdowns/>

### Changelog

<table><thead><tr><th width="123.03515625">Version</th><th width="155.48828125">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>20 March 2024</td><td>Accessibility updates for WCAG 2.2 compliance</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Quote

The Quote component displays distinctive text with attribution, visually separated from regular content to emphasise important statements or testimonials.

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3539-120946&t=mpeAG9TsCSheJs4e-1>" %}

### When to use

Use the Quote component when you need to:

* Highlight or emphasise a direct quotation from a person or publication
* Feature testimonials from users, stakeholders, or partners
* Showcase important statements that deserve special attention
* Break up large blocks of content to add visual interest and improve readability

### When not to use

Do not use the Quote component when:

* The statement is not a direct quotation or does not have an attributed source
* The content should be displayed as standard body text without special emphasis
* The text is too lengthy or contains multiple paragraphs, as quotes work best with concise content
* You need to display code snippets (use a code component instead)

***

### Best practice guidelines

* **Keep quotes concise**: Quotes should be relatively short and to the point. Long quotes can lose impact and disrupt the reading flow.
* **Always include attribution**: Include the source of the quote to provide context and credibility. This could be a person's name, title, organisation, or publication source.
* **Maintain visual distinction**: Quotes should be visually distinct from the surrounding content, using elements like vertical bars, indentation, or background styling to clearly separate them.
* **Preserve original wording**: When quoting directly, maintain the exact wording of the original statement. If edits are needed for clarity or length, use ellipses (...) to indicate omissions.
* **Consider placement carefully**: Position quotes strategically within content to enhance rather than interrupt the flow of information. Quotes can work well to introduce a section, punctuate important points, or summarise key messages.
* **Ensure accessibility**: Make sure that the visual styling of quotes maintains sufficient contrast and that any decorative elements don't interfere with screen readers.

***

### Accessibility

The Quote component has been assessed against WCAG 2.2 accessibility guidelines. According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Quote component passes the following standards:

<table><thead><tr><th width="233.57421875">WCAG 2.2 Criterion</th><th width="85.25">Level</th><th>Description</th></tr></thead><tbody><tr><td>1.3.1 Info and Relationships</td><td>A</td><td>Information, structure, and relationships conveyed through presentation can be programmatically determined</td></tr><tr><td>1.4.3 Contrast (Minimum)</td><td>AA</td><td>Text and images of text have sufficient contrast against their background</td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Text can be resized without assistive technology up to 200% without loss of content or functionality</td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>No loss of content or functionality occurs when text spacing is adjusted</td></tr><tr><td>2.1.1 Keyboard</td><td>A</td><td>All functionality is operable through a keyboard interface</td></tr><tr><td>2.4.3 Focus Order</td><td>A</td><td>Components receive focus in an order that preserves meaning and operability</td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Keyboard focus indicator is visible on the interface element that has focus</td></tr></tbody></table>

The component is designed to maintain appropriate contrast, be navigable via keyboard, and retain proper structure and relationships when interpreted by assistive technologies.

### Security

No specific security concerns exist for this component as it is a static presentational element. Standard content sanitisation practices should be applied when the quote contains user-generated or externally sourced content.

### Sites using this component

The Quote component is widely used across government websites, educational institutions, and corporate sites that implement the CivicTheme design system. As this is a fundamental component for displaying testimonials and significant statements, it appears in various content-rich environments.

### Component inspiration and uplift

This component has been modelled after the Default Callout component from the former Australian Government Design System (AGDS). CivicTheme has uplifted the component in the following ways:

* Rather than present a heading and body copy as the foundations of the component, the Quote component uses larger body copy for the quote and smaller citation copy to cite the source of the quote
* The component leverages the style and treatment of the Callout component to present quotes that creators may want to highlight within the content of the page
* A distinctive vertical bar design element has been added to visually differentiate quotes from surrounding content

The Quote component helps to separate large amounts of text into smaller, readable blocks, applying the concept of "chunking" from cognitive psychology to improve content processing and readability.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Based on indirect evidence and established design patterns)

While no specific user research data is available for this exact implementation of the Quote component in CivicTheme, the design follows established patterns that have been validated through research in other contexts. The component builds on well-established design patterns for displaying quotations that have been demonstrated to be effective across various digital platforms.

User testing on similar quote components in other design systems has shown that users appreciate the visual distinction that sets quotes apart from regular content, making important statements more memorable and impactful.

More targeted research specific to this implementation would help validate its effectiveness within the CivicTheme ecosystem.

### Known issues

* Responsive behaviour: On smaller mobile screens, longer quotes may create readability challenges if not properly handled
* Attribution alignment: When attribution text is lengthy, it may wrap in ways that affect the visual balance of the component
* Visual distinction: In some contexts, the visual styling of the quote may not provide sufficient distinction from surrounding elements

### More research needed

Research is needed in the following areas:

* User comprehension: How effectively do users distinguish between quoted content and regular text across different contexts?
* Optimal quote length: What is the ideal length for quotes before user engagement decreases?
* Attribution placement: What attribution placement (bottom, right, inline) is most effective for different types of quotes?
* Responsive design: How can the quote component best adapt to various screen sizes while maintaining impact?

If you have conducted user research that addresses any of these gaps, please consider contributing your findings to help improve this component.

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to our quote component discussion on GitHub
* Submit your user research findings to help improve the quote component
* Propose a change to the quote component through a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3539-120946\&t=b83UZlIpwPkLMi9E-1)
* Storybook
* GitHub

### References

* Nielsen Norman Group. (2019). [How Chunking Helps Content Processing](https://www.nngroup.com/articles/chunking/)
* Web Content Accessibility Guidelines (WCAG) 2.2. (2023). [1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG22/#info-and-relationships)
* Web Content Accessibility Guidelines (WCAG) 2.2. (2023). [1.4.3 Contrast (Minimum)](https://www.w3.org/TR/WCAG22/#contrast-minimum)

### Changelog

<table><thead><tr><th width="103.89453125">Version</th><th width="168.9453125">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Recategorised from Molecules to Atoms</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Accessibility improvements for WCAG 2.2 compliance</td></tr><tr><td>1.6.0</td><td>15 Jan 2024</td><td>Initial component release</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Table

The table component displays information in a structured, grid-based format with rows and columns to help users efficiently compare and analyse data.

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39298&t=mpeAG9TsCSheJs4e-1>" %}

### When to use

Use the table component when you need to:

* Present structured data that users need to scan, compare, or analyse
* Display tabular information with clear relationships between data points
* Show information that naturally fits into rows and columns
* Present data that requires sorting, filtering, or other manipulation
* Help users find specific values or compare related data points

### When not to use

Do not use the table component when:

* The data doesn't have a logical row and column structure
* You need to display complex, hierarchical information that would be better represented in another format
* The information would be better communicated through a chart, graph, or other visual representation
* You have very large datasets that could overwhelm users (consider pagination or alternative visualisations)
* Mobile users are your primary audience and the table contains many columns (consider alternative presentations for small screens)

***

### Best practice guidelines

* **Structure and hierarchy**: Ensure your table has clear column headers that describe the data in each column. Use row headers when appropriate to identify each row.
* **Responsive design**: Design tables to be responsive, adapting to different screen sizes and devices. Consider how tables will display on mobile devices, potentially using horizontal scrolling, stacking, or collapsing techniques.
* **Accessibility**: Include a proper caption that describes the table's purpose and content. Use appropriate HTML elements (`<th>`, `<caption>`, etc.) and ARIA attributes to ensure screen readers can interpret the table correctly.
* **Visual clarity**: Use alternating row colours (striping) to help users track across rows, especially in wider tables. Maintain adequate spacing between cells for readability.
* **Interactive features**: When appropriate, implement sorting, filtering, and search functionality to help users navigate larger tables more effectively.
* **Content alignment**: Align text-based content to the left, and numerical data to the right to aid scanning and comparison.
* **Optional caption**: Include an optional caption field to provide context for the table content, which helps users understand the data being presented.

***

### Accessibility

This component meets WCAG 2.2 accessibility guidelines, with tests conducted against the standards. Based on the CivicTheme v1.7.0 Accessibility Assessments, the Table component has been thoroughly tested and passes the following criteria:

<table><thead><tr><th width="237.95703125">WCAG Criterion</th><th width="78.84375">Level</th><th>Description</th></tr></thead><tbody><tr><td>1.3.1 Info and Relationships</td><td>A</td><td>Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.</td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Text is still visible and readable when resized to at least 200%.</td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>Text is visible/readable when the line spacing is at least 1.5 times the font size, letter spacing is at least 0.12 times the font size, and word spacing is at least 0.16 times the font size.</td></tr><tr><td>2.1.1 Keyboard</td><td>A</td><td>Tables are accessible using a keyboard only.</td></tr><tr><td>2.1.2 No Keyboard Trap</td><td>A</td><td>There are no keyboard traps when navigating using a keyboard.</td></tr><tr><td>2.4.3 Focus Order</td><td>A</td><td>Focusable form fields receive focus in an order that preserves meaning and operability.</td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Focus is visible when navigating using a keyboard.</td></tr><tr><td>2.5.3 Label in Name</td><td>A</td><td>For table fields that contain labels the name contains the text that is presented visually.</td></tr><tr><td>3.2.1 On Focus</td><td>A</td><td>Focusable cells receive focus in an order that preserves meaning and operability.</td></tr><tr><td>3.3.2 Labels or Instructions</td><td>A</td><td>Detailed labels or instructions are provided when a table field requires user input.</td></tr><tr><td>3.3.3 Error Suggestion</td><td>AA</td><td>If an error is detected then suggestions are provided to the user to correct.</td></tr><tr><td>4.1.2 Name, Role, Value</td><td>A</td><td>For all form elements the name and role can be programmatically determined.</td></tr><tr><td>4.1.3 Status Messages</td><td>AA</td><td>All status messages can be programmatically determined.</td></tr></tbody></table>

### Security

No specific security concerns have been identified for this component. Standard web security practices should be followed when implementing interactive table features such as sorting or filtering.

### Component inspiration and uplift

This component has been modelled after the Table component in the Australian Design System (AGDS). CivicTheme has uplifted the component in the following ways:

* The striped variant of the CivicTheme table is enabled by default. Based on research findings that users found it easier to track across rows with alternating backgrounds, especially in data-heavy tables.
* All tables include an optional caption field. This addition helps improve accessibility by providing context for the table content.

These uplifts were based on user research findings which showed that the majority of CivicTheme's table usage has been for larger, more complex table structures. For these complex tables, the alternating striped variant was found to be more effective at helping users scan and interpret the data.

The caption field addition was included as a useful element to help describe the information presented within the table, and aligns with other government design systems, including Victoria's Ripple and NSW\.Digital.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by limited research with end users)

Based on available evidence, the Table component has undergone usability testing and evaluation, though not as extensively as some other components. Research findings indicate that users generally find the striped table variant easier to scan and navigate, especially when dealing with larger datasets.

Key insights from the research include:

* Users appreciate the improved readability offered by the alternating row colours
* The inclusion of captions provides helpful context for interpreting table data
* Mobile responsiveness remains a challenge, with some users expressing difficulty navigating wide tables on small screens

No detailed user research data is available specifically for this component's performance across different contexts or with diverse user groups.

### Known issues

* **Mobile usability**: Wide tables with many columns can create usability challenges on mobile devices, potentially requiring horizontal scrolling which some users find difficult to discover and use.
* **Complex data representation**: Tables with merged cells or complex hierarchical structures may present accessibility challenges for screen reader users.
* **Sorting and filtering**: While the base table component supports these features, implementation complexity increases when tables contain mixed data types or special formatting.

### More research needed

More user research is needed in the following areas:

* Comprehensive testing with users who have accessibility needs to ensure tables are fully usable with assistive technologies
* Evaluation of different responsive design approaches for tables on mobile devices
* Investigation of optimal data density and formatting for various types of tabular data
* How users interact with complex data manipulation features (sorting, filtering, pagination) within tables

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our table component discussion on GitHub
* Submit your user research findings to help improve the table component
* Propose a change to the table component through a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39298\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* Web Content Accessibility Guidelines (WCAG) 2.2 - Table Requirements
* Australian Government Design System - Table Component Guidelines
* Nielsen Norman Group - Data Tables Design Guidelines

### Changelog

## Table Component Version History

<table><thead><tr><th width="102.8125">Version</th><th width="157.890625">Release Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>• Standardized naming convention to "Table" from previous "Tables"</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>• Updated for WCAG 2.2 compliance</td></tr><tr><td>1.6.0</td><td>-</td><td>• Updated styling for improved mobile responsiveness</td></tr><tr><td>1.5.0</td><td>-</td><td>• Added support for optional captions</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Tag

Tags are visual indicators that categorise and label content, helping users quickly identify and filter information based on relevant attributes or topics.

### When to use

Use the Tag component when you need to:

* Categorise content by type, status, or topic to help users quickly scan and identify relevant information
* Allow users to filter content based on attributes or categories
* Highlight important metadata, such as content status, format, or other attributes
* Create a visual system for content classification that aids scanning and recognition
* Provide a consistent labelling system across different content types

### When not to use

Do not use the Tag component when:

* The action requires user interaction that changes system state (use buttons instead)
* The element is meant to navigate users to another page (use links instead)
* You need to display complex information that requires more context
* The interface already contains many visual elements and adding Tags would create visual clutter
* The categorisation is not meaningful to users or doesn't aid in comprehension or navigation

***

### Best practice guidelines

* **Consistency**: Use Tags consistently across your digital service to establish a clear visual language. Maintain consistent styling, sizing, and placement.
* **Clarity**: Keep Tag text concise and clear. Aim for 1-3 words that accurately describe the category or attribute.
* **Visual distinction**: Ensure Tags are visually distinct from buttons and other interactive elements to avoid confusion about their function.
* **Purposeful colour**: Use colour purposefully to convey meaning, but never rely solely on colour to communicate information. Ensure colour choices meet accessibility standards.
* **Limited quantity**: Avoid using too many Tags on a single piece of content. Too many Tags can overwhelm users and diminish their effectiveness.
* **Hierarchy**: If using different styles of Tags (primary, secondary, tertiary), establish a clear visual hierarchy that reflects the importance of the information.
* **Responsive design**: Ensure Tags adapt appropriately to different screen sizes without losing readability or purpose.
* **Contextual relevance**: Only use Tags that are relevant and helpful to users within the context they appear.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39379&t=mpeAG9TsCSheJs4e-1>" %}

* **Primary Tag**: Used for the most important categories or statuses
* **Secondary Tag**: Used for supporting categories or attributes
* **Tertiary Tag**: Used for supplementary information
* **With Icon**: Tags can include icons to enhance visual recognition
* **Without Icon**: Tags can be displayed without icons for simpler presentation

***

### Accessibility

Based on the CivicTheme v1.7.0 Accessibility Assessments document, the Tag component meets WCAG 2.2 AA accessibility guidelines, with the following test results:

<table><thead><tr><th>WCAG Criterion</th><th width="114.1875">Level</th><th width="96.9609375">Status</th><th>Notes</th></tr></thead><tbody><tr><td>1.4.3 Contrast (Minimum)</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>1.4.4 Resize text</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>1.4.11 Non-text Contrast</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>1.4.12 Text Spacing</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>2.1.1 Keyboard</td><td>A</td><td>Pass</td><td></td></tr><tr><td>2.4.4 Link Purpose (In Context)</td><td>A</td><td>Pass</td><td></td></tr><tr><td>2.4.7 Focus Visible</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>2.5.8 Target Size (Minimum)</td><td>AA</td><td>Fail</td><td>The size of the target for pointer inputs is less than the required 24 by 24 CSS pixels</td></tr><tr><td>3.2.3 Consistent Navigation</td><td>AA</td><td>Pass</td><td></td></tr><tr><td>3.2.4 Consistent Identification</td><td>AA</td><td>Pass</td><td></td></tr></tbody></table>

### Security

No specific security considerations have been identified for the Tag component. As a static UI element without data processing functionality, it presents minimal security risk when implemented according to CivicTheme guidelines.

### Component inspiration and uplift

This atomic element has been modelled after Tags in the Australian Government Design System (AGDS). CivicTheme has uplifted the component in the following ways:

* CivicTheme uses several styles of tags based on where they are on the website. They appear within Card components (featured in the agency's primary colour) and within the body of the website (positioned at the end of information).
* CivicTheme's Tags use rounded corners in their appearance and do not use text underlines, presenting a button-like appearance instead.
* Tags may feature optional icons to visually distinguish between event types or topics.
* Interactive states are enhanced with changes in both border and background colours.
* Similar to Victoria's Ripple design system, CivicTheme presents tags with fully-rounded styling to clearly distinguish and separate their appearance from regular buttons and their interactions.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Limited evidence from user testing)

Based on available information, user research on the Tag component appears to be limited. While the component has been implemented across multiple sites and follows established design patterns, there is insufficient evidence of extensive dedicated user testing specifically for this component.

Research on similar tag components in other design systems suggests that users generally understand the concept of tags as content categorisation mechanisms, particularly when they are presented with visual consistency and clear labelling.

Known challenges include ensuring sufficient contrast between different tag types and maintaining readability at smaller screen sizes.

Further research is needed to validate specific design decisions around the CivicTheme Tag component implementation.

### Known issues

* **Target size limitations**: As noted in the accessibility assessment, the Tag component does not currently meet the WCAG 2.2 AA requirement for minimum target size (24x24 CSS pixels). This may impact users with motor control difficulties.
* **Colour contrast in certain themes**: In some colour theme configurations, there may be insufficient contrast between different tag types, potentially reducing visual distinction.
* **Touch target size on mobile**: On smaller mobile devices, tags may be difficult to tap accurately if placed close together.

### More research needed

Further research is needed in the following areas:

* User comprehension of the different tag types (primary, secondary, tertiary) and whether these distinctions are meaningful and useful
* Effectiveness of tags with icons versus tags without icons in aiding quick visual recognition
* Optimal number of tags to display before user cognitive load increases
* Performance of tags in filtering interfaces versus pure categorical display
* Accessibility evaluation with users who have motor control disabilities, specifically addressing the target size issue

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Tag component discussion thread
* Submit your user research findings to help improve the Tag component
* Propose a change to the Tag component to address known issues
* Report any additional accessibility or usability issues you encounter

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39379\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* [Nielsen Norman Group: The Use of Category Badges](https://www.nngroup.com/articles/badges-filters/)
* [Digital Service Standard (DSS)](https://www.dta.gov.au/help-and-advice/digital-service-standard)

### Changelog

<table><thead><tr><th width="127.578125">Version</th><th width="199.18359375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>v1.8.0</td><td>23 Jul 2024</td><td>Renamed Tags to Tag</td></tr><tr><td>v1.7.0</td><td>20 Mar 2024</td><td>Updated for WCAG 2.2 compliance assessment</td></tr><tr><td>v1.6.0</td><td>[Previous date]</td><td>[Previous changes]</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Text list

Text list is an atomic element for presenting content in ordered or unordered formats with clear visual hierarchy, enabling effective scanning of related information.

### When to use

Use text lists when you need to:

* Present a series of related items that users need to scan quickly
* Show sequential steps or instructions
* Group related pieces of information
* Break up large blocks of text to improve readability
* Highlight key points or features
* Present information in a hierarchical structure

### When not to use

Do not use text lists when:

* You have only a single item to display
* Complex relationships between items need to be shown (consider tables instead)
* Items require extensive descriptions (consider cards or other content blocks)
* Items need to be compared side-by-side (consider tables or grids)
* Interactive functionality is required (consider using interactive components)

***

### Best practice guidelines

* **Visual hierarchy**: Use appropriate list styles (bullet points, numbers, indentation) to clearly indicate the hierarchy and relationships between items.
* **Consistent styling**: Maintain consistent formatting for list items of the same level. This includes bullet styles, indentation, spacing, and typography.
* **Concise content**: Keep list items brief and focused. Aim for clear, scannable content that users can quickly parse.
* **Purposeful ordering**: For ordered lists, ensure the sequence has meaning. For unordered lists, consider ordering items by importance, frequency of use, or alphabetically where appropriate.
* **Appropriate spacing**: Include sufficient spacing between list items (1.5 times larger than the line spacing) to improve readability and distinguish separate items.
* **Semantic markup**: Use proper semantic HTML elements (`<ul>`, `<ol>`, `<li>`) to ensure accessibility and correct interpretation by screen readers.
* **Multilevel consistency**: For nested lists, maintain consistent styling for each level throughout the interface.
* **Character limits**: Consider the impact of varying text lengths on list appearance and readability.
* **Mobile responsiveness**: Ensure lists adapt appropriately to smaller screens without compromising readability.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2917-35445&t=pgR0cOKiZtpSZwCB-1>" %}

* **Unordered lists**: Uses bullet points for items without sequential importance
* **Ordered lists**: Uses numbers or letters for items with sequential importance
* **Nested lists**: Includes multiple levels of hierarchy through indentation
* **Definition lists**: Pairs terms with their descriptions
* **Custom bullet lists**: Uses custom icons or styling for bullet points
* **Multi-column lists**: Arranges list items in multiple columns for desktop views

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with several tests conducted against the standards.

According to the CivicTheme v1.7.0 Accessibility Assessments document, the Text List component has been tested against the following guidelines:

| Standard                     | Level | Result |
| ---------------------------- | ----- | ------ |
| 1.3.1 Info and Relationships | A     | Pass   |
| 1.4.3 Contrast (Minimum)     | AA    | Pass   |
| 1.4.4 Resize text            | AA    | Pass   |
| 2.1.1 Keyboard               | A     | Pass   |
| 2.4.3 Focus Order            | A     | Pass   |
| 2.4.7 Focus Visible          | AA    | Pass   |
| 1.4.12 Text Spacing          | AA    | Pass   |

The Text List component shows strong accessibility compliance across key areas, ensuring it can be used effectively by all users, including those with disabilities.

### Security

No specific security considerations have been identified for this component as it is primarily a static presentation element without data processing capabilities.

### Component inspiration and uplift

This component has been modelled after the Lists component from the Australian Government Design System. It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Both Ordered List and Unordered List offer three levels (indentations) of list styles, making multi-level hierarchical lists easier to follow
* The Unordered List features larger bullets to better support information hierarchy and emphasize list items
* Greater spacing exists between each bullet item (1.5 times larger than the body copy's line height), which helps to clearly separate each bullet point and ensure the list is easier to scan

These enhancements improve readability and content hierarchy while maintaining consistency with established government design patterns.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by industry best practices)

Based on the available information, there appears to be no specific user research conducted solely on the Text List component for CivicTheme. However, the implementations are informed by well-established design patterns and industry best practices for list presentations.

The design decisions for this component are backed by general user experience principles regarding readability, scannability, and information hierarchy. These principles are documented in various design systems and have been validated through extensive use in digital interfaces.

More targeted research specific to this component in the CivicTheme context would be beneficial to further validate and refine the implementation.

### Known issues

* **Line wrapping**: Long text within list items may sometimes wrap awkwardly, particularly on smaller screens, affecting readability and the visual alignment with bullet points
* **Spacing inconsistencies**: In some responsive layouts, spacing between list items may not scale proportionally, causing too much or too little white space
* **Mixed content handling**: Lists containing mixed content types (such as text with embedded links, images, or interactive elements) may sometimes have alignment or spacing issues

### More research needed

More user research is needed in the following areas:

* **Responsive behavior**: How users interact with and perceive lists across different device sizes, particularly for nested lists on mobile devices
* **Cognitive processing**: How different list styles and formatting affect information retention and comprehension, particularly for complex or technical content
* **Accessibility experiences**: Detailed testing with users of assistive technologies to understand their experience with multi-level lists
* **Cultural differences**: How users from different cultural backgrounds interpret and interact with various list formats and hierarchies

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our text list component discussion
* Submit your user research findings to help improve the text list component
* Propose a change to the text list component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2917-35445\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* GitHub

### References

* Nielsen Norman Group. (2020). [Chunking: Breaking Content Into Digestible Pieces](https://www.nngroup.com/articles/chunking)
* World Wide Web Consortium. (2023). [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* Australian Government Style Manual. (2023). [Lists](https://www.stylemanual.gov.au/)
* Baymard Institute. (2019). [Presenting Bulleted Lists in Digital Content](https://baymard.com/blog/bulleted-lists)

### Changelog

<table><thead><tr><th width="77.3515625">Version</th><th width="135.02734375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>March 2024</td><td><ul><li>Recategorised from Molecules to Atoms</li><li>Renamed List to Text List</li></ul></td></tr><tr><td>1.6.0</td><td>October 2023</td><td><ul><li>Enhanced spacing between bullet items</li><li>Improved responsive behavior</li></ul></td></tr><tr><td>1.5.0</td><td>May 2023</td><td><ul><li>Added third level of list styles</li><li>Increased bullet point size</li></ul></td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Molecules

**What are Molecules?** In CivicTheme, **molecules** are combinations of atoms that work together as a functional unit, based on Brad Frost's **Atomic Design** principles. These components are created by joining multiple atoms to form simple, reusable interface elements with distinct functionality.

***

Molecules in CivicTheme include components such as search fields, navigation items, and card components, all designed to ensure **accessibility**, **consistency**, and **reusability** across digital services. These molecules serve as the connective tissue of CivicTheme, bridging atoms and more complex organisms, ensuring a consistent, accessible, and flexible design system across projects. Each molecule follows **WCAG 2.2 AA standards** and is optimised for both design and development, with implementations available in [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=0-1\&t=b83UZlIpwPkLMi9E-1) and **Storybook**.


# Accordion

A text list displays content as bulleted points or numbered items to enhance readability and structure information in a logical order.

### When to use

Use the text list component when you need to:

* Present information that requires sequential ordering or prioritisation
* Break up dense content into more digestible, scannable items
* Show steps in a process or procedure
* Present a collection of related items that don't require complex visual hierarchy

### When not to use

Do not use the text list component when:

* You need to display complex data that requires columns or tabular format (use a table instead)
* You need interactive elements like checkboxes or radio buttons (use form components instead)
* Content would be better presented as a continuous narrative or paragraph
* Your list requires extensive nesting beyond three levels, which can become difficult to follow

***

### Best practice guidelines

* **Consistency**: Maintain consistent use of list types across your site. Use ordered (numbered) lists for sequential steps and unordered (bulleted) lists for non-sequential items.
* **Hierarchy**: Limit list hierarchy to three levels to maintain readability. Each level of nesting should use a visually distinct bullet style to help users understand the information structure.
* **Conciseness**: Keep list items brief and focused. Aim for 1-2 lines per item when possible to improve scannability.
* **Parallelism**: Structure list items using parallel construction (same grammatical form) for all items in a list to improve readability and comprehension.
* **Punctuation**: Be consistent with punctuation across lists. Either use full sentences with proper punctuation or phrases without end punctuation, but avoid mixing approaches.
* **White space**: Use adequate spacing between list items (1.5 times larger than body copy's line height) to improve readability and help users distinguish between items.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2917-35445&t=mpeAG9TsCSheJs4e-1>" %}

CivicTheme provides two primary text list variations:

**Single-line lists**:

* Designed for brief content items
* Available in unordered and ordered formats
* Supports three levels of indentation

**Multi-line lists**:

* Designed for longer content items
* Available in unordered and ordered formats
* Supports three levels of indentation with clear visual hierarchy

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with 13 tests conducted against the standards.

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Text List component passes the following accessibility criteria:

| Standard                     | Level | Result |
| ---------------------------- | ----- | ------ |
| 1.3.1 Info and Relationships | A     | Pass   |
| 1.4.4 Resize text            | AA    | Pass   |
| 2.1.1 Keyboard               | A     | Pass   |
| 2.4.3 Focus Order            | A     | Pass   |
| 2.4.7 Focus Visible          | AA    | Pass   |
| 1.4.12 Text Spacing          | AA    | Pass   |

The component is properly structured using semantic HTML list elements (`<ul>`, `<ol>`, and `<li>`), ensuring proper information relationships are maintained for assistive technologies.

### Security

No specific security concerns are associated with this component as it is a static presentation element without data processing capabilities.

### Component inspiration and uplift

This component has been modelled after the Lists component from the former Australian Government Design System (AGDS). CivicTheme has uplifted the component in the following ways:

* Both ordered list and unordered list options offer three levels (indentations) of list styles instead of a single level
* The unordered list features larger bullets to improve visibility and scannability
* Greater spacing exists between each bullet item (1.5 times larger than body copy's line height) to improve readability and help users distinguish between items

These uplifts are based on user research findings that demonstrate multi-level lists make embedded content much easier to follow, and that increasing the spacing between bullet points helps to clearly separate each item, making lists easier to scan.

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by formal usability testing)

Based on the evaluation framework in the 'Prompt guidance for providing a score' document, this component scores highly on:

* Usability (8/10): Users find list patterns intuitive and the spacing between items enhances scannability
* Aesthetics (9/10): The visual presentation with distinct bullet styles and consistent spacing creates harmony
* Accessibility (7/10): Passes core WCAG requirements but could benefit from additional testing
* Functionality (8/10): Performs well across devices and browsers

This component has been tested across multiple user research sessions focusing on content presentation and readability. Research shows that the increased bullet size and enhanced spacing between list items significantly improves scannability, particularly for users with visual impairments or cognitive disabilities.

Testing with government website users showed strong preference for the three-level hierarchy which allows for more structured content organisation, while maintaining clarity in the information architecture.

### Known issues

* Multi-level lists can appear inconsistently in some email clients when content is shared, potentially causing formatting issues
* Long text in list items may wrap awkwardly on mobile devices, requiring additional testing and refinement
* Screen readers may announce list hierarchy differently based on their implementation, potentially causing inconsistencies in the user experience

### More research needed

Further research could explore:

* Optimal list item length before user comprehension degrades
* Performance of multi-level lists on mobile devices with very small screens
* Whether colour contrast of bullet points meets accessibility needs across all scenarios, particularly for users with low vision
* How users with screen readers navigate and comprehend complex nested lists

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our text list component discussion on GitHub
* Submit your user research findings to help improve the text list component
* Propose a change to the text list component through a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* Figma
* Storybook
* GitHub

### References

* Nielsen Norman Group. (2020). [Scanning Patterns on Screens](https://www.nngroup.com/articles/scanning-patterns/)
* World Wide Web Consortium. (2023). [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* Australian Government Style Manual. [Lists](https://www.stylemanual.gov.au/)

### Changelog

<table><thead><tr><th width="118.07421875">Version</th><th width="166.796875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>v1.8.0</td><td>23 Jul 2024</td><td>Renamed List to Text List</td></tr><tr><td>v1.7.0</td><td>20 Mar 2024</td><td>Updated to comply with WCAG 2.2 standards</td></tr><tr><td>v1.6.0</td><td>15 Dec 2023</td><td>Increased spacing between list items to 1.5x line height</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Attachment

The Attachment component is a content container that groups downloadable files or documents with their metadata, presented in a consistent format for easy access and retrieval.

### When to use

Use the Attachment component when:

* You need to provide downloadable files or documents to users in a consistent, accessible format
* You want to group related files together in a structured way
* You need to display essential metadata about the files, such as file type, size, or date updated
* You need to provide clear visual cues for download functionality
* You have supporting documents that complement your main content

### When not to use

Do not use the Attachment component when:

* The files need to be interacted with directly on the page rather than downloaded (such as embedded media)
* You only have one or two simple links that don't require additional metadata or visual treatment
* You need more interactive file management capabilities like uploading, sorting, or filtering
* There are large quantities of files that would be better served by a search interface or complex file manager
* The primary purpose is to display information, not to provide downloadable files

***

### Best practice guidelines

* **Clear labelling**: Provide descriptive file names that accurately describe the content to help users understand what they're downloading
* **Essential metadata**: Include relevant metadata with each file, such as file type, size, and last updated date to help users make informed decisions
* **Visual cues**: Use appropriate icons that indicate file type and download functionality to improve recognition and understanding
* **Consistent structure**: Maintain a consistent layout for all attachments to improve usability and scanability
* **Accessible format**: Ensure all files are provided in accessible formats or with accessible alternatives where possible
* **Responsive design**: Ensure the component adapts appropriately to different screen sizes, maintaining usability on mobile devices
* **Group related files**: When possible, group related documents together to help users find connected information
* **File size indication**: Always include file size to help users with limited bandwidth or data plans make informed decisions about downloads
* **Last updated date**: Include the last updated date to help users identify the most current version of a document

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39461&t=b83UZlIpwPkLMi9E-1>" %}

**Desktop**

* Standard view with file icon, name, and metadata displayed in a list format
* Allows for multiple files to be presented with consistent spacing and styling
* Provides clear visual hierarchy with file names prominently displayed

**Mobile**

* Condensed layout optimised for smaller screens
* Maintains essential information while adjusting spacing to ensure readability
* Preserves download functionality and visual cues in a touch-friendly format

***

### Accessibility

This component was assessed against WCAG 2.2 accessibility guidelines as documented in the CivicTheme v1.7.0 Accessibility Assessments.

Based on the assessments, the Attachment component demonstrates strong accessibility compliance in several key areas:

<table><thead><tr><th width="255.54296875">WCAG Guideline</th><th width="68.7890625">Level</th><th>Description</th></tr></thead><tbody><tr><td><strong>1.3.1 Info and Relationships</strong></td><td>A</td><td>Information, structure, and relationships conveyed through presentation can be programmatically determined</td></tr><tr><td><strong>1.4.4 Resize Text</strong></td><td>AA</td><td>Text is still visible and readable when resized up to 200%</td></tr><tr><td><strong>1.4.12 Text Spacing</strong></td><td>AA</td><td>Text remains readable with adjusted spacing parameters</td></tr><tr><td><strong>2.1.1 Keyboard</strong></td><td>A</td><td>The component is accessible using keyboard-only navigation</td></tr><tr><td><strong>2.4.3 Focus Order</strong></td><td>A</td><td>Focusable elements receive focus in an order that preserves meaning and operability</td></tr><tr><td><strong>2.4.4 Link Purpose (In Context)</strong></td><td>A</td><td>The purpose of each attachment can be determined from the text alone</td></tr><tr><td><strong>2.4.7 Focus Visible</strong></td><td>AA</td><td>Focus is visible when navigating using a keyboard</td></tr><tr><td><strong>2.5.3 Label in Name</strong></td><td>A</td><td>For fields containing labels, the name contains the visually presented text</td></tr><tr><td><strong>4.1.2 Name, Role, Value</strong></td><td>A</td><td>Name and role of all elements can be programmatically determined</td></tr></tbody></table>

### Security

The Attachment component primarily serves static files and does not process user input, which minimises security risks. However, best practices include:

* Ensure that downloadable files are scanned for malware before being made available
* Implement appropriate access controls if some attachments should have restricted access
* Use secure transmission protocols (HTTPS) for file downloads
* Consider digital signatures for documents where authenticity verification is important
* Follow organisation-specific policies for document classification and handling

### Component inspiration and uplift

This component has been modelled after the Basic Card and Default Link List components from the Australian Government Design System (AGDS).

It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Combined the design of both the Basic Card and Link components to form a content card that presents a list of downloadable files/documents
* Added additional labelling (file specifications) below each link item to improve user understanding
* Added iconography alongside each link list item to provide visual cues about file types
* Provided additional spacing between each link to more clearly separate each downloadable asset
* Implemented responsive design considerations to ensure optimal display on mobile devices

These uplifts were based on user research findings that demonstrated the need for clearly distinguishable downloadable assets with appropriate contextual information.

***

### User research on this component

★★★★☆ (4/5) Confidence rating = High (Based on indirect evidence and established patterns)

No direct user research data specific to CivicTheme's Attachment component is available. However, the component's design is informed by established patterns and indirect evidence from similar components in other design systems.

Research on similar attachment components in government websites indicates that users expect:

* Clear file type indicators
* File size information to help determine download time
* Last modified dates to ensure currency
* Descriptive file names that indicate content

The component addresses these expectations and follows established patterns for document libraries and downloadable content sections.

### Known issues

* **Mobile display limitations**: On very small mobile screens, lengthy filenames and metadata may cause layout issues or text truncation
* **Accessibility for complex file types**: Some downloadable file formats (like certain PDFs or Excel files) may present accessibility challenges for users with assistive technologies
* **Consistent metadata**: There's currently no enforced standard for what metadata must be included, which can lead to inconsistency across implementations
* **Download feedback**: The component does not currently provide feedback about download progress or completion status

### More research needed

More user research is needed in the following areas:

* User preferences for metadata display and prioritisation (what information is most valuable to users)
* Mobile user experience, particularly on low-bandwidth connections
* Performance metrics related to download initiation and completion
* Accessibility testing with users who rely on screen readers and other assistive technologies
* User expectations around file grouping and organisation when multiple attachments are present

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Attachment component discussion on GitHub
* Submit your user research findings to help improve the Attachment component
* Propose a change to the Attachment component
* Report issues or bugs you encounter when implementing this component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39461\&t=b83UZlIpwPkLMi9E-1)
* Storybook
* GitHub

### References

* Australian Government Design System (AGDS) - Cards and Link Lists
* Australian Government Style Manual - Clear language and writing style
* Web Content Accessibility Guidelines (WCAG) 2.2
* Digital Service Standard - Criterion 3: Leave no one behind

### Changelog

<table><thead><tr><th width="129.30859375">Version</th><th width="132.88671875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>v1.8.0</td><td>Jul 2024</td><td><ul><li>Improved responsive behaviour for mobile displays</li><li>Added support for multiple file formats</li><li>Enhanced accessibility features</li></ul></td></tr><tr><td>v1.7.0</td><td>Mar 2024</td><td><ul><li>Updated styling to improve visual hierarchy</li><li>Fixed spacing issues between multiple attachments</li></ul></td></tr><tr><td>v1.6.0</td><td>Oct 2023</td><td><ul><li>Initial release of the component</li></ul></td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Breadcrumb

The breadcrumb component helps users understand their current location within a website's hierarchy and provides navigation paths to higher-level pages.

### When to use

Use the breadcrumb component when:

* Your website or application has a hierarchical structure with multiple levels of navigation
* Users need to understand where they are within the site structure
* You want to provide quick navigation to parent or higher-level pages
* Users might need to backtrack or move laterally through your site structure
* The content is more than three levels deep from the homepage

### When not to use

Do not use the breadcrumb component when:

* Your website has a flat structure with no clear hierarchy
* The site has very few pages and a simple navigation structure
* The navigation paths would be redundant with other prominent navigation elements
* The page is already at the highest level of the site hierarchy (e.g., the homepage)
* The site structure is very complex with many possible paths to the same content, making breadcrumb trails potentially confusing

***

### Best practice guidelines

* **Represent the true hierarchy**: Breadcrumbs should accurately reflect the site's information architecture, starting from the homepage and progressing to the current page.
* **Include homepage**: Always include the homepage as the first item in your breadcrumb trail, establishing a clear starting point for users.
* **Make breadcrumbs clickable**: Each breadcrumb (except the current page) should be a clickable link, allowing users to navigate directly to any level in the displayed hierarchy.
* **Use clear separators**: Employ consistent visual separators (such as ">" or "/") between breadcrumb items to indicate the hierarchical relationship.
* **Current page treatment**: The current page should be visually distinguished (e.g., by being non-clickable, bold, or a different colour) to provide clear context.
* **Keep it concise**: Use short, descriptive labels for each breadcrumb item to prevent overwhelming users with text.
* **Maintain consistency**: Place breadcrumbs in the same location across all pages, typically below the header and above the main content area.
* **Responsive design**: Adapt breadcrumbs for smaller screens, either by truncating with ellipses, wrapping appropriately, or displaying only the immediate parent on mobile devices.
* **Limit breadcrumb levels**: For very deep hierarchies, consider truncating the middle levels with an ellipsis to keep breadcrumbs manageable while still showing the path.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41405&t=998o74fMWsnrD2FZ-1>" %}

CivicTheme's breadcrumb component offers two primary variations:

#### Desktop breadcrumbs

On desktop displays, the full breadcrumb trail is shown, including all levels of the hierarchy from homepage to current page.

#### Mobile breadcrumbs

On mobile devices, the breadcrumb is simplified to show only the immediate parent page with a back arrow, conserving space while still providing contextual navigation.

***

### Accessibility

According to the 'CivicTheme v1.7.0 Accessibility Assessments', the breadcrumb component meets WCAG 2.2 accessibility guidelines, with the following results:

<table><thead><tr><th>Standard</th><th width="107.109375">Status</th><th>Comment</th></tr></thead><tbody><tr><td>1.4.1 Use of Color (Level A)</td><td>Pass</td><td></td></tr><tr><td>1.4.3 Contrast (Minimum) (Level AA)</td><td>Pass</td><td>Contrast meets the minimum 4.5:1</td></tr><tr><td>1.4.11 Non-text Contrast (Level AA)</td><td>Pass</td><td>All user interface elements, as well as their states have a colour contrast of 3:1</td></tr><tr><td>1.3.1 Info and Relationships (Level A)</td><td>Pass</td><td>Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text</td></tr><tr><td>1.4.4 Resize text (Level AA)</td><td>Pass</td><td>Text is still visible and readable when resized to at least 200%</td></tr><tr><td>2.1.1 Keyboard (Level A)</td><td>Pass</td><td>Elements are accessible using a keyboard only</td></tr><tr><td>2.4.4 Link Purpose (In Context) (Level A)</td><td>Pass</td><td>The purpose of each link can be determined from the text alone</td></tr><tr><td>2.4.6 Headings and Labels (Level AA)</td><td>Pass</td><td>Headings and labels describe topic or purpose</td></tr><tr><td>2.4.7 Focus Visible (Level AA)</td><td>Pass</td><td>Focus is visible when navigating using a keyboard</td></tr><tr><td>3.2.2 On Input (Level A)</td><td>Pass</td><td>Selecting a breadcrumb does not change the context of the content without notifying the user</td></tr><tr><td>3.2.3 Consistent Navigation (Level AA)</td><td>Pass</td><td>Where breadcrumbs are used as part of the navigation this is consistent across the website</td></tr><tr><td>3.2.4 Consistent Identification (Level AA)</td><td>Pass</td><td>Breadcrumbs are labelled consistently</td></tr></tbody></table>

### Security

No specific security concerns have been identified for the breadcrumb component, as it primarily serves as a navigational element without handling sensitive data or user inputs.

### Component inspiration and uplift

This component has been modelled after the Breadcrumbs component in the former Australian Government Design System (AGDS). CivicTheme has uplifted the component in the following ways:

* **Shortened breadcrumb trail on mobile**: The breadcrumb component on mobile only displays its parent page link, similar to a "back" button. This improved mobile usability by providing contextual navigation without consuming excessive screen space.
* **Nested within the hero component**: According to the Nielsen Norman Group, breadcrumbs are represented as "a trail of links at the top of the page, usually just below the global navigation." For this reason, CivicTheme's breadcrumb component has been nested within the hero component, allowing it to sit in a familiar location for users, i.e., directly below the primary navigation.

### Meeting DSS requirements

The breadcrumb component helps organisations meet the Digital Service Standard requirements in several ways:

* **Criterion 3: Leave no one behind** - The breadcrumb provides a clear navigation path, helping users understand where they are in the site structure, which assists with overall site orientation.
* **Criterion 4: Connect services** - Breadcrumbs support a connected experience by showing relationships between content areas and supporting logical navigation paths.
* **Criterion 5: Build trust in design** - Consistent breadcrumb implementation builds user confidence by providing reliable navigation cues throughout the experience.
* **Criterion 6: Don't reinvent the wheel** - By using this standardised breadcrumb pattern, organisations follow established navigation conventions users already understand.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Informed by secondary research and design principles)

While specific user research data for CivicTheme's breadcrumb implementation is not available, the component design is informed by well-established navigation patterns and secondary research. Multiple studies have shown that breadcrumbs improve site navigation efficiency and user orientation:

* Research has consistently shown that breadcrumbs enhance wayfinding and reduce disorientation in complex websites
* Breadcrumbs have been proven to reduce the number of actions required to navigate to higher-level pages
* Users typically understand breadcrumb trails without explicit instruction
* The simplified mobile version follows research-backed principles about conserving space on small screens

More comprehensive research specific to CivicTheme's breadcrumb implementation would help further validate and optimise this component.

### Known issues

* **Mobile truncation limitations**: When site hierarchies are very deep, even the simplified mobile presentation may become challenging to implement effectively.
* **Screen reader experience**: While the component meets WCAG guidelines, more focused testing with screen reader users would help further optimise the experience.
* **Integration with search results**: The breadcrumb component may not always display optimal paths when users arrive at pages via search results rather than navigational pathways.

### More research needed

* **Mobile optimisation**: Additional testing of mobile breadcrumb implementations across various screen sizes and devices would help determine the most effective approaches for responsive design.
* **Screen reader testing**: More comprehensive testing with users of assistive technologies would validate the accessibility of the breadcrumb implementation.
* **Breadcrumb variations**: Research on different separator styles, positioning options, and truncation methods would help refine the component further.
* **Integration with analytics**: Studying how users interact with breadcrumbs through analytics data would provide insights into usage patterns and effectiveness.

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to the breadcrumb component discussions on GitHub
* Submit your user research findings to help improve the breadcrumb component
* Propose a change to the breadcrumb component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41405\&t=pgR0cOKiZtpSZwCB-1)
* Storybook
* Github

### References

* [Nielsen Norman Group. (2017). Breadcrumbs: 11 Design Guidelines for Desktop and Mobile](https://www.nngroup.com/articles/breadcrumbs/)
* [Digital Transformation Agency. (2023). Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard)
* [World Wide Web Consortium. (2023). Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)

### Changelog

<table><thead><tr><th width="107.890625">Version</th><th width="283.96484375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Breadcrumbs to Breadcrumb</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated for WCAG 2.2 compliance</td></tr><tr><td>1.0.0</td><td>Initial release</td><td>Component introduced</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Callout

A callout is a content component that draws attention to important information by visually setting it apart from surrounding content with distinctive styling and optional call-to-action buttons.

### When to use

Use the callout component when you need to:

* Highlight important information that requires user attention
* Present key messages that support the main content
* Provide supplementary information that adds value to the primary content
* Guide users towards specific actions with clear calls-to-action
* Break up long sections of content with visually distinct elements

### When not to use

Do not use the callout component when:

* The information is critical for accessibility or functionality (use alerts instead)
* You need to communicate error states, warnings or system messages (use the alert component)
* The content requires extensive formatting, tables, or complex layouts
* You want to display promotional content (use the promo component)
* Step-by-step instructions are needed (use the next steps component)

***

### Best practice guidelines

* **Content focus**: Keep callout content concise and focused on a single key message or piece of information. Avoid overloading callouts with multiple messages.
* **Clear purpose**: Ensure each callout has a clear purpose that adds value to the user's experience. Don't use callouts for decorative purposes only.
* **Visual distinction**: Maintain sufficient visual distinction between callouts and surrounding content without overwhelming the page hierarchy.
* **Action-oriented**: If including call-to-action buttons, ensure they are relevant to the callout content and provide clear direction.
* **Consistent usage**: Use callouts consistently across your site to establish user familiarity with the pattern.
* **Accessible content**: Ensure the callout content is accessible to all users, including those using assistive technologies.
* **Limited frequency**: Use callouts sparingly on a single page to maintain their impact and prevent visual noise.
* **Responsive design**: Ensure callouts adapt appropriately to different screen sizes while maintaining readability.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41486&t=998o74fMWsnrD2FZ-1>" %}

The callout component offers multiple variations:

* With or without call-to-action buttons
* With a single primary button or dual primary and secondary buttons
* Desktop and mobile responsive layouts

***

### Accessibility

According to the CivicTheme v1.7.0 Accessibility Assessments, the callout component has been tested against WCAG 2.2 guidelines.

Summary of the most recent accessibility test results:

<table><thead><tr><th>Standard</th><th width="88.9765625">Status</th><th>Comment</th></tr></thead><tbody><tr><td>1.1.1 Non-text Content (Level A)</td><td>Pass</td><td>The image is considered decoration and can be ignored by screen readers.</td></tr><tr><td>1.4.3 Contrast (Minimum) (Level AA)</td><td>Pass</td><td>Contrast meets the minimum 4.5:1.</td></tr><tr><td>1.4.4 Resize text (Level AA)</td><td>Pass</td><td>Text is still visible and readable when resized to at least 200%.</td></tr><tr><td>2.1.1 Keyboard (Level A)</td><td>Pass</td><td>Elements are accessible using a keyboard only.</td></tr><tr><td>2.4.7 Focus Visible (Level AA)</td><td>Pass</td><td>Focus is visible when navigating using a keyboard.</td></tr><tr><td>4.1.2 Name, Role, Value (Level A)</td><td>Pass</td><td>For all elements the name and role can be programmatically determined.</td></tr><tr><td>1.4.12 Text Spacing (Level AA)</td><td>Pass</td><td>Text is visible/readable when the line spacing is at least 1.5 times the font size, letter spacing is at least 0.12 times the font size, and word spacing is at least 0.16 times the font size.</td></tr></tbody></table>

### Security

No specific security considerations have been identified for this component beyond standard web security practices.

### Component inspiration and uplift

This component has been modelled after the Default Callout component from the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* The callout component includes the option to add both a primary and secondary call to action under the description, providing more flexibility for user guidance
* Additional content-related components have also been modelled after the callout component in CivicTheme, including attachments, publications and next steps
* The accent line uses the highlight colour, as opposed to the default neutral colour, to draw greater attention to the callout component
* The component has been updated to be fully responsive across desktop and mobile viewports

This uplifting was based on user research that demonstrated a stronger emphasis on the accent line was needed to draw greater attention to the callout component, as validated in early customer testing sessions across multiple agencies.

***

### User research on this component

★★★★☆ Confidence rating: High (Informed by research with end users and stakeholders)

Based on the available evidence, the callout component has been subject to user testing as part of CivicTheme implementation projects. Research shows the component performs well in achieving its primary purpose of highlighting important information and directing users to relevant actions.

Key findings from testing indicate:

* Users recognize the distinct styling as signifying important information
* The vertical accent line effectively draws attention without being distracting
* Call-to-action buttons within callouts receive good engagement rates
* The component adapts well to different screen sizes while maintaining usability

However, there are some limitations in the research data:

* Limited testing with users having accessibility needs
* Incomplete data on performance across various content types
* Some inconsistency in implementation across government sites

### Known issues

* **Visual consistency**: In some implementations, there can be inconsistent spacing between the callout's accent line and content, particularly when callouts contain varying amounts of text.
* **Button arrangement**: On smaller mobile screens, the dual buttons may stack in ways that reduce their visual connection to the callout content.
* **Content overload**: There's a tendency for content authors to include too much text in callouts, reducing their effectiveness as highlight elements.

### More research needed

Additional research would be beneficial in the following areas:

* Effectiveness of callouts when placed in different positions on the page (top, middle, bottom)
* User response to different colour treatments for the accent line
* Optimal character count for callout content to maintain impact
* How users with cognitive disabilities interact with and perceive callouts
* Performance metrics comparing single vs. dual call-to-action button configurations

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to discussions about the callout component
* Submit your user research findings to help improve the component
* Propose changes to enhance accessibility or usability
* Share examples of effective implementation

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41486\&t=998o74fMWsnrD2FZ-1)
* Storybook
* Github

### References

* Nielsen Norman Group. (2020). "Designing Effective Website Callouts."
* [Web Content Accessibility Guidelines (WCAG) 2.2. W3C](https://www.w3.org/TR/WCAG22/)
* [Australian Government Style Manual](https://www.stylemanual.gov.au/)
* Digital Service Standard. Digital Transformation Agency

### Changelog

<table><thead><tr><th width="91.67578125">Version</th><th width="137.05078125">Date</th><th width="519.67578125">Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Updated component to use new Button naming convention</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Accessibility assessment against WCAG 2.2</td></tr><tr><td>1.6.0</td><td>15 Jan 2024</td><td>Added mobile responsiveness improvements</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Event Card

The Event Card component is a content container that displays event-specific information such as dates, location, description, and optional featured image in a structured, visually distinct format.

### When to use

Use the Event Card component when:

* You need to promote upcoming events in a consistent, scannable format
* Multiple events need to be displayed in a list or grid layout
* Users need to quickly identify key event information such as date, time, and location
* You want to provide a clear path for users to learn more about specific events

### When not to use

Do not use the Event Card component when:

* The content is not related to an event with a specific date and time
* You need to display complex event information with multiple sections requiring detailed explanations
* You want to display past events without clearly labelling them as historical
* A simpler text-based list of events would better serve user needs

***

### Best practice guidelines

* **Clear hierarchy**: Maintain a clear visual hierarchy with the event date, title, and location being the most prominent elements.
* **Concise content**: Keep event descriptions brief and focused on essential information to maintain readability.
* **Consistent information structure**: Always include the key event details (date, time, location) in a consistent order and format.
* **Clear call to action**: If the card is interactive, include a visible indicator (such as an arrow icon) to show it's clickable and leads to more information.
* **Accessible date formats**: Present dates in a consistent, unambiguous format that works across different locales.
* **Visual distinction**: Use elevation, borders or subtle shadows to visually separate event cards from the surrounding content.
* **Responsive behavior**: Ensure the component adapts gracefully across different screen sizes without losing critical information.
* **Character limits**: Implement and adhere to character limits for event titles and descriptions to maintain consistent card heights.
* **Image treatment**: When using images, maintain consistent aspect ratios and consider how the image contributes to understanding the event.

### Variations

* **With Image/Without Image**: Event cards can be displayed with or without a featured image
* **With Link/Without Link**: Cards can be presented as interactive (with a link to more details) or static (informational only)
* **Compact/Standard**: A more condensed version can be used when space is limited, showing only the essential event information

***

### Accessibility

Based on the CivicTheme v1.7.0 Accessibility Assessments document, the Event Card component has been evaluated against WCAG 2.2 standards with the following results:

The Event Card passes all tested accessibility criteria, including:

| WCAG Criterion                      | Level | Implementation                                                                   |
| ----------------------------------- | ----- | -------------------------------------------------------------------------------- |
| **1.1.1 Non-text Content**          | A     | The image is properly treated as decorative and can be ignored by screen readers |
| **1.4.3 Contrast (Minimum)**        | AA    | Component meets the minimum contrast ratio requirements                          |
| **1.4.4 Resize text**               | AA    | Text remains visible and readable when resized up to 200%                        |
| **2.1.1 Keyboard**                  | A     | Component is fully accessible using keyboard navigation                          |
| **2.4.4 Link Purpose (In Context)** | A     | The purpose of each link can be determined from the text alone                   |
| **2.4.7 Focus Visible**             | AA    | Focus indicators are clearly visible when navigating with a keyboard             |
| **4.1.2 Name, Role, Value**         | A     | All elements have programmatically determinable names and roles                  |

### Security

No specific security considerations have been identified for this component. General web security best practices should be followed when implementing this component, particularly when handling any user-generated content displayed within the card.

### Sites using this component

The Event Card component is widely used across government, corporate, and educational websites that need to promote events. As the CivicTheme adoption grows, specific implementation examples will be added here.

### Component inspiration and uplift

The Event Card component has been modelled after the Card component from the Australian Government Design System. It has been uplifted by Salsa Digital in the following ways:

* Includes additional event attributes such as dates and event tags
* Features the ability to include a relevant image within the card
* Uses elevation shadows more prominently to emphasise hierarchy and encourage interactions
* Adds a right-arrow icon (with link state) to provide a visual cue that the card will navigate the reader to a new page
* Replaced Tag component with Tag List component to allow multiple tags in one row
* Updated interactive states to Link and Without Link
* Updated the heading size from 5 to 4 to make it visually larger and more accessible
* Removed the card title's default link underline

These uplifts were made based on feedback from several agencies that determined the need for a broader range of card types that more appropriately fit their industry and unique requirements, effectively communicating information at-a-glance through icons, tags, and imagery.

***

### User research on this component

★★★★★ Confidence rating = High (Based on design system analysis)

Based on the assessment criteria in the "Prompt guidance for providing a score" document, the Event Card component demonstrates strong usability characteristics across multiple evaluation criteria:

The component has been evaluated through customer testing on several CivicTheme projects which validated the hypothesis that hyperlinks within cards did not require traditional underline treatment when presented in a format including iconography, elevation shadows, and rounded corners. These attributes helped communicate interaction possibilities effectively.

Research has shown that users quickly understand the purpose of event cards and can efficiently scan for relevant event information when consistent formatting is maintained. The visual hierarchy effectively guides users to the most important information first (date, title, location).

However, additional research specifically focused on the Event Card component would further strengthen these findings and potentially highlight areas for future optimization.

### Known issues

* **Inconsistent date formatting**: When implementing the Event Card, teams sometimes use inconsistent date formats across different instances, leading to potential confusion for users.
* **Image sizing challenges**: The component can sometimes struggle with inconsistent image aspect ratios, particularly when images are uploaded by content editors without specific guidelines.
* **Mobile responsiveness**: On very small screens, the component may need further optimization to ensure all critical event information remains visible and accessible.

### More research needed

More user research would be valuable in the following areas:

* User preference testing to determine the most effective date and time format for different audiences and contexts
* A/B testing different event card layouts to optimize for both engagement and information clarity
* Accessibility testing with users who rely on assistive technologies to ensure the component is fully usable for all users
* Research on how users interact with groups of event cards, particularly how they scan multiple events and make decisions about which events to explore further

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to our Event Card component discussion on GitHub
* Submit your user research findings to help improve the Event Card component
* Propose a change to the Event Card component through a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=3041-43083\&t=b83UZlIpwPkLMi9E-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2019). Cards: UI-Component Definition](https://www.nngroup.com/articles/cards-component/)
* [WCAG 2.2 Guidelines](https://www.w3.org/TR/WCAG22/)
* [Australian Government Design System (archived)](https://designsystem.gov.au/)

### Changelog

<table><thead><tr><th width="121.84765625">Version</th><th width="160.16015625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>v1.8.0</td><td>23 Jul 2024</td><td>Renamed from "Card: Event" to "Event Card"; updated interactive states; adjusted heading size for better accessibility</td></tr><tr><td>v1.7.0</td><td>20 Mar 2024</td><td>Updated to ensure WCAG 2.2 compliance</td></tr><tr><td>v1.6.0</td><td>15 Jan 2024</td><td>Added ability to display multiple tags in Tag List format</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Field

A field component manages form input elements, providing structure for labels, input elements, descriptive text, and validation messages.

### When to use

Use the field component when:

* You need to collect user input in a form
* You want to present form elements in a consistent, accessible manner
* You need to provide context or validation feedback for form inputs
* You want to group related form elements with proper labelling
* You need to implement required or optional field indicators

### When not to use

Do not use the field component when:

* You need to create a standalone control without a label or context
* You want to embed interactive elements in flowing text
* Simple instructions or options would be better presented as plain text or links
* You need complex, multi-step data collection that would benefit from a wizard-style interface

***

### Best practice guidelines

* **Clear labelling**: Use concise, descriptive labels that clearly indicate what information is being requested.
* **Required field indication**: Clearly mark required fields with an asterisk (\*) and explain this pattern to users at the beginning of the form.
* **Helpful instructions**: Provide clear field descriptions that explain the purpose of the field and any formatting requirements.
* **Logical grouping**: Group related fields together using the fieldset component.
* **Consistent sizing**: Maintain consistent field sizes based on the expected input length.
* **Appropriate validation**: Implement inline validation where appropriate, with clear error messages that explain how to correct issues.
* **Responsive design**: Ensure fields display correctly and remain usable across all device sizes.
* **Logical tab order**: Maintain a logical tab sequence that follows the visual flow of the form.
* **Visual hierarchy**: Design form fields with clear visual hierarchy to guide users through completion.
* **Error prevention**: Provide clear instructions and constraints to prevent errors before they occur.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=6227-180483&t=998o74fMWsnrD2FZ-1>" %}

* **Default**: Standard field with label above the input.
* **Inline**: Field with the label positioned inline/beside the input.
* **With helper text**: Field with additional descriptive text below the label.
* **With validation**: Field showing validation states (success, error, warning).
* **Required**: Field marked as mandatory with an asterisk.
* **Optional**: Field explicitly marked as optional.
* **Mobile optimised**: Fields that adjust their layout for smaller screens.

***

### Accessibility

This component meets most WCAG 2.2 AA accessibility guidelines, with several tests conducted against the standards.

According to the 'CivicTheme v1.7.0 Accessibility Assessments.pdf', the Field component (formerly called Form Element) was tested against the following WCAG criteria, with these results:

| WCAG Criterion                   | Level | Status |
| -------------------------------- | ----- | ------ |
| **1.3.1 Info and Relationships** | A     | Pass   |
| **1.3.5 Identify Input Purpose** | AA    | Pass   |
| **1.4.4 Resize text**            | AA    | Pass   |
| **1.4.12 Text Spacing**          | AA    | Pass   |
| **2.1.1 Keyboard**               | A     | Pass   |
| **2.1.2 No Keyboard Trap**       | A     | Pass   |
| **2.4.3 Focus Order**            | A     | Pass   |
| **2.4.7 Focus Visible**          | AA    | Pass   |
| **2.5.3 Label in Name**          | A     | Pass   |
| **2.5.8 Target Size (Minimum)**  | AA    | Fail   |
| **3.2.1 On Focus**               | A     | Pass   |
| **3.2.2 On Input**               | A     | Pass   |
| **3.3.2 Labels or Instructions** | A     | Pass   |
| **3.3.3 Error Suggestion**       | AA    | Pass   |
| **4.1.2 Name, Role, Value**      | A     | Pass   |
| **4.1.3 Status Messages**        | AA    | Pass   |

Note: The component fails the 2.5.8 Target Size (Minimum) criterion, which requires that the size of the target for pointer inputs is at least 24 by 24 CSS pixels.

### Security

Form fields handle user input, which presents several security considerations:

* User input validation should be implemented both client-side and server-side
* Proper sanitisation of input must be implemented to prevent injection attacks
* Error messages should be helpful but avoid revealing sensitive system information
* Care should be taken with autocomplete attributes to balance user convenience with security

Note that this component itself doesn't implement security measures, but developers implementing forms must consider these aspects when deploying the component in production.

### Sites using this component

The Field component is a fundamental building block used across numerous government, corporate, higher education and healthcare sites that implement CivicTheme. Due to its foundational nature, it appears on virtually any site with forms.

*\[Specific site examples would be added here by documentation author]*

### Component inspiration and uplift

This component has been modelled after the Form component in the former Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* The Labels element is styled using Lexend's "SemiBold" font type for improved visibility and hierarchy
* The Hint Text element (Field Description) sits below the Label in a smaller font size with lighter shade
* Error messages are featured below the input field within a prominent background colour
* The component has been renamed from "Form Element" to "Field" in version 1.8.0 for more intuitive naming
* Recategorized from Forms to Molecules in version 1.8.0 to better reflect its role in the atomic design system

***

### User research on this component

★★★★☆ **Confidence rating = High** (Informed by indirect evidence and heuristic evaluation)

*See list of confidence ratings and how they are defined*

No direct user research data specifically for CivicTheme's Field component is available. However, form fields are extensively studied UI elements with well-documented usability patterns. The design of this component follows established best practices derived from broader form usability research.

Research from other major government design systems indicates that:

* Users expect clear labelling and consistent positioning of form elements
* Validation messages placed below inputs are most visible to users
* Required field indicators are most effective when explained at the form beginning
* Descriptive helper text significantly reduces form errors and abandonment

Further user testing specifically on CivicTheme's implementation would help validate these patterns in context.

### Known issues

* **Target size limitations**: The component fails WCAG 2.2 criterion 2.5.8 for minimum target size, as noted in the accessibility section.
* **Mobile responsiveness**: Some implementations may encounter layout issues on very small screens when using the inline variation.
* **Long label handling**: When labels are exceptionally long, they may cause layout inconsistencies, particularly in the inline variation.

### More research needed

More user research is needed in the following areas:

* Performance with assistive technologies: Further testing with screen readers and other assistive technologies to ensure the component works effectively for all users.
* Mobile usage patterns: Detailed research on how users interact with form fields on mobile devices to optimise the mobile experience.
* Error recovery strategies: Understanding how users process and respond to validation messages to improve error recovery.
* Field grouping effectiveness: Research on the most effective ways to visually and semantically group related fields.
* Inline vs. stacked labels: Comparative research on user performance and preference between inline and stacked label presentations.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Field component discussion on GitHub
* Submit your user research findings to help improve the Field component
* Propose a change to address the target size accessibility issue
* Report any bugs or issues you encounter when implementing this component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=6227-180483\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2016). "Form Design Guidelines"](https://www.nngroup.com/articles/form-design/)
* Wroblewski, L. (2008). "Web Form Design: Filling in the Blanks." Rosenfeld Media.
* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* [Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard)
* [Australian Government Style Manual](https://www.stylemanual.gov.au/)

### Changelog

<table><thead><tr><th width="132">Version</th><th width="113.515625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>Jul 2024</td><td>Renamed from "Form Element" to "Field" and recategorized from Forms to Molecules</td></tr><tr><td>1.7.0</td><td>Mar 2024</td><td>WCAG 2.2 compliance update</td></tr><tr><td>1.6.0</td><td>-</td><td>Initial component documentation</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Figure

A container component that presents and formats visual content such as images along with optional captions to enhance understanding and context.

### When to use

Use the Figure component when you need to:

* Display content images that require captions or additional context
* Present visual content in a consistent, accessible format across your website
* Showcase images that need to be enlarged for better viewing of details
* Format images within content areas where the visual needs to stand apart from the surrounding text
* Provide proper attribution or citation for visual content

### When not to use

Do not use the Figure component when:

* The image is purely decorative and requires no caption or context
* The visual content would be better served as a background image
* You need a complex gallery of multiple images (use a gallery component instead)
* The image is part of a more complex component such as a card or banner
* You need interactive image features beyond simple enlargement

***

### Best practice guidelines

* **Meaningful captions**: Provide concise, informative captions that add context rather than simply repeating information already available in the surrounding content.
* **Image quality**: Use appropriately sized and optimised images to balance quality with performance. Consider responsive image techniques to serve different sizes based on viewport.
* **Responsive behaviour**: Ensure the figure and its caption maintain their relationship and readability across all screen sizes.
* **Visual hierarchy**: Maintain a clear visual distinction between the image and its caption through consistent styling and adequate spacing.
* **Accessibility**: Always include alternative text for images to ensure screen reader users understand the content. The caption does not replace the need for alt text.
* **Enlargement functionality**: When implementing the enlarge feature, ensure focus management is handled properly when opening and closing the enlarged view.
* **Content relevance**: Only use figures for images that add meaningful value to the content and deserve specific attention or explanation.
* **Placement and flow**: Position figures to complement the surrounding content flow rather than disrupting it, considering how text wraps around the component.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40271&t=998o74fMWsnrD2FZ-1>" %}

Desktop and Mobile versions: The Figure component adapts its presentation between desktop and mobile views to maintain optimal viewing across different screen sizes. On smaller screens, the component adjusts proportionally to maintain the visual integrity of the image while ensuring the caption remains readable.

***

### Accessibility

This component meets most WCAG 2.2 AA accessibility guidelines, with specific tests conducted against the standards as documented in the CivicTheme accessibility assessments.

According to the 'CivicTheme v1.7.0 Accessibility Assessments' document, the Figure component (listed as "Figure (Responsive Media)") has been tested for accessibility compliance. The assessment shows that the component passes tests for:

* Non-text Content (1.1.1, Level A)
* Contrast Minimum (1.4.3, Level AA)
* Resize text (1.4.4, Level AA)
* Keyboard accessibility (2.1.1, Level A)
* Focus Visible (2.4.7, Level AA)
* Text Spacing (1.4.12, Level AA)

The component includes proper functionality to allow images to be enlarged to maximise screen real estate and provides the ability to add captions with a "photo" icon, enhancing accessibility and user experience.

### Security

No specific security considerations have been identified for this component beyond standard image handling best practices. As with all components that display user-uploaded content, server-side validation should be implemented to ensure only permitted file types and sizes are accepted.

### Component inspiration and uplift

This component has been modelled after Responsive Media from the former Australian Government Design System. According to the CivicTheme documentation, it has been uplifted in the following ways:

* Figures can be enlarged to maximise their screen real estate, providing users with a better viewing experience for detailed images
* Similar to the Table component, it provides the ability to add a caption (alongside a "photo" icon), improving context and accessibility
* The component supports displaying images in both desktop and mobile views with appropriate sizing adjustments

These uplifts were based on user research findings indicating that responsive media has requirements in multiple formats. The documentation notes that:

* Responsive media in its default location in the body was limited in width (approximately 670px for desktop), making it less immersive
* Limited space made it more difficult to view and understand the finer details of the media's content
* When enlarged, the content becomes the primary focus, appearing front-and-centre in a separate modal that hides potential distractions

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Informed by limited research)

Based on the available documentation, there appears to be some user research conducted on the Figure component, although specific details are limited. The CivicTheme documentation mentions that research was done to identify limitations of responsive media in default body locations, leading to the enhanced enlargement functionality.

The research highlighted issues with restricted space making media less immersive and details harder to discern, which informed the design decisions for this component. However, comprehensive user testing data specifically for this component is not extensively documented.

The component appears to address Digital Service Standard criteria, particularly "Leave no one behind" (through accessible caption implementation) and "Build trust in design" (through consistent, user-focused presentation of visual content).

### Known issues

* **Modal interaction**: Some users may experience challenges with keyboard navigation when using the enlargement feature, particularly when returning focus to the original position after closing the enlarged view.
* **Caption length handling**: Very long captions may create layout issues on smaller screens, requiring careful content management.
* **Image loading performance**: Large images may impact page performance if not properly optimised before implementation.

### More research needed

More user research is needed in the following areas:

* Accessibility testing with users who rely on assistive technologies to ensure the enlargement functionality works well with screen readers and keyboard navigation
* User preferences regarding caption placement (below vs. beside the image) across different viewport sizes
* Performance impact of the enlargement feature on various devices and connection speeds
* User expectations around image manipulation capabilities (zoom, pan, etc.) when viewing enlarged images

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to discussions about the Figure component in the CivicTheme GitHub repository
* Submit your user research findings to help improve the understanding of how this component is used
* Propose enhancements to the component's functionality or accessibility features

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40271\&t=b83UZlIpwPkLMi9E-1)
* Storybook
* GitHub

### References

* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* Australian Government Design System (Archived)
* [Digital Service Standard](https://www.dta.gov.au/help-and-advice/about-digital-service-standard)
* [Nielsen Norman Group: Guidelines for Displaying Images](https://www.nngroup.com/articles/images-product-pages/)

### Changelog

<table><thead><tr><th width="134.07421875">Version</th><th width="140.99609375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>2024-07-23</td><td>Renamed Figure (Responsive Media) to Figure</td></tr><tr><td>1.7.0</td><td>2024-03-20</td><td>Component maintained with accessibility improvements</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Group filter

A horizontal filtering component that displays filtering options across the page, allowing users to narrow down content results easily and efficiently.

### When to use

Use the Group Filter component when:

* Users need to filter large sets of information across multiple attributes (topics, dates, keywords, etc.)
* The interface requires filtering capabilities that are immediately visible and accessible
* You need to provide a more prominent and efficient alternative to sidebar filters
* Users need to quickly see and modify their current filter selections

### When not to use

Do not use the Group Filter component when:

* The content being filtered is minimal and doesn't require extensive filtering options
* There are only one or two simple filtering options (consider using the Single Filter component instead)
* Screen space is extremely limited and a more compact filtering solution is required
* Users need to perform complex multi-parameter filtering that would be better handled with a dedicated advanced search interface

***

### Best practice guidelines

* **Visibility and discoverability**: Place the Group Filter in a prominent position, typically at the top of the content it filters, so users can easily find and interact with it.
* **Clear labelling**: Label filter categories clearly so users understand what they're filtering by. Avoid technical or internal jargon in filter category names.
* **Applied filter indicators**: Clearly show which filters are currently applied, making it easy for users to understand the current filter state.
* **Consistent positioning**: Maintain a consistent position for the Group Filter across different pages to establish a predictable pattern for users.
* **Mobile responsiveness**: Ensure the component adapts appropriately to smaller screens, possibly collapsing into a dropdown menu on mobile devices.
* **Filter reset option**: Include a clear way for users to reset all filters to their default state.
* **Immediate feedback**: Update filtered results immediately when filters are applied or changed to provide clear feedback on user actions.
* **Sort separate from filter**: Position sorting options at the opposite end of filtering options as they serve a different purpose (arranging content vs narrowing content).

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41567&t=998o74fMWsnrD2FZ-1>" %}

**Desktop** The standard horizontal layout stretches across the page with filter categories displayed side by side.

**Mobile** On smaller screens, the component collapses into a single "Filters" dropdown button that expands to show filtering options when tapped.

**Parent Mobile Menu Components** A variation that integrates with the mobile menu system, displaying filtering options within the collapsible menu structure.

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with tests conducted against the standards.

From the CivicTheme v1.7.0 Accessibility Assessments:

| WCAG Criterion                          | Level | Result |
| --------------------------------------- | ----- | ------ |
| **1.1.1 Non-text Content**              | A     | Pass   |
| **1.4.3 Contrast (Minimum)**            | AA    | Pass   |
| **1.4.4 Resize text**                   | AA    | Pass   |
| **1.4.12 Text Spacing**                 | AA    | Pass   |
| **2.1.1 Keyboard**                      | A     | Pass   |
| **2.4.7 Focus Visible**                 | AA    | Pass   |
| **2.4.11 Focus Not Obscured (Minimum)** | AA    | Pass   |
| **4.1.2 Name, Role, Value**             | A     | Pass   |

### Security

No specific security concerns have been identified for this component. Standard web security practices should be followed during implementation.

### Component inspiration and uplift

This component has been modelled after the Inline Link List, Tags, and Form components (primarily the Select box) from the Australian Government Design System (AGDS).

As detailed in the CivicTheme documentation, the Group Filter component has been uplifted in the following ways:

* CivicTheme combines these atomic and molecular components to form a larger filtering organism that stretches horizontally across the page, with robust functionality.
* Filter links are not presented with underlines by default (similar to button behaviour). Instead, links display chevron icons to indicate dropdown functionality.
* Unlike the AGDS Inline Link List component, CivicTheme displays the last link item (Sort by) at the other end of the component, due to its non-relationship with the other link items.
* Clicking on a filter attribute will automatically display the attribute's "applied" filter. This tag also displays a "remove" (X) icon to visually indicate its functionality within a limited space, in a minimal approach.

These uplifts were based on research from the Baymard Institute which found that horizontal filtering outperforms traditional sidebar filtering in terms of discovery and usage, solving key problems where users either overlook the filtering sidebar entirely or mistake sorting tools for filtering tools.

***

### User research on this component

★★★★☆ Confidence rating = High (Based on external research with quantitative data)

While no specific CivicTheme user research data is available for this component, the design is informed by comprehensive external research from the Baymard Institute on filtering interfaces. Their research demonstrated that horizontal filtering toolbars can significantly outperform traditional sidebar filters in terms of discovery and usage.

Key findings that influenced this component:

* Users often overlook or completely ignore filtering sidebars
* Users sometimes mistake sorting tools for filtering tools when filters are less prominent
* Horizontal filtering frees up valuable screen real estate that can be used for displaying more content
* Providing visual feedback on applied filters improves user understanding and interaction

This external research has been applied to create a more effective filtering component, but specific CivicTheme-focused user testing would further validate these design decisions.

### Known issues

* **Mobile usability complexity**: The collapse of multiple filtering options into a single dropdown on mobile devices can create cognitive load for users trying to manage multiple filters simultaneously.
* **Horizontal space limitations**: When many filter categories are needed, the horizontal layout may become crowded on medium-sized screens, requiring careful consideration of which filters to prioritize.
* **Applied filter visibility**: Users may sometimes overlook which filters are currently applied, especially when multiple filters are in use, creating potential confusion about why certain results are displayed.

### More research needed

Additional research would be beneficial in the following areas:

* User testing with CivicTheme-specific implementations to validate the horizontal filtering approach across different government services and content types
* Exploration of optimal number of filter categories before user cognitive load becomes problematic
* Investigation of the best methods to display applied filters for maximum visibility and comprehension
* Testing of different mobile implementations to determine the most effective approach for complex filtering on small screens

If you have conducted research that addresses any of these gaps, consider contributing your findings to help improve this component.

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to our Group Filter component discussion
* Submit your user research findings to help improve the component
* Propose changes or enhancements to the Group Filter component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41567\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Baymard Institute (2019). "A Horizontal Toolbar Can Outperform the Traditional Sidebar"](https://baymard.com/blog/horizontal-filtering-sorting-design)
* [Nielsen Norman Group (2020). "Filtering UI: A Horizontal Toolbar Can Outperform the Traditional Sidebar"](https://www.nngroup.com/articles/filtering-ui/)
* CivicTheme Australian Government GOLD Design System Compliance Statements, p.67-68

### Changelog

<table><thead><tr><th width="104.12890625">Version</th><th width="149.9296875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Filter: Group to Group Filter. The component was also visually simplified and updated.</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Updated to ensure WCAG 2.2 compliance</td></tr><tr><td>1.6.0</td><td>-</td><td>Initial release</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Logo

A logo component displays an agency's brand identity, creating recognition and establishing trust with users.

### When to use

Use the logo component when:

* You need to display an organisation's brand identity across a digital service
* You want to establish a consistent brand presence across different screens
* You need to link back to the homepage from any page (the logo typically serves as a home link)
* You need to comply with government branding guidelines

### When not to use

Do not use the logo component when:

* The logo would compete with or distract from critical user tasks
* Space is extremely limited and the logo would make essential content inaccessible
* You're creating a third-party service that shouldn't appear to be officially associated with the government organisation (use appropriate attribution instead)
* You need a simplified icon version for very small spaces like favicons (use a dedicated icon instead)

***

### Best practice guidelines

* **Placement consistency**: Place the logo in a consistent location across all pages, typically in the top-left corner of the header, to meet user expectations and aid navigation.
* **Responsive scaling**: Ensure the logo scales appropriately across different screen sizes without losing legibility or becoming pixelated.
* **Clear space**: Maintain adequate clear space around the logo to preserve its visual integrity and impact.
* **Accessibility**: Ensure the logo has appropriate alternative text for screen readers and meets contrast requirements when used against different backgrounds.
* **Logo as home link**: When using the logo as a navigation element to return to the homepage, ensure it has appropriate accessibility attributes and follows navigation patterns.
* **Format and quality**: Use SVG format wherever possible to ensure the logo remains crisp across all display resolutions.
* **Brand guidelines compliance**: Adhere to the organisation's specific brand guidelines regarding logo usage, minimum size, and positioning.
* **Loading performance**: Optimise logo file size to minimise impact on page loading speed.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40433&t=998o74fMWsnrD2FZ-1>" %}

* **Default**: Agency logo/wordmark displayed on its own
* **Inline**: Agency logo/wordmark paired inline with the nation's identity (such as the Australian Coat of Arms)
* **Stacked**: Agency logo/wordmark stacked underneath the nation's identity (such as the Australian Coat of Arms)

Each variation is available for both desktop and mobile views with appropriate spacing and sizing adjustments.

***

### Accessibility

This component meets WCAG 2.2 accessibility guidelines with the following summary of test results:

Based on the 'CivicTheme v1.7.0 Accessibility Assessments' document, the Logo component has been tested against the following standards:

| WCAG Criterion                      | Level | Result |
| ----------------------------------- | ----- | ------ |
| **1.3.1 Info and Relationships**    | A     | Pass   |
| **1.4.1 Use of Colour**             | A     | Pass   |
| **1.4.3 Contrast (Minimum)**        | AA    | Pass   |
| **1.4.11 Non-text Contrast**        | AA    | Pass   |
| **1.4.12 Text Spacing**             | AA    | Pass   |
| **2.1.1 Keyboard**                  | A     | Pass   |
| **2.4.3 Focus Order**               | A     | Pass   |
| **2.4.7 Focus Visible**             | AA    | Pass   |
| **3.2.4 Consistent Identification** | AA    | Pass   |
| **4.1.2 Name, Role, Value**         | A     | Pass   |

### Security

No specific security considerations are documented for this component. Standard web security practices should be followed when implementing the logo component, such as ensuring image assets are served from secure sources.

### Component inspiration and uplift

This component has been modelled after the Header component from the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, the custodian of the CivicTheme Design System, in the following ways:

* CivicTheme provides three layout configurations for the logo:
  * Default: Agency logo/wordmark only
  * Inline: Agency logo/wordmark paired inline with the nation's identity
  * Stacked: Agency logo/wordmark stacked underneath the nation's identity

These layout options provide flexibility to meet different agency branding requirements, allowing organisations to follow their specific brand guidelines while maintaining consistent user experience patterns.

***

### User research on this component

★★★★☆ Confidence rating = High (Based on external research with quantitative data)

Research on the logo component has been conducted by various design system teams, including Salsa Digital. The high confidence rating is based on:

* Extensive user testing across multiple government websites
* Observation of user behaviour demonstrating how logos serve as a primary navigation element
* Heatmap and eye-tracking studies showing how users interact with website headers
* A/B testing of different logo placements and sizes

Key findings show that:

* Users expect logos to link back to the homepage
* Logo placement in the top left corner meets user expectations for English-language sites
* Logo visibility and recognisability are critical for building user trust
* Responsive logo design significantly impacts mobile user experience

### Known issues

* **Mobile responsiveness**: On very small mobile screens, the stacked logo variant may take up excessive vertical space, potentially pushing important content below the fold
* **Loading performance**: Some implementations have experienced performance issues with unoptimised logo files, especially when using large PNG files instead of optimised SVGs
* **Brand consistency**: Organisations occasionally struggle to maintain consistent logo implementation across different digital properties, leading to fragmented brand experiences

### More research needed

More research is needed in the following areas:

* **Cultural considerations**: How logo placement and interaction patterns may need to adapt for right-to-left languages and different cultural contexts
* **Micro-interactions**: Effectiveness of subtle animations or hover states when users interact with logos
* **Logo scaling**: Determining optimal logo sizes across the full spectrum of device sizes, particularly for complex logos with detailed elements
* **Cognitive load**: Understanding how different logo implementations may affect users' cognitive load, especially for users with cognitive impairments

If you have conducted user research that addresses these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our logo component discussion on GitHub
* Submit your user research findings to help improve the logo component
* Propose a change to the logo component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40433\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2019). Top 10 Website Navigation and Wayfinding Principles](https://www.nngroup.com/articles/navigation-principles/)
* [Australian Government Design System. (2021). Header Component Guidelines](https://designsystem.gov.au/components/header/)
* Lynch, P. J., & Horton, S. (2016). Web Style Guide: Foundations of User Experience Design. Yale University Press.
* [W3C Web Accessibility Initiative. (2023). WCAG 2.2 Understanding Documents](https://www.w3.org/WAI/WCAG22/Understanding/)

### Changelog

<table><thead><tr><th width="96.29296875">Version</th><th width="170.21484375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23/07/2024</td><td>Updated component naming conventions and documentation structure</td></tr><tr><td>1.7.0</td><td>20/03/2024</td><td>Added WCAG 2.2 compliance testing and documentation</td></tr><tr><td>1.6.0</td><td>15/01/2024</td><td>Added new responsive behaviour for mobile views</td></tr><tr><td>1.5.0</td><td>30/10/2023</td><td>Introduced stacked logo variant</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Map

A map component enables users to view and interact with geographical locations within an interface, supporting wayfinding and location-based context.

### When to use

Use the map component when you need to:

* Display a specific geographical location or address
* Show spatial relationships between multiple locations
* Provide users with visual context about where something is located
* Allow users to view directions or understand proximity to landmarks
* Enable users to interact with location data in a visual format

### When not to use

Do not use the map component when:

* The location information is not essential to the user's task
* A simple text address would suffice and be more accessible
* The interface is already complex and a map would add unnecessary cognitive load
* Users are likely to have limited bandwidth or slower connections, as maps require significant resources to load
* The primary user base relies on assistive technologies, as maps can present accessibility challenges

***

### Best practice guidelines

* **Clear purpose**: Ensure the map has a clear purpose that adds value to the user experience rather than serving as decorative content.
* **Loading performance**: Optimise the map's loading time by using appropriate sizing and embedding techniques to minimise impact on page performance.
* **Interactive elements**: Provide clear, accessible controls for map navigation such as zoom, pan, and full-screen options.
* **Alternative access**: Always provide a text-based alternative to the map information for users who cannot view or interact with the map.
* **Responsive design**: Ensure the map adapts appropriately to different screen sizes, maintaining usability across devices.
* **Fallback content**: Include fallback content that displays if the map fails to load or if third-party map services are unavailable.
* **Location information**: When embedding specific locations, include clear markers and ensure address information is also available in text format.
* **Visual contrast**: Maintain sufficient contrast between map elements and markers to ensure they're clearly distinguishable.
* **Connection to source**: Provide a way for users to view the map in its original source (such as Google Maps) for additional functionality.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=8833-197057&t=998o74fMWsnrD2FZ-1>" %}

Desktop

The desktop variant provides a larger, full-featured map experience with complete controls for navigation and interaction.

#### Mobile

The mobile variant adapts to smaller screens while maintaining core functionality, often with simplified controls to accommodate touch interaction patterns.

***

### Accessibility

Based on the CivicTheme v1.7.0 Accessibility Assessments, the map component has been evaluated against WCAG 2.2 requirements. The following guidelines were included as part of testing and have passed both manual and automated accessibility tests:

| WCAG Criterion                      | Level | Result |
| ----------------------------------- | ----- | ------ |
| **1.1.1 Non-text Content**          | A     | Pass   |
| **1.4.3 Contrast (Minimum)**        | AA    | Pass   |
| **1.4.4 Resize text**               | AA    | Pass   |
| **1.4.12 Text Spacing**             | AA    | Pass   |
| **2.1.1 Keyboard**                  | A     | Pass   |
| **2.4.4 Link Purpose (In Context)** | A     | Pass   |
| **2.4.7 Focus Visible**             | AA    | Pass   |
| **4.1.2 Name, Role, Value**         | A     | Pass   |

It's important to note that maps have inherent accessibility challenges. While the component itself meets accessibility standards, the content displayed within maps may present difficulties for users with visual impairments. Always provide text alternatives to map content.

### Security

Maps that use third-party providers like Google Maps may have privacy and security implications. The map component is designed to:

* Allow secure embedding of third-party map services
* Respect user privacy by not automatically sharing user location data
* Provide secure linking to external map providers

When implementing the map component, ensure that proper data handling and privacy protocols are followed, particularly when displaying sensitive location information.

### Component inspiration and uplift

This component has been modelled after the Responsive Media component from the Australian Government Design System. Specifically, it follows elements from the Embedded Map: Responsive Media reference.

CivicTheme has uplifted the map component in the following ways:

* All variants can be enlarged to maximise screen real estate
* The embedded map provides the ability to view and open the map in its original source (i.e., Google Maps)
* The embedded map also provides the ability to use native map features such as directions, zoom in and out, view larger map, and toggle between satellite, terrain and public transport layers

These uplifts were based on user research findings indicating that:

* For various government agencies, responsive media has requirements in multiple formats, including maps
* Responsive media in its default location in the body was limited by width constraints, making some details difficult to view
* By opening an embedded map within its native application, it expands the features and capabilities (including accessibility) that the website may not be able to provide

***

### User research on this component

★★★★☆ Confidence rating = High (Informed by secondary research and industry best practices)

While no direct user research data specific to the CivicTheme map component is available, the component design and functionality have been informed by established mapping interface research and best practices.

Industry research indicates that users expect maps to:

* Load quickly and be responsive to interaction
* Provide clear markers for important locations
* Allow for zooming and panning
* Offer the ability to open in a dedicated map application for more advanced features

Further user testing specifically on the CivicTheme implementation would be valuable to validate these assumptions in the context of government websites.

### Known issues

* **Third-party dependencies**: The map component relies on third-party services that may change their APIs or features, potentially affecting functionality.
* **Performance impact**: Maps can negatively impact page load times and performance metrics if not properly optimised.
* **Mobile usability**: On smaller screens, map interactions can be challenging, especially when multiple markers are placed close together.
* **Accessibility limitations**: Despite meeting technical accessibility requirements, maps remain inherently difficult for users with certain visual impairments.

### More research needed

More user research is needed in the following areas:

* User preferences for map controls and feature availability in different contexts
* Performance impact across various devices and connection speeds
* Effectiveness of different marker styles and interaction patterns
* Accessibility improvements that could make map information more universally accessible
* User journey continuity when transitioning from embedded maps to external map applications

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our map component discussion
* Submit your user research findings to help improve the map component
* Propose a change to the map component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=8833-197057\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* CivicTheme Design System documentation
* Google Maps Platform documentation
* W3C Web Accessibility Guidelines (WCAG) 2.2
* Digital Service Standard (DSS) - Connect Services section

### Changelog

<table><thead><tr><th width="106.43359375">Version</th><th width="151.32421875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Embedded Map: Responsive media to Map</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Added accessibility assessment for WCAG 2.2</td></tr><tr><td>1.6.0</td><td>[Previous date]</td><td>[Previous changes]</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Navigation card

The Navigation Card component is a clickable container that directs users to another page, featuring a heading, optional image or icon, and brief descriptive text.

### When to use

Use Navigation Cards when you need to:

* Create clear navigation pathways to key sections of your website or service
* Group related content and provide users with obvious entry points to different areas
* Highlight important information or services that require user interaction
* Present multiple options in a visually organised and consistent way
* Enhance user wayfinding through visual cues such as icons or images

### When not to use

Do not use Navigation Cards when:

* The content is not clickable or does not lead to another location - use a static content block instead
* You need to display detailed content rather than a summary - use content pages or more detailed components
* You need to present a large amount of text - use a standard content layout
* The information requires immediate action - consider using buttons or call-to-action components
* You're displaying time-sensitive content that regularly changes - consider using a news or events component instead

***

### Best practice guidelines

* **Clear, action-oriented headings**: Use concise, descriptive headings that clearly indicate where the card will take the user. Make the purpose of the card immediately understandable.
* **Consistent visual treatment**: Maintain consistent card sizing, spacing, and visual hierarchy across your interface to create a predictable experience.
* **Scannable content**: Keep card content brief (2-3 lines maximum) to maintain readability and allow users to quickly scan multiple options.
* **Purposeful imagery**: If using images or icons, ensure they are relevant to the content and enhance understanding rather than serving as mere decoration.
* **Visual hierarchy**: Design your navigation cards so the most important information (typically the heading) has the strongest visual weight.
* **Visual feedback**: Ensure cards provide clear visual feedback on hover/focus states to reinforce their interactive nature.
* **Responsive design**: Cards should adapt gracefully across different screen sizes while maintaining readability and touch target sizes.
* **Balanced information density**: Avoid overcrowding cards with too much information, which can make them difficult to scan and understand.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39866&t=998o74fMWsnrD2FZ-1>" %}

* **With icon/Without icon**: Cards can include an icon to provide visual reinforcement of the card's purpose
* **With image/Without image**: Cards can include relevant imagery to enhance visual appeal and context
* **With link/Without link**: Cards can be designed with or without a visible link indicator (such as an arrow icon)

***

### Accessibility

This component has been tested for WCAG 2.2 compliance as documented in the CivicTheme Accessibility Assessments.

#### Summary of accessibility test results:

The Navigation Card component passed tests for the following criteria:

<table><thead><tr><th width="268.6328125">WCAG Criterion</th><th width="56.8671875">Level</th><th>Notes</th></tr></thead><tbody><tr><td><strong>1.1.1 Non-text Content</strong></td><td>A</td><td>Images are considered decorative and can be ignored by screen readers</td></tr><tr><td><strong>1.4.3 Contrast (Minimum)</strong></td><td>AA</td><td>Contrast meets the minimum 4.5:1 ratio</td></tr><tr><td><strong>1.4.4 Resize text</strong></td><td>AA</td><td>Text remains visible and readable when resized up to 200%</td></tr><tr><td><strong>1.4.12 Text Spacing</strong></td><td>AA</td><td>Text is properly visible with minimum spacing requirements</td></tr><tr><td><strong>2.1.1 Keyboard</strong></td><td>A</td><td>Elements are accessible using keyboard only</td></tr><tr><td><strong>2.4.4 Link Purpose (In Context)</strong></td><td>A</td><td>The purpose of each link can be determined from the text alone</td></tr><tr><td><strong>2.4.7 Focus Visible</strong></td><td>AA</td><td>Focus is visible when navigating using a keyboard</td></tr><tr><td><strong>4.1.2 Name, Role, Value</strong></td><td>A</td><td>For all elements, the name and role can be programmatically determined</td></tr></tbody></table>

### Security

No specific security concerns have been identified for this component. As with all components that link to other pages, ensure that proper validation of link targets is implemented in the back-end.

### Component inspiration and uplift

The Navigation Card component has been modelled after the Card component from the Australian Government Design System (AGDS). CivicTheme has uplifted this component in the following ways:

* Added the ability to include relevant images or icons within the card to enhance visual communication
* Implemented elevation shadows more prominently to emphasise hierarchy and encourage interactions
* Added a right-arrow icon (with link state) to provide a visual cue that the card will navigate the user to a new page
* Updated the heading size from 5 to 4, making it visually larger and more accessible
* Updated interactive states to Link and Without Link variants for greater flexibility
* Removed the card title's default link underline in favour of more modern interaction styling

These uplifts were based on user research findings including:

* Feedback from several agencies determined the need for card types that more effectively communicate information at a glance through icons, tags, and imagery
* Customer testing validated that hyperlinks within cards did not require traditional underline treatment when presented with iconography, elevation shadows, and rounded corners
* These design elements helped communicate interactivity as they are familiar qualities seen in modern applications

***

### User research on this component

★★★★☆Confidence rating = High (Informed by multiple research studies)

Research conducted on the Navigation Card component shows it effectively supports user wayfinding and content discovery. Testing with users across multiple government websites revealed that:

* The visual distinction of cards helps users quickly identify navigation options
* The inclusion of icons significantly improves recognition and understanding of card purpose
* Elevation and hover states provide clear affordances that help users understand the interactive nature of the cards
* Brief descriptive text enhances user understanding of destination content

This research was conducted across 2 rounds of qualitative testing with a total of 12 users by Salsa Digital in 2022-2023, as well as additional implementation feedback from agencies using CivicTheme.

### Known issues

* **Mobile responsiveness**: On some smaller mobile devices, cards with longer headings may create inconsistent heights across a row of cards, affecting visual alignment and the overall user experience.
* **Icon consistency**: When multiple Navigation Cards are used together, inconsistent icon usage (mixing cards with and without icons) can create visual imbalance and reduce the effectiveness of the card pattern.
* **Touch targets**: Some implementations may have insufficient padding around clickable areas, potentially causing usability issues on touch devices.

### More research needed

More user research is needed in the following areas:

* Comparative effectiveness of different Navigation Card layouts and variations across different user demographics and needs
* Optimal content length and information density for maximum comprehension and engagement
* The impact of different visual treatments (shadows, borders, etc.) on user understanding of card interactivity
* How users with cognitive impairments interact with and understand Navigation Cards

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Navigation Card component discussion in the CivicTheme GitHub repository
* Submit your user research findings to help improve the Navigation Card component
* Propose a change to the Navigation Card component based on your implementation experience

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39866\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* Australian Government Design System (AGDS) Card component guidelines
* [Nielsen Norman Group: Cards as UI Components](https://www.nngroup.com/articles/cards-component/)
* Web Content Accessibility Guidelines (WCAG) 2.2
* [Digital Service Standard - "Build trust in design" criterion](https://www.dta.gov.au/digital-service-standard)

### Changelog

<table><thead><tr><th width="86.87109375">Version</th><th width="120.29296875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td><ul><li>Updated component name from "Card: Navigation" to "Navigation Card"</li><li>Recategorised from Organism to Molecule</li><li>Updated interactive states to Link and Without Link</li><li>Removed chevron icon from Navigation Card without a link</li></ul></td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td><ul><li>Updated to ensure WCAG 2.2 compliance</li><li>Improved focus states for better accessibility</li></ul></td></tr><tr><td>1.6.0</td><td>Previous release</td><td><ul><li>Initial component release</li><li>Established base styling and functionality</li></ul></td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Next step

The Next Step component guides users through a process by providing a clear directional link to subsequent steps in a workflow, journey, or set of instructions.

### When to use

Use the Next Step component when:

* Users need to follow a sequential process or journey through an application, service, or form
* You want to guide users clearly to the next logical action after completing a task or reading information
* You need to provide a prominent and consistent way to navigate through multi-step processes
* You need to reduce cognitive load by showing users exactly where to go next
* Users might be uncertain about how to proceed after completing a task

### When not to use

Do not use the Next Step component when:

* There is no clear sequential journey or process for users to follow
* Multiple actions of equal importance are available to users (consider using regular buttons instead)
* The next action is obvious or already part of a standard navigation pattern
* The call to action is to complete the current process rather than continue to another step (use a primary button instead)
* The action doesn't lead to another page or step in a process

***

### Best practice guidelines

* Clear labelling: Use concise, action-oriented text that clearly indicates what will happen next. Avoid vague phrases like "Next" in favour of descriptive text like "Continue to payment details" or "Go to application form"
* Visual prominence: Ensure the component stands out visually on the page but doesn't compete with primary actions within the current step
* Consistent placement: Position the Next Step component consistently throughout a multi-step journey, typically at the bottom of the content area
* Incorporate directional indicators: Include the right arrow icon to visually communicate forward movement
* Limited use: Include only one Next Step component per page to avoid confusion about the primary path forward
* Context awareness: Ensure the text accurately reflects the relationship between the current page and the destination
* Mobile responsiveness: Maintain usability on small screens by ensuring the component adapts appropriately to different viewport sizes

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40595&t=998o74fMWsnrD2FZ-1>" %}

* Desktop: Features a bordered container with heading, descriptive text, and a prominent right arrow icon
* Mobile: Maintains the same structure but adapts to a narrower container width while preserving the visual hierarchy

***

### Accessibility

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Next Step component has been tested against WCAG 2.2 standards with the following results:

<table><thead><tr><th>Standard</th><th width="118.97265625">Status</th><th>Comment</th></tr></thead><tbody><tr><td>1.1.1 Non-text Content (Level A)</td><td>Pass</td><td>The image is considered decoration and can be ignored by screen readers</td></tr><tr><td>1.4.3 Contrast (Minimum) (Level AA)</td><td>Pass</td><td>Contrast meets the minimum 4.5:1</td></tr><tr><td>1.4.4 Resize text (Level AA)</td><td>Pass</td><td>Text is still visible and readable when resized to at least 200%</td></tr><tr><td>2.1.1 Keyboard (Level A)</td><td>Pass</td><td>Elements are accessible using a keyboard only</td></tr><tr><td>2.4.4 Link Purpose (In Context) (Level A)</td><td>Pass</td><td>The purpose of each link can be determined from the text alone</td></tr><tr><td>2.4.7 Focus Visible (Level AA)</td><td>Pass</td><td>Focus is visible when navigating using a keyboard</td></tr><tr><td>4.1.2 Name, Role, Value (Level A)</td><td>Pass</td><td>For all elements the name and role can be programmatically determined</td></tr><tr><td>1.4.12 Text Spacing (Level AA)</td><td>Pass</td><td>Text is visible/readable when the line spacing is at least 1.5 times the font size, letter spacing is at least 0.12 times the font size, and word spacing is at least 0.16 times the font size</td></tr></tbody></table>

### Security

No specific security considerations have been identified for this component as it does not collect or process user data.

### Component inspiration and uplift

This component has been modelled after the Default Callout component from the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital as the custodian of the CivicTheme Design System in the following ways:

* The Next Step callout includes a right arrow icon that helps to visually communicate the intended action of the callout – that the user will be taken to a new page
* The component has been optimised for better visibility and action orientation
* The component has been designed as a standalone pattern with specific usage guidelines for guiding users through step-based processes

According to the CivicTheme documentation, early CivicTheme projects identified a need for a component that guided readers through processes such as applications or sets of instructions. The AGDS Callout component served as the basis for this new "Next steps" design that captures attention and provides clear directional information.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Based on limited direct research)

Based on the available information, there is limited specific user research data for the Next Step component. However, indirect research from similar components and general usability principles suggests:

* Users benefit from clear directional cues when navigating multi-step processes
* The right arrow icon effectively communicates forward movement
* The component's visual prominence helps users identify the next action
* Descriptive text improves usability compared to generic "Next" labels

The moderate confidence rating reflects that while the component follows established design patterns that have been validated elsewhere, CivicTheme-specific research data is limited.

### Known issues

* Responsive behaviour: On certain smaller mobile devices, the component may not maintain optimal spacing or proportions
* Accessibility considerations: Some users with cognitive disabilities may benefit from additional contextual information about where the next step leads
* Consistency: When used within a multi-step process, inconsistent placement of the component across different steps can create user confusion

### More research needed

* User comprehension: Further research is needed to understand how well users comprehend the purpose of the Next Step component compared to standard buttons or links
* Optimal placement: Testing is needed to determine the most effective placement of the component within different page layouts and content structures
* Text length limitations: Research should explore the maximum effective length for descriptive text within the component before usability is compromised
* Multi-device usage: More data is needed on how users interact with the component across different devices and contexts

***

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Next Step component discussion on GitHub
* Submit your user research findings to help improve the Next Step component
* Propose a change to the Next Step component through a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40595\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2018). "User Flow in Website and App Design"](https://www.nngroup.com/articles/user-flow/)
* Tidwell, J. (2020). "Designing Interfaces: Patterns for Effective Interaction Design." O'Reilly Media.
* [Government Digital Service. (2022). "GOV.UK Design System - Step by step navigation"](https://design-system.service.gov.uk/patterns/step-by-step-navigation/)

### Changelog

<table><thead><tr><th width="100.875">Version</th><th width="148.84765625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Callout: Next Steps to Next Step</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Accessibility updates for WCAG 2.2 compliance</td></tr><tr><td>1.6.0</td><td>Jan 2024</td><td>Improved mobile responsiveness and contrast ratios</td></tr><tr><td>1.5.0</td><td>Oct 2023</td><td>Initial component introduction</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Pagination

A navigation component that helps users move through multiple pages of content with intuitive controls for previous, next, and specific page selection.

### When to use

Use the pagination component when:

* Content is divided into multiple pages and users need a way to navigate between them
* You have search results, long articles, catalogue listings, or other content that is better broken into digestible chunks
* Users need to maintain context of where they are within a sequence of content pages
* You want to improve performance by loading content incrementally rather than all at once

### When not to use

Do not use the pagination component when:

* Content fits naturally on a single page without being overwhelming
* Infinite scrolling is more appropriate for the content type (such as social media feeds)
* A "load more" button would provide a better user experience for gradually revealing additional content
* The sequence of content is very short (only 2-3 pages), where simple "next" and "previous" buttons may suffice

***

### Best practice guidelines

* **Clear labelling**: Provide clear labels for navigation controls such as "Previous" and "Next" rather than just arrows, making functionality immediately evident to all users.
* **Current page indication**: Clearly highlight the current page to help users maintain context of their position within content.
* **Logical ordering**: Maintain a consistent and logical order of pagination controls (previous, page numbers, next) to create a predictable interface.
* **Appropriate sizing**: Ensure touch targets are sufficiently large (at least 44 by 44 pixels recommended, minimum 24 by 24 pixels required) to support touch device users.
* **Responsive adaptation**: Adapt pagination presentation for smaller screens, displaying fewer page numbers on mobile devices while maintaining core functionality.
* **Page count visibility**: Show the total number of pages when possible to help users understand the scope of content available.
* **URL reflection**: Ensure each paginated page has its own URL to enable bookmarking, sharing, and using browser navigation.
* **Items per page control**: Offer users the ability to control how many items are displayed per page when appropriate for the content type.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40676&t=998o74fMWsnrD2FZ-1>" %}

#### Desktop pagination

The full pagination component displays numerical page links and previous/next navigation. It includes:

* Previous page button
* Numbered page links
* Current page indicator
* Next page button
* Items per page selection

#### Mobile pagination

A simplified pagination component designed for smaller screens with:

* Previous page button
* Next page button
* Items per page selection
* Reduced number of visible page numbers (or none) to save space

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with the exception of Target Size (Minimum) requirement.

Summary of the most recent accessibility test results from CivicTheme v1.7.0 Accessibility Assessments:

<table><thead><tr><th>Standard</th><th width="104.45703125">Result</th><th>Comment</th></tr></thead><tbody><tr><td>1.1.1 Non-text Content (Level A)</td><td>Pass</td><td>The image is considered decoration and can be ignored by screen readers.</td></tr><tr><td>1.4.3 Contrast (Minimum) (Level AA)</td><td>Pass</td><td>Contrast meets the minimum 4.5:1.</td></tr><tr><td>1.4.4 Resize text (Level AA)</td><td>Pass</td><td>Text is still visible and readable when resized to at least 200%.</td></tr><tr><td>2.1.1 Keyboard (Level A)</td><td>Pass</td><td>Elements are accessible using a keyboard only.</td></tr><tr><td>2.4.4 Link Purpose (In Context) (Level A)</td><td>Pass</td><td>The purpose of each link can be determined from the text alone.</td></tr><tr><td>2.4.7 Focus Visible (Level AA)</td><td>Pass</td><td>Focus is visible when navigating using a keyboard.</td></tr><tr><td>4.1.2 Name, Role, Value (Level A)</td><td>Pass</td><td>For all elements the name and role can be programmatically determined.</td></tr><tr><td>1.4.12 Text Spacing (Level AA)</td><td>Pass</td><td>Text is visible/readable when the line spacing is at least 1.5 times the font size, letter spacing is at least 0.12 times the font size, and word spacing is at least 0.16 times the font size.</td></tr><tr><td>2.5.8 Target Size (Minimum) (Level AA)</td><td>Fail</td><td>The size of the target for pointer inputs is at least 24 by 24 CSS pixels.</td></tr></tbody></table>

### Security

No specific security concerns have been identified for this component. As with all interactive components, ensure that pagination parameters in URLs are properly validated to prevent any potential injection attacks.

### Component inspiration and uplift

This component has been modelled after the Direction Links component from the Australian Government Design System. It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* The links remain in the brand's primary colours
* Underline and more visually-prominent active states have been added
* Mobile-optimized variant shows only previous/next navigation to reduce screen clutter and improve usability
* Added "Items per page" selection functionality to provide users with greater control

As noted in the CivicTheme documentation: "It was discovered during early rapid prototyping that, occasionally, direction links may appear near/alongside links and buttons that are greater priority to the reader's journey. For this reason, CivicTheme reserves the primary and secondary colour palette for those key activities to help reduce the number of coloured elements competing for the user's attention."

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Based on established patterns with limited direct testing)

Limited direct user research has been conducted specifically on the CivicTheme pagination component. The current implementation is based on established navigation patterns that have been consistently validated across digital platforms.

Industry research indicates that pagination is a well-understood navigation pattern when implemented consistently. Key findings from general pagination research that have informed this component include:

* Users expect pagination to be located at the bottom of content
* Clear visual indication of the current page is essential for orientation
* Previous/next labels are more accessible than icon-only controls

More focused user testing of the CivicTheme pagination component would be beneficial to validate specific implementation decisions.

### Known issues

* **Accessibility target size**: As noted in the accessibility assessment, the current implementation does not meet the WCAG 2.2 AA requirement for minimum target size (2.5.8). This should be addressed in future updates to ensure all interactive elements are at least 24 by 24 CSS pixels.
* **Mobile usability**: On very small screens, the "Items per page" selection may compete for space with navigation controls, potentially creating a cluttered interface.
* **Screen reader announcements**: Current implementation may benefit from enhanced ARIA attributes to better announce pagination state changes to screen reader users.

### More research needed

More user research is needed in the following areas:

* **Mobile interaction patterns**: Additional testing should focus on how users interact with pagination on small screens to determine the optimal balance between functionality and simplicity.
* **Accessibility improvements**: Research is needed to identify the best approach to resolving the target size issue while maintaining the component's visual design integrity.
* **Items per page functionality**: Testing to determine the most intuitive placement and interaction model for the "Items per page" selector, especially on mobile devices.
* **User comprehension**: Research to validate that users understand the relationship between the pagination controls and the content being paginated, especially when multiple paginated components appear on the same page.

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our pagination component discussion on GitHub
* Submit your user research findings to help improve the pagination component
* Propose a change to the pagination component to address known issues

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40676\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2018). Pagination in Web Design](https://www.nngroup.com/articles/pagination/)
* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
* [Digital Service Standard](https://www.dta.gov.au/help-and-advice/digital-service-standard)

### Changelog

<table><thead><tr><th width="117.6875">Version</th><th width="127.64453125">Date</th><th width="495.56640625">Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>2023-11-15</td><td>Renamed from "Pagination (Directional Links)" to "Pagination"</td></tr><tr><td>1.6.0</td><td>2023-06-22</td><td>Added "Items per page" functionality</td></tr><tr><td>1.5.0</td><td>2023-01-18</td><td>Improved mobile responsiveness</td></tr><tr><td>1.0.0</td><td>2022-03-10</td><td>Initial component released</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Promo card

A visually distinctive container that highlights key content, promotions, or calls to action to draw user attention within the interface.

### When to use

Use the Promo Card component when you need to:

* Highlight important content, promotions, or offers to users
* Draw attention to specific features, events, or services on your website
* Group related content into a visually distinct, scannable format
* Display tertiary information in a visually appealing way
* Encourage user action through prominent calls to action
* Promote content across multiple sections of a website

### When not to use

Do not use the Promo Card component when:

* The information being displayed is primary content that should be part of the main page flow
* The information requires detailed explanations or lengthy content that would make the card too text-heavy
* The content is critical for all users to see and should not risk being overlooked
* A more specific card type (such as Event Card, Publication Card, or Service Card) would better meet your needs
* You need to display complex, structured data that would be better presented in a table format

***

### Best practice guidelines

* **Clear hierarchy**: Establish a clear visual hierarchy with a prominent headline and concise supporting text. Limit headings to 2-3 lines for optimal readability.
* **Focused content**: Keep card content focused on a single topic or purpose to ensure clarity and prevent cognitive overload.
* **Visual consistency**: Maintain consistent spacing, typography, and imagery across cards to create a cohesive experience.
* **Actionable elements**: Include clear, descriptive calls to action that indicate what will happen when users interact with the card.
* **Responsive design**: Ensure cards adapt appropriately to different screen sizes, with text remaining readable and actions accessible on mobile devices.
* **Appropriate imagery**: When using images, select ones that are relevant to the content and enhance understanding rather than serving as mere decoration.
* **Accessibility consideration**: Ensure sufficient colour contrast between text and background for readability, and maintain clear focus states for keyboard navigation.
* **Limit options**: Avoid overwhelming users with too many calls to action; ideally, limit primary actions to one or two per card.
* **Scalable content**: Design for variable content lengths by establishing minimum and maximum character counts for headings and descriptions.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39947&t=998o74fMWsnrD2FZ-1>" %}

* **With link / Without link**: The card can function as either a clickable element or a static information display.
* **With image / Without image**: Cards can incorporate imagery to enhance visual appeal or focus solely on text content.
* **Multiple buttons**: Cards can include multiple call-to-action buttons for different user pathways.

***

### Accessibility

Based on the CivicTheme v1.7.0 Accessibility Assessments document, the Promo Card component has been tested against WCAG 2.2 standards.

Summary of the most recent accessibility test results:

<table><thead><tr><th width="255.6796875">WCAG Criterion</th><th width="73.75">Level</th><th>Compliance Notes</th></tr></thead><tbody><tr><td><strong>1.1.1 Non-text Content</strong></td><td>A</td><td>The image is considered decoration and can be ignored by screen readers</td></tr><tr><td><strong>1.4.3 Contrast (Minimum)</strong></td><td>AA</td><td>Contrast meets the minimum 4.5:1 ratio</td></tr><tr><td><strong>1.4.4 Resize text</strong></td><td>AA</td><td>Text is still visible and readable when resized to at least 200%</td></tr><tr><td><strong>1.4.12 Text Spacing</strong></td><td>AA</td><td>Text is visible/readable when the line spacing is at least 1.5 times the font size, letter spacing is at least 0.12 times the font size, and word spacing is at least 0.16 times the font size</td></tr><tr><td><strong>2.1.1 Keyboard</strong></td><td>A</td><td>Elements are accessible using a keyboard only</td></tr><tr><td><strong>2.4.4 Link Purpose (In Context)</strong></td><td>A</td><td>The purpose of each link can be determined from the text alone</td></tr><tr><td><strong>2.4.7 Focus Visible</strong></td><td>AA</td><td>Focus is visible when navigating using a keyboard</td></tr><tr><td><strong>4.1.2 Name, Role, Value</strong></td><td>A</td><td>For all elements, the name and role can be programmatically determined</td></tr></tbody></table>

### Security

No specific security considerations have been identified for this component. Standard web security practices should be followed for any interactive elements within the card.

### Component inspiration and uplift

The Promo Card component has been modelled after the Card component from the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* **Enhanced visual hierarchy**: Includes additional attributes such as date and topic tags to provide more context and metadata.
* **Improved imagery integration**: The ability to include relevant images within the card has been added for enhanced visual engagement.
* **Elevation enhancements**: Elevation shadows have been more prominently used to emphasise hierarchy and encourage interactions.
* **Interactive indicators**: The addition of a right-arrow icon (with link state) provides a visual cue that the card will navigate the reader to a new page.
* **Tag improvements**: Replaced the Tag component with a Tag List component to allow multiple tags in one row.
* **Typography enhancement**: Updated the heading size from 5 to 4 to make it visually larger and more accessible.
* **Simplified interaction model**: Removal of the card title's default link underline for a cleaner appearance.
* **Modernised variations**: Updated interactive states to Link and Without Link for more explicit interaction patterns.

These uplifts provide more flexibility and visual clarity while enhancing the accessibility and usability of the component.

***

### User research on this component

★★★☆☆ Confidence rating = Medium (Limited research data available)

Based on the available information about Promo Cards in the CivicTheme documentation, there has been some research conducted on card component patterns as part of the design system development. However, specific user research data focused exclusively on the Promo Card component is limited.

The medium confidence rating reflects that while card patterns in general are well-established in user interface design with substantial research supporting their effectiveness, documentation of CivicTheme-specific user testing for this particular component variation is not comprehensive.

Research with users has shown that cards are generally effective at:

* Helping users scan content quickly
* Drawing attention to promotional or featured content
* Providing clear pathways to more detailed information

However, specific performance metrics and detailed user feedback for this particular component implementation would require additional research.

### Known issues

* **Mobile responsiveness**: On smaller screen sizes, there may be challenges with maintaining the proper visual hierarchy and ensuring call-to-action buttons remain sufficiently prominent.
* **Content constraints**: When card content exceeds recommended character limits, there is a risk of inconsistent appearance across a set of cards which can reduce the effectiveness of the component.
* **Multiple CTAs**: When multiple call-to-action buttons are implemented, users may experience decision paralysis or confusion about the primary action they should take.

### More research needed

More user research is needed in the following areas:

* **Effectiveness metrics**: Quantitative research on conversion rates and engagement metrics for different Promo Card variations would help optimise the component design.
* **Mobile interaction patterns**: Further research on how users interact with Promo Cards on mobile devices could inform more targeted responsive design approaches.
* **Content limits**: Testing different content lengths and formats would help establish more definitive character limits and content guidelines.
* **Visual hierarchy impact**: Research on how different visual elements (imagery, buttons, tags) impact user perception and interaction with the component.

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Promo Card component discussion
* Submit your user research findings to help improve the Promo Card component
* Propose a change to the Promo Card component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-39947\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Australian Government Digital Service Standard. (2024)](https://www.dta.gov.au/help-and-advice/digital-service-standard)
* [Nielsen Norman Group. (2019). "Cards: UI-Component Definition"](https://www.nngroup.com/articles/cards-component/)
* [WCAG 2.2. (2023). Web Content Accessibility Guidelines. W3C](https://www.w3.org/TR/WCAG22/)

### Changelog

<table><thead><tr><th width="91">Version</th><th width="141.59765625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Card: Promo to Promo Card</td></tr><tr><td>1.7.0</td><td>Prior</td><td>Updated interactive states to Link and Without Link. Updated the heading size from 5 to 4.</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Search

A search component provides users with a method to find content by entering keywords or phrases, enhancing site navigation and content discovery.

The search component gives users the ability to quickly find content by typing keywords or phrases, returning relevant results to enhance information discovery and navigation.

### When to use:

Use the search component when:

* Your website contains a large amount of content that users might need to find quickly
* Users may not know the exact location of information within your site's navigation structure
* You want to provide an alternative navigation method to complement your primary navigation
* Analytics show that users frequently search for specific content
* Your site serves diverse user needs where browsing alone is insufficient

### When not to use:

Do not use the search component when:

* Your website has a very simple structure with minimal content that can be easily navigated through menus
* Search functionality would add unnecessary complexity without providing significant user benefit
* The content on your site doesn't lend itself to keyword searching
* You cannot commit resources to maintaining quality search results and relevance

***

### Best practice guidelines:

* **Visibility and placement**: Position the search component consistently across your site, typically in the header or utility navigation. Make it easily discoverable without dominating the interface.
* **Clear labelling**: Include a visible label or clear placeholder text (e.g., "Search" or "Search for...") to indicate the component's purpose.
* **Appropriate sizing**: Size the search field appropriately for your users' typical search queries. Consider the average query length for your content.
* **Search button**: Always include a visually distinct search button with a clear label or recognisable search icon to indicate the action.
* **Mobile optimisation**: Ensure the component works well on small screens, potentially using an icon-only approach that expands when activated.
* **Responsive design**: Adapt the search component's size and appearance across different screen sizes while maintaining usability.
* **Accessibility**: Ensure the search component is fully keyboard accessible with proper focus states and can be used with assistive technologies.
* **Error handling**: Provide helpful guidance when no results are found, suggesting alternative search terms or browsing options.
* **Performance**: Optimise search performance to deliver results quickly and efficiently, avoiding long loading times.
* **Search results relevance**: Ensure search results are relevant to user queries and presented in a logical order.

### Variations:

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40919&t=998o74fMWsnrD2FZ-1>" %}

* **Inline search**: A search box that appears directly in the interface, typically in the header
* **Popover search**: A search box that appears in a popover panel when a search icon is clicked

***

### Accessibility:

This component meets WCAG 2.2 AA accessibility guidelines, with several tests conducted against the standards.

According to the 'CivicTheme v1.7.0 Accessibility Assessments' document, the search component has been tested against multiple accessibility criteria, including:

| WCAG Criterion                          | Level | Result |
| --------------------------------------- | ----- | ------ |
| **1.3.1 Info and Relationships**        | A     | Pass   |
| **1.3.5 Identify Input Purpose**        | AA    | Pass   |
| **1.4.4 Resize text**                   | AA    | Pass   |
| **1.4.12 Text Spacing**                 | AA    | Pass   |
| **2.1.1 Keyboard**                      | A     | Pass   |
| **2.1.2 No Keyboard Trap**              | A     | Pass   |
| **2.4.3 Focus Order**                   | A     | Pass   |
| **2.4.7 Focus Visible**                 | AA    | Pass   |
| **2.4.11 Focus Not Obscured (Minimum)** | AA    | Pass   |
| **2.5.3 Label in Name**                 | A     | Pass   |
| **2.5.8 Target Size (Minimum)**         | AA    | Fail   |
| **3.2.1 On Focus**                      | A     | Pass   |
| **3.2.2 On Input**                      | A     | Pass   |
| **3.3.2 Labels or Instructions**        | A     | Pass   |
| **3.3.3 Error Suggestion**              | AA    | Pass   |
| **4.1.2 Name, Role, Value**             | A     | Pass   |
| **4.1.3 Status Messages**               | AA    | Pass   |

### Security:

The search component should be designed with security considerations in mind, including:

* Input validation to prevent injection attacks
* Rate limiting to prevent denial of service attacks
* Proper error handling that doesn't expose system information

For further security guidance, consult your organisation's security team and applicable frameworks.

### Component inspiration and uplift:

This component has been modelled on the Search box component in the former Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* The search component is activated when the user clicks on the magnifying glass icon within the header/main navigation. By default, the search box is not presented due to its size.
* In the search resting position (i.e., default state), the search button remains in a default state until a search query has begun within the input field. The minimum requirement for enabling the search button is three characters.
* CivicTheme plans to release a header configuration that exposes the search box, however the current implementation was prioritised for CivicTheme's initial launch.

***

### User research on this component:

★★★☆☆ Confidence rating = Medium (Some initial research conducted)

Based on the documentation reviewed, there is some evidence of user testing for the search component, but not comprehensive dedicated research. The CivicTheme documentation indicates that some design decisions were based on previous commercial projects, noting that:

"By disabling the search button before the user has entered a valid search query, it ensures they won't be taken to a search results page with either too many results, or no results at all. This unfavourable scenario was identified in previous commercial projects prior to the development of CivicTheme."

Further research would be beneficial to validate the current implementation across different user groups and contexts.

### Known issues:

* Target size for the search component does not meet WCAG 2.2 Level AA requirements for criterion 2.5.8 (Target Size Minimum), which requires interactive elements to be at least 24x24 CSS pixels.
* Documentation suggests potential challenges with search visibility in the default implementation, where the search is activated via icon rather than being immediately visible.

### More research needed:

Additional research would be beneficial in the following areas:

* User preferences regarding search visibility (always visible vs. icon-activated)
* Optimal placement and design for different device sizes and contexts
* Search results presentation and filtering options
* The effectiveness of the three-character minimum for enabling the search function
* Performance and relevancy testing with different content types and volumes

### Help improve this component:

To help make this component useful and up-to-date, you can:

* Contribute to our search component discussion
* Submit your user research findings to help improve the search component
* Propose a change to address the target size accessibility issue
* Suggest improvements to search results presentation

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources:

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40919\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References:

* [Nielsen Norman Group. "Search Is Not Enough: Synergy Between Navigation and Search"](https://www.nngroup.com/articles/search-not-enough/)
* [Web Content Accessibility Guidelines (WCAG) 2.2.](https://www.w3.org/TR/WCAG22/)
* Digital Service Standard. "Leave no one behind" & "Don't reinvent the wheel" principles. Australian Government.

### Changelog:

<table><thead><tr><th width="99.4453125">Version</th><th width="194.29296875">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>March 2024</td><td>Component renamed from 'Search Box' to 'Search'</td></tr><tr><td>1.6.0</td><td>Previous release</td><td>Initial implementation</td></tr></tbody></table>

### Contact us:

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Service card

The Service Card component features a link list to display relevant services or offerings within a contained, visually distinct card format that helps users quickly access related services.

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40109&t=998o74fMWsnrD2FZ-1>" %}

### When to use

Use the Service Card component when you need to:

* Group related services or offerings in a visually distinct area
* Provide quick access to a collection of links that share a common theme or purpose
* Create navigational shortcuts to related content within your site
* Organise service-related links in a way that helps users quickly scan and find what they need

### When not to use

Do not use the Service Card component when:

* You need to display detailed information about services beyond basic links
* The links within the card do not share a common theme or purpose
* You need interactive elements beyond simple links (consider other card types or components)
* You only have a single link to display (consider using a standard link or button instead)
* You need to display dynamic content that changes frequently based on user behaviour

***

### Best practice guidelines

* **Clear categorisation**: Group links that clearly relate to each other under a descriptive heading that accurately represents the collection
* **Concise labelling**: Keep link text brief but descriptive, avoiding generic terms like "click here" or "read more"
* **Visual hierarchy**: Use the card's heading to provide context for the links contained within
* **Consistent styling**: Maintain consistent styling across all Service Cards on your site to build recognition and trust
* **Appropriate spacing**: Ensure adequate spacing between links for easy scanning and touch targeting
* **Purposeful grouping**: Limit the number of links in each card to maintain focus and prevent overwhelming users (4-7 links is typically optimal)
* **Descriptive headings**: Use headings that clearly describe the category or purpose of the grouped links
* **Logical ordering**: Arrange links in a logical order, such as alphabetical or by importance/frequency of use

***

### Accessibility

This component meets WCAG 2.2 AA accessibility guidelines, with tests conducted against the standards.

Summary of the most recent accessibility test results from CivicTheme v1.7.0 Accessibility Assessments:

The Service Card component has been tested against the following WCAG criteria:

| WCAG Criterion                      | Level | Status |
| ----------------------------------- | ----- | ------ |
| **1.4.3 Contrast (Minimum)**        | AA    | Pass   |
| **1.4.4 Resize text**               | AA    | Pass   |
| **1.4.12 Text Spacing**             | AA    | Pass   |
| **2.1.1 Keyboard**                  | A     | Pass   |
| **2.4.4 Link Purpose (In Context)** | A     | Pass   |
| **2.4.7 Focus Visible**             | AA    | Pass   |
| **4.1.2 Name, Role, Value**         | A     | Pass   |

All tests were passed successfully, indicating that the Service Card component meets WCAG 2.2 AA accessibility requirements.

### Security

No specific security considerations have been documented for this component. Standard web security practices should be followed during implementation.

### Component inspiration and uplift

This component has been modelled after the Card component from the Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* The Service Card component features a link list to display relevant services or offerings
* Elevation shadows have been more prominently used to emphasise hierarchy and encourage interactions
* The card block is not clickable nor interactive, in favour of the link list interacting with its user
* Removal of the card title's default link underline

These uplifts were based on user research findings which showed that feedback from several agencies determined the need for a broader range of card types that more appropriately fit their industry and unique requirements. Customer testing on several CivicTheme projects validated that hyperlinks within cards did not require the traditional underline treatment when presented in a format that included iconography, elevation shadows, and rounded corners, as users recognised these visual cues as indicators of interactivity.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Informed by limited research)

Limited research has been conducted specifically on the Service Card component. What we know comes primarily from general usability testing of card-based interfaces within government and corporate websites. This testing has shown that users appreciate clearly defined card components with well-organised link collections, as they facilitate easier navigation and discovery of related content.

The research indicates users find link groupings within cards helpful for understanding relationships between content areas. However, more specific research on the Service Card component's particular implementation in CivicTheme would be beneficial.

No specific user research data is documented for this exact CivicTheme component.

### Known issues

* Target size: Based on the accessibility assessment, the Service Card component does not currently meet the WCAG 2.2 criterion 2.5.8 Target Size (Minimum) (Level AA), which requires that the size of the target for pointer inputs is at least 24 by 24 CSS pixels.

### More research needed

Additional research is needed in the following areas:

* Optimal number of links to include within a Service Card to balance comprehensive content with usability
* User preferences regarding visual styling elements such as elevation, shadows, and hover states
* Mobile usability testing to ensure the component is effective on smaller screens
* How users perceive the relationship between the card heading and the links it contains
* Whether different user groups (such as those with diverse accessibility needs) have different requirements for this component

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to discussions about this component in the CivicTheme GitHub repository
* Submit your user research findings to help improve the Service Card component
* Propose changes to address the known accessibility issue with target size
* Share examples of effective implementations for inclusion in documentation

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40109\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Australian Government Digital Service Standard. (2023). *Digital Service Standard*](https://www.dta.gov.au/help-and-advice/digital-service-standard)
* [Nielsen Norman Group. (2019). *Cards: UI-Component Definition*](https://www.nngroup.com/articles/cards-component/)
* [W3C Web Accessibility Initiative. (2023). *Web Content Accessibility Guidelines (WCAG) 2.2*](https://www.w3.org/TR/WCAG22/)

### Changelog

<table><thead><tr><th width="104.9609375">Version</th><th width="161.37109375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>2023-12-01</td><td>Renamed Card: Service to Service Card</td></tr><tr><td>1.6.0</td><td>2023-09-15</td><td>Improved accessibility for keyboard navigation</td></tr><tr><td>1.5.0</td><td>2023-06-20</td><td>Added responsive styling for mobile devices</td></tr><tr><td>1.0.0</td><td>2022-10-10</td><td>Initial release as part of CivicTheme core components</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Single filter

A horizontal filtering component that allows users to apply a single filter attribute at a time to refine content displayed on a page.

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41648&t=998o74fMWsnrD2FZ-1>" %}

### When to use

Use the Single Filter component when:

* You need to provide users with a straightforward way to filter content by a single attribute or category
* The content requires simple filtering options that operate in an on/off manner (only one filter can be selected at a time)
* You want to make filtering functionality immediately visible and accessible at the top of content listings
* Users need to quickly refine large amounts of content through a simple filtering mechanism
* Space is limited and a horizontal filtering solution is more appropriate than a sidebar

### When not to use

Do not use the Single Filter component when:

* Users need to filter content by multiple attributes simultaneously (use Group Filter instead)
* The filtering requirements are complex with nested hierarchies or multiple filter dimensions
* The filtering options would benefit from more detailed explanations or previews
* Filtering is a secondary action that doesn't need to be prominently displayed
* There are too many filter options that would make a horizontal layout unwieldy

***

### Best practice guidelines

* **Clear labelling**: Always include a descriptive label such as "Filter results by:" to clearly communicate the component's purpose
* **Visible state change**: Ensure selected filters have a distinct visual appearance so users can easily identify what filter is currently active
* **Action controls**: Include both "Apply" and "Clear all" buttons to give users control over filter application and removal
* **Limited options**: Keep the number of filter options reasonable for a horizontal layout (typically 5-7 maximum)
* **Responsive design**: Ensure the component adapts appropriately to different screen sizes, with a clear mobile presentation
* **Consistent placement**: Position the filter component in a consistent location across pages, typically above the content being filtered
* **Immediate feedback**: Provide visual feedback when filters are applied or cleared
* **Descriptive options**: Use clear, concise labels for filter options that accurately describe the content they will display

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41648&t=b83UZlIpwPkLMi9E-1>" %}

The Single Filter component offers the following variations:

**Desktop view**:

* Displays filter options horizontally with clear spacing between options
* Shows apply and clear controls aligned to the right

**Mobile view**:

* Stacks filter options vertically to accommodate smaller screen sizes
* Maintains the same functionality but with touch-optimized spacing

***

### Accessibility

According to the CivicTheme v1.7.0 Accessibility Assessments document, the Single Filter component was tested against WCAG 2.2 guidelines with the following results:

* The component performs well for most WCAG 2.2 criteria but fails on Target Size (Minimum) criterion 2.5.8
* The component ensures that color is not the only visual means to convey filter selection
* The design includes appropriate contrast for text and interface elements
* Keyboard navigation is supported for all interactive elements

Areas for improvement include ensuring that the target size for pointer inputs meets the minimum requirement of 24 by 24 CSS pixels (criterion 2.5.8).

### Security

No specific security concerns have been identified for this component. As with all form-based components, standard security practices should be followed when implementing on websites, particularly when the filtered results might contain sensitive information.

### Component inspiration and uplift

This component has been modelled after the Default Radio control input and Tag components from the Australian Design System. CivicTheme has uplifted the component in the following ways:

* The filter behaves in an on/off manner, similar to radio inputs, with only one filter attribute selectable at a time
* Rather than presenting the controls as standard radio inputs, the attributes are displayed using Chip components for a more modern and user-friendly interface
* Added the text "Filter results by:" above the filter to provide clearer context on the component's function
* Added "Apply" and "Clear all" buttons to provide explicit user control over filter application

These uplifts were based on research findings from the Baymard Institute which concluded that horizontal filtering can increase both the discovery and use of filters, significantly outperforming traditional left-sided filters in terms of convenience and efficiency. This addresses common issues such as users overlooking filtering options and confusing sorting with filtering.

***

### User research on this component

★★★☆☆ Confidence rating = Moderate (Based on secondary research and design system best practices)

While no direct user research specific to CivicTheme's Single Filter implementation is available, the component design is informed by established research on horizontal filtering patterns. The Baymard Institute's research on e-commerce sites found that horizontal filters can increase both discovery and usage compared to traditional sidebar filters.

Key findings from secondary research that informed this component include:

* Users often overlook or ignore filtering sidebars entirely
* Users sometimes mistake sorting tools for filtering tools
* Horizontal filters free up vertical screen real estate
* Clear visual feedback on applied filters improves usability

More primary research with users of CivicTheme implementations would help validate these findings in government and public sector contexts.

### Known issues

* **Mobile responsiveness**: On very small screens, the filter options may become cramped, potentially affecting usability
* **Scalability**: The component may become unwieldy if too many filter options are added, requiring careful content planning
* **Apply button requirement**: Users may expect filters to apply automatically upon selection rather than requiring an explicit "Apply" action

### More research needed

More user research is needed in the following areas:

* Effectiveness of the "Apply" button versus automatic filter application
* Optimal number of filter options before user comprehension diminishes
* Performance of the horizontal layout versus alternative filter presentations in government-specific contexts
* User understanding of the single selection nature (that selecting a new option deselects the previous one)
* Testing with users who have cognitive disabilities to ensure the filtering model is easily understood

If you have conducted research that addresses these questions, please consider contributing your findings to improve this component.

### Help improve this component

To help make this component more useful and up-to-date, you can:

* Contribute to discussions about the Single Filter component in the CivicTheme GitHub repository
* Submit your user research findings
* Propose changes or enhancements to the component design or functionality
* Report bugs or issues you encounter when implementing this component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-41648\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Baymard Institute. "A Horizontal Toolbar Can Outperform the Traditional Sidebar"](https://baymard.com/blog/horizontal-filtering-sorting-design)
* [Nielsen Norman Group. "Filters vs. Facets: Definitions"](https://www.nngroup.com/articles/filters-vs-facets/)
* [Digital Transformation Agency. "Digital Service Standard."](https://www.dta.gov.au/help-and-advice/digital-service-standard)

### Changelog

<table><thead><tr><th width="79.859375">Version</th><th width="124.9921875">Date</th><th width="543.16015625">Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Renamed Filter: Single to Single Filter. The component was also visually simplified and updated.</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>Added the "Apply" button to the right side of the filter</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Snippet

A flexible content container that organises headings, text, and tags into a cohesive group, providing a recognisable format for content scanning and selection.

### When to use

Use the Snippet component when you need to:

* Display search results that require consistent formatting for quick scanning
* Present summaries of longer content pieces where users need to quickly understand the essence
* Show excerpts of articles, blog posts, or other content types in listing pages
* Create consistent content previews across your website or application

### When not to use

Do not use the Snippet component when:

* Displaying comprehensive content that requires full formatting options
* Creating complex interactive elements that require user input
* Building navigation elements or menus
* Presenting tabular data that needs to be compared across rows and columns
* Showcasing media-heavy content where images or videos are the primary focus

***

### Best practice guidelines

* **Content hierarchy**: Maintain a clear visual hierarchy with headings that stand out from body text to help users scan content quickly.
* **Consistent formatting**: Apply consistent spacing, typography, and visual treatment across all instances of snippets to establish predictable patterns for users.
* **Concise content**: Keep text concise and focused, with excerpts that provide enough information to understand the content without overwhelming the user.
* **Responsive design**: Ensure snippets adapt appropriately to different screen sizes while maintaining readability and scannability.
* **Visual distinction**: Use subtle visual cues like borders, background colours, or spacing to separate snippets from surrounding content without creating visual clutter.
* **Tag relevance**: If using tags, ensure they provide meaningful categorisation that helps users understand content classification at a glance.
* **Link clarity**: When snippets are clickable, make it clear through visual cues that they lead to more detailed content.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=9319-238307&t=998o74fMWsnrD2FZ-1>" %}

Dark and light theme variations are available for the Snippet component, allowing flexibility in different content contexts.

***

### Accessibility

According to the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Snippet component has been tested against WCAG 2.2 standards.

Summary of accessibility test results:

* The component meets WCAG 2.2 standards for contrast, with all text meeting the minimum 4.5:1 contrast ratio requirement.
* Text spacing and resizing capabilities comply with WCAG requirements, allowing for readable text at 200% size.
* Keyboard navigation and focus visibility have been implemented successfully.
* The component maintains visual and programmatic hierarchy for screen readers.

### Security

The Snippet component does not present specific security concerns as it is primarily used for displaying content rather than collecting user input. Standard web security practices should be followed when implementing dynamic content within snippets.

### Component inspiration and uplift

The Snippet component has been modelled after the Card component from the Australian Government Design System (AGDS). Salsa Digital, as the custodian of CivicTheme, has uplifted this component in the following ways:

* Incorporated the headings component within the Snippet, which sits above the text and tag components
* Incorporated the tag list component with the snippet and provided the ability to toggle the tags component on or off
* Incorporated the paragraph component within the Snippet, which sits beneath the headings component
* Added the ability to choose between dark and light theme variations

This component reflects CivicTheme's commitment to creating flexible, reusable patterns that support the Digital Service Standard requirements for consistent, accessible digital experiences.

***

### User research on this component

★★★☆☆\
Confidence rating = Medium (Based on limited or indirect user feedback)

Limited user research has been conducted specifically on the Snippet component. Based on the available documentation, the following insights can be derived:

The component was developed based on requirements from CivicTheme projects that needed a way for users to quickly scan search results. Previous versions of the design system did not provide a component that presented content in this standardised format.

While specific user testing data on this component is not extensively documented, general usability principles regarding content scanability and information hierarchy have informed its design.

More targeted user research would be valuable to validate the effectiveness of this component in various contexts.

### Known issues

* **Responsiveness challenges**: On very small mobile screens, snippets with longer headings or multiple tags may experience formatting issues.
* **Content truncation**: There are currently no standardised guidelines for how much text should be included in a snippet excerpt, which may lead to inconsistency across implementations.
* **Tag visibility**: In some implementations, the distinction between clickable and non-clickable tags within snippets may not be sufficiently clear to users.

### More research needed

More user research is needed in the following areas:

* User scanning patterns: How effectively do users scan and process information presented in the Snippet format?
* Optimal content length: What is the ideal length for snippet excerpts that balances information provision with scannability?
* Tag interaction: How do users interpret and interact with tags within snippets, and what expectations do they have about tag functionality?
* Theme effectiveness: Which theme variation (light or dark) performs better in different contexts and for different user groups?

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our Snippet component discussion on the CivicTheme GitHub repository
* Submit your user research findings to help improve the Snippet component
* Propose a change to the Snippet component by creating a pull request

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=9319-238307\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* [Nielsen Norman Group. (2019). F-Shaped Pattern of Reading on the Web](https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/)
* [U.S. Web Design System. (2022). Cards component](https://designsystem.digital.gov/components/card/)
* Australian Government Design System. (2021). Card component documentation.
* [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)

### Changelog

<table><thead><tr><th width="90.890625">Version</th><th width="174.12890625">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.7.0</td><td>20 March 2024</td><td>Updated component to improve accessibility compliance with WCAG 2.2 standards</td></tr><tr><td>1.6.0</td><td>Previous</td><td>Initial version of the component</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Subject Card

The Subject Card component provides a clickable, themed card interface for presenting navigational topics or categories with visual emphasis through optional background imagery.

### When to use:

Use the Subject Card component when you need to:

* Present popular or high-priority topics in a visually engaging format
* Create category navigation that benefits from visual differentiation
* Direct users to key content areas within your site in a prominent way
* Group related content under themed visual containers
* Enhance the visual hierarchy of your information architecture

### When not to use:

Do not use the Subject Card component when:

* The content requires detailed explanations or multiple actions that would be better served by more complex components
* You need to display dynamic, frequently updating content that would be better suited to a feed or list format
* You're presenting purely informational content with no navigational purpose
* Users need to compare detailed information across multiple items, which would be better served by a table or list view
* Space is limited and simpler navigation patterns would be more appropriate

***

### Best practice guidelines:

* **Clear labelling**: Use concise, descriptive headings that clearly communicate the topic or category represented
* **Visual consistency**: Maintain a consistent visual style across all Subject Cards on a page to create a cohesive experience
* **Background imagery**: When using background images, ensure they are relevant to the subject matter and don't impede text readability
* **Hierarchy considerations**: Place the most important or frequently accessed topics in prominent positions within the layout
* **Responsive behaviour**: Ensure Subject Cards adapt appropriately across different viewport sizes, maintaining readability and usability
* **Balanced design**: When using multiple Subject Cards together, create a balanced layout with consistent spacing and sizing
* **Accessibility focus**: Ensure sufficient contrast between text and background, especially when using themed backgrounds
* **Touch targets**: Make the entire card clickable for easier interaction on touch devices, not just the heading or text elements

### Variations:

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40190&t=998o74fMWsnrD2FZ-1>" %}

* **With/without link**: Cards can be configured to be interactive links or static display cards
* **With/without image**: Cards can include background imagery for visual emphasis or use a simpler, solid background
* **Light/dark theme**: Cards can be styled with either light or dark themes to suit different design requirements

***

### Accessibility:

Based on the 'CivicTheme v1.7.0 Accessibility Assessments' file, the Subject Card component has been evaluated against WCAG 2.2 standards with the following results:

The component has passed testing for multiple standards including:

| WCAG Criterion                      | Level | Status |
| ----------------------------------- | ----- | ------ |
| **1.1.1 Non-text Content**          | A     | Pass   |
| **1.4.3 Contrast (Minimum)**        | AA    | Pass   |
| **1.4.4 Resize text**               | AA    | Pass   |
| **1.4.12 Text Spacing**             | AA    | Pass   |
| **2.1.1 Keyboard**                  | A     | Pass   |
| **2.4.4 Link Purpose (In Context)** | A     | Pass   |
| **2.4.7 Focus Visible**             | AA    | Pass   |
| **4.1.2 Name, Role, Value**         | A     | Pass   |

This component meets WCAG 2.2 AA accessibility guidelines.

### Security:

No specific security considerations have been identified for this component beyond standard web security practices.

### Component inspiration and uplift:

The Subject Card component has been modelled after the Card component from the former Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* **Enhanced theming**: Subject Cards can now be themed with background imagery to create more visually engaging navigation elements
* **Improved hierarchy**: Elevation shadows have been more prominently used to emphasise hierarchy and encourage interactions
* **Interactive states**: Updated interactive states to "Link" and "Without Link" for clearer usage patterns
* **Typography improvements**: Updated the heading size from 5 to 4, making it visually larger and more accessible
* **Simplified interaction design**: The card title's default link underline has been removed to create a cleaner visual appearance while maintaining accessibility

The component follows the Digital Service Standard requirements for accessible, user-centred design by ensuring it can be easily understood and navigated by all users.

***

### User research on this component:

★★★☆☆ Confidence rating = Medium (Limited testing with end users)

Based on the available information, some user research has been conducted on card components generally in the CivicTheme system, though specific detailed research focused solely on the Subject Card component is limited. Research across similar card patterns indicates users respond positively to:

* Clear visual hierarchy that helps them quickly scan and identify relevant topics
* The ability to navigate directly to topic areas through visually distinct elements
* Background imagery that provides visual context for the topic area

More comprehensive user testing specifically focused on the Subject Card component would enhance confidence in these findings.

### Known issues:

* **Mobile responsiveness**: On smaller screens, cards with background images may sometimes have readability issues if the image and text don't maintain sufficient contrast at all screen sizes
* **Consistency in implementation**: When multiple content editors add Subject Cards across a site, maintaining visual consistency in background imagery selection can be challenging
* **Loading performance**: When using high-resolution background images, care must be taken to optimise image file sizes to prevent performance impacts

### More research needed:

More user research is needed in the following areas:

* Comparative effectiveness of Subject Cards with and without background imagery for different user groups and contexts
* Optimal number of Subject Cards to display in a single view before cognitive load becomes an issue
* User expectations and preferences regarding interaction patterns when encountering Subject Card components
* Effectiveness of Subject Cards for improving information architecture comprehension across different demographics
* Performance impact of background imagery on page load times, especially for users on slower connections

### Help improve this component:

To help make this component useful and up-to-date, you can:

* Contribute to our Subject Card component discussion
* Submit your user research findings to help improve the Subject Card component
* Propose a change to the Subject Card component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources:

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-40190\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References:

* Krug, S. (2014). Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability.
* [Material Design (2020). Cards - Components](https://material.io/components/cards)
* [Nielsen Norman Group (2019). Cards: UI-Component Definition](https://www.nngroup.com/articles/cards-component/)

### Changelog:

<table><thead><tr><th width="103.1484375">Version</th><th width="147.83984375">Date</th><th>Changes</th></tr></thead><tbody><tr><td>1.8.0</td><td>23 Jul 2024</td><td>Updated interactive states to Link and Without Link; Updated the heading size from 5 to 4</td></tr><tr><td>1.7.0</td><td>20 Mar 2024</td><td>WCAG 2.2 compliance updates</td></tr><tr><td>1.6.0</td><td>[Previous date]</td><td>Previous updates</td></tr></tbody></table>

### Contact us:

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.


# Table of Contents

A navigational component that helps users understand the structure of the current page and jump directly to specific sections.

### When to use

Use the table of contents component when:

* Content pages are long with multiple sections and subsections
* Users need to quickly scan the structure of a page
* You want to provide easy navigation to different sections of a long document
* You need to improve navigation within content-heavy pages such as information guides, policy documentation, or lengthy articles

### When not to use

Do not use the table of contents component when:

* The page has minimal content or only a few short sections
* The page structure is extremely simple with limited headings
* Content is primarily visual rather than text-based
* The space available is too limited to display the table of contents effectively
* The content follows a step-by-step wizard pattern where linear progression is required

***

### Best practice guidelines

* **Accurate reflection**: Ensure the table of contents accurately reflects the heading structure of the page, maintaining the correct hierarchy of headings.
* **Concise entries**: Keep table of contents entries concise and clear, ideally no more than one line per item.
* **Logical structure**: Maintain a clear visual hierarchy that shows the relationship between sections and subsections through appropriate indentation.
* **Responsive design**: Adapt the presentation of the table of contents for different screen sizes, potentially converting to a collapsible component on mobile devices.
* **Persistent access**: Consider making the table of contents "sticky" or persistent on long pages so users always have access to navigation as they scroll.
* **Visual distinction**: Ensure the table of contents is visually distinct from the main content while still following the design system's visual language.
* **Highlight current section**: Indicate the user's current position in the document by highlighting the corresponding entry in the table of contents.
* **Avoid overloading**: Only include meaningful section headers (H2, H3) in the table of contents—avoid including every heading level as this can create visual clutter.

### Variations

{% embed url="<https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-42377&t=998o74fMWsnrD2FZ-1>" %}

The table of contents component is available in the following variations:

**Standard table of contents**:

* Default styling, typically placed at the top of a content page before the main content begins
* Includes section titles linked to their respective sections on the page

**Sticky/fixed table of contents**:

* Remains visible as the user scrolls down the page, typically positioned in a sidebar
* Provides constant access to navigation regardless of scroll position

**Collapsible table of contents**:

* Can be expanded or collapsed to save space, particularly useful on mobile devices
* Usually displays a "Table of contents" or "In this page" header with an expansion indicator

**Nested table of contents**:

* Shows multiple levels of headings with clear visual hierarchy
* Provides more detailed navigation for complex documents

***

### Accessibility

This component has been assessed against WCAG 2.2 accessibility guidelines. Based on the CivicTheme v1.7.0 Accessibility Assessments, the following standards were tested for this component:

Summary of test results:

* All WCAG 2.2 Level A guidelines passed
* All WCAG 2.2 Level AA guidelines passed
* Not tested against all WCAG 2.2 Level AAA guidelines

Key accessibility features:

* Proper heading structure and semantic markup
* Keyboard navigability between all links
* Visible focus indicators for keyboard users
* Sufficient color contrast for text and interactive elements
* Proper ARIA roles and attributes to enhance screen reader compatibility

### Security

The table of contents component does not process user data or handle sensitive information, minimizing security concerns. Standard web security practices should be followed during implementation.

### Component inspiration and uplift

This component has been modelled after the In-page Nav component in the former Australian Government Design System (AGDS). It has been uplifted by Salsa Digital, as the custodian of the CivicTheme Design System, in the following ways:

* Created stronger contrast/distinction between resting and hover states of section links
* Used smaller text sizes for section links to better establish content hierarchy
* Improved interaction states to match CivicTheme's design language
* Enhanced mobile responsiveness for improved usability on smaller screens

These uplifts were based on user testing that showed users preferred clearer visual indicators for interactive elements and a more compact design that doesn't overwhelm the main content.

***

### User research on this component

★★★★☆ Confidence rating = High (Based on controlled testing)

User research has been conducted by CivicTheme's design team on the table of contents component's usability and effectiveness. This involved multiple rounds of testing with a diverse group of users.

Key findings from the research:

* Users appreciate the ability to quickly scan page structure before reading content
* Sticky/fixed variations were particularly valued on long pages
* Some users initially overlooked the component, leading to design improvements that increase visual prominence
* Testing confirmed the importance of current section highlighting to help users maintain their bearings

The research validated the table of contents as an essential navigation aid for content-heavy pages and informed several usability improvements to the component.

### Known issues

* **Scroll synchronization**: Some users experience issues with the highlighted section not always accurately reflecting their current position on the page, particularly when sections are close together.
* **Mobile usability**: On smaller screens, the table of contents can take up significant vertical space, potentially pushing important content below the fold if not implemented as a collapsible component.
* **Heading depth**: There is occasional confusion about which heading levels should be included in the table of contents, with some users expecting to see deeper heading levels than are typically shown.

### More research needed

More user research is needed in the following areas:

* Optimal positioning of the table of contents on different page layouts
* User preferences regarding dynamic vs. static table of contents on mobile devices
* Effectiveness of different visual treatments for indicating the current section
* Usage patterns across different user demographics and contexts

If you have conducted user research that addresses any of these gaps, you can submit your research findings to help improve this component.

### Help improve this component

To help make this component useful and up-to-date, you can:

* Contribute to our table of contents component discussion on the CivicTheme GitHub repository
* Submit your user research findings to help improve the component
* Propose a change to the table of contents component via a pull request
* Report bugs or issues you encounter when implementing this component

Check out our [contributing section](/contributing/contribution-model) to learn more.

***

### Resources

* [Figma](https://www.figma.com/design/nXTZFR1mKPLExtEbYtazzD/CivicTheme--Design-System-v1.9.0?node-id=2976-42377\&t=998o74fMWsnrD2FZ-1)
* Storybook
* GitHub

### References

* Nielsen, J. (2010). "Scrolling and Attention." Nielsen Norman Group.
* Loranger, H. (2014). "Minimize Design Risk by Focusing on Outcomes and Context." Nielsen Norman Group.
* W3C Web Accessibility Initiative. (2021). "WAI-ARIA Authoring Practices 1.2: Navigation."
* Australian Government Design System Documentation (Archived)

### Changelog

<table><thead><tr><th width="101.703125">Version</th><th width="134.16796875">Date</th><th>Description</th></tr></thead><tbody><tr><td>1.0.0</td><td>Initial release</td><td>Initial component release</td></tr><tr><td>1.7.0</td><td>March 2024</td><td>Updated to improve contrast between states and optimize for mobile</td></tr></tbody></table>

### Contact us

If you have a question about the CivicTheme design system or need our help, visit the [Getting Help](/getting-started/getting-help) page for guidance.




---

[Next Page](/llms-full.txt/1)

