Add more guidance for the "Accessible" field

[sandbergja]

Scope / difficulty

This would probably require some thorough conversations, but then be technically relatively simple to implement.

Impact

I suspect that there is currently a lot of bad data in this field, making it less useful for people to find an accessible restroom.

Rationale

Many users add bathrooms to Refuge Restrooms, but are unsure about how to assess whether or not a restroom is accessible. Sometimes accessible bathrooms have a physical sign labeling them as accessible, but it's also not uncommon for a business to mistakenly label an inaccessible bathroom as accessible.

If users have some more guidance in answering this question, I supect the data will start becoming a lot more useful.

Proposal

Currently, the new restroom form (https://refugerestrooms.org/restrooms/new) has a dropdown menu labeled "Accessible". This has two options: Accessible and Not accessible.

I would like to propose that this form include some simple guidance on what it means for a bathroom to be considered accessible. Perhaps a short checklist that the user could use to identify any common access issues?

Alternatively, the form could have a different way of asking about accessibility, asking users to check boxes for specific information.

How to actually do this:

Have a discussion about it to identify the best solution! And in that discussion, we should prioritize feedback from people with disabilities whose access needs are not met by inaccessible bathrooms.

[DeeDeeG]

Hi @sandbergja, thanks for the suggestion.

I would like to see what we can do about this. Possibly link to some ADA guidelines? I know I sometimes wonder if I can identify an accessible restroom properly myself.

I think the good-to-have features are:

• that you can get into the building, and from there into the restroom, in a wheelchair. No stairs required. No odd things that would block a wheelchair, or such a small restroom you can't wheel the chair in and still close the door.
• Hand rails by the toilet for transferring in/out of chair.
• Nice to have a mirror angled so it points at seated height, rather than flat with the wall which only works if you're standing. Edit to add:
• Sink isn't too tall to use seated. Clearance under sink for legs.
• Nice if there is a braille sign.
• Once source says door handles should ideally be levers, not round doorknobs.

But I'd be happy to do some more research. And if there's a nice link, I think we should be able to actually insert the link on the page.

(Thanks for filling out all the parts of the form!)

Adding more fields is possible, but would have to discuss it first with the team. If we do go about adding more checkboxes/fields, or in deciding what guidelines to link to, would IMO be great to do a shout-out to people on twitter and see if they have any suggestions.

[DeeDeeG]

I'm surprised there isn't much that's super concise on the web, at least that I can find right away. Should be reasonably easy (for the technical half of it) to add a page of our own explaining the guidelines for accessibility. Which we could link to from the New Restroom form if that's the direction we go with things.

Would want to translate such a pages as well, to the various languages we have supported so far.

Edit to add: This is a start, though I wish it were more official, and didn't have ads on it. Want to have something that we can either use or do better than. So here's something, anyway: https://www.thebalancesmb.com/ada-construction-guidelines-for-accesible-bathrooms-844778

Edit 2: A couple more that are more geared toward building a restroom than assessing an existing one... https://www.hgtv.com/design/remodel/bathroom-remodel/bathrooms-with-disability-access https://homeguides.sfgate.com/building-handicapped-bathroom-49003.html

[DeeDeeG]

Hi again, it has been a while!

Some basic takeaways I can name:

• Doorways should actually be wide enough for a wheelchair user to go through.
• Enough turning space that the wheelchair user may wheel in to the relevant spaces, turn, close the door and have privacy.
• Accessible facilities within reach: toilet has space around it to transfer from chair to toilet. Grab bars are in a reasonable location. Soap and water can reasonably be used from a seated position. If there are mirrors, at least one mirror should be angled to face a person at seated height.

There are some more perspectives direct from wheelchair users/folks with other disabilities speaking for themselves on YouTube: https://www.youtube.com/results?search_query=wheelchair+bathroom

We still haven't reached out on Twitter yet. (@mi-wood @tkwidmer if one of you would like to post about this, we are looking for input on guidelines -- what people who look for accessible restroom want to have ffor a restroom to qualify as a good "accessible" restroom.)

[Joranhezon]

Hey, I'd like to work on this issue!

How about instead of a webpage with these informations, we added a hover feature to the Accessible option, with some guidelines? Or maybe an info button next to it. I don't know how much information we would add to a page, so I don't know which would be better(Maybe even an info button and a page).

[DeeDeeG]

Those sound like good ideas! The hover feature or info button does sound good, else I worry no-one will see it on a separate page! I think we have enough information to put something in, regardless of what format it takes. If you are okay with using filler text/nonsense, I would be glad to see some kind of technical solution to work with.

(Of course, if you know anyone who uses accessible restroom facilities, we'd like to hear from them... Haha. But we will figure something out to vet this information one way or another.)

[DeeDeeG]

If we have a lot of information, enough for a separate page, then I suppose a link inside the hover or info button popup. The info button itself sounds more accessible for those using a screen reader (text to speech software for interacting with a computer). So that's probabl better than a hover feature.

[Joranhezon]

Yeah, an info button does sound better considering that. I am totally okay working with filler text. Maybe put the info button to the right of the dropdown? The link inside the popup is also gret.

I'll start working on it right away. I'll also ask my friends if they know someone who uses accessible restrooms.

[DeeDeeG]

Thank you for working on this! If your friends have any input that would be appreciated.

Edit: To the right of the dropdown sounds fine. I suppose floating within the margin between the dropdown and the edge of the viewport/screen. So as to keep the dropdowns at the width they already are. (They are pretty narrow on phones, for example.)

Edit 2: I suppose we want it to appear as a question mark button: (?) or [?]. Or an "i" for "info" button: (i) [i].

[arielrezinn]

What's the status on this? I'd love to implement it!

[DeeDeeG]

Hello @arielrezinn thank you for the offer. I have been the most active maintainer here for a bit, though other folks may chime in if they have a spare moment or two.

The todos for this are (as I picture it):

• Work on and finalize some text to use (should be appropriate to the actual needs of users of accessibility features in restrooms)
• Come up with a technical implementation
  • Perhaps add a simple page, similar in structure to the "about" or "business info"
  • Then link to that in some appropriate places
  • Or as was described above, add some popover/tooltip messages on the "new restroom" page

But perhaps the neater "contribution" for someone to work on would be the tech side of it. Bringing up a new page, adding some links. Or the popover option. [Edit: I see from your GitHub bio that you are studying disability rights. Could you help with ensuring the text/recommendations we make are reasonable? Are the proposed bullet points toward the beginning of this thread about right? Is there anything you would change, or add?]

I personally never got around to finishing the text. It feels like consulting with someone who uses the accessibility features is a missing piece to make the text acceptable in any case, so that has felt like a bit of a dead end as I'm not sure where to reach out.

Before this info would go live, I personally would like to hear from someone (ideally multiple people) who use accessibility features in the restrooms so we can be sure this is relevant advice. (On that subtopic, I wonder where is the balance is between getting it right vs "better than nothing"? Given that we can't necessarily instantly find someone to talk to us about this with our limited following on the social media sites. I personally don't have access to post on our socials, or I would have put a shoutout that we were looking for help on the info side of this issue.)

We are in general on a bit of a maintenance/"just keeping things going" mode, without a lot of time among the current maintainers for a lot of development hours. But I hope to respond to people with interest in contributing, as much as I can with limited time I can devote to this personally. I would try to set some time aside to see this through, but I can't really make guarantees.

P.S. I am away on a prior commitment for most of tomorrow, but I may (should) be around later in the day.

[DeeDeeG]

By the way, I hope this is a useful place to start: here is our about page: https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/app/views/pages/about.html.haml

(It's written in HAML, which is language for concisely typing out HTML, that also allows embedding Ruby code. We have a wiki article about HAML here: https://github.com/RefugeRestrooms/refugerestrooms/wiki/What-is-HAML%3F)

The actual text for the About page (technically: the English "translation system" strings) are all here: https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/locales/en/about.en.yml

(More information about the translation system can be found here: https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/locales/about_translations.yml).

So that's an example of a page in our app. If one wanted to copy that structure to make another page, I think that is a fine place to start.

[arielrezinn]

Thanks for getting back to me, that was quick! Here's what I'm thinking for a tentative game plan:

1. The bullet points above seem like a good place to start for the text on the page, but I don't have enough personal experience to make any decisions myself. However, I have a few contacts and resources (read: professors and classmates) that might be able to help with drafting the text! Scratch what I said earlier about wanting to get this all done in a day, I'll try to have a rough draft of the text ready by next weekend.

2. I agree that an info button linking to a new page makes the most sense and will likely be more screenreader-friendly, so I'll go that route. I'll get started on that and try to have it somewhat fleshed out by Tuesday, but it may take a little longer.

I appreciate the warm welcome, helpful links, and encouragement to contribute!

[arielrezinn]

A little update- there was a slight hiccup involving an indirect dependency archive (mimemagic). I just fixed and committed this to my branch, and am now going to get started!

Edit: here's a few links that will be helpful when generating the text! PISSAR Checklist I think this is a great** document to check out This is an article discussing the PISSAR checklist Checklist ADA Guide to Toilet Rooms ABA Guide to Toilet Rooms All ABA Guides

[arielrezinn]

I'm adding this comment solely as a reminder to myself :)

I need to run the tests and lint my code prior to opening the pr! Here's the link w/ details on how: https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/CONTRIBUTING.md

[DeeDeeG]

I heard about mimemagic but I didn't get around to seeing how we are affected. Sounds like it wasn't too much of a problem though! Thanks for taking care of that.

[arielrezinn]

I did some preliminary work and have pushed my changes, but I ran into an issue that I'm having trouble resolving myself, probably because I'm not super familiar with HAML. I have a gut feeling that it's something really small/easy that I'm missing.

Here's my branch! https://github.com/arielrezinn/refugerestrooms

And here's a picture of the error and offending file :)

[DeeDeeG]

I am rebuilding my Docker container, since I'm on an account on a borrowed laptop. For now I can look at the code and try to decipher the error.

This error is a little bit ambiguous to my eyes:

Psych::SyntaxError: (<unknown>): did not find expected key while parsing a block mapping at line 3 column 5

I'm not totally sure yet what that's about.

• I did notice that some files got moved! app/javascript/packs/ --> app/javascript/acc. Maybe the error is to do with not being able to load some JavaScript files?

• If it's not that, maybe it's string quoting in the translations (yml files). https://github.com/arielrezinn/refugerestrooms/blob/53380df48ae46be8319c82f3b1584307e715342d/config/locales/en/restroom.en.yml#L28

    accessible: 'Accessible <a href='/a11y'>What makes a restroom accessible?</a>'

This has nested quoting. Which can be like "outer: 'inner'" or 'outer: "inner"'. Alternating between single or double quotes is needed for nested quotes, so the parser doesn't think the quoted string ends early.

Otherwise, it might think this is the full quoted string: 'Accessible <a href='.

[mi-wood]

Cross-posting from slack, there's a single quote surrounded by single quotes in the last line.

p2: "Here's a collection of resources with information about accessible restrooms." should fix it.

[DeeDeeG]

In related news, I finally found a good reference for quoting rules in YAML, after looking for one for years. https://www.yaml.info/learn/quote.html

I went ahead and added that to the wiki page we have on translations. https://github.com/RefugeRestrooms/refugerestrooms/wiki/How-do-I-translate-Refuge-Restrooms.org%3F#quote-marks--and--in-the-translation-files

[skylerwharton]

Hi! I'm new to this project, and have been reading through some issues to get a feel for the project. I love this idea! Have you finalized the list of specific accessibility needs for restrooms? If not, I'd recommend Airbnb's Accessibility filters as an additional resource. I know they've done a lot of work, including user research, to refine their filters to make them more specific and useful for people who use wheelchairs or other mobility devices. (Please note though that I do not use a wheelchair or other mobility device, so I defer to the expertise of folks who do.)

Here are Airbnb's accessibility filters: (I've included a typed version of the text in the images after the two images.)

Accessibility needs Select features you'll need to make your trip comfortable and accessible. For more info, ask the host or go to the Accessibility section of the listing page. Wide entrances are at least 32in (81cm).

Entering the place

• No stairs or steps to enter
• Step-free path to entrance
• Wide entrance for guests
• Disabled parking spot - There's a parking spot that's been designated as suitable for a person with disabilities.

Bedroom

• No stairs or steps to enter
• Wide entrance

Bathroom

• No stairs or steps to enter
• Fixed grab bars for shower
• Step-free shower
• Wide doorway to guest bathroom
• Fixed grab bars for toilet
• Shower chair

Equipment

• Ceiling hoist

_(To find this list yourself, go to any page of search results on Airbnb.com (for example), click "More filters", scroll down to the "Accessibility" section within "More options", and click "Choose features of your place to stay".)_

Perhaps the items in the "Entering the place", "Bathroom", and "Equipment" sections could be relevant to this task?

Thoughts?

[arielrezinn]

This is super helpful, thank you!!

[skylerwharton]

Great!! You're welcome! :)

[Joseph-McGroarty]

Hi, I'm new here, I just came across this and I think I could help with getting requirements. I'm fairly involved with the disability community on twitter, so I could get feedback from a fairly wide variety of disabled people. (Also I do know some ruby and javascript so I could help with implimentation as well)

Based on what I know, I'm wondering if the "accessible/inaccessible" data field and search filters could be updated to have multiple true/false values for specific search criteria. Similar to the AirBNB check boxes above.

My thinking is that the binary in/accessible options a) create a lot of room for user error in entering data, b) leave disabled users with little confidence accessible-marked restrooms will actually be usable, and c) stop bathrooms which may be accessible to a subset of disabled users from showing up in their search (ex, a user needs no steps to get in, but doesn't need grab bars or clearance for a wheelchair - a bathroom exists near them that meets these criteria, but they don't see it in a search for "accessible" rooms because it's not fully wheelchair accessible)

I realize this might be a broader scope of update than was intended in the original issue, but I feel very strongly about the importance of this kind of accessibility and I'm willing to help out as much as needed.

[arielrezinn]

Awesome! I completely agree about the "accessible/inaccessible" boolean not being a great option! I reached out to some people in my circles (I study disability and computer science) and have included their feedback below. Some food for thought! We had recently been discussing the PISSAR Checklist, so you'll notice that a lot of people mention it. It is a little dated, but it's a starting place. The tl;dr of the feedback is that "accessible" means different things to each of us, depending on our disability.

Reflecting on the feedback, I think it would be worth our while to go back to the drawing board and get it approved with the long-term maintainers of Refuge Restrooms to add multiple check boxes or a multi-select field inspired by the Airbnb options.

@DeeDeeG What do you think?

---

Olivia R: I think something like checking boxes would be more useful information for someone who is looking for an accessible bathroom. It also begs the question who is the space deemed accessible to? There needs to be a range of specific options beyond accessible versus non-accessible.

Lauren L: Accessibility could cover a range of abilities/disabilities so who is to say if it is entirely accessible for all users?

Alicia C: I think the PISSAR checklist is a good starting point for helping to determine if a restroom is accessible or not, but I also think it is important to consider deaf individuals and if there may be a sign or something indicating whether the restroom is in use or not. A restroom could also include light settings, so individuals who are sensitive to light could adjust those settings. Since the current settings only shows accessible or inaccessible, I thought it would be important to include variations in between those two categories. The app could then show restrooms that are accessible for some functions and not others, and individuals could find bathrooms that are accessible to them, even if it may not be accessible to some other people.

Rebecca K: Because everyone doesn't have the same needs, what's accessible and inaccessible is up to an individual's opinion unless otherwise explained. I agree with Olivia that a checklist of accessibility (similar to the PISSAR checklist) would be much more inclusive.

Sierra S: The PISSAR checklist is a great start for accessibility but maybe the form itself should be changed (I’m talking about the form where people can submit accessible or not). Maybe there can be a rating system based upon how boxes it checks on the PISSAR checklist? Or the form can note who it is accessible for? (i.e. wheelchair accessible, etc..)

Hannah B: I'm surprised that Refuge Restrooms didn't already have a lot of information on how to determine what is considered an accessible bathroom, but I wonder if this is because everyone's interpretation of accessibility is different? I definitely don't think that's appropriate reasoning, but just trying to come up with a possible answer...

Alex M: I agree that the PISSAR checklist would be a great place to start. Is Github the only platform where people can leave reviews? If so maybe a comment or suggestion box should be developed so voices could be heard easier.

[DeeDeeG]

Thank you all for the continued input and research.

I can agree the AirBnB options seem like a good improvement. (I would like to move away from the "Accessible" checkbox as the main distinguishing data point for accessible restrooms, toward specific accessible features or qualities the location has.) The AirBnB data points are real-world tested, and strike a bit of a balance between including essential/basic granularity without being overwhelming.

---

More general thoughts:

We can skip "Bedroom" related data fields. (Not applicable to any public restrooms I can think of.) There are a few that are effectively redundant: We only need one of "step-free path" (starting from outside, all the way into the stall itself) and I think we combine this with "no steps to enter"? Likewise, I think we only need only need one "wide entrances/doors" (which in my mind would mean: starting from outside, through to entering the stall itself, all is wide enough for a wheelchair.) We can probably skip the shower-related ones... But at the same time, that info can be really really useful if you need it, and some restrooms are at like a YMCA/shelter/community center or similar, so I'm not sure how I feel about that at the moment. (Anyhow, "which check-boxes to include" is not a significant technical consideration, adding one is about as hard as adding twelve, so deciding which check-boxes to include can be delayed until late in the process if need be, and need not block developing a proof of concept implementation).

When folks are entering in a new restroom, I'd like to somehow encourage people to type up further info not reflected in the checkboxes, via the "description" or "directions" fields, as relevant. These descriptions/instructions are surfaced by the mobile apps, and by the web app, so folks can get a broader, free-form idea of what features the restroom has without us having to anticipate everything with checkboxes. (A question: Are full guidelines a good idea (As a popup, or on its own page)? Or should the advisory text be limited to strictly a small amount of info in the "Submit a new Restroom" page explaining how to submit good accessibility info?)

---

Technical overview of Refuge Restrooms (the web app):

I'd like to mention how Refuge works "under the hood"/technologically, which is useful for making a roadmap forward.

Refuge Restrooms is a few things (to simplify a bit) under the hood:

• A SQL database
• Various user interfaces to add, browse and search the listings. (To/from the database).
• A public API that enables additional interfaces to browse and search restrooms (notably used by the official Android and iOS apps). (This API is also backed by the database).

Note: For a smooth transition to the new data fields, I think the "Accessible" data field will have to stay technically in the database, for compatibility reasons and as legacy data, but we are free to de-emphasize it to the extent that it makes sense to in the UI. As there isn't a way for us to automatically and accurately populate new fields for older restrooms, and to avoid needing to update the mobile apps, the "Accessible" field can remain as a legacy field, but also as a fallback option for folks who might want to cast a wider net when searching for restrooms...

(Unfortunately in my experience, depending on where you are located, narrowing down to accessible options sometimes means "show no results," depending on the area and the comprehensiveness/quality of the restroom data. So being able to zoom out to "accessible to some kind of extent" might be useful in a pinch. And for some years now we have collected the "Accessible" data point, but these new fields would have very few entries at first. Or... maybe not? Thoughts on this? Should searching by "Accessible" be deprecated/removed from the web-app UI? And eventually the mobile apps?)

---

Draft implementation goals, broken into sub-tasks:

So I would say a successful implementation of the "AirBnB style"/split accessibility checkboxes would entail these sub-tasks:

• Add the new check-boxes to the "Add a restroom" interface
  • (Hide the "Accessible" checkbox? If so, I think we should set it automatically behind the scenes, based on whether there are one or more accessibility check-boxes checked. Or something like that. See note above for potentially deprecating the "Accessible" field.)
  • (Bonus: This updates the mobile apps, too; We don't have an upload API at the moment; The mobile apps lean on the "Add a restroom" page of the web app, via a webview.)
• Make sure the database is okay with handling the new, specific accessibility fields per restroom entry
  • Update the API definition a bit to reflect the new fields?
  • (Note: may not require changes? I am not a big databases or APIs person, personally, but I have seen those parts of the app's code before. Our API is written in Grape, FWIW.)
• Make sure that the various interfaces in the web app can handle/surface the new fields
  • Web app search (list view)
  • Web app search (map view)
  • Web app API demo page
• Watch for regressions/failures in the web app in general, as always
• Contact past translators and/or put out calls for translations for the new text/strings.
• Medium/long-term: Get the mobile app developers' attention and see if they can display, and make it possible to search/filter results by, the new accessibility criteria in the mobile apps.
• Documentation! (People like documentation!)
  • I think it could be neat to have a page that informs users how to interpret the check-boxes we have, and possibly link to more information on what makes a good restroom (such as the PISSAR checklist), to give folks a good idea of what to mention in the restroom's description, whether it has/doesn't have those features. "How to give good accessibility info" or something along those lines.
  • Alternatively, we could limit the info (for how to enter good accessibility information) to things we can display or embed in the "Add a new restroom" page, via always-showing normal text, and/or popups/tooltips?

[DeeDeeG]

For reference, here was the last pull request that added a data field to the whole Refuge Restrooms web app: https://github.com/RefugeRestrooms/refugerestrooms/pull/248

We can follow in those steps, though the app has been changed a bit overall since then.

(Edit to add: This PR also added some data fields more recently, but it was a more complicated PR with some things we wouldn't need to do for this -- i.e. for adding granular accessibility data fields: https://github.com/RefugeRestrooms/refugerestrooms/pull/487)

[DeeDeeG]

(Note: this is mildly off-topic, I guess.)

Is Github the only platform where people can leave reviews? If so maybe a comment or suggestion box should be developed so voices could be heard easier.

It just so hapens to be the most reliable way for feedback to reach me specifically.

We also have a contact page on the website, social media accounts (mainly Twitter, the Facebook is basically inactive), and Slack, which the other maintainers might be monitoring, but which I am not. (I don't have access to the email inbox the website's contact form goes to. I don't have login credentials to respond via the Twitter account, nor am I on Twitter in general. I don't monitor the Slack because it is very low traffic, and they somewhat frustratingly refuse to send out notification emails when someone messages the general channels, unless they have Direct Messaged or @mentioned a specific person, in which case that person will be notified... (Usually? Only if messaged during their configured "on"/"business" hours though, I think?).)

We are all basically pretty busy with other things and not pouring lots of time into Refuge, but the status of the project is still such that we are committed to keeping it up and running at bare minimum. When a good idea comes around with a will and a way to implement it, I try to encourage such efforts. It might not be speedy and buzzing with activity, but it's alive at least.

[Joseph-McGroarty]

Documentation! (People like documentation!)

I think it could be neat to have a page that informs users how to interpret the check-boxes we have, and possibly link to more information on what makes a good restroom (such as the PISSAR checklist), to give folks a good idea of what to mention in the restroom's description, whether it has/doesn't have those features. "How to give good accessibility info" or something along those lines. Alternatively, we could limit the info (for how to enter good accessibility information) to things we can display or embed in the "Add a new restroom" page, via always-showing normal text, and/or popups/tooltips?

I'd be happy to help with writting the documentation when the time comes.

[Joseph-McGroarty]

So here's my broad workflow for my end at the moment (if anyone wants me to change/add things, lmk)

1. Reach out to the disabled community seeking input on what they'd like from this update. This is mostly to ask about what checkboxes to include, as well as the few other considerations (see bellow) that they might have input on.
2. Structure that input into big ideas to translate into technical/project requirements. Meaning list of check boxes to include and potentially also other more technical details based on feedback
3. Present that structure back here

Then from there we'd move into discussion of how to impliment, work out any roadblocks, eventually getting to implimentation and documentation

Other condiderations I'd mentioned (which I'd like to get community feedback on as I think implimentation of them could heavily impact disabled users' experience of the change):

• balancing the specificity of information they like with desire to create a UI that doesn't overwhelm the user
• handling legacy use of the "accessible" boolean: eg should new entries auto fill this based on the new more specific check boxes? Should legacy bathroom entries marked "accessible" without further info show up in searches for specific accessibility criteria? etc

I'll aim to have step one done by early next week, then I don't think 2 and 3 should take me long from there

I'm thinking once the update is rolled out, it might be good to have some way to encourage users to help in updating legacy "accessible" bathrooms. Like a pop up message in the app/website banner or something like "hey, we changed this feature recently, you can help disabled users near you have accurate info by checking and updating legacy accessible bathrooms near you with more useful info." Cause I agree initially this change would face an issue of having very few data entries and I'm thinking user awareness is likely the fastest way to solve that

[Joseph-McGroarty]

OK just sent out tweets, will update when I get some responses back

[DeeDeeG]

Thanks for all this, hope it goes well. I'll consider any replies along with the things @arielrezinn heard from friends and colleagues etc.

Brief update and clarification regarding the mobile apps (In summary: we probably won't [be able to] update the iOS app to reflect these changes, since it (the iOS app) is deprecated).

I took another look at the iOS app recently, and I noticed that it can't really filter results at all. It only searches by location. (It tells you if a restroom is "accessible" in general and whether it's unisex or not. But there's no filtering.) So this update wouldn't technically mean much, other than reading the new data and surfacing some new icons/text about the new accessibility aspects of a given restroom. But it also reminded me (upon re-reading the popover message that shows upon app launch) that the iOS app is deprecated, so I don't expect that to be updated, really. It has some bugs that were never figured out or fixed, and the popover message advises folks to use the web app instead (Refugerestrooms.org). The iOS app has been deprecated/had its development paused for some time now, due to a lack of programming time from the previous developer, and no-one stepping in to maintain the existing codebase. (Context: We've had some offers to develop new iOS apps from scratch, but the other two web app/core maintainers and I were not able to really come to a conclusion on those, and discussion sort of tapered off... No consensus or real game plan was reached there, and neither person really got a green light from us.) So, all told, I don't think updating the iOS app is realistic at this exact moment, unless someone steps in to revive the app (and all the hassle of dealing with the Apple App Store that goes with it) -- and assuming we reach consensus and make/greenlight some game plan there. So, any updates to mobile apps would probably be limited to the Android app, if that. Would need to reconnect with the Android developers if we have something to ship in the web app/main server.

[Joseph-McGroarty]

Update: so far I've only had two responses to my twitter queery. I think later today I'll RT again, maybe at a different time of day. Here's what I have so far:

Person 1:

Number of available stalls could be helpful. With a digestive disease, erm, time is of the essence — and so if you're going to try to pick which bathroom location you're going to, it's helpful to know which location is more likely to have an available stall.

Person 2:

I’d love there to be an option about space. Bathrooms with a wheelchair stall are often difficult to enter and get to the accessible stall, then the stall itself might not fit me and my service dog, making the whole thing useless. Also, weight of doors. [There may have been a second tweet to this, twitter makes it look like there is one but I can't see it if I click on the tweet, will update if I find that]

I also made a few polls to agregate opinions on some design decisions we'd talked about. Those only have one vote each so far, but at this point, the options chosen are: "use both checkboxes and the boolean accessible field," "have the accessible field still be checked by the user who submits the bathroom (not autofilled)," and "let user decide (when they're searching whether to include/exclude legacy bathrooms marked 'accessible' without further detail)"

I'd also thought of two things on my own that I thought would be useful: 1) Whether the bathroom has paper towels, hand blow dryers, or both: autistic people and other ppl with various kinds of sensory processing differences can sometimes have a very hard time dealing with the noise and skin-sensation of blow dryers 2) Whether there's a menstral product dispenser (and if so if it's free or paid)

[Joseph-McGroarty]

No new responses since last update, but I took the liberty of gathering the feedback we've gotten so far into a rough list of requirements. I'll loosely group them by type of access need (bellow). I think tommorow I'll review this with fresh eyes and also start looking exploring how the code side works. In the meantime lmk if anyone has thoughts/additions/corrections/etc. Thoughts especially invited wrt wheelchair/mobility section

SENSORY

• hand drying options: (paper towels, hand blow dryer, both)
• toilet flushes: (automatically, manually)
• type of lighting: (flourescent, natural, other)
• lights can be turned off: (true/false)

MISC

• pad dispenser: (paid, free, no)
• tampon dispenser: (paid, free, no)
• number of 'accessible' all-gender toilets in location: (NUMBER): number of 'inaccessible' all gender toilets in location: (NUMBER)
• kind of fosset handles: (lever, automatic, seperate knobs)

WHEELCHAIR ACCESS/OTHER MOBILITY RELATED DISABILITIES For wheelchair accessibility ratings, what I've gathered from the feedback we've gotten plus the PISSAR checklist is that there's a fairly long list of specific criteria wrapped under wheelchair accessibility. That in itself is fine, my concern is more that many of the criteria as they're listed in the PISSAR questions ask about specific size measurements in inches - I'm guessing most Refuge users who submit new bathrooms aren't carrying tape measures around with them. So there's a question of how to ask users about wheelchair accessibility in a way that they can get an easy visual guage of.

My thought here is that most people can sort of recognize at a glance if something like a sink or other amenity looks to be at wheelchair height, and we could maybe include a parenthetical in the question if necessary givng an inch measurement. But the question itself could look something like this:

Wheelchair accessible ammentiies: check boxes to indicate these amentities are at a wheelchair accessible height and not blocked by obstacles a wheelchair couldn't manuver around: toilet(17-19in), sink (countertop <34in), soap dispenser(reach <48in), tampon dispenser(reach <48in), pad dispenser(reach <48in), seat cover dispenser(reach <48in), mirror(bottom of mirror <40in)

Then there's a few additional wheelchair/mobility related questions:

• if there's a wheelchair-height sink, are the pipes covered to prevent burns? (yes, no)
• is there enough space for a wheelchair to fit in the bathroom?
• are all doorways needed to get into the building wide enough for a wheelchair (32in minimum)?
• can get from outside of building to toilet without steps: (no steps, just a few steps, staircase)
• grab bars by the toilet: (yes, no)
• how does the door open: (sliding latch, small turn knob, large turn knob with lip, automatic/button, other)
• does the door close automatically: (yes, no)