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 AmenityFeature concept, as a best practice, for associating places with their amenity features, or rather combine the types below with Place and nest them using hasPart/isPartOf and/or geo* 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 `HowTo`s 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

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 CreativeWork and 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

schemaorg / suggestions-questions-brainstorming

Add vocabulary to describe complex physical accessibility #39