Files of Affordances: Designing for Action
wondelai/
affordances.md
Show the full text260 lines
Affordances: Designing for Action
An affordance is a relationship between an object and a person that determines how the object could possibly be used. A chair affords sitting. A handle affords pulling. A button affords pressing. Affordances exist in the physical properties of the object relative to the capabilities of the user, whether or not the user perceives them. The central design challenge is making affordances visible and unmistakable.
Affordance Types
| Type | Definition | Key Characteristic | Example |
|---|---|---|---|
| Real affordance | An action the object genuinely supports | Exists in the physics/code | A physical button can be pressed; a text input accepts keystrokes |
| Perceived affordance | An action the user believes is possible | Exists in the user's mind | A raised, shadowed rectangle looks pressable even if it is decorative |
| Hidden affordance | An action that exists but is not visible | Discoverable only by accident or instruction | Right-click context menus, multi-finger trackpad gestures |
| False affordance | An appearance of action that does not exist | Misleads the user | Underlined blue text that is not a link; a card with a shadow that is not clickable |
| Anti-affordance | A deliberate prevention of action | Communicates "you cannot do this" | A grayed-out disabled button; a railing that prevents falling |
The Critical Distinction
Real affordances are properties of the system. Perceived affordances are properties of the user's interpretation. Good design aligns these two: every real affordance should be perceived, and no false affordance should exist.
Digital Affordance Patterns
Buttons
| Property | Affords | Signal |
|---|---|---|
| Raised appearance / shadow | Pressing / clicking | Drop shadow, gradient, border |
| Color contrast with background | Attention and interaction | Primary color, high contrast |
| Hover state change | "I respond to interaction" | Background darkens, cursor changes |
| Active/pressed state | "Your click registered" | Slight depression, color shift |
| Disabled state (grayed) | "Not available right now" | Reduced opacity, no cursor change |
Links
| Property | Affords | Signal |
|---|---|---|
| Color differentiation | Navigation | Blue or brand-accent color |
| Underline | "I am clickable text" | Text decoration underline |
| Cursor change to pointer | "Click me" | CSS cursor: pointer |
| Visited state color | "You have been here" | Purple or muted color |
Text Inputs
| Property | Affords | Signal |
|---|---|---|
| Border / outline | "Type here" | Visible rectangular boundary |
| Placeholder text | "This is what goes here" | Light gray sample text |
| Focus ring | "You are editing this" | Blue outline on focus |
| Blinking cursor | "I am ready for input" | Text insertion cursor |
| Label above/beside | "This field is for X" | Descriptive text |
Sliders
| Property | Affords | Signal |
|---|---|---|
| Handle / thumb | Dragging | Circular or rectangular grab target |
| Track | Range of movement | Horizontal or vertical line |
| Fill color | Current value | Colored portion of the track |
| Min/max labels | Boundaries | Text or numbers at each end |
Drag Targets
| Property | Affords | Signal |
|---|---|---|
| Grip dots or lines | "Grab and move me" | Six-dot handle icon |
| Cursor change to grab | "Draggable" | CSS cursor: grab |
| Lift animation on drag start | "I am being moved" | Shadow increase, slight scale up |
| Drop zone highlight | "Drop it here" | Border change, background tint |
Physical vs. Digital Affordances
| Dimension | Physical | Digital |
|---|---|---|
| Perception | Seen, felt, heard directly | Seen on screen; no physical texture |
| Constraint | Physics prevents wrong use | Only code prevents wrong use |
| Discoverability | Explore by touch and manipulation | Explore by clicking, hovering, scrolling |
| Feedback | Immediate tactile response | Must be programmed explicitly |
| Cultural learning | Handles, knobs, buttons are universal | UI conventions are learned (hamburger menu, swipe gestures) |
| Cost of error | May cause physical harm | Rarely dangerous, but data loss possible |
Implications for Digital Design
Physical objects get affordances "for free" from their material properties. Digital interfaces must manufacture every affordance through visual design. This means:
- Every interactive element needs deliberate visual treatment.
- Non-interactive elements must be visually distinct from interactive ones.
- New interaction patterns (gestures, voice) start with zero perceived affordance and need onboarding.
The Flat Design Problem: When Affordances Disappear
Flat design (the removal of skeuomorphic visual cues like shadows, gradients, and borders) creates a systematic affordance crisis. When buttons look like labels and labels look like buttons, users cannot distinguish interactive elements from static content.
What Flat Design Removes
| Removed Cue | Affordance Lost | User Impact |
|---|---|---|
| Drop shadows on buttons | "This is pressable" | Users do not recognize buttons |
| Borders on inputs | "Type here" | Users do not know where to click to type |
| Underlines on links | "This navigates" | Users cannot find links in body text |
| Gradients and bevels | "This is interactive" | All elements look equally flat and static |
| Visual depth / layering | "This is above/below that" | Users lose sense of hierarchy |
Recovering Affordances in Flat Design
- Use color contrast to distinguish interactive elements from static ones.
- Add hover and focus states that reveal interactivity.
- Use consistent spacing to create clickable regions.
- Apply subtle shadows or borders (flat design does not mean zero visual depth).
- Always provide cursor changes on interactive elements.
- Pair icons with labels so meaning is not ambiguous.
Touch vs. Mouse Affordances
| Factor | Mouse | Touch |
|---|---|---|
| Hover state | Available and essential | Does not exist; cannot preview interactivity |
| Precision | High (single pixel) | Low (finger covers ~44px) |
| Right-click | Common interaction | Not available natively |
| Drag and drop | Natural with mouse | Conflicts with scroll gesture |
| Cursor feedback | Changes shape to signal affordance | No cursor exists |
| Target size | Minimum ~24px | Minimum 44x44px (Apple HIG) or 48x48dp (Material) |
Touch-Specific Affordance Strategies
- Make all touch targets at least 44x44 points.
- Use visual weight (size, color, shadow) instead of hover states to signal interactivity.
- Provide haptic feedback (vibration) on interaction to replace the tactile click of a mouse button.
- Avoid relying on gestures as the only way to access critical actions; always provide a visible alternative.
- Show visual hints for swipeable content (partial next-card visible, dots indicator).
Affordance Audit Checklist
Use this checklist to evaluate any screen or physical product.
Interactive Elements
- Every button is visually distinguishable from non-interactive text and containers.
- Every link has at least two signals (color + underline, or color + cursor change).
- Every text input has a visible boundary (border, background contrast, or underline).
- Every slider has a visible handle and track.
- Every draggable element has a grip indicator.
- All touch targets are at least 44x44 points (mobile) or 24x24 pixels (desktop).
Non-Interactive Elements
- Static text does not use the same color as links.
- Decorative images do not have clickable appearance (no pointer cursor, no hover effect).
- Section headers are not styled like buttons.
- Cards and containers that are not clickable do not have hover lift effects.
Hidden Affordances
- Any gesture-based interaction also has a visible control alternative.
- Keyboard shortcuts are documented in the interface (tooltip, menu, help).
- Right-click menus duplicate functionality available through visible controls.
- Swipeable content shows a visual hint that more content exists.
False Affordances
- No underlined text that is not a link.
- No colored text that looks like a link but is not.
- No card shadows or hover effects on non-interactive containers.
- No cursor: pointer on non-interactive elements.
Before/After Examples of Affordance Improvements
Example 1: Flat Submit Button
Before: A gray text label "Submit" with no border, no shadow, no background color. Users do not realize it is clickable.
After: A filled blue rectangle with white text "Submit", a subtle shadow, and a darkened hover state. Users immediately recognize it as a button.
Principle applied: Perceived affordance aligned with real affordance through visual treatment.
Example 2: Hidden Navigation
Before: A three-line hamburger icon in the top corner. New users do not know it contains navigation. Engagement with secondary pages is low.
After: A visible horizontal navigation bar with text labels for the top 4 sections, plus a "More" dropdown for the rest. Engagement with secondary pages increases by 50% or more.
Principle applied: Hidden affordance converted to visible affordance.
Example 3: Non-Obvious Text Input
Before: A thin bottom-border line with a small floating label. Users click randomly around the area unsure where the input field actually is.
After: A fully bordered rectangle with a label above, placeholder text inside, and a clear focus ring. Users click into the input immediately.
Principle applied: Real affordance made perceivable through boundary signifiers.
Example 4: Gesture-Only Delete
Before: On mobile, the only way to delete a list item is to swipe left. Users who do not know the gesture cannot delete items.
After: Swipe-to-delete still works, but each item also has a visible trash icon on tap or a long-press menu. All users can access the delete function.
Principle applied: Hidden affordance supplemented with visible alternative.
Common Affordance Failures by Platform
Web
| Failure | Impact | Fix |
|---|---|---|
| Ghost buttons (transparent with thin border) | Low click-through rates | Use filled buttons for primary actions |
| Cards without hover state that are clickable | Users miss clickable content | Add hover elevation or background change |
| Dropdown triggers that look like labels | Users do not know to click | Add a chevron icon and border |
Mobile (iOS / Android)
| Failure | Impact | Fix |
|---|---|---|
| Small touch targets | Frequent mis-taps, frustration | Minimum 44pt / 48dp targets |
| Swipe-only actions | Core functionality is invisible | Provide visible button alternative |
| Bottom sheet handle with no label | Users do not know to drag up | Add "Swipe up for details" text or an upward chevron |
Desktop Applications
| Failure | Impact | Fix |
|---|---|---|
| Toolbar with icon-only buttons | Users memorize slowly, new users lost | Add text labels below icons |
| Resizable panels without grab edges | Users cannot resize | Show a dotted grab edge or resize cursor on hover |
| Menu items with no keyboard shortcut listed | Power users cannot accelerate | Show shortcut text next to every menu item |
Accessibility and Affordances
Affordances must work for all users, including those who use assistive technologies.
| User Group | Affordance Consideration |
|---|---|
| Screen reader users | Every interactive element must have an accessible role (button, link, input) and a descriptive label. Visual affordances are invisible; semantic affordances must replace them. |
| Keyboard-only users | Every interactive element must be focusable and operable with Enter or Space. Focus rings are the keyboard equivalent of hover states: they are affordance signifiers. |
| Low-vision users | Interactive elements need sufficient color contrast (WCAG 4.5:1 for text, 3:1 for UI components). Size thresholds increase. |
| Motor-impaired users | Touch targets must be larger (WCAG recommends 44x44 CSS pixels). Drag-and-drop must have a click-based alternative. |
| Cognitive disabilities | Affordances must be explicit, not implied. Labels are better than icons alone. Consistent placement is essential. |
Accessibility Affordance Checklist
- All interactive elements have correct ARIA roles or native HTML semantics.
- Focus order follows visual order.
- Focus rings are visible and high-contrast.
- Interactive elements are reachable and operable via keyboard.
- Color is not the only affordance signal (shape, border, or icon accompanies color).
- Touch targets meet minimum size requirements.
- Drag interactions have non-drag alternatives.
| 1 | # Affordances: Designing for Action |
| 2 | |
| 3 | An affordance is a relationship between an object and a person that determines how the object could possibly be used. A chair affords sitting. A handle affords pulling. A button affords pressing. Affordances exist in the physical properties of the object relative to the capabilities of the user, whether or not the user perceives them. The central design challenge is making affordances visible and unmistakable. |
| 4 | |
| 5 | ## Affordance Types |
| 6 | |
| 7 | | Type | Definition | Key Characteristic | Example | |
| 8 | |------|------------|-------------------|---------| |
| 9 | | **Real affordance** | An action the object genuinely supports | Exists in the physics/code | A physical button can be pressed; a text input accepts keystrokes | |
| 10 | | **Perceived affordance** | An action the user believes is possible | Exists in the user's mind | A raised, shadowed rectangle looks pressable even if it is decorative | |
| 11 | | **Hidden affordance** | An action that exists but is not visible | Discoverable only by accident or instruction | Right-click context menus, multi-finger trackpad gestures | |
| 12 | | **False affordance** | An appearance of action that does not exist | Misleads the user | Underlined blue text that is not a link; a card with a shadow that is not clickable | |
| 13 | | **Anti-affordance** | A deliberate prevention of action | Communicates "you cannot do this" | A grayed-out disabled button; a railing that prevents falling | |
| 14 | |
| 15 | ### The Critical Distinction |
| 16 | |
| 17 | Real affordances are properties of the system. Perceived affordances are properties of the user's interpretation. Good design aligns these two: every real affordance should be perceived, and no false affordance should exist. |
| 18 | |
| 19 | |
| 20 | |
| 21 | ## Digital Affordance Patterns |
| 22 | |
| 23 | ### Buttons |
| 24 | |
| 25 | | Property | Affords | Signal | |
| 26 | |----------|---------|--------| |
| 27 | | Raised appearance / shadow | Pressing / clicking | Drop shadow, gradient, border | |
| 28 | | Color contrast with background | Attention and interaction | Primary color, high contrast | |
| 29 | | Hover state change | "I respond to interaction" | Background darkens, cursor changes | |
| 30 | | Active/pressed state | "Your click registered" | Slight depression, color shift | |
| 31 | | Disabled state (grayed) | "Not available right now" | Reduced opacity, no cursor change | |
| 32 | |
| 33 | ### Links |
| 34 | |
| 35 | | Property | Affords | Signal | |
| 36 | |----------|---------|--------| |
| 37 | | Color differentiation | Navigation | Blue or brand-accent color | |
| 38 | | Underline | "I am clickable text" | Text decoration underline | |
| 39 | | Cursor change to pointer | "Click me" | CSS cursor: pointer | |
| 40 | | Visited state color | "You have been here" | Purple or muted color | |
| 41 | |
| 42 | ### Text Inputs |
| 43 | |
| 44 | | Property | Affords | Signal | |
| 45 | |----------|---------|--------| |
| 46 | | Border / outline | "Type here" | Visible rectangular boundary | |
| 47 | | Placeholder text | "This is what goes here" | Light gray sample text | |
| 48 | | Focus ring | "You are editing this" | Blue outline on focus | |
| 49 | | Blinking cursor | "I am ready for input" | Text insertion cursor | |
| 50 | | Label above/beside | "This field is for X" | Descriptive text | |
| 51 | |
| 52 | ### Sliders |
| 53 | |
| 54 | | Property | Affords | Signal | |
| 55 | |----------|---------|--------| |
| 56 | | Handle / thumb | Dragging | Circular or rectangular grab target | |
| 57 | | Track | Range of movement | Horizontal or vertical line | |
| 58 | | Fill color | Current value | Colored portion of the track | |
| 59 | | Min/max labels | Boundaries | Text or numbers at each end | |
| 60 | |
| 61 | ### Drag Targets |
| 62 | |
| 63 | | Property | Affords | Signal | |
| 64 | |----------|---------|--------| |
| 65 | | Grip dots or lines | "Grab and move me" | Six-dot handle icon | |
| 66 | | Cursor change to grab | "Draggable" | CSS cursor: grab | |
| 67 | | Lift animation on drag start | "I am being moved" | Shadow increase, slight scale up | |
| 68 | | Drop zone highlight | "Drop it here" | Border change, background tint | |
| 69 | |
| 70 | |
| 71 | |
| 72 | ## Physical vs. Digital Affordances |
| 73 | |
| 74 | | Dimension | Physical | Digital | |
| 75 | |-----------|----------|---------| |
| 76 | | **Perception** | Seen, felt, heard directly | Seen on screen; no physical texture | |
| 77 | | **Constraint** | Physics prevents wrong use | Only code prevents wrong use | |
| 78 | | **Discoverability** | Explore by touch and manipulation | Explore by clicking, hovering, scrolling | |
| 79 | | **Feedback** | Immediate tactile response | Must be programmed explicitly | |
| 80 | | **Cultural learning** | Handles, knobs, buttons are universal | UI conventions are learned (hamburger menu, swipe gestures) | |
| 81 | | **Cost of error** | May cause physical harm | Rarely dangerous, but data loss possible | |
| 82 | |
| 83 | ### Implications for Digital Design |
| 84 | |
| 85 | Physical objects get affordances "for free" from their material properties. Digital interfaces must manufacture every affordance through visual design. This means: |
| 86 | |
| 87 | Every interactive element needs deliberate visual treatment. |
| 88 | Non-interactive elements must be visually distinct from interactive ones. |
| 89 | New interaction patterns (gestures, voice) start with zero perceived affordance and need onboarding. |
| 90 | |
| 91 | |
| 92 | |
| 93 | ## The Flat Design Problem: When Affordances Disappear |
| 94 | |
| 95 | Flat design (the removal of skeuomorphic visual cues like shadows, gradients, and borders) creates a systematic affordance crisis. When buttons look like labels and labels look like buttons, users cannot distinguish interactive elements from static content. |
| 96 | |
| 97 | ### What Flat Design Removes |
| 98 | |
| 99 | | Removed Cue | Affordance Lost | User Impact | |
| 100 | |-------------|----------------|-------------| |
| 101 | | Drop shadows on buttons | "This is pressable" | Users do not recognize buttons | |
| 102 | | Borders on inputs | "Type here" | Users do not know where to click to type | |
| 103 | | Underlines on links | "This navigates" | Users cannot find links in body text | |
| 104 | | Gradients and bevels | "This is interactive" | All elements look equally flat and static | |
| 105 | | Visual depth / layering | "This is above/below that" | Users lose sense of hierarchy | |
| 106 | |
| 107 | ### Recovering Affordances in Flat Design |
| 108 | |
| 109 | Use **color contrast** to distinguish interactive elements from static ones. |
| 110 | Add **hover and focus states** that reveal interactivity. |
| 111 | Use **consistent spacing** to create clickable regions. |
| 112 | Apply **subtle shadows or borders** (flat design does not mean zero visual depth). |
| 113 | Always provide **cursor changes** on interactive elements. |
| 114 | Pair **icons with labels** so meaning is not ambiguous. |
| 115 | |
| 116 | |
| 117 | |
| 118 | ## Touch vs. Mouse Affordances |
| 119 | |
| 120 | | Factor | Mouse | Touch | |
| 121 | |--------|-------|-------| |
| 122 | | **Hover state** | Available and essential | Does not exist; cannot preview interactivity | |
| 123 | | **Precision** | High (single pixel) | Low (finger covers ~44px) | |
| 124 | | **Right-click** | Common interaction | Not available natively | |
| 125 | | **Drag and drop** | Natural with mouse | Conflicts with scroll gesture | |
| 126 | | **Cursor feedback** | Changes shape to signal affordance | No cursor exists | |
| 127 | | **Target size** | Minimum ~24px | Minimum 44x44px (Apple HIG) or 48x48dp (Material) | |
| 128 | |
| 129 | ### Touch-Specific Affordance Strategies |
| 130 | |
| 131 | Make all touch targets at least 44x44 points. |
| 132 | Use visual weight (size, color, shadow) instead of hover states to signal interactivity. |
| 133 | Provide haptic feedback (vibration) on interaction to replace the tactile click of a mouse button. |
| 134 | Avoid relying on gestures as the only way to access critical actions; always provide a visible alternative. |
| 135 | Show visual hints for swipeable content (partial next-card visible, dots indicator). |
| 136 | |
| 137 | |
| 138 | |
| 139 | ## Affordance Audit Checklist |
| 140 | |
| 141 | Use this checklist to evaluate any screen or physical product. |
| 142 | |
| 143 | ### Interactive Elements |
| 144 | |
| 145 | [ ] Every button is visually distinguishable from non-interactive text and containers. |
| 146 | [ ] Every link has at least two signals (color + underline, or color + cursor change). |
| 147 | [ ] Every text input has a visible boundary (border, background contrast, or underline). |
| 148 | [ ] Every slider has a visible handle and track. |
| 149 | [ ] Every draggable element has a grip indicator. |
| 150 | [ ] All touch targets are at least 44x44 points (mobile) or 24x24 pixels (desktop). |
| 151 | |
| 152 | ### Non-Interactive Elements |
| 153 | |
| 154 | [ ] Static text does not use the same color as links. |
| 155 | [ ] Decorative images do not have clickable appearance (no pointer cursor, no hover effect). |
| 156 | [ ] Section headers are not styled like buttons. |
| 157 | [ ] Cards and containers that are not clickable do not have hover lift effects. |
| 158 | |
| 159 | ### Hidden Affordances |
| 160 | |
| 161 | [ ] Any gesture-based interaction also has a visible control alternative. |
| 162 | [ ] Keyboard shortcuts are documented in the interface (tooltip, menu, help). |
| 163 | [ ] Right-click menus duplicate functionality available through visible controls. |
| 164 | [ ] Swipeable content shows a visual hint that more content exists. |
| 165 | |
| 166 | ### False Affordances |
| 167 | |
| 168 | [ ] No underlined text that is not a link. |
| 169 | [ ] No colored text that looks like a link but is not. |
| 170 | [ ] No card shadows or hover effects on non-interactive containers. |
| 171 | [ ] No cursor: pointer on non-interactive elements. |
| 172 | |
| 173 | |
| 174 | |
| 175 | ## Before/After Examples of Affordance Improvements |
| 176 | |
| 177 | ### Example 1: Flat Submit Button |
| 178 | |
| 179 | **Before**: A gray text label "Submit" with no border, no shadow, no background color. Users do not realize it is clickable. |
| 180 | |
| 181 | **After**: A filled blue rectangle with white text "Submit", a subtle shadow, and a darkened hover state. Users immediately recognize it as a button. |
| 182 | |
| 183 | **Principle applied**: Perceived affordance aligned with real affordance through visual treatment. |
| 184 | |
| 185 | ### Example 2: Hidden Navigation |
| 186 | |
| 187 | **Before**: A three-line hamburger icon in the top corner. New users do not know it contains navigation. Engagement with secondary pages is low. |
| 188 | |
| 189 | **After**: A visible horizontal navigation bar with text labels for the top 4 sections, plus a "More" dropdown for the rest. Engagement with secondary pages increases by 50% or more. |
| 190 | |
| 191 | **Principle applied**: Hidden affordance converted to visible affordance. |
| 192 | |
| 193 | ### Example 3: Non-Obvious Text Input |
| 194 | |
| 195 | **Before**: A thin bottom-border line with a small floating label. Users click randomly around the area unsure where the input field actually is. |
| 196 | |
| 197 | **After**: A fully bordered rectangle with a label above, placeholder text inside, and a clear focus ring. Users click into the input immediately. |
| 198 | |
| 199 | **Principle applied**: Real affordance made perceivable through boundary signifiers. |
| 200 | |
| 201 | ### Example 4: Gesture-Only Delete |
| 202 | |
| 203 | **Before**: On mobile, the only way to delete a list item is to swipe left. Users who do not know the gesture cannot delete items. |
| 204 | |
| 205 | **After**: Swipe-to-delete still works, but each item also has a visible trash icon on tap or a long-press menu. All users can access the delete function. |
| 206 | |
| 207 | **Principle applied**: Hidden affordance supplemented with visible alternative. |
| 208 | |
| 209 | |
| 210 | |
| 211 | ## Common Affordance Failures by Platform |
| 212 | |
| 213 | ### Web |
| 214 | |
| 215 | | Failure | Impact | Fix | |
| 216 | |---------|--------|-----| |
| 217 | | Ghost buttons (transparent with thin border) | Low click-through rates | Use filled buttons for primary actions | |
| 218 | | Cards without hover state that are clickable | Users miss clickable content | Add hover elevation or background change | |
| 219 | | Dropdown triggers that look like labels | Users do not know to click | Add a chevron icon and border | |
| 220 | |
| 221 | ### Mobile (iOS / Android) |
| 222 | |
| 223 | | Failure | Impact | Fix | |
| 224 | |---------|--------|-----| |
| 225 | | Small touch targets | Frequent mis-taps, frustration | Minimum 44pt / 48dp targets | |
| 226 | | Swipe-only actions | Core functionality is invisible | Provide visible button alternative | |
| 227 | | Bottom sheet handle with no label | Users do not know to drag up | Add "Swipe up for details" text or an upward chevron | |
| 228 | |
| 229 | ### Desktop Applications |
| 230 | |
| 231 | | Failure | Impact | Fix | |
| 232 | |---------|--------|-----| |
| 233 | | Toolbar with icon-only buttons | Users memorize slowly, new users lost | Add text labels below icons | |
| 234 | | Resizable panels without grab edges | Users cannot resize | Show a dotted grab edge or resize cursor on hover | |
| 235 | | Menu items with no keyboard shortcut listed | Power users cannot accelerate | Show shortcut text next to every menu item | |
| 236 | |
| 237 | |
| 238 | |
| 239 | ## Accessibility and Affordances |
| 240 | |
| 241 | Affordances must work for all users, including those who use assistive technologies. |
| 242 | |
| 243 | | User Group | Affordance Consideration | |
| 244 | |-----------|------------------------| |
| 245 | | **Screen reader users** | Every interactive element must have an accessible role (button, link, input) and a descriptive label. Visual affordances are invisible; semantic affordances must replace them. | |
| 246 | | **Keyboard-only users** | Every interactive element must be focusable and operable with Enter or Space. Focus rings are the keyboard equivalent of hover states: they are affordance signifiers. | |
| 247 | | **Low-vision users** | Interactive elements need sufficient color contrast (WCAG 4.5:1 for text, 3:1 for UI components). Size thresholds increase. | |
| 248 | | **Motor-impaired users** | Touch targets must be larger (WCAG recommends 44x44 CSS pixels). Drag-and-drop must have a click-based alternative. | |
| 249 | | **Cognitive disabilities** | Affordances must be explicit, not implied. Labels are better than icons alone. Consistent placement is essential. | |
| 250 | |
| 251 | ### Accessibility Affordance Checklist |
| 252 | |
| 253 | [ ] All interactive elements have correct ARIA roles or native HTML semantics. |
| 254 | [ ] Focus order follows visual order. |
| 255 | [ ] Focus rings are visible and high-contrast. |
| 256 | [ ] Interactive elements are reachable and operable via keyboard. |
| 257 | [ ] Color is not the only affordance signal (shape, border, or icon accompanies color). |
| 258 | [ ] Touch targets meet minimum size requirements. |
| 259 | [ ] Drag interactions have non-drag alternatives. |
| 260 |
Discussion
Browse more free Claude skills.