|
| 1 | +# Guideline |
| 2 | + |
| 3 | +## Intro 👈🤖 |
| 4 | + |
| 5 | +A badge is a compact visual indicator that highlights status, notifications, or categorization within an interface using color-coded labels. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## Definition |
| 10 | + |
| 11 | +The Badge is a small UI element used to highlight status, notifications, or categorization within an interface. It is often displayed as a label or indicator with a distinct background color and text. |
| 12 | + |
| 13 | +**Usage:** |
| 14 | +• Renders as a static label without a number. |
| 15 | +Used for status indicators (e.g., "New", "Pending", "Success"). |
| 16 | +The size remains unchanged despite the increase in the interface size. |
| 17 | + |
| 18 | +--- |
| 19 | + |
| 20 | +## Best for 👈🤔 |
| 21 | + |
| 22 | +✅ Indicating system or item status (success, warning, error, info) |
| 23 | + |
| 24 | +✅ Highlighting new features, updates, or content discoveries |
| 25 | + |
| 26 | +✅ Showing approval or completion states in workflows |
| 27 | + |
| 28 | +✅ Categorizing content with color-coded visual labels |
| 29 | + |
| 30 | +✅ Drawing attention to important metadata without interrupting user flow |
| 31 | + |
| 32 | +✅ Communicating urgency levels in dashboard or list views |
| 33 | + |
| 34 | +✅ Displaying content states like "Draft", "Published", or "Archived" |
| 35 | + |
| 36 | +✅ Supplementing navigation items with status context |
| 37 | + |
| 38 | +✅ Providing quick visual feedback for data validation results |
| 39 | + |
| 40 | +✅ Marking items requiring user attention in compact spaces |
| 41 | + |
| 42 | +--- |
| 43 | + |
| 44 | +## Anatomy 👈🤖 |
| 45 | + |
| 46 | +| # | Element | Purpose | Optional | |
| 47 | +|---|---------|---------|----------| |
| 48 | +| 1 | Container | Pill-shaped background that holds the badge and applies semantic color | N | |
| 49 | +| 2 | Background fill | Color surface indicating status type (neutral, accent, positive, info, warning, negative) | N | |
| 50 | +| 3 | Border radius | Fully rounded corners (pill shape) for visual distinction | N | |
| 51 | +| 4 | Size constraint | Fixed dimensions based on size variant (8px, 12px, 16px, 20px) | N | |
| 52 | +| 5 | Disabled state styling | Reduced opacity/color to indicate inactive status | Y | |
| 53 | + |
| 54 | +--- |
| 55 | + |
| 56 | +## State |
| 57 | + |
| 58 | +**`Enabled`** The active state of a badge. Includes all possible visual statuses that represent the current state of the system or element (e.g., success, warning, error, information, etc.). Used when the badge should attract attention and convey meaningful information. |
| 59 | + |
| 60 | +**`Disabled`** The inactive state of a badge. Used to indicate that the user isn't allowed to interact with an element, or when the status is unavailable. It appears less prominent and serves as a secondary indication. |
| 61 | + |
| 62 | +--- |
| 63 | + |
| 64 | +## state_do_&_dont 👈🤔 |
| 65 | + |
| 66 | +✅ **Do:** Use the enabled state when the badge conveys actionable or relevant status information that users need to see. |
| 67 | +❌ **Don't:** Display enabled badges for outdated or irrelevant status that no longer applies. |
| 68 | + |
| 69 | +✅ **Do:** Apply the disabled state when the associated element or feature is unavailable or inactive. |
| 70 | +❌ **Don't:** Use disabled badges as the primary way to hide information—consider removing the badge entirely if not needed. |
| 71 | + |
| 72 | +✅ **Do:** Maintain consistent visual distinction between enabled and disabled states across all status variants. |
| 73 | +❌ **Don't:** Allow disabled badges to have the same visual weight as enabled badges, causing confusion. |
| 74 | + |
| 75 | +✅ **Do:** Use disabled badges to indicate temporarily unavailable statuses that may become active later. |
| 76 | +❌ **Don't:** Use disabled state for permanent conditions—choose appropriate enabled status colors instead. |
| 77 | + |
| 78 | +✅ **Do:** Ensure disabled badges still meet minimum contrast requirements for accessibility. |
| 79 | +❌ **Don't:** Make disabled badges so faint that users cannot perceive them at all. |
| 80 | + |
| 81 | +--- |
| 82 | + |
| 83 | +## Status |
| 84 | + |
| 85 | +Badges have seven states depending on the context of the information they represent. Each state is designed to convey a specific meaning and ensure clarity in communication. |
| 86 | + |
| 87 | +**Non fonctionnel** |
| 88 | + |
| 89 | +**`Neutral`** Used for general labels without specific emphasis. |
| 90 | + |
| 91 | +**`Accent`** Employed to highlight discovery or exploration-related content. |
| 92 | + |
| 93 | +**Fonctionnel** |
| 94 | + |
| 95 | +**`Positive`** Indicates success, completion, or approval. |
| 96 | + |
| 97 | +**`Info`** Provides informational context without urgency. |
| 98 | + |
| 99 | +**`Warning`** Negatives the user to potential risks or cautionary messages. |
| 100 | + |
| 101 | +**`Negative`** Draws attention to important or critical information. |
| 102 | +Often used for errors, restrictions, or urgent messages, but not exclusively for failures. |
| 103 | + |
| 104 | +--- |
| 105 | + |
| 106 | +## status_do_&_dont 👈🤔 |
| 107 | + |
| 108 | +✅ **Do:** Use semantic colors consistently—green for positive outcomes, red for errors, blue for informational content, yellow for warnings. |
| 109 | +❌ **Don't:** Use random colors that don't align with established semantic meanings in your design system. |
| 110 | + |
| 111 | +✅ **Do:** Reserve negative (red) status for critical issues requiring immediate attention like errors or failures. |
| 112 | +❌ **Don't:** Overuse negative status badges, which desensitizes users to actual critical information. |
| 113 | + |
| 114 | +✅ **Do:** Use neutral status for general labels that don't carry semantic weight or emotional connotation. |
| 115 | +❌ **Don't:** Use neutral badges when a specific status color would better communicate the intended meaning. |
| 116 | + |
| 117 | +✅ **Do:** Apply accent status to highlight new features, discoveries, or promotional content that needs emphasis. |
| 118 | +❌ **Don't:** Use accent badges for system status information where functional colors (positive, warning, negative) are more appropriate. |
| 119 | + |
| 120 | +✅ **Do:** Use info status for non-urgent informational context like "In Progress" or "Pending Review". |
| 121 | +❌ **Don't:** Use info badges for states that require user action—use warning or negative instead. |
| 122 | + |
| 123 | +--- |
| 124 | + |
| 125 | +## Size |
| 126 | + |
| 127 | +**`Xsmall`** A compact badge for minimal space usage, ideal for small UI elements like icons or tooltips. |
| 128 | + |
| 129 | +**`Small`** A slightly larger badge that remains subtle but improves readability, often used for inline labels. |
| 130 | + |
| 131 | +**`Medium`** The default size, providing a balance between visibility and space efficiency, suitable for most use cases. |
| 132 | + |
| 133 | +**`Large`** A prominent badge for drawing more attention, often used in dashboards or highlighted sections. |
| 134 | + |
| 135 | +--- |
| 136 | + |
| 137 | +## size_do_&_dont 👈🤔 |
| 138 | + |
| 139 | +✅ **Do:** Choose badge size proportional to the element it accompanies—use xsmall for icons, medium for standard UI components. |
| 140 | +❌ **Don't:** Use oversized badges that visually overpower the primary content they're meant to supplement. |
| 141 | + |
| 142 | +✅ **Do:** Maintain consistent badge sizes within the same context or view for visual harmony. |
| 143 | +❌ **Don't:** Mix multiple badge sizes randomly within the same component or list. |
| 144 | + |
| 145 | +✅ **Do:** Use larger badges (medium or large) when the badge conveys critical status information that must be noticed. |
| 146 | +❌ **Don't:** Use xsmall badges for important status information that users might easily miss. |
| 147 | + |
| 148 | +✅ **Do:** Consider touch target requirements when badges appear in mobile or touch interfaces—ensure adequate size for accessibility. |
| 149 | +❌ **Don't:** Use xsmall badges as the only status indicator in touch-heavy interfaces without supporting context. |
| 150 | + |
| 151 | +✅ **Do:** Scale badge size appropriately across responsive breakpoints while maintaining the fixed-size principle within each viewport. |
| 152 | +❌ **Don't:** Allow badges to dynamically resize based on interface scaling, which contradicts the component's design intent. |
| 153 | + |
| 154 | +--- |
| 155 | + |
| 156 | +# Specs |
| 157 | + |
| 158 | +## States |
| 159 | + |
| 160 | +**`Enabled`** The active state of a badge. Includes all possible visual statuses that represent the current state of the system or element (e.g., success, warning, error, information, etc.). Used when the badge should attract attention and convey meaningful information. |
| 161 | + |
| 162 | +**`Disabled`** The inactive state of a badge. Used to indicate that the user isn't allowed to interact with an element, or when the status is unavailable. It appears less prominent and serves as a secondary indication. |
| 163 | + |
| 164 | +--- |
| 165 | + |
| 166 | +## Layout and spacing |
| 167 | + |
| 168 | +🚧 Content to be added |
| 169 | + |
| 170 | +--- |
| 171 | + |
| 172 | +# Accessibility 👈🤖 |
| 173 | + |
| 174 | +## Accessibility intro |
| 175 | + |
| 176 | +Badge components must meet WCAG 2.2 Level AA requirements to ensure status information is perceivable by all users, including those using assistive technologies. For comprehensive accessibility guidance, see the [Orange Unified Design System Accessibility Overview](https://unified-design-system.orange.com/472794e18/p/88ebab-accessibility-and-sustainability). |
| 177 | + |
| 178 | +--- |
| 179 | + |
| 180 | +## Accessibility Challenges |
| 181 | + |
| 182 | +Badges present unique accessibility challenges because they rely heavily on color to convey meaning, are typically small in size, and may update dynamically without user interaction. Screen reader users cannot perceive color differences, so status information must be communicated through alternative means. |
| 183 | + |
| 184 | +### Key Challenges |
| 185 | +- Color-dependent meaning requires text alternatives for color-blind and screen reader users |
| 186 | +- Small size may make badges difficult to perceive for users with low vision |
| 187 | +- Dynamic badge updates may not be announced to assistive technology users |
| 188 | +- Status semantics must be conveyed programmatically, not just visually |
| 189 | + |
| 190 | +### Critical Success Factors |
| 191 | +1. Provide text labels or accessible names that convey the badge's meaning (WCAG 1.1.1) |
| 192 | +2. Ensure sufficient color contrast between badge background and surrounding content (WCAG 1.4.3) |
| 193 | +3. Use ARIA live regions for dynamically updating badge content (WCAG 4.1.3) |
| 194 | +4. Never rely solely on color to communicate status—pair with text or icons |
| 195 | + |
| 196 | +--- |
| 197 | + |
| 198 | +## Design Requirements |
| 199 | + |
| 200 | +### Structure & Labels |
| 201 | +- [ ] **Accessible name**: Provide `aria-label` or visible text that describes the badge status ([Orange labelling guide](https://a11y-guidelines.orange.com/en/web/develop/textual-content/)) |
| 202 | +- [ ] **Semantic meaning**: Use `role="status"` for badges that convey current state information |
| 203 | +- [ ] **Programmatic association**: Associate badge with related element using `aria-describedby` when needed |
| 204 | + |
| 205 | +### Visual Design |
| 206 | +- [ ] **Color contrast**: Ensure ≥3:1 contrast ratio between badge and adjacent background ([Orange contrast guide](https://a11y-guidelines.orange.com/en/web/design/colors-and-contrasts/)) |
| 207 | +- [ ] **Non-color indicators**: Supplement color with text labels or patterns for status meaning |
| 208 | +- [ ] **Minimum size**: Maintain minimum 8px dimension; consider 16px+ for critical status information |
| 209 | + |
| 210 | +### Content |
| 211 | +- [ ] **Descriptive labels**: ❌ "Red badge" / ✅ "Error status" ([Orange text alternatives](https://a11y-guidelines.orange.com/en/web/develop/textual-content/)) |
| 212 | +- [ ] **Concise text**: Keep badge labels brief but meaningful—use full words when space permits |
| 213 | + |
| 214 | +--- |
| 215 | + |
| 216 | +## Testing Checklist |
| 217 | + |
| 218 | +### Screen Reader Testing |
| 219 | +- [ ] Test with NVDA (Windows), JAWS (Windows), VoiceOver (macOS/iOS), TalkBack (Android) |
| 220 | +- [ ] Verify status meaning announced, not just color; dynamic updates spoken via live regions |
| 221 | + |
| 222 | +### Keyboard Testing |
| 223 | +- [ ] Confirm badge is not focusable (badges are display-only, not interactive) |
| 224 | +- [ ] Verify focus moves logically past badges to interactive elements |
| 225 | + |
| 226 | +### Visual Testing |
| 227 | +- [ ] Test with Windows High Contrast Mode, grayscale filters, and color blindness simulators |
| 228 | + |
| 229 | +Resources: [Orange Accessibility Testing Guide](https://a11y-guidelines.orange.com/en/web/test/) |
| 230 | + |
| 231 | +--- |
| 232 | + |
| 233 | +## Key WCAG Criteria |
| 234 | + |
| 235 | +- **1.1.1 Non-text Content** (A): Provide text alternatives for badge icons or color-only indicators |
| 236 | +- **1.4.1 Use of Color** (A): Don't use color as the only visual means of conveying status information |
| 237 | +- **1.4.3 Contrast (Minimum)** (AA): Badge background must have ≥4.5:1 contrast with any text content |
| 238 | +- **1.4.11 Non-text Contrast** (AA): Badge container must have ≥3:1 contrast against adjacent backgrounds |
| 239 | +- **4.1.3 Status Messages** (AA): Use `role="status"` or `aria-live="polite"` for dynamic badge updates |
| 240 | + |
| 241 | +For complete reference: [Orange Accessibility Guidelines - Components](https://a11y-guidelines.orange.com/en/web/components-examples/) |
| 242 | + |
| 243 | +--- |
| 244 | + |
| 245 | +## Additional Resources |
| 246 | + |
| 247 | +- [Orange Accessibility Guidelines - Colors and Contrasts](https://a11y-guidelines.orange.com/en/web/design/colors-and-contrasts/) |
| 248 | +- [Orange Accessibility Guidelines - Textual Content](https://a11y-guidelines.orange.com/en/web/develop/textual-content/) |
| 249 | +- [WCAG 2.2 Understanding Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color) |
| 250 | +- [W3C ARIA Status Role](https://www.w3.org/TR/wai-aria-1.2/#status) |
| 251 | +- [Orange Design System - Accessibility & Sustainability](https://unified-design-system.orange.com/472794e18/p/88ebab-accessibility-and-sustainability) |
| 252 | + |
| 253 | +--- |
| 254 | + |
| 255 | +# Changelog |
| 256 | + |
| 257 | +| Date | Number | Notes | Designer | |
| 258 | +|------|--------|-------|----------| |
| 259 | +| Oct 14, 2025 | 1.2.0 | • The component now has two states: Enabled and Disabled. • Documentation has been updated and published in Zeroeight, with use case examples provided for every state. • The colors and background tokens for the functional states of the positive and info statuses have been changed. • For the "Status neutral" variant, the surface token "color-surface-status-neutral-emphasized" has been replaced by the token "color-surface-inverse-high" | Anton Astafev | |
| 260 | +| Jun 16, 2025 | 1.1.0 | • "Accent" variant added | Maxime Tonnerre | |
| 261 | +| Mai 9, 2025 | 1.0.0 | • Component creation | Anton Astafev | |
0 commit comments