Skip to content

Commit 5fa0ed9

Browse files
committed
update/badge.md
1 parent 4b53f5c commit 5fa0ed9

1 file changed

Lines changed: 261 additions & 0 deletions

File tree

  • components/indicator/badge/badge
Lines changed: 261 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,261 @@
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

Comments
 (0)