# 1.1 Address Accessibility
Blockchain addresses must be presented in accessible formats.
## Success Criteria
### 1.1.1 Address Text Alternatives (Level A)
**Requirement**: All blockchain addresses have text alternatives that convey the same information in an accessible format. This includes ENS names, address book labels, or properly formatted truncations with the full address available.
**Intent**: 42-character hexadecimal addresses are effectively unreadable by screen reader users and create significant barriers for users with cognitive disabilities. Text alternatives provide meaningful identification.
**Benefits**:
- **Blind users**: Can understand which address is being referenced without hearing 40+ characters
- **Cognitive disabilities**: Can recognize addresses by memorable names
- **Motor impairments**: Reduces copying errors when verifying addresses
**Techniques**:
- Display ENS names when available with address as secondary info
- Allow users to label addresses in an address book
- Format truncated addresses consistently (e.g., `0x742d...595f`)
- Provide full address on hover/focus for verification
**Failures**:
- Displaying only the raw hex address with no alternative
- Screen reader announces each character individually
- No way to verify the full address behind a truncation
---
### 1.1.2 Address Checksum Communication (Level A)
**Requirement**: Address validation state (checksum pass/fail) is communicated through accessible means, not just visual indicators like color.
**Intent**: EIP-55 checksums use mixed-case to encode validation. This is invisible to screen readers and inaccessible to colorblind users if indicated only by color.
**Benefits**:
- **Blind users**: Know if an address is valid before sending funds
- **Colorblind users**: Don't rely on red/green validation indicators
**Techniques**:
- Use `aria-invalid="true"` for invalid addresses
- Provide text status: "Valid address" / "Invalid checksum"
- Use icons with accessible labels alongside color
**Failures**:
- Only using color to show valid (green) vs invalid (red)
- No programmatic indication of validation state
- Checksum errors only shown visually
---
### 1.1.3 Screen Reader Address Formatting (Level AA)
**Requirement**: Addresses can be announced by screen readers in digestible chunks (e.g., groups of 4 characters) rather than as a single 42-character string.
**Intent**: Hearing "zero x seven four two d three five..." for 40 characters is cognitively impossible to process. Chunked announcement enables verification.
**Benefits**:
- **Blind users**: Can actually verify addresses character by character
- **Cognitive disabilities**: Smaller chunks are easier to compare
**Techniques**:
```tsx
// Format for aria-label
const formatForSR = (addr: string) => {
const chunks = addr.slice(2).match(/.{1,4}/g);
return `0x ${chunks?.join(' ')}`;
};
// "0x 742d 35Cc 6634 C053 2925 a3b8 44Bc 9e75 95f"
```
**Failures**:
- Address announced as continuous string
- No way to pause or repeat sections
- Chunks are too long (8+ characters)
---
### 1.1.4 Preferred Address Format (Level AAA)
**Requirement**: Users can set their preferred address display format (full, truncated, ENS-only, chunked) in application settings.
**Intent**: Different users have different needs. Power users may want full addresses; others prefer ENS names only.
**Techniques**:
- User preference stored in local settings
- Format persists across sessions
- Preview of format in settings
---
## Related Success Criteria
- [1.2.1 Transaction Type Labeling](./1.2-transaction-clarity.md)
- [3.3.1 Address Validation](../understandable/3.3-error-prevention.md)
