schemaorg
Add vocabulary to describe complex physical accessibility
Part of schemaorg/schemaorg#254. Related to schemaorg/schemaorg#2439 and schemaorg/schemaorg#2438.
We need a set of types to describe physical / civic / architectural features of places that facilitate mobility in general, e.g. stairways, travelators, escalator, elevators, doors connecting Places and Rooms, and a separate concept of entrances/exits (an entrance/exit is not necessarily a door, but can be an escalator, for example). Data formats that contain data like this exist - you can find physical a11y datasets on OpenStreetMap, Wheelmap, accessibility.cloud, and in GTFS pathways data sources, for example.
While schemaorg/schemaorg#2438 explains an idea to describe the simple existence/non-existence of defined general accessibility features, hazards, or controls, the types described below can provide information about more complex aspects of accessibility.
Below is our rough idea how an extension for accessibility could look like, extracted from our experiences with collecting physical accessibility attributes in A11yJSON.
This proposal does not aim to provide a complete vocabulary for routing and navigation.
Questions:
- What do you think about the idea to separate the concept of entrance/exit and the physical thing that IS the entrance using multi-type entities? How would we deal with entrances that consist of multiple
Things (for example: two doors and two escalators), as a best practice? - Are there still properties in this proposal that would better be defined as defined terms, like described in schemaorg/schemaorg#2438? For
AnimalPolicy(described below) it seemed the structure was easier to understand than inventing defined terms. - Should we use the
AmenityFeatureconcept, as a best practice, for associating places with their amenity features, or rather combine the types below withPlaceand nest them usinghasPart/isPartOfand/orgeo*properties? - Should this proposal be split further into multiple GitHub issues? Should we create a separate repository + external vocabulary for this proposal or simply make PRs to pending, then go on and discuss from there?
- Is the inheritance structure chosen well, or do you have ideas for better choices?
Ideas for proposed changes
Place
| Attribute | Type | Description |
|---|---|---|
| hasEntrance | EntranceOrExit | Describes the entrance(s) and exit(s) from/to this place. |
| hasGroundSurface | GroundSurface | Describes the ground surface at this place. This is relevant for vehicle mobility and accessibility for people with mobility impairments. |
| hasVisitorAnimalPolicy | AnimalPolicy | Describes how the operators of this place deal with visitors accompanied by animals. This is relevant for people who need an assistance animal (e.g. a guide dog), or travel with a pet. |
| turningSpaceInside | QuantitativeValue | Describes how wide is the space inside that is usable for turning. If given, the value SHOULD have a minValue property. This is relevant for wheelchair accessibility, especially for users of electric wheelchairs. |
Service
| Attribute | Type | Description |
|---|---|---|
| hasUserAnimalPolicy | AnimalPolicy | Describes how the operators of this service deal with users of the service accompanied by animals. This is relevant for people who need an assistance animal (e.g. a guide dog), or travel with a pet. |
Organization
| Attribute | Type | Description |
|---|---|---|
| hasEmployeeAnimalPolicy | AnimalPolicy | Describes how this organization deals with employees accompanied by animals. This is relevant for people who need an assistance animal (e.g. a guide dog), and work at the organization. |
Vehicle
| Attribute | Type | Description |
|---|---|---|
| mobilityService | MobilityService | Contains accessibility service information for using the vehicle. |
| operationalStatus | OperationalStatus | Describes current usability of the vehicle. Can be used for real-time status updates. |
Ideas for proposed new types
Thing > Intangible > AnimalPolicy
Provides information about how the operators of an Organization, Place or Service deal with people accompanied by animals. This is relevant for people who need an assistance animal (e.g. a guide dog), or travel with a pet.
| Attribute | Type | Description |
|---|---|---|
| allowsAnyAnimals | Boolean | True if the place allows bringing any kind of animal, False if not. |
| allowsAnyDogs | Boolean | True if the place allows visitors to bring dogs in general, False if bringing them is explicitly prohibited (with exception of assistance dogs, if allowsAssistanceDogs is True). |
| allowsAssistanceDogs | Boolean | True if the place allows visitors to bring assistance/guide dogs, False if bringing them is explicitly prohibited. |
| dogsNeedMuzzle | Boolean | True if the place denies entry to visitors bringing a dogs without muzzles, False if dogs without muzzles are explicitly allowed. |
| suppliesWaterForPets | Boolean | True if the place supplies water for accompanying animals, False if explicitly not. |
Thing > Intangible > Service > MobilityService
An aggregation of references to services that are usually associated with mobility in public transport. This is relevant as accessibility information for travellers.
| Attribute | Type | Description |
|---|---|---|
| serviceOperator | Organization | The operating organization, if different from the provider. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor. |
| assistanceOperator | Organization or ContactPoint | Operator of the assistance service for this facility. Helpful for people with impaired mobility. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor. |
| facilityManagementOperator | Organization or ContactPoint | Operator to be contacted to report service outages and other problems with this facility. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor. |
| emergencyOperator | Organization or ContactPoint | Operator to be contacted in case of an emergency. This enables the representation of services that are provided by an organization, but operated by another organization like a subcontractor. |
Thing > Intangible > OperationalStatus
Describes the current operational status of a Thing.
| Attribute | Type | Description |
|---|---|---|
| facility | Thing | Reference to the facility that has the status described by this resource. |
| isWorking | Boolean | Allows live status update. True if the equipment is currently usable, False if it's out of service. |
| timestamp | Date | Describes when the live status of this equipment was last determined. Important to determine if a status information is outdated. |
| sources | URL | Reference to sources for this status information. |
| alternatives | HowTo | One or more HowTos that describe alternative ways a user can take when they can’t use the facility (for excample because it is out of order). |
| outOfOrderReason | Text | If the equipment is out of order, this contains a description that can provide more information about causes of and workarounds for the current outage (e.g. "in maintenance until December 20, 2025. Please use the east entrance instead.) |
| currentVerticalDirection | verticalDirection | Current vertical direction ("up" or "down"). Can be used to provide real-time updates, e.g. for Elevator or Escalator. |
Thing > GroundSurface
Describes the quality of a physical ground surface. Use this to describe road or sidewalk conditions, or to provide indoor accessibility information for people with mobility impairments.
| Attribute | Type | Description |
|---|---|---|
| isEven | Boolean | True if the surface is even and not plastered, False if not even or plastered. |
| isLevel | Boolean | True if the described object can be used step-free and the ground/floor is level, False if not (e.g. if users have to take a step to use the main functionality). Can be True even if the ground/floor is not perfectly even but plastered, for example - for this case, you can provide a surface property instead. |
| surface | Text | Rating of surface/sidewalk conditions. Use strings from https://wiki.openstreetmap.org/wiki/Key:surface as values, for example. |
| slopeAngle | QuantitativeValue | Angle of the slope that this ground surface has, if applicable. |
Thing > Product > Door
Describes a physical door, typically used as entrance or exit to a room or building. You can combine this as multi-type entity with Place (for adding geospatial information).
| Attribute | Type | Description |
|---|---|---|
| isAutomaticOrAlwaysOpen | Boolean | True if the door is always open or fully automatic, False if it has to be opened or closed manually. |
| isAutomaticallyClosing | Boolean | True if the door closes automatically, False if it has to be closed manually. |
| isRevolving | Boolean | True if the door is a revolving door, False if not. |
| isTurnstile | Boolean | True if the door is a turnstile, False if not. |
| isTransparent | Boolean | True if the door is made of transparent material, False if not. Relevant for people with visual impairments. |
| openingForce | QuantitativeValue | Force needed to open the door completely, given in lbs. This is relevant for accessibility - Interior doors should require no more than 5 lbs. of force to open. |
| closingSpeed | QuantitativeValue | Speed taken for the door from its full open position to the degree where the latch phase begins. Given in degrees (for doors with a rotational axis) or distance (for linear doors) per time. |
| latchingSpeed | QuantitativeValue | Speed taken for the door to close and latch shut over the last degrees of its closing phase. Given in degrees (for doors with a rotational axis) or distance (for linear doors) per time. |
| turningSpaceRadius | QuantitativeValue | Turning space available for using this door. Relevant for wheelchair and rollator accessibility. If this attribute is given, it should at least have a minValue property. |
| needsAccessKeyOrCard | Text | Standardized key needed to access this place, e.g. "radarAccessKey" for a RADAR key, or "euroAccessKey" for a Euro key. |
| operationalStatus | OperationalStatus | Describes current usability of the door. Can be used for real-time status updates. |
Place > EntranceOrExit
Describes a physical entrance to a place. If a Thing is used as an entrance or exit, this type can be combined as multi-type entity with other types like Door, Elevator, Escalator, or Ramp.
An Entrance SHOULD have a name property with the name of the entrance if there are multiple entrances to the same place. If one or more physical sign(s) exist for the entrance, the value of name SHOULD correspond to what is readable on the sign(s).
| Attribute | Type | Description |
|---|---|---|
| isMainEntranceOrExit | Boolean | True if this is the designated main entrance/exit for the associated place, False if not. |
| isEntrance | Boolean | True if this resource can be used by visitors to enter the Place it is contained in, False if not. |
| isExit | Boolean | True if this resource can be used by visitors to exit the Place it is contained in, False if not. |
| origin | Place or Thing | The Place or Thing from which this EntranceOrExit leads to somewhere else. Use together with the isUnidirectional property. |
| destination | Place or Thing | The Place or Thing to which this EntranceOrExit leads. Use together with the isUnidirectional property. |
| walkingDistanceToDroppedCurb | QuantitativeValue | Specifies the distance between the resource and the next dropped physical curb if the place is reachable from a street. This is relevant for people using mobility aids like wheelchairs. |
| isUnidirectional | Boolean | True if users can only traverse this resource in one direction, False if it can by explicitly used bidirectionally. If set to True, the order of origin and destination describes the allowed traversal direction. |
| groundSurface | GroundSurface | Describes the ground surface traversed when using this entrance or exit. If different surfaces exist, this should describe the worst one for accessibility. |
| operationalStatus | OperationalStatus | Describes current usability of the entrance/exit. Can be used for real-time status updates. |
Thing > Product > Handrails
Describes one single physical handle bar, a pair of handle bars, or support handrails, typically provided as a standing or walking aid needed while using a physical facility (e.g. a corridor, or a toilet).
| Attribute | Type | Description |
|---|---|---|
| distanceBetweenHandles | QuantitativeValue | Indicates how far the handles are apart, which can be relevant for handlebars next to toilets. |
| isOnUsersLeftSide | Boolean | True if there is a folding handle on left side(from the perspective of somebody using the toilet), false if not, undefined if condition is unknown. |
| isOnUsersRightSide | Boolean | true if there is a folding handle on right side(from the perspective of somebody using the toilet), false if not, undefined if condition is unknown. |
| heightFromFloor | QuantitativeValue | Indicates the handle bars’ height at the position where they are meant to be held, measured as distance from the floor. |
| direction | handRailsDirection | "horizontal", "vertical", "diagonal" |
Thing > Product > Vehicle > Ramp
Describes a static or mobile ramp with a slope/incline. Use this to provide information for people with mobility impairments.
| Attribute | Type | Description |
|---|---|---|
| isMobile | Boolean | True if the ramp is removable or mobile, False if it is fixed. Many places have smaller steps at the entrance, but provide a mobile ramp to compensate this when asked. This ramp is usually installed when a visitor calls for assistance in advance, uses a designated doorbell, or when they are seen from the inside. |
| incline | QuantitativeValue | Grade as calculated by rise / run or the tangent of the angle of inclination (e.g. "20%"), or given as angle of the inclination (e.g. "11.3 degrees"). See Wikipedia for a definition. |
| connectedFloorLevels | Text | The connected floor levels in a multi-storey building, as list, if applicable. Since counting systems vary internationally, the local system should be used where possible. |
| operationalStatus | OperationalStatus | Describes current usability of the ramp. Can be used for real-time status updates. |
Thing > Product > Vehicle > Stairs
Describes physical stairs. Use this to provide information for people with mobility impairments.
| Attribute | Type | Description |
|---|---|---|
| stepHeight | QuantitativeValue | Indicates how high the steps if these stairs are (can be a range). |
| hasAntiSlipNosing | Boolean | True if all relevant steps are coated with anti-slip material, False if not. |
| hasHighContrastNosing | Boolean | True if all relevant steps have a visually recognizable high contrast nosing, False if not. |
| connectedFloorLevels | Text | The connected floor levels in a multi-storey building, as list, if applicable. Since counting systems vary internationally, the local system should be used where possible. |
| operationalStatus | OperationalStatus | Describes current usability of the stairs. Can be used for real-time status updates. |
| incline | QuantitativeValue | Grade as calculated by rise / run or the tangent of the angle of inclination (e.g. "20%"), or given as angle of the inclination (e.g. "11.3 degrees"). See Wikipedia for a definition. |
Thing > Product > Vehicle > Elevator
Describes a physical elevator that transports people or goods vertically. If properties of the supertypeVehicle are used, they should describe the elevator’s cabin, moving platform, or sling. If a cabin or platform is part of the elevator, it's width and depth properties should be included for accessibility.
| Attribute | Type | Description |
|---|---|---|
| doors | Door | List containing descriptions of the elevator’s door(s). |
| hasDoorsInOppositeDirections | Boolean | True if the equipment has doors in opposite directions. Relevant for people using a wheelchair, rollator, cargo bike or pushchair to know if they have to turn. |
| connectedFloorLevels | Text | The connected floor levels in a multi-storey building, as list, if applicable. Since counting systems vary internationally, the local system should be used where possible. |
| operationalStatus | OperationalStatus | Describes current usability of the facility. Can be used for real-time status updates. |
| alternativeWays | Thing | If there are alternative routes to this elevator, they can be linked using this property. |
Thing > Product > Vehicle > Escalator
An escalator is a moving staircase which carries people between floors of a building. It consists of a motor-driven chain of individually linked steps on a track which cycle on a pair of tracks which keep them horizontal (Wikipedia).
| Attribute | Type | Description |
|---|---|---|
| connectedFloorLevels | Text | The connected floor levels in a multi-storey building, as list, if applicable. Since counting systems vary internationally, the local system should be used where possible. |
| steps | Stairs | Describes the escalator’s staircase. Relevant for passengers if an escalator is out of service, and there is no alternative route. |
| handrails | Handrails | Provides information about the escalator’s handrails. |
| operationalStatus | OperationalStatus | Describes current usability of the escalator. Can be used for real-time status updates. |
Thing > Product > Vehicle > Escalator > Stairlift
A stair lift is a mechanical device for lifting people up and down stairs. For sufficiently wide stairs, a rail is mounted to the treads of the stairs. A chair or lifting platform is attached to the rail. A person gets onto the chair or platform and is lifted up or down the stairs by the chair which moves along the rail.
Stair lifts are known variously as stair lifts, stair-lifts, chair lifts, stair gliders and by other names. This type of chair lift should not be confused with the chairlift used by skiers. The term stair climber can refer either to stair lifts, or more commonly to the exercise equipment by the same name. (Wikipedia).
New identifiers
- Thing > Property > identifier > accessKey
- Thing > Property > identifier > accessKey > radarAccessKey
- Thing > Property > identifier > accessKey > euroAccessKey
- Thing > Property > identifier > handRailsDirection
- Thing > Property > identifier > handRailsDirection > horizontal
- Thing > Property > identifier > handRailsDirection > vertical
- Thing > Property > identifier > handRailsDirection > diagonal
- Thing > Property > identifier > verticalDirection > up
- Thing > Property > identifier > verticalDirection > down
Thank you for all this! You've clearly put a lot of work into these investigations, so we should talk about how best to progress things from here. Schema.org in general is wary of adding large vocabularies that are not accompanied by plans to consume/read/extract and use the corresponding data. We have messed up on this previously (eg see https://health-lifesci.schema.org/) and are wary of repeating that experience. Are there any tools, projects or services who could engage with this physical accessibility vocabulary work and commit to using it in some user-facing product? Without something like that to guide us it will be hard to pick an appropriate level of detail...
Thanks for this information! I've been working for several years on physical a11y data (consuming and producing) and I think I understand exactly what you mean :) This proposal would not make sense without others that want to adopt it.
I've added a missing stakeholder group to my comment in schemaorg/schemaorg#254, text copied here:
Professional accessibility assessors: From our experience, it seems like every municipality creates its own data standard and software for assessing the accessibility of its venues, often in great detail. Even from bigger projects that assess accessibility details, we get report data for Wheelmap.org and accessibility.cloud in in very heterogeneous formats, often as a PDF with copy & pasted text fragments. The detail level can go as far down as to the material of the carpets and how often they are vacuumed (this is actually a real-life example we found in hotel accessibility certification surveys). This is valuable information, but it is not usable if it only exist as a text fragment. There was an argument made against a detailed schema.org accessibility in the mailing list, but that was back in 2015 and we have gotten quite a bit further with the issue in the meantime :) For assessors such as those mentioned and to be able to make use of their data globally, we need a high level of detail in the standard. This does not mean we can't have a simple defined term list; having a structure analog to
CreativeWorkand a structure with detailed types are not mutually exclusive, but can in fact complement each other.
I hope this sheds some light on why simple defined term lists as described in https://github.com/schemaorg/schemaorg/issues/2438 are not enough.
From an end user's perspective, this is a real world issue: For example, it's almost impossible to book an accessible hotel online because accessibility is not described in detail but in very general terms. This means it's not clear if a "wheelchair accessible hotel" actually has a room that fits the specific needs of a guest. Even if a room is marked as accessible, this doesn't guarantee (for example) that there is enough space for turning a wheelchair next to the bed. In reality, a person booking an accessible hotel has to call each potential hotel to find out if it can really accommodate their needs, or to consult a certification provider. We want to change this. A11y should be a built-in feature of mainstream products, and not create a separate world for people with disabilities. Numerous examples exist in other areas that affect people with disabilities, for instance in public transportation and in e-commerce.
I acknowledge that in some regards we're in a chicken-and-egg situation here – if there is no standard, the accessibility problem won't be fixed in the real world, and if it isn't fixed in the real world yet, it is difficult to standardize a solution. The issues described above might take a decade to fix, but having them be part of a global standard, even if it's not yet perfect, is a big step towards that fix.
We (Sozialhelden e.V. / Wheelmap.org / accessibility.cloud) are committed to using the new vocabulary as consumers and as data producers, and to promoting the standard in our communications with the tourism industry, location-based/maps/navigation services, public transport providers, and media outlets. Our plan is to replace A11yJSON with a web community-based linked data standard. Wheelmap already asks end users to survey data in the detail level described in this proposed idea, but is based on A11yJSON. Professional a11y assessors have much greater detail in their surveys, but as described above, the missing global standard makes their data non-exchangable. We would also like to add schema.org descriptions to each place on Wheelmap.org. Because our data often contains unique URLs of the places, embedding schema.org would provide augmented accessibility information that would go beyond what venues provide themselves.
Parties that are probably interested in standardizing physical a11y and its certification - some of whom are contributors to accessibility.cloud - are:
- Deutsches Seminar für Tourismus (DSFT), involved with schema.org via the STI tourism ontology, also (https://www.reisen-fuer-alle.de/zertifizierte_angebote_249.html)
- HERE Maps, FourSquare, several public transport networks (Deutsche Bahn, VBB)
- Open data platforms of municipalities such as the city of Berlin (e.g. for public toilets and other civic infrastructure datasets)
Other user facing products where we see potential value:
- Tourism booking platforms like Booking, restaurant guide apps such as Yelp
- PoI data providers like FourSquare
- City marketing webpages such as VisitBerlin
- Commercial map/navigation apps like Google Maps (which uses GTFS and GTFS pathways for accessible routing), Apple Maps, Citymapper, Transit, komoot, and OSM-based apps like business directories in general
- Local public transport apps that want to display merged a11y information about stations, vehicles, static mobility facilities from various transportation networks (the proposal can be used to augment LinkedGTFS or LinkedGeoData with a11y, for example)
- Non-profits like Wheelmap (DE), AXSMap (US), ginto.guide (CH), Jaccede (FR)
For almost every one of the proposed types and attributes we have a real-world use case as well as at least one user-facing consumer and one potential producer in our network or on accessibility.cloud. The plan is that Wheelmap.org will show all the properties proposed above. Accessibility.cloud, the world's largest open a11y dataset, which has 60 open data sources with ~1,3m places with a11y, and ~3300 elevators from multiple public transport providers, will migrate it’s data to a global standard, when it is available. We are in this for the long haul - wheelmap.org has already been around for 10 years, which in internet time is something ;)
What do you think about these next steps? I'm totally open for different suggestions :)
- deploy an instance of an ontology manager tool (e.g. https://github.com/zazuko/ontology-manager, does this make sense?) with a separate GitHub repo (or is there a tool to contribute directly to pending? should we even do this?)
- split the idea into smaller sub-domains to raise the chances that other organizations get involved and commit to adopting the vocabulary
- write a motivation text for each attribute, example data for the use cases here and here, and a best practices documentation
What are the next steps here? To create a PR:
https://github.com/schemaorg/schemaorg/tree/main/data/ext/pending
- add .ttl and examples.txt
