Describe physical accessibility analog to `CreativeWork`?

[opyh]

This is a sub-issue of schemaorg/schemaorg#254.

Should there be a structure to analog to describing the accessibility of CreativeWork? What's your opinion about extending Thing with accessMode, accessModeSufficient, accessibilityAPI, accessibilityControl, accessibilityFeature, accessibilityHazard, accessibilitySummary and allow these properties to refer to a mixed list of Things and defined terms?

Many physical features can simply be described in terms of their (non-)existence, analog to 'flashingHazard' as a value for accessibilityHazard for CreativeWork. If physical accessibility would be described in features, hazards, and controls, we could havedefined terms like on CreativeWork so you can simply use them like other features of a place (e.g. a sauna of a hotel) for discovery, filtering search results, and showing features next to a list items as icons. Additionally, accessibilityControl, accessibilityHazard, and accessibilityFeature could include anything else as Thing reference to reference to more complex features/hazards/controls.

Having these attributes would allow to describe more complex accessibility information for physical things in an understandable way that is open to associations with other data. This proposal would include a shared term vocabulary for the most basic use case of discovery and search result filtering using terms like "fullWheelchairAccessibility", "audioDescription" or "signLanguage", and still it would support more complex future extensions like AnimalPolicy, Elevator, extensions of Room, … for more complex cases.

After this extension, amenityFeature/LocationFeatureSpecification would inherit e.g. accessibilityFeature, which would allow to specify location features in all their complexity.

Simple case: defined terms to describe single available features

This would work analog to media accessibility terms described in WebSchemas, but for physical features/controls/hazards.

Examples for simple-to-describe physical amenity features that seem to be easier to agree upon in my experience and could be defined as terms listed in accessibilityFeature:

• "fullWheelchairAccess": full wheelchair accessibility of a place (= the entrance is wheelchair accessible, all key amenities/features/services are accessible by a wheelchair user).
• "brailleNavigation": The resource provides physical braille navigation in locally spoken languages.
• "tactileGuideStrips": One or more tactile markers exist as guide(s), implying textures detectable with the touch of a foot or sweep of a cane, helping blind (& sighted) people orient themselves.
• "tactileNorthMarker": The resource provides a tactile marker that helps blind (& sighted) people orient themselves.

I'm working with Sozialhelden e.V., an NGO with a focus on physical accessibility, I'm sure we can come up with a more comprehensive list of attributes together with the target groups we work with. In a UI, the terms above could match a list of checkboxes for resource discovery, e.g. to find an accessible Hotel or Event.

What's not part of this: Describing complex accessibility resources

Examples for physical accessibilityFeature that would need more complex schema.org types:

• a wheelchair accessible bathroom (local standards of accessible bathroom equipment vary widely)
• a sitemap PDF (which, for example, shows the entrances and wheelchair-accessible ways)
• a wheelchair-accessible hotel Bed in a specified size
• audio description over an induction loop or as a service that provides headphones to visitors - it's important to note how the audio description is provided.
• sign language media/description in locally spoken sign language(s). It's not obvious how to note content different sign languages, maybe as CreativeWork or as Service type?

A more complex case for a physical a11y hazard:

• an entrance for a park that is a turnstile, coming with a text description for an alternative way to enter the park with a wheelchair

A more complex case for a physical a11y control:

• A reference to an IoT switch (e.g. a reference using an external IoT vocabulary) that is a doorbell for a door, used to call for wheelchair mobility assistance

What do you think?

[opyh]

Here is an example of the amenity features that Deutsches Seminar für Tourismus (DSFT), a central German tourism association, lists on their barrier free travel search:

The listed terms can be used to filter tourism-related places in an end-user facing search. The modeling could be semantically improved, but hopefully shows what I aim trying to solve with this issue.

[RichardWallis]

See issue #7 for the context of the move from the main Schema.org issue tracker to this repository.

[westurner]

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