Sensory Processing Sensitivity accommodations have become an important part of an ever-increasingly inclusive world. Many retailers, businesses, and offices have started to implement “sensory friendly” hours to cater to the needs of these individuals, such as Walmart’s Sensory-Friendly Hours. People who have autism and similar conditions can have Sensory Issues that would benefit greatly by shops, cafes, and other destinations having clear sensory level information and when (where applicable) sensory-friendly hours exist.
Previously, “Key:sensory” had been proposed (and approved) for use in playground contexts surrounding items that produce a sensory reaction such as visual, tactile, audible, and smell. Usage of this tag is minimal however the utility of it should be retained. Similarly, the “Proposal:Quiet hours” had some great groundwork for the sensory friendly hours aspect but did not include sensory level information, source, or other relevant information that those who have sensory processing sensitivity may find useful.
Sensory was chosen over quiet or other options due to the scientific research in this area using the term sensory, despite many retailers using the term “Quiet Hours” and to also include visual stimuli.
Link to Proposal. Please discuss this proposal on its Wiki Talk page.
This looks like it could also be useful for describing some places of worship that offer “sensory-friendly” religious services in addition to their normal services.
Good thought, perhaps adding subtags for smell or scent would be beneficial in that regard, for example some services which uses incense in some services.
That might be difficult to tag predictably. In my experience, it would depend on the denomination but also a liturgical calendar that often can’t be expressed in OSM’s opening_hours syntax.
Rather, sensory:friendly_hours=yes had me thinking that sensory:friendly_times=yes might be appropriate when, for example, a diocese designates one of its churches to offer sensory-friendly services twice a month, by analogy with service_times=*, which accepts a point in time rather than a time window.
Also good thought. Kinda goes to sensory=* vs :sensory=. For instance, originally for sensory:friendly_hours=* I thought to use opening_hours:sensory=* but sensory as the main key opens the door to other accessibility tags and also distinguishes between sensory friendly hours and a time solely for sensory sensitive groups, similar to the utility of service_times or collection_times.
I like the idea of adding liturgy=* as a tag, may be my next proposal.
sensory= : First of all, sensory=yes has no meaning. What would be the reason for it to replace that voted in playground= ? sensory:*=yes provides no further info than sensory=* to justify.
Examples: They are almost all defaults that shouldn’t be added. It’s known usually a =library is =quiet , =cinema is =dim but has =flash , and =casino or =amusement_arcade has sensory:visual=yes (what’s the ambience here anyway?). playground=musical_instrument should already imply sensory=audible now.
=dim , =quiet , =normal , =loud , =bright , etc: all very subjective and low verifiability in other situations. At least it needs to be relatable, eg discomfort, can’t stare or listen to prolonged time, able to talk to others softly.
=protection : Is counterintuitive. It doesn’t mean the sense is protected, but that hearing protection is needed. Personal protective equipment requirements should be a general topic that doesn’t fall into this aspect.
sensory:friendly_hours: As I have commented on quiet_hours= before, inventing a *_hours= / *_times= for every purpose is not scalable. It should be attempted to fit into existing methods first, eg service_times:sensory_sensitivity= . Indeed, sensory_sensitivity= may better for showing whether a feature has been designed for them. similar to wheelchair= for physical accessibility. Eg sensory_sensitivity:conditional=designated @ (Mo-Fr 08:00-10:00) , and sensory_sensitivty=designated on “quiet room” / “calm space” (=shelter ?).
sensory:friendly_hours:source= : As much as I personally prefer *:source= as found in OHM, source:*= is used in OSM. Furthermore, what you want is *:signed= , as source= is freeform text. For the other options, adding *:url= as in opening_hours:url= is more straightforward and useful.
Hi there! Thanks so much for commenting on my first ever proposal! I’d be happy to expand on my rationale in the proposal. sensory=* is my way of saying “hey, there may be unspecified sensory elements in this environment!” This is useful for when there may not be further details (like a quick edit) or may be useful for querying, say, all places in an area that have sensory considerations. However, I am happy to oblige to the community standard if this parent tag is frowned upon.
So far as the details and their implicit characteristics, while many may instinctively know what a casino is and what it is like (for example,) someone who needs these accessibility cues may not. To them, it is far easier to see somewhere is friendly / not friendly to their limitation than to debate if a particular location would be suitable for their ability. Consider also outside the accessibility space where a world traveler may encounter an unfamiliar name or description and would benefit knowing the environment before committing to go somewhere.
Visual accessibility is a wide ranging set and while we may never tag perfectly for all accommodations, many would be served by the options presented such as dim, quiet, etc. versus a more detailed attribute like lux or subjective like comfort. These types of descriptions are useful for those needing accommodations as they can easily parse the information given, but I am certainly open to improving upon the wording if someone knows of better-accepted accessibility language. Open to suggestions on improving protection however it seems like the intent came across successfully.
The reason behind sensory:friendly_hours is to clarify to the user that these times are not exclusive to sensory sensitive groups but are a time where sensory friendly activities may be happening. A non-sensory sensitive person may also benefit from this information, for example when shopping for a TV one may want to see moving pictures on the screen versus static images largely shown in sensory friendly hours for visual. Having designated or a subtag risks sensory sensitive people thinking these hours are the only times they can be there. Many sensory sensitive people are able to go into a shop anytime even if they prefer a sensory friendly time, and having the information for what sensory levels are there may help determine when and where they go. Sensory friendly is not a subset of the building or a designation of customers allowed, but rather a notice of when certain activities may be happening.
I will look at the convention for the source, the main goal is that contributors can verify the hours on OSM, so if there is already an accepted way to do this, I am all for editing the proposal to match!
Thanks again for commenting on my first proposal! I’m very pleased to see such a robust community and thoughtful responses here!
You can propose for such features to have a default. They don’t need to be tagged explicitly. =designated doesn’t mean exclusive or mandatory. It’s specifically designed, or official and preferred. It could be =yes at other times, meaning it’s acceptable.
Similarly, the implication of wheelchair= is not only literal, or for mobility impairment. It’s still useful for carrying heavy baggage, pushing strollers or carts, and perhaps pushing a bike up when there’s no dedicated ramp:bicycle= there. It’s the highest standard to target.
Link to Proposal. Please discuss this proposal on its Wiki Talk page.
some shops also emit scents through the ventilation system, the idea is influencing buyers through subtle scents they don’t notice or perceive as positive
There is a need for this information, and it is present on many websites for points of interest such as museums. So finding that information and adding to OpenStreetMap would be very valuable.
To say sensory=yes has no meaning is incorrect. Some places have specific exhibits, spectator rooms, etc., for neurodivergent visitors.
So, for a place to have a sensory=yes tag, it means a facility/POI, etc., offers space/services/experiences tailored to neurodivergent visitors and those with accessibility needs.
sensory:friendly_hours=* is a useful tag and there are some good examples of where that would apply, the formatting should be similar to opening hours, i.e. for the 3rd Thursday of each month.
The information available varies. Some museums state ideal hours or days when they generally have fewer visitors and are quieter, while others (such as MoPOP above) have specific dates and times that visitors can register for.
Some of the other tags, such as sensor:ambient_auditory, etc may be tricky to add - it’s variable through time, and would definitely need verification via an in-person visit?
What’s incorrect is, how can you interpret your description from sensory=yes alone? All this says is the feature has “sensory”. What does that mean? Having a Sensory Day is not the same, and is not expressed by sensory= either.
In fact, I would wonder if you did not read the proposal, which defines it “Parent tag of further sensory information”. That’s an unnecessary intermediary. It’s why I said it should be more specific.
You are conflating how this is useful info, vs whether sensory:friendly_hours= is a good tag. If =designated is unwanted despite being used in wheelchair= and many more, it can still be sensory_sensitivity:conditional=friendly @ (Th[3]) , or service_times:sensory_friendly= , etc.
Otherwise, the implication need to be considered. Does *:friendly_hours= mean it would be usable on other features, eg lgbtq:friendly_hours= ? On the contrary, quiet_hours= limits its effect. If *_hours= is to be an accepted format, it can simply be sensory_friendly_hours= , if not verbose.
A particular problem with your example is “Guests will get access to the Museum, during off-hours*”. opening_hours= needs to be treated together here.
Overall format-wise, considering sensory:auditory= , it should be sensory:*:max= and sensory:*:ambience= . This avoids creating multiple sensory:max_*= and sensory:ambient_*= .
The definition for the tag would need to be read, much like other keys with yes/no values. The current definition needs to be adjusted, but the key=value pair is fine in my opinion.
If @GA_Kevin would like to add a specific definition that’s fine, it’s their proposal, I am just weighing in. I am not about to edit it without discussion. “Parent tag of further sensory information.” is a description of the tag, not a definition of what is describes.
My suggestion would be for sensory=yes/no (other/unknown do not seem relevant, it only really matters if if it’s a yes or no in my opinion) would be to for sensory=yes to indicate that a POI/facility/amenity, etc has sensory accommodations/features/services.
I appreciate your concern, but I did read the proposal.
Do you have an alternative suggestion for sensory:friendly_hours=?
If it relates to opening hours then designated doesn’t tell a map user anything - what are those hours? We are talking about a new tag for a different purpose, so opening hours isn’t relevant here.
Quiet hours was proposed and isn’t widely used, so I am not sure why you mention it here. Sensory:friendly_hours as a concept makes more sense, given that there are more sensory triggers than sound alone, therefore sensory:friendly_hours fits better than quiet_hours and is more specific to the purpose. Otherwise, quiet_hours could be interpreted as only related to noise or even foot traffic.
A good tag should not be open to interpretation, it should be specific to the purpose, and what information is being conveyed.
Please suggest alternatives rather than roadblocks, I encourage all readers to be constructive, not restrictive, dismissive, or otherwise. This is interesting and important information that could be added to the map.
Very ironic you say it “should not be open to interpretation, it should be specific to the purpose, and what information is being conveyed”. I can’t see how sensory=yes meets that standard. A criteria not mentioned here is being intuitive. Providing sensory-friendly services is not the same as providing sensory-stimulating functionalities, as found in playground= + sensory= now.
Regardless of you two’s definition in the end, a fundamental problem with sensory= is redefining it to be more useless and indirect than (if also not the opposite of) sensory=auditory with sensory=yes (what’s even its meaning on playground= equipment?) + sensory:auditory=yes , while providing no other significant benefits.
I have put out many alternatives already. Your claim of “roadblocks” , and hint of being “restrictive, dismissive”, are not constructive at all.
Let’s ping also the creator of the proposal for “quiet_hours” @b-unicycling.
There shouldn’t be a new proposal with exactly the same description, but just a different key without a common discussion.
Thanks for your input here, I agree the description and intent needs clarifying before this proposal goes to a vote and potential implementation. I have started a new topic on the talk page of this proposal regarding this and requesting community feedback.
RFC requested for the following from the talk page:
Through the discussion on the community forumn, it has occurred to me there is a uncertainty surrounding if the Proposal:Sensory tag should be used in a warning or accommodative sense. In the original proposal, it is written from a warning perspective, i.e. sensory levels that may be problematic to those with sensitivities to such. However, through discussion, and particularly this comment from PCarew_EG, it seems it can also be interpreted “to indicate that a POI/facility/amenity, etc has sensory accommodations/features/services.”
This raises the important distinction that should be made whether the consensus surrounding the sensory tag is a warning or accommodation. This is critically only applicable to the overall sensory=* tag as further subtags such as sensory:ambient_auditory=* have in their options ways to tag such as low level (quiet, for example) all the way to extreme (needing protection.)
I would like the community’s input before clarifying on the overall proposal prior to voting.
I think it’s a good point. Maybe it’s better not to piggyback on the existing sensory=* key but use a different key instead. When we encounter a wheelchair ramp leading to a wheelchair-accessible entrance, we might tag wheelchair=yes/limited on the entrance but not hazard=incline.
How about sensory_friendly=* (fitting the usual term) or sensory_accommodation=*?
I quite like the suggestion of sensory_friendly, however would that make more sense as a conditional then? sensory_friendly:auditory:conditional=loud; quiet @ Mo-Su 08:00-10:00 “Sensory-friendly hours”
Seems rather long for a tag and I think I’d still prefer the proposed sensory friendly hours and just replace the top line sensory with sensory_friendly which would clarify it’s a positive for those who have sensitivity to such not ambiguous.
