Système de Design de l'État - DSFR

repository·main·Indexed 18 days ago

https://github.com/gouvernementfr/dsfr

A collection of web components (HTML, CSS, and JavaScript) designed for public administration teams to create accessible digital interfaces for government websites. The DSFR is strictly regulated for use by public administrations on .gouv.fr domains and is distributed under the Etalab 2.0 license.

Tokens
221K
Snippets
345
Records
798
Agent score
63%

What's inside DSFR

  1. Overview of the Consent Manager component

    main

    The Consent Manager (Gestionnaire de consentement) is a component designed to inform users and collect their agreement regarding the use of non-essential cookies and personal data. It is built to comply with CNIL recommendations and GDPR requirements.

    Key features include:

    • Consent Banner: Displayed upon site loading to capture initial user choice.
    • Consent Modal: Provides fine-grained management of purposes (finalités) and sub-purposes (sous-finalités).
    • Permanent Accessibility: Ensures users can access and adjust their preferences at any time via a link in the footer.
    • Accessibility: Designed to be accessible to all users.

    Note: The component is not customizable except for the displayed text content.

  2. Overview of the Tableau (Table) component

    main

    The Tableau (Table) component is used to present structured lists of textual and/or numerical data. It is designed to simplify the analysis and comparison of information for users.

    Key features include:

    • Data Organization: Displays information in rows and columns.
    • Functionality: Supports sorting, pagination, and row selection.
    • Interactivity: Can integrate various interactive components such as buttons, links, and input fields.
    • States and Sizes: Supports multiple states (e.g., default, selected) and display sizes (SM, MD, LG) depending on the context.
    • Usage Recommendation: Best suited for complex or large datasets, while maintaining attention to readability across different screen formats.
  3. Overview of DSFR color palette and design tokens

    main
    The DSFR color palette is derived from the official Marque de l’État. Colors are implemented using design tokens, which serve as a transverse naming convention used across design tools (Sketch, Figma) and the codebase. This ensures visual harmony and consistent navigation cues across all State interfaces. The palette is divided into different categories including primary, neutral, system, and illustrative colors, and is designed to work across both light and dark themes.
  4. Overview of the DSFR Analytics API

    main

    The DSFR (Système de Design de l’État) provides an integrated audience measurement tool based on the Eulerian solution. This API is designed to collect and analyze user traffic data (such as visit counts, most consulted pages, time spent, and referral sources) to help optimize content and user experience.

    Key benefits of using the DSFR Analytics API include:

    • Native performance tracking: The API includes built-in tracking markers, eliminating the need for developers to create a custom marking plan (plan de marquage) for their projects.
    • Standardization: It provides a harmonized measurement base for all citizen interactions with DSFR components across different public websites.
    • Standalone capability: While provided by the DSFR, the tool can be used independently via a standalone version.

    For implementation details, refer to the technical documentation.

  5. DSFR Usage Restrictions and Licensing

    main

    ⚠️ Important Usage Rules

    The DSFR is a visual identity marker for the French State. Its use is strictly regulated:

    • Authorized Entities: Only public administrations.
    • Domain Restriction: Use is limited to .gouv.fr domain names.
    • Prohibited Use: Use by entities outside the public administration or for deceptive/fraudulent purposes is strictly forbidden.

    Licensing

    • The code is under the Etalab 2.0 license.
    • Certain assets, such as the Marianne fonts, are subject to specific conditions.
    • For full details, refer to the Terms of Use.
  6. Use the Ajout de fichier (File Upload) component

    main

    The Ajout de fichier component allows users to select and send one or multiple files through an interface. It provides clear indications regarding expected file formats and potential errors.

    Key features include:

    • Support for single or multiple file uploads.
    • Visual feedback for file constraints (format, weight, nature).
    • Standardized, non-customizable design to ensure visual consistency across government services.
    • Accessible integration within forms.
  7. Use the Navigation principale component

    main

    The Navigation principale component serves as the central navigation system for a website, guiding users through primary and secondary sections. It is typically positioned below the header and can incorporate dropdown menus or mega menus to structure information hierarchy.

    Key characteristics:

    • Purpose: Orienting users within the site's main sections.
    • Structure: Supports hierarchical access to information through various levels.
    • Placement: Usually located directly under the site header.
    • Variations: Can include dropdowns or mega menus depending on the density of information.

    For interactive examples and implementation details, refer to the Storybook documentation or the component's specific code and design guides.

  8. Use the Transcription component

    main

    The Transcription component provides a way to display or hide text associated with media content (like video or audio) within an interface. It is designed to ensure accessible and fluid simultaneous reading for users who need text alternatives for media.

    It can be implemented in two primary ways:

    1. Accordion: An expandable/collapsible area directly on the page.
    2. Modal: A pop-up overlay that displays the text.

    This component is built to follow strict integration rules to ensure accessibility and clear structure.

  9. Use the En-tête (Header) component

    main

    The En-tête (Header) component is a navigation element positioned at the top of every page. It serves to identify the site, provide access to the search engine, and offer quick links to key pages or functionalities.

    Key characteristics:

    • Consistency: It ensures visual coherence and compliance with the State's design charter across both desktop and mobile versions.
    • Non-customizable core: The structure is designed to be non-customizable to maintain standard identity and accessibility, though it can be enriched or simplified depending on the site's specific needs.
    • Core elements: Typically integrates visual identity (branding), quick access links, and a search engine.
  10. When to use the Combobox (Liste déroulante riche)

    main

    The Combobox is an advanced selection component designed for complex interactions within forms. Use it when:

    • You need to allow users to select one or multiple options from a list.
    • You want to provide search or filtering capabilities within the list of options.

    Comparison and Best Practices

    • Combobox vs. Simple Select: Use the standard Select component if you want to restrict the user to a single choice only.
    • Combobox vs. Radio/Checkbox: Avoid using a Combobox if there are fewer than 3 options.
    • Comparability: If options must be easily compared (e.g., product prices), prefer Radio buttons over a Combobox.
  11. Button sizes and states

    main

    Sizes

    Buttons are available in three sizes:

    • SM (Small): Best used inside other components.
    • MD (Medium): The default size. Recommended for most use cases.
    • LG (Large): Recommended for high-priority actions.

    Best Practice: Maintain size consistency across a single page.

    States

    • Hover State: Visual feedback when a user mouses over the button.
    • Click State: Visual feedback when the button is clicked.
    • Disabled State: Indicates the button cannot be interacted with.

    Warning: The disabled state is strongly discouraged because it is not keyboard-accessible and can cause user error.

  12. Understand screen reader behavior for Tags

    main

    By default, screen readers announce the name, description, state, and type of a Tag. The specific announcement of the aria-pressed attribute varies by screen reader:

    • VoiceOver (macOS/iOS): Announces as a "toggle button" (bouton de basculement). On macOS, it announces the state ("selected"). On iOS, it announces states like "not pressed / pressed" or "unchecked / checked".
    • NVDA and JAWS: Announces as "toggle button" (bouton bascule / bouton à bascule). States are announced as "not pressed / pressed" (non enfoncé / enfoncé).
    • Narrator and Talkback: Announces as "activation / deactivation button" (bouton d'activation / désactivation). States are announced as "disabled / enabled" (désactivé / activé).