Proposal:Mobility Access Tags
| Mobility Access Tags | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | DesktopGEO |
| Tagging: | mobility=*
|
| Applies to: | |
| Definition: | will depict direct accessability (physical - in opposition to 'access=*') of OSM features that are accessable by humans. |
| Statistics: |
|
| Draft started: | 2026-02-06 |
Problem Statement
The current `wheelchair=*` tag is widely used for mapping physical accessibility but has significant limitations:
- Too narrow in scope: Only addresses wheelchair users, ignoring people using walking aids (crutches, walkers, rollators), prosthetics, or those with other mobility impairments who don't use wheelchairs
- Ambiguous application: A place can be wheelchair-accessible but still unusable for someone who cannot stand up, or vice versa. The tag doesn't distinguish between different types of mobility requirements
- Oversimplified values: The `yes/no/limited` scheme doesn't capture the nuanced reality of accessibility. What makes something "limited"? How limited?
- Missing critical details: Doesn't specify what makes something accessible or inaccessible (steps? slope? door width? surface type?)
- Assumes one-size-fits-all: Different mobility impairments have different needs that aren't captured by a single binary tag
This proposal introduces a comprehensive `mobility:*` namespace that provides detailed, actionable accessibility information.
Proposal
This proposal introduces a new tagging namespace `mobility:*` to provide comprehensive information about physical accessibility for people with various mobility impairments. The following tags are proposed:
New tags being added:
- `mobility:wheelchair=yes/no/limited`
- `mobility:walking_aid=yes/no/limited`
- `mobility:standing=required/optional/not_required`
- `mobility:sitting=required/optional/possible/not_possible`
- `mobility:steps=<number>`
- `mobility:handrail=yes/no/left/right/both`
- `mobility:slope=<percentage or degrees>`
- `mobility:door_width=<centimeters>`
- `mobility:path_width=<centimeters>`
- `mobility:surface_quality=excellent/good/fair/poor`
- `mobility:description=<free text>`
Relationship to existing tags:
- `wheelchair=*` is not deprecated but will coexist with the new schema
- `mobility:wheelchair=*` provides the same information as `wheelchair=*` but within a more structured system
- Mappers can use both during transition period
Applicable to: All database elements (nodes, ways, areas, relations) where accessibility information is relevant.
Rationale
Why a new namespace?
Creating `mobility:*` rather than extending `wheelchair:*` provides:
- Semantic clarity: The namespace clearly indicates these tags are about mobility accessibility in general
- Future extensibility: Easy to add new mobility-related tags (e.g., `mobility:elevator`, `mobility:ramp_length`)
- Avoids overloading: Doesn't force the `wheelchair` key to mean things it wasn't originally intended for
- Better data structure: Related tags are grouped together logically
Why these specific tags?
`mobility:standing` and `mobility:sitting`: Many facilities and playground equipment require or allow specific body positions. Examples:
- A spinning circle can be used while sitting (accessible to those who cannot stand)
- A standing desk requires standing ability
- A viewing platform might offer both sitting and standing options
`mobility:walking_aid`: Someone using crutches, a walker, or a rollator has different needs than a wheelchair user:
- May navigate narrow passages more easily than wheelchairs
- May struggle with smooth but sloped surfaces
- May need handrails or rest points
`mobility:steps`, `mobility:handrail`, `mobility:slope`: These provide objective, measurable data that:
- Help users make informed decisions
- Can be used by routing algorithms
- Avoid subjective assessments like "limited"
British English preference: Following OSM convention, we use "handrail" (British) rather than "guardrail" or "railing" (American).
Tagging
Core Tags
| Tag | Values | Applies to | Description |
|---|---|---|---|
| `mobility:wheelchair` | yes/no/limited | All elements | Accessible to wheelchair users. Same meaning as legacy `wheelchair=*` |
| `mobility:walking_aid` | yes/no/limited | All elements | Accessible to people using crutches, walkers, rollators, or similar aids |
| `mobility:standing` | required/optional/not_required | Facilities, equipment | Whether standing is required to use this feature |
| `mobility:sitting` | required/optional/possible/not_possible | Facilities, equipment | Whether sitting is required, possible, or not possible |
| `mobility:steps` | number (0, 1, 2, ...) | Entrances, paths | Number of steps. Use 0 for step-free access |
| `mobility:handrail` | yes/no/left/right/both | Steps, ramps | Presence and location of handrails |
| `mobility:slope` | percentage or degrees | Ramps, paths | Gradient of slope (e.g., "5%" or "3°") |
| `mobility:door_width` | centimeters | Doors, entrances | Width of door or passage in cm |
| `mobility:path_width` | centimeters | Paths, corridors | Width of accessible path in cm |
| `mobility:surface_quality` | excellent/good/fair/poor | Paths, surfaces | Subjective assessment of surface quality for mobility devices |
| `mobility:description` | free text | All elements | Additional details about accessibility |
Value Definitions
For yes/no/limited tags:
- `yes` - Fully accessible
- `no` - Not accessible
- `limited` - Partially accessible (use `mobility:description` to explain)
For `mobility:standing`:
- `required` - Must be able to stand to use this feature
- `optional` - Can be used either standing or sitting
- `not_required` - Can be used while seated or lying down
For `mobility:sitting`:
- `required` - Must be seated to use
- `possible` - Seating is available/possible
- `optional` - Can be used seated but not required
- `not_possible` - Cannot be used while seated
Combination with Existing Tags
These tags work alongside existing accessibility tags:
- `wheelchair=*` (legacy, can coexist)
- `tactile_paving=*` (for visual impairment)
- `kerb=*` (for curb details)
- `surface=*` (surface material)
- `incline=*` (can complement `mobility:slope`)
When to Use Other Tags Instead
- For visual impairment: Use `tactile_paving=*`, `blind:description=*`
- For hearing impairment: Use `deaf:description=*`, `hearing_loop=*`
- For cognitive accessibility: Consider other namespaces in future proposals
Examples
Example 1: Playground Spinning Circle
```
Rationale: The spinning circle can be accessed and used by wheelchair users and people with walking aids. Users can operate it either standing or sitting, making it accessible to people who cannot stand. There are no steps to access it.
Example 2: Restaurant with Limited Access
``` amenity=restaurant name=Café Beispiel mobility:wheelchair=limited mobility:walking_aid=yes mobility:steps=2 mobility:handrail=no mobility:door_width=80 mobility:description=Two steps at entrance, no ramp available. Interior is level once inside. ```
Rationale: The restaurant has steps making it inaccessible to wheelchairs but potentially manageable for people with walking aids. The specific details (2 steps, no handrail, door width) help users make informed decisions.
Example 3: Accessible Viewing Platform
``` tourism=viewpoint name=Panorama Terrace mobility:wheelchair=yes mobility:walking_aid=yes mobility:standing=optional mobility:sitting=possible mobility:steps=0 mobility:handrail=both mobility:slope=3% mobility:path_width=150 ```
Rationale: Fully accessible platform with gentle slope, wide path, handrails on both sides. Both standing and sitting viewing are possible (benches available).
Example 4: Standing-Only Facility
```
amenity=vending_machine
mobility:wheelchair=limited
mobility:standing=required
mobility:description=Controls are at 140cm height, requires reaching and standing
```
Rationale: Some facilities require standing ability even if wheelchair-accessible in terms of approach.
Impact on Data Consumers
Existing Data Consumers
Minimal breaking changes:
- Data consumers using `wheelchair=*` will continue to work unchanged
- `mobility:wheelchair=*` can be mapped 1:1 to legacy `wheelchair=*` for backwards compatibility
- Transition period allows gradual adoption
Benefits for Data Consumers
Routing applications:
- Can provide more nuanced routing based on specific mobility needs
- Can calculate routes for walker/rollator users differently than wheelchair users
- Can warn about steps, steep slopes, or narrow passages
Accessibility apps (e.g., Wheelmap.org):
- Can display more detailed information
- Can filter by specific mobility requirements
- Can show objective measurements (steps, width, slope)
Map renderers:
- Could show different symbols for different accessibility levels
- Could highlight step-free routes
- Could indicate facilities with seating options
Migration Strategy
**Phase 1 (Current):** Proposal and discussion
**Phase 2:** Mappers begin adding `mobility:*` tags alongside existing `wheelchair=*`
**Phase 3:** Tools and applications add support for new tags
**Phase 4:** Gradual transition as new tags prove valuable
**Long-term:** `wheelchair=*` remains valid but `mobility:*` provides richer data
Features/Pages affected
If approved, the following wiki pages would need updates:
- Key:wheelchair - Add note about `mobility:wheelchair` as enhanced alternative
- Key:playground - Add examples using mobility tags
- Accessibility - Major update to include new tagging scheme
- Map Features - Add mobility namespace
- New pages to create:
External discussions
- Tagging mailing list: [Link to be added after posting]
- Community forum: [Link to be added after posting]
- Related proposals:
- Proposed features/wheelchair (original wheelchair proposal if it exists)
- Other accessibility-related proposals
Comments
Please comment on the discussion page.