update doc

Author: taohsu

.gitignore

@@ -3,4 +3,11 @@ node_modules
 package-lock.json
 package.json
 .claude
-.env.claude
+.env.claude
+
+# Local secrets — Figma Personal Access Token (never commit)
+.figma-token
+*.pat
+
+# Local-only helper scripts (machine-specific, not for remote)
+/scripts/

components/action/button/button/dsm/changelog.md

@@ -1,5 +1,6 @@
 | Date | Number | Notes |
 |------|--------|-------|
+| Mar 16, 2026 | - | <ul><li>Documentation writing:<ul><li>Rounded corners brand theme availability<li>Multiline and responsiveness</ul></ul> |
 | Jan 21, 2026 | - | <ul><li>Documentation writing: Rounded corners update<li>Documentation writing: Dedicated component: On coloured bg</ul> |
 | Jan 6, 2026 | - | <ul><li>Documentation writing: Definition update</ul> |
 | Oct 10, 2025 | 3.2.0 | The specific component "On colored bg" has been split into two distinct components: <ul><li>A public version offering traditional management of dark and light modes <li>A private version (allowing the core team to nest the component with other components) offering customized mode management with four possible configurations: <ul><li>Always in light mode <li>Always in dark mode <li>Light to dark mode <li>Dark to light mode </ul><li>Consequently, for the private version, the name of the "Inverted color" variant has been replaced to "Mode control".</ul> |

components/action/button/button/dsm/guideline/behaviour_and_accessibility.md

@@ -0,0 +1,30 @@
+A button component must be clearly identifiable, easily navigable via keyboard, accessible to screen readers, and offer intuitive interaction for all users. Adopting these guidelines ensures compliance with WCAG 2.1 standards and an inclusive user experience.
+
+**Semantics and Structure**
+Ensure that each button has a clear and defined action.
+Always use the HTML `<button>` element for buttons, as it is natively accessible and supported by assistive technologies (screen readers).
+Avoid using `<div>` or `<span>` styled as buttons, unless absolutely necessary. In such cases:
+* Add the appropriate ARIA role: `role="button"`.
+* Manage keyboard navigation properly.
+
+**Accessible Text**
+The button's visible text should be clear and easy to understand ("Send" or "Add to Cart").
+Avoid unlabeled or empty buttons.
+If the button contains only an icon, provide a textual alternative using:
+* The `aria-label` attribute (`aria-label="Search"`), or
+* Hidden screen-reader text (using CSS techniques such as `.sr-only`).
+
+**Visible Focus**
+The button must display a clear and visible focus style when navigated to via keyboard (a border or highlight).
+Never disable the browser's native focus state without providing an alternative.
+
+**Screen Reader Compatibility**
+The button's role is automatically detected when using the `<button>` element. If another element is used, add `role="button"`.
+Provide additional context with `aria-label` or `aria-describedby` if the button's action is not clear from the visible text.
+Use ARIA technologies to notify screen readers of changes if necessary (`aria-live`).
+
+**Keyboard Navigation**
+If the button serves a specific role (opening a menu), ensure interactions are intuitive and align with user expectations.
+Users must be able to navigate to and activate the button using only the keyboard:
+* Use the Tab key for navigation.
+* Use Enter or Space for activation.

components/action/button/button/dsm/guideline/multiline_and_responsiveness.md

@@ -0,0 +1,18 @@
+**Multiline**
+This component allows multi-line text editing. Although the number of lines is not technically limited, it is recommended not to exceed one line of text.
+In its "Text + icon" variant, if the label spans multiple lines, the label remains horizontally centred and the icon remains vertically centred.
+
+**Max-width vs full-width**
+For greater flexibility, this component doesn't have a default max-width. To avoid exceeding a width that would degrade readability and the perception of a compact interactive element, we recommend applying **a max-width of around 360px.**
+The component can also naturally wrap within the parent container (or the screen in a mobile use context for exemple) and use the full available width.
+Please note that this behavior is not the default rule; it may be preferred if the template allows it (to improve user comfort or for better page structure/hierarchy).
+
+**User zoom in/out**
+The behavior of the text during user zoom in/out must follow a fundamental principle: the text must remain readable, accessible, and must never break the structure or lose information.
+* The text must always scale proportionally with user zoom. Text resizing must never be blocked.
+* Zooming must never cause text to be truncated or hidden. The component must expand vertically to allow line wrapping.
+* The component's height and width must be flexible, never fixed, in order to automatically adapt its dimensions according to the level of zoom.
+* In order to preserve the minimun interactive area during user zoom out, this component have a min-width and a min-height **of 48px**.
+* Even if, the component has a max-height or a max-width for resizing control purposes, technically, during user zoom in, these limitations are not fixed but must be scalable in order to adapt to the user's zoom level.
+* In its "Text + icon" variant, user zoom in/out doesn't affect the size of the icons; they remain fixed in size (decorative use).
+* As the text is missing, in its "Icon only" variant, the icons follow the same rules as the text.

components/action/button/button/dsm/guideline/rounded_corner.md

@@ -2,4 +2,14 @@
 The square rendering corresponds to Orange's historical style. It conveys the brand's sense of seriousness, robustness and utility-driven. It remains the default style for our digital interface components.
 
 **`True`**
-The rounded rendering offers flexibility without sacrificing the attribution to the brand. It helps anchoring the service in a reality where the visual codes of the mobile area tends to rub off on all interfaces. Use rounded corners for a softer, more approachable, friendly and tactile feel.
+The rounded rendering offers flexibility without sacrificing the attribution to the brand. It helps anchoring the service in a reality where the visual codes of the mobile area tends to rub off on all interfaces. Use rounded corners for a softer, more approachable, friendly and tactile feel.
+
+**Brand theme availability**
+This option is technically not available for all brand themes. Here's the list of rounded corners availability by brand theme:
+
+| Brand theme | Availability |
+|---|---|
+| Orange | ✅ Available |
+| Orange Compact | ✅ Available |
+| Sosh | ❌ Unavailable |
+| Wireframe | ❌ Unavailable |

components/action/button/button/figma/button_changelog.md

@@ -1,5 +1,8 @@
 | Date | Number | Notes | Designer |
 |------|--------|-------|----------|
+| Mar 16, 2026 | - | <ul><li>Documentation writing:<ul><li>Rounded corners brand theme availability<li>Multiline and responsiveness</ul></ul> | Maxime Tonnerre |
+| Jan 21, 2026 | - | <ul><li>Documentation writing: Rounded corners update<li>Documentation writing: Dedicated component: On colored bg</ul> | Cyriaque Billard |
+| Jan 6, 2026 | - | <ul><li>Documentation writing: Definition update</ul> | Cyriaque Billard |
 | Oct 10, 2025 | 3.2.0 | The specific component "On colored bg" has been split into two distinct components: <ul><li>A public version offering traditional management of dark and light modes <li>A private version (allowing the core team to nest the component with other components) offering customized mode management with four possible configurations: <ul><li>Always in light mode <li>Always in dark mode <li>Light to dark mode <li>Dark to light mode </ul><li>Consequently, for the private version, the name of the "Inverted color" variant has been replaced to "Mode control".</ul> | Maxime Tonnerre |
 | Sep 28, 2025 | 3.1.0 | <ul><li>Brand variant: New background and content color tokens added for hover/pressed/loading/focus states <li>The name of the "Hierarchy" variant has been replaced to "Appearance"</ul> | Maxime Tonnerre |
 | Jul 24, 2025 | 3.0.0 | <ul><li>New hierarchical variant: Brand → [Component tokens changelog 1.4.0](https://www.figma.com/design/Co2t6wHMf4GB9NJVGs2Hes/-OUDS-Core-Lib--Design-tokens?m=auto&node-id=9280-2568&t=HLVB4jOd35DWr8Bj-1) <li>Rounded corner property is now available → [Component tokens changelog 1.4.0](https://www.figma.com/design/Co2t6wHMf4GB9NJVGs2Hes/-OUDS-Core-Lib--Design-tokens?m=auto&node-id=9280-2568&t=HLVB4jOd35DWr8Bj-1) <li>Minimal variant: Color and width border tokens removed <li>Minimal variant: Color background tokens removed in the enabled state <li>Minimal variant: Color background tokens removed in the loading state <li>Minimal variant: Color background tokens removed in the disabled state</ul> | Maxime Tonnerre |

components/action/button/button/figma/button_overview.md

@@ -58,6 +58,16 @@ Uses the "Skeleton" component, variant "Security marge=False".
 **`True`** For a finish with rounded corner.
 To be favored in more emotional, immersive contexts or those tied to specific visual identities. For standard or business-oriented journeys, keep the default corners. This evolution addresses the need for flexibility in adapting the design to certain brand contexts.
 
+**Brand theme availability**
+This option is technically not available for all brand themes. Here's the list of rounded corners availability by brand theme:
+
+| Brand theme | Availability |
+|---|---|
+| Orange | ✅ Available |
+| Orange Compact | ✅ Available |
+| Sosh | ❌ Unavailable |
+| Wireframe | ❌ Unavailable |
+
 ---
 
 ## Specific component: On colored bg
@@ -69,3 +79,61 @@ This variant ensures a sufficiently high level of accessibility when the compone
 • In dark mode: For a white finish
 
 ---
+
+## Multiline and responsiveness
+
+**Multiline**
+This component allows multi-line text editing. Although the number of lines is not technically limited, it is recommended not to exceed one line of text.
+In its "Text + icon" variant, if the label spans multiple lines, the label remains horizontally centred and the icon remains vertically centred.
+
+**Max-width vs full-width**
+For greater flexibility, this component doesn't have a default max-width. To avoid exceeding a width that would degrade readability and the perception of a compact interactive element, we recommend applying **a max-width of around 360px.**
+The component can also naturally wrap within the parent container (or the screen in a mobile use context for exemple) and use the full available width.
+Please note that this behavior is not the default rule; it may be preferred if the template allows it (to improve user comfort or for better page structure/hierarchy).
+
+**User zoom in/out**
+The behavior of the text during user zoom in/out must follow a fundamental principle: the text must remain readable, accessible, and must never break the structure or lose information.
+* The text must always scale proportionally with user zoom. Text resizing must never be blocked.
+* Zooming must never cause text to be truncated or hidden. The component must expand vertically to allow line wrapping.
+* The component's height and width must be flexible, never fixed, in order to automatically adapt its dimensions according to the level of zoom.
+* In order to preserve the minimun interactive area during user zoom out, this component have a min-width and a min-height **of 48px**.
+* Even if, the component has a max-height or a max-width for resizing control purposes, technically, during user zoom in, these limitations are not fixed but must be scalable in order to adapt to the user's zoom level.
+* In its "Text + icon" variant, user zoom in/out doesn't affect the size of the icons; they remain fixed in size (decorative use).
+* As the text is missing, in its "Icon only" variant, the icons follow the same rules as the text.
+
+---
+
+## Behaviour and accessibility
+
+A button component must be clearly identifiable, easily navigable via keyboard, accessible to screen readers, and offer intuitive interaction for all users. Adopting these guidelines ensures compliance with WCAG 2.1 standards and an inclusive user experience.
+
+**Semantics and Structure**
+Ensure that each button has a clear and defined action.
+Always use the HTML `<button>` element for buttons, as it is natively accessible and supported by assistive technologies (screen readers).
+Avoid using `<div>` or `<span>` styled as buttons, unless absolutely necessary. In such cases:
+* Add the appropriate ARIA role: `role="button"`.
+* Manage keyboard navigation properly.
+
+**Accessible Text**
+The button's visible text should be clear and easy to understand ("Send" or "Add to Cart").
+Avoid unlabeled or empty buttons.
+If the button contains only an icon, provide a textual alternative using:
+* The `aria-label` attribute (`aria-label="Search"`), or
+* Hidden screen-reader text (using CSS techniques such as `.sr-only`).
+
+**Visible Focus**
+The button must display a clear and visible focus style when navigated to via keyboard (a border or highlight).
+Never disable the browser's native focus state without providing an alternative.
+
+**Screen Reader Compatibility**
+The button's role is automatically detected when using the `<button>` element. If another element is used, add `role="button"`.
+Provide additional context with `aria-label` or `aria-describedby` if the button's action is not clear from the visible text.
+Use ARIA technologies to notify screen readers of changes if necessary (`aria-live`).
+
+**Keyboard Navigation**
+If the button serves a specific role (opening a menu), ensure interactions are intuitive and align with user expectations.
+Users must be able to navigate to and activate the button using only the keyboard:
+* Use the Tab key for navigation.
+* Use Enter or Space for activation.
+
+---